Hispanopedia WikiEn ingeniería de software e ingeniería de sistemas , un requisito funcional define una función de un sistema o de sus componentes, donde una función se describe como un resumen (o especificación o declaración) del comportamiento entre entradas y salidas. [ 1 ]
Los requisitos funcionales pueden incluir cálculos, detalles técnicos, manipulación y procesamiento de datos, y otras funcionalidades específicas que definen lo que se supone que debe lograr un sistema. [ 2 ] Los requisitos de comportamiento describen todos los casos en los que el sistema utiliza los requisitos funcionales; estos se capturan en casos de uso . Los requisitos funcionales están respaldados por requisitos no funcionales (también conocidos como "requisitos de calidad"), que imponen restricciones al diseño o la implementación (como requisitos de rendimiento, seguridad o confiabilidad). Generalmente, los requisitos funcionales se expresan en la forma "el sistema debe hacer <requisito>", mientras que los requisitos no funcionales toman la forma "el sistema debe ser <requisito>". [ 3 ] El plan para implementar los requisitos funcionales se detalla en el diseño del sistema, mientras que los requisitos no funcionales se detallan en la arquitectura del sistema . [ 4 ] [ 5 ]
En ingeniería de requisitos , los requisitos funcionales especifican resultados particulares de un sistema. Esto contrasta con los requisitos no funcionales, que especifican características generales como el costo y la confiabilidad . Los requisitos funcionales determinan la arquitectura de la aplicación de un sistema, mientras que los requisitos no funcionales determinan su arquitectura técnica. [ 4 ]
En algunos casos, un analista de requisitos genera casos de uso después de recopilar y validar un conjunto de requisitos funcionales. La jerarquía de recopilación y cambio de requisitos funcionales, en términos generales, es: solicitud del usuario/ parte interesada → análisis → caso de uso → incorporación. Las partes interesadas hacen una solicitud; los ingenieros de sistemas intentan discutir, observar y comprender los aspectos del requisito; se construyen casos de uso, diagramas de entidad-relación y otros modelos para validar el requisito; y, si se documenta y aprueba, el requisito se implementa/incorpora. [ 6 ] Cada caso de uso ilustra escenarios de comportamiento a través de uno o más requisitos funcionales. Sin embargo, a menudo, un analista comenzará por obtener un conjunto de casos de uso, a partir de los cuales puede derivar los requisitos funcionales que deben implementarse para permitir que un usuario realice cada caso de uso.
Proceso
Una especificación típica de un requisito funcional contendrá un nombre y número únicos, un resumen breve, una justificación que describa la razón por la que es necesario, los requisitos de comportamiento o función, y referencias a casos de uso y otros requisitos relevantes para comprender este. Esta información se utiliza para ayudar al lector a comprender por qué se necesita el requisito y para realizar un seguimiento del requisito durante el desarrollo del sistema. [ 7 ] El núcleo del requisito es la descripción del comportamiento requerido, que debe ser clara y legible. El comportamiento descrito puede provenir de reglas organizacionales o de negocio, o puede descubrirse a través de sesiones de obtención de requisitos con usuarios, partes interesadas y otros expertos dentro de la organización. [ 7 ] Muchos requisitos pueden descubrirse durante el desarrollo del caso de uso. Cuando esto sucede, el analista de requisitos puede crear un requisito provisional con un nombre y un resumen, e investigar los detalles más adelante, para completarlos cuando se conozcan mejor.
Véase también
Referencias
- ↑ Fulton R, Vandermolen R (2017). «Capítulo 4: Requisitos - Redacción de requisitos» . Garantía de diseño de hardware electrónico aerotransportado: Guía práctica para RTCA/DO-254 . CRC Press. págs. 89–93 . ISBN 9781351831420Consultado el 15 de junio de 2018 .
- ↑ "Suplemento 4-A, Un procedimiento para el análisis de requisitos". Fundamentos de ingeniería de sistemas (PDF) . Gobierno de los Estados Unidos, Ejército de los EE. UU. 2001. ISBN 978-1484120835Archivado del original (PDF) el 31 de enero de 2017. Consultado el 18 de marzo de 2016 .
- ↑ Loucopoulos, P. (2005). «Capítulo 4: Ingeniería de requisitos». En Clarkson J, Eckert C (eds.). Mejora del proceso de diseño: Una revisión de la práctica actual . Springer-Verlag. pp. 116–139 . ISBN 9781846280610.
- 1 2 Adams, KM (2015). "3.2 Definiciones de requisitos funcionales y no funcionales". Requisitos no funcionales en el análisis y diseño de sistemas . Springer. págs. 45–50 . ISBN 9783319183442.
- ↑ Jönsson P, Lindvall M (2006). «Capítulo 6: Análisis de impacto». En Aurum A, Wohlin C (eds.). Ingeniería y gestión de requisitos de software . Springer Science & Business Media. pp. 117–142 . ISBN 9783540282440.
- ↑ Comunicaciones Corporativas y Asuntos Públicos de MITRE. «Ingeniería de Requisitos: Obtención, Recopilación y Desarrollo de Requisitos». La Guía de Ingeniería de Sistemas de MITRE . MITRE Corporation. págs. 304–313 . ISBN 9780615974422Consultado el 15 de junio de 2018 .
- 1 2 Stellman, Andrew; Greene, Jennifer (2005). «Capítulo 6: Requisitos de software» . Gestión de proyectos de software aplicada . O'Reilly Media. págs. 97–130 . ISBN 9780596553821Consultado el 15 de junio de 2018 .
- Requisitos de software
- Ingeniería de sistemas