Hispanopedia WikiEn ingeniería de sistemas e ingeniería de requisitos , un requisito no funcional ( RNF ) es un requisito que especifica criterios que pueden usarse para evaluar el funcionamiento de un sistema, en lugar de comportamientos específicos. Se diferencian de los requisitos funcionales , que definen comportamientos o funciones específicas. El plan para implementar los requisitos funcionales se detalla en el diseño del sistema . El plan para implementar los requisitos no funcionales se detalla en la arquitectura del sistema , ya que suelen ser requisitos arquitectónicamente significativos . [ 1 ] Algunos autores también denominan requisitos no funcionales como requisitos transversales. [ 2 ]
En arquitectura de software , los requisitos no funcionales se conocen como "características arquitectónicas". Cabe destacar que la comunicación síncrona entre los componentes arquitectónicos del software los interrelaciona, y deben compartir las mismas características arquitectónicas. [ 3 ]
Definición
En términos generales, los requisitos funcionales definen lo que se supone que debe hacer un sistema , mientras que los requisitos no funcionales definen cómo se supone que 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ás explícitamente en el sentido de una función matemática , una descripción de caja negra , un modelo funcional de entrada, salida, proceso y control ( modelo IPO ). Por el contrario, los requisitos no funcionales tienen la forma de "el sistema debe ser <requisito>", una propiedad general del sistema en su conjunto o de un aspecto particular, y no una función específica. Las propiedades generales del sistema suelen marcar la diferencia entre el éxito y el fracaso del proyecto de desarrollo.
Los requisitos no funcionales suelen denominarse " atributos de calidad " de un sistema. Las propiedades emergentes [ Nota 1 ] de un sistema se clasifican como requisitos no funcionales. Otros términos para los requisitos no funcionales son "cualidades", "objetivos de calidad", "requisitos de calidad de servicio", "restricciones", "requisitos no conductuales" [ 4 ] o "requisitos técnicos" [ 5 ] . De manera informal, a veces se les llama " cualidades ", por atributos como estabilidad y portabilidad. Las cualidades —es decir, los requisitos no funcionales— se pueden dividir en dos categorías principales:
- Cualidades de ejecución, como seguridad, protección y facilidad de uso, que son observables durante el funcionamiento (en tiempo de ejecución).
- Cualidades evolutivas, como la capacidad de prueba , la mantenibilidad, la extensibilidad y la escalabilidad, que se incorporan a la estructura estática del sistema. [ 6 ] [ 7 ]
Dado que los requisitos no funcionales son todos aquellos que no entran en la categoría de requisitos funcionales, también incluyen tanto características de las funciones como restricciones del sistema, tales como elementos no relacionados con el diseño, como normas, protocolos, requisitos legales, reglamentarios u otros requisitos externos.
Es importante especificar los requisitos no funcionales de forma específica y medible. [ 8 ] [ 9 ]
Clasificación de los requisitos no funcionales
Las clasificaciones no funcionales comunes, relevantes para todos los tipos de sistemas, incluyen [ 10 ].
- Actuación
- Fiabilidad, disponibilidad, mantenibilidad y seguridad
- Escalabilidad
- Capacidad de prueba
Ciertos tipos de sistemas enumeran explícitamente categorías de requisitos no funcionales en sus estándares.
- Sistemas de hardware
- Sistemas embebidos
- Sistemas críticos para la seguridad
- Sistemas de software
Ejemplos
Un sistema puede requerir mostrar al usuario el número de registros en una base de datos. Este es un requisito funcional. La frecuencia con la que debe actualizarse este número es un requisito no funcional. Si el número debe actualizarse en tiempo real , los arquitectos del sistema deben asegurarse de que este sea capaz de mostrar el recuento de registros en un intervalo de tiempo aceptablemente corto tras el cambio en el número de registros.
Un ancho de banda de red suficiente puede ser un requisito no funcional de un sistema. Otros ejemplos incluyen:
- Accesibilidad
- Adaptabilidad
- Auditabilidad y control
- Disponibilidad (ver acuerdo de nivel de servicio )
- Respaldo
- Tiempo de arranque
- Capacidad , actual y prevista
- Proceso de dar un título
- Cumplimiento
- Gestión de la configuración
- Conformidad
- Costo, costo inicial y costo del ciclo de vida
- Integridad de los datos
- retención de datos
- Dependencia de otras partes
- Despliegue
- Entorno de desarrollo
- Recuperación ante desastres
- Documentación
- Durabilidad
- Eficiencia (consumo de recursos para una carga determinada)
- Eficacia (rendimiento resultante en relación con el esfuerzo)
- Elasticidad
- Factores emocionales (como diversión, entretenimiento o un "factor sorpresa")
- Protección ambiental
- Depósito
- Ética
- Explotabilidad
- Extensibilidad (agregar funciones y conservar las personalizaciones en la próxima actualización de versión principal)
- Gestión de fallos
- Tolerancia a fallos (por ejemplo, monitorización, medición y gestión de sistemas operativos)
- Flexibilidad (por ejemplo, para hacer frente a futuros cambios en los requisitos)
- Reducción de huella: reduce el tamaño de los archivos ejecutables.
- Integrabilidad (por ejemplo, capacidad de integrar componentes)
- Internacionalización y localización
- Interoperabilidad
- Cuestiones legales y de licencias o evitabilidad de la infracción de patentes
- Mantenibilidad (por ejemplo, tiempo medio de reparación – MTTR)
- Gestión
- Optimización de memoria
- Modificabilidad
- Topología de red
- Código abierto
- Operatividad
- Rendimiento (velocidad, duración de la batería, rendimiento, tiempo de respuesta ( ingeniería de rendimiento ))
- Características físicas (tamaño, peso, potencia, refrigeración, etc.)
- Compatibilidad de la plataforma
- Privacidad (cumplimiento de las leyes de privacidad )
- Portabilidad
- Calidad (por ejemplo, fallos detectados, fallos en la entrega, eficacia en la eliminación de fallos )
- Legibilidad
- Fiabilidad (por ejemplo, tiempo medio entre fallos/hasta fallos – MTBF/MTTF)
- Informes
- Resiliencia
- Limitaciones de recursos (velocidad del procesador, memoria, espacio en disco, ancho de banda de la red, etc.)
- Tiempo de respuesta
- Reutilización
- Robustez
- Seguridad o factor de seguridad
- Escalabilidad (horizontal, vertical)
- Cronograma (gestión de proyectos) para el desarrollo y la entrega
- Seguridad (cibernética y física)
- Compatibilidad de software, herramientas, estándares, etc.
- Estabilidad
- Soporte
- Capacidad de prueba
- Rendimiento
- Capacitación
- Transparencia
- Usabilidad (factores humanos) por comunidad de usuarios objetivo
- Pruebas de volumen
Crítica
El término "requisito no funcional" es criticado por considerarse un nombre inapropiado que minimiza la importancia del conjunto de requisitos que abarca. [ 11 ] [ 12 ] En su lugar, se ha propuesto y adoptado en ThoughtWorks el término "requisito transversal" (CFR) . [ 2 ]
Véase también
Referencias
- ↑ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Caracterización de requisitos arquitectónicamente significativos". IEEE Software . 30 (2): 38– 45. doi : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 .
- 1 2 "Una década de requisitos multifuncionales (CFR) - Sarah Taraporewalla" . sarahtaraporewalla.com . Consultado el 8 de noviembre de 2025 .
- ↑ Richards, Mark; Ford, Neal (2020). Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media, Incorporated. ISBN 978-1492043454.
- ↑ Stellman, Andrew; Greene, Jennifer (2005). Gestión de proyectos de software aplicados . O'Reilly Media . pág. 113. ISBN 978-0-596-00948-9Archivado del original el 9 de febrero de 2015.
- ↑ Ambler, Scott. "Requisitos técnicos (no funcionales): una introducción ágil" . Modelado ágil . Ambysoft Inc. Consultado el 5 de octubre de 2018 .
- ↑ Wiegers, Karl; Beatty, Joy (2013). Requisitos de software, tercera edición . Microsoft Press. ISBN 978-0-7356-7966-5.
- ↑ Young, Ralph R. (2001). Prácticas efectivas de requisitos . Addison-Wesley. ISBN 978-0-201-70912-4.
- ↑ Zimmermann, Olaf; Stocker, Mirko (2021). Repositorio de prácticas de diseño . LeanPub.
- ↑ Glinz, Martin (2008). "Un enfoque basado en el riesgo y orientado al valor para los requisitos de calidad" (PDF) . IEEE Software . 25 (2): 34– 41. doi : 10.1109/MS.2008.31 . S2CID 19015424 .
- ↑ "Ingeniería de sistemas y atributos de calidad KA" . sebokwiki.org . Consultado el 24 de mayo de 2025 .
- ↑ "No creo en los NFR - Sarah Taraporewalla" . sarahtaraporewalla.com . Consultado el 8 de noviembre de 2025 .
- ↑ Newman, Sam (2015). Building microservices: designing fine-grained systems (1.ª ed.). Sebastopol, CA: O'Reilly Media. p. 151. ISBN 978-1-4919-5035-7.
Notas
- ↑ Véase la definición en el glosario de SeBoK
Enlaces externos
- Petter LH Eide (2005). "Cuantificación y trazabilidad de los requisitos". CiteSeerX 10.1.1.95.6464 .
- Dalbey, John. "Requisitos no funcionales" . Csc.calpoly.edu . Consultado el 3 de octubre de 2017 .
- "Modelado de aspectos no funcionales en la arquitectura orientada a servicios" (PDF) . Cs.umb.edu . Archivado del original (PDF) el 24 de julio de 2011. Consultado el 3 de octubre de 2017 .
- "Requisitos no funcionales: ¿Realmente ayudan las historias de usuario?" . Methodsandtools.com . Consultado el 3 de octubre de 2017 .
- "Requisitos no funcionales aquí - CISQ - Consorcio para la calidad del software de TI" . it-cisq.org . Archivado del original el 26 de septiembre de 2018. Consultado el 3 de octubre de 2017 .
- ""¿Las arquitecturas de software cumplen con los requisitos extrafuncionales o no funcionales?"" . 19 de noviembre de 2020.
- Requisitos de software
- Ingeniería de sistemas
- Calidad del software
