Requisitos funcionales y no funcionales

Ejemplos de requisitos funcionales y no funcionales

Consideremos un sistema en el que un fallo se define como el incumplimiento de un plazo por parte de una determinada funcionalidad. En este caso, lo correcto sería capturar la naturaleza sensible al tiempo de la función como un requisito básico del sistema, es decir, incluir el plazo dentro de la definición de requisitos y, por tanto, considerarlo un requisito funcional.
Obsérvese que el requisito funcional impone una restricción concreta que puede utilizarse posteriormente para evaluar la implementación mediante un criterio de aprobado/desaprobado. El requisito no funcional no tiene tales implicaciones en el diseño/implementación del sistema.

Diferencia entre requisitos funcionales y no funcionales en forma de tabla

En ingeniería de sistemas e ingeniería de requisitos, un requisito no funcional (NFR) es un requisito que especifica criterios que pueden utilizarse para juzgar el funcionamiento de un sistema, en lugar de comportamientos específicos. Se contraponen a los requisitos funcionales, que definen comportamientos o funciones específicas. El plan de aplicación de los requisitos funcionales se detalla en el diseño del sistema. El plan de implementación de los requisitos no funcionales se detalla en la arquitectura del sistema, ya que suelen ser requisitos importantes desde el punto de vista arquitectónico[1].
A grandes rasgos, los requisitos funcionales definen lo que debe hacer un sistema y los no funcionales cómo debe ser. Los requisitos funcionales suelen tener la forma de «el sistema debe hacer <requisito>», una acción individual o una parte del sistema, quizá explícitamente en el sentido de una función matemática, una descripción de caja negra de entrada, salida, un modelo funcional de proceso y control o un modelo IPO. En cambio, los requisitos no funcionales tienen la forma de «el sistema debe ser <requisito>», una propiedad global del sistema en su conjunto o de un aspecto concreto y no una función específica. Las propiedades globales del sistema suelen marcar la diferencia entre el éxito o el fracaso del proyecto de desarrollo.

Diferencia entre requisitos funcionales y no funcionales en ingeniería de software

El objetivo final de un proyecto es entregar un producto de alta calidad exactamente como lo pidió el cliente. Los requisitos funcionales son la principal forma en que el cliente comunica sus requisitos al equipo del proyecto. Los requisitos funcionales ayudan a que el equipo del proyecto vaya en la dirección correcta.
Unos requisitos poco claros conducen a un alcance mal definido que crea muchos problemas desde el principio del proyecto. Un alcance mal definido conduce a la ampliación del calendario y al aumento de los costes. El cliente puede no tener tiempo ni dinero para invertir, por lo que se limita a aceptar un producto de baja calidad.
Normalmente, el cliente tiene tanto necesidades como deseos. Después de ver la estimación de costes, puede pedir que se reduzca el alcance. Por lo general, eliminar algunos de los requisitos no funcionales reduce el alcance. Una gran cantidad de requisitos no funcionales puede aumentar rápidamente el coste, mientras que unos requisitos no funcionales insuficientes pueden dar lugar a una mala experiencia de usuario.
Comprender la diferencia entre requisitos funcionales y no funcionales ayudará tanto al cliente como al proveedor de TI, ya que podrán entender sus requisitos con claridad. Esto conduce a un refinamiento del alcance, un coste optimizado y, finalmente, un cliente satisfecho.

Requisitos funcionales y no funcionales de un juego

Al igual que muchas profesiones, el mundo de la ingeniería y la gestión de proyectos tiene sus propios «términos de arte» que pueden resultar confusos tanto para los expertos como para los novatos. Mientras revisa su documento de requisitos, puede preguntarse cuál es la diferencia entre un requisito funcional y un requisito no funcional. ¿Es importante esta diferencia? A continuación detallaremos por qué la diferencia es importante, y profundizaremos en cómo generar y escribir estos requisitos utilizando las mejores prácticas.
En última instancia, usted quiere entregar el producto que el cliente pidió. Los requisitos funcionales son la principal forma en que el cliente comunica sus necesidades al equipo. Hacen que todos los miembros del equipo del proyecto vayan en la misma dirección. Sin un documento de requisitos funcionales acordado que defina claramente el ámbito de aplicación, es probable que el producto final no dé en el blanco.  Entregar inicialmente un alcance equivocado es claramente un problema, pero también crea otros problemas. Para corregir el alcance, el calendario se amplía y el coste aumenta. Es posible que el cliente no tenga tiempo ni dinero para corregir los errores, así que los acepta y considera que su producto tiene defectos de calidad.  Sin embargo, no todo el alcance es igual de importante. Normalmente, el cliente tiene tanto necesidades como deseos. Después de ver la estimación de costes, puede pedir que se reduzca el alcance. A menudo, los ejercicios de reducción del alcance se centran en los requisitos no funcionales. Un exceso de requisitos no funcionales puede aumentar rápidamente el coste, mientras que unos requisitos no funcionales insuficientes dan lugar a malas experiencias de los usuarios.  Conocer la diferencia entre requisitos funcionales y no funcionales ayudará tanto al cliente como al proveedor a entender sus necesidades en profundidad, lo que llevará a un mejor refinamiento del alcance, a la optimización del coste y, en última instancia, a un cliente satisfecho.