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) del comportamiento entre entradas y salidas. [1]
Los requisitos funcionales pueden implicar cálculos, detalles técnicos, manipulación y procesamiento de datos y otras funciones 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, que se capturan en los 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]
Tal 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 → 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 crean casos de uso, diagramas de relación de entidad y otros modelos para validar el requisito; y, si se documenta y se 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á obteniendo un conjunto de casos de uso, de los cuales el analista puede derivar los requisitos funcionales que se deben implementar para permitir que un usuario realice cada caso de uso.
Un requisito funcional típico contendrá un nombre y un 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 clara y legible. El comportamiento descrito puede provenir de reglas organizacionales o comerciales, o puede descubrirse a través de sesiones de elicitación 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 de marcador de posición con un nombre y un resumen, e investigar los detalles más tarde, para completarlos cuando sean más conocidos.