En ingeniería de software e ingeniería de sistemas , un requisito funcional define una función de un sistema o su componente, donde una función se describe como un resumen (o especificación o declaración) de comportamiento entre entradas y salidas. [1]
Los requisitos funcionales pueden implicar 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 en el 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]
Como se define en la ingeniería de requisitos , los requisitos funcionales especifican resultados particulares de un sistema. Esto debe contrastarse con los requisitos no funcionales, que especifican características generales como el costo y la confiabilidad . Los requisitos funcionales impulsan la arquitectura de la aplicación de un sistema, mientras que los requisitos no funcionales impulsan la arquitectura técnica de un sistema. [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 → analizar → caso de uso → incorporar. Las partes interesadas hacen una solicitud; los ingenieros de sistemas intentan discutir, observar y comprender los aspectos del requisito; se crean casos de uso, diagramas de relaciones entre entidades y otros modelos para validar el requisito; y, si está documentado y aprobado, 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, de los cuales puede derivar los requisitos funcionales que deben implementarse para permitir que un usuario realice cada caso de uso.
Un requisito funcional típico contendrá un nombre y número únicos, un breve resumen y una justificación. Esta información se utiliza para ayudar al lector a comprender por qué se necesita el requisito y para realizar un seguimiento del requisito a lo largo del desarrollo del sistema. [7] El quid del requisito es la descripción del comportamiento requerido, que debe ser claro y legible. El comportamiento descrito puede provenir de reglas organizacionales o comerciales, o puede descubrirse a través de sesiones de obtención de información con usuarios, partes interesadas y otros expertos dentro de la organización. [7] Es posible que se descubran muchos requisitos durante el desarrollo del caso de uso. Cuando esto sucede, el analista de requisitos puede crear un requisito de marcador de posición con un nombre y un resumen, e investigar los detalles más adelante, para completarlos cuando sean más conocidos.