Type of requirement in systems engineering
En ingeniería de sistemas e ingeniería de requisitos , un requisito no funcional ( NFR ) es un requisito que especifica criterios que pueden usarse para juzgar el funcionamiento de un sistema, en lugar de comportamientos específicos. Se contrastan con 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 requisitos no funcionales se detalla en la arquitectura del sistema , porque generalmente son requisitos arquitectónicamente significativos . [1]
Definición
En términos generales, los requisitos funcionales definen lo que se supone que debe hacer un sistema y los requisitos no funcionales definen cómo se supone que debe ser un sistema . Los requisitos funcionales suelen tener la forma de "el sistema debe hacer <requisito>", una acción individual o parte del sistema, quizás explícitamente en el sentido de una función matemática , una descripción de caja negra de entrada, salida, proceso y modelo funcional de control o Modelo de salida a bolsa . Por el contrario, los requisitos no funcionales adoptan la forma de "el sistema será <requisito>", una propiedad general del sistema en su conjunto o de un aspecto particular y no de una función específica. Las propiedades generales del sistema comúnmente marcan la diferencia entre el éxito o el fracaso del proyecto de desarrollo.
Los requisitos no funcionales a menudo se denominan " atributos de calidad " de un sistema. Otros términos para requisitos no funcionales son "cualidades", "objetivos de calidad", "requisitos de calidad de servicio", "restricciones", "requisitos no conductuales" [2] o "requisitos técnicos". [3] Informalmente, a veces se les llama "ilidades", debido a 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 usabilidad, que son observables durante la operación (en tiempo de ejecución).
- Cualidades de evolución, como la capacidad de prueba , la mantenibilidad, la extensibilidad y la escalabilidad, que se materializan en la estructura estática del sistema. [4] [5]
Es importante especificar los requisitos no funcionales de forma específica y mensurable. [6] [7]
Ejemplos
Es posible que se requiera que un sistema presente al usuario una visualización del número de registros en una base de datos. Este es un requisito funcional. La actualidad que debe tener este número es un requisito no funcional. Si es necesario actualizar el número en tiempo real , los arquitectos del sistema deben asegurarse de que el sistema sea capaz de mostrar el recuento de registros dentro de un intervalo aceptablemente corto desde que cambia 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.
- Certificación
- Cumplimiento
- Gestión de configuración
- Conformidad
- Costo, costo inicial y de ciclo de vida
- Integridad de los datos
- Retención de datos
- Dependencia de otras partes
- Despliegue
- Entorno de desarrollo
- Recuperación de desastres
- Documentación
- Durabilidad
- Eficiencia (consumo de recursos para una carga determinada)
- Efectividad (rendimiento resultante en relación al esfuerzo)
- Elasticidad
- Factores emocionales (como diversión, absorción o factor "¡Guau!")
- Protección del medio ambiente
- Depósito
- Explotabilidad
- Extensibilidad (agregar funciones y transferir personalizaciones a la próxima actualización importante de la versión)
- Gestión de fallos
- Tolerancia a fallos (por ejemplo, supervisión, medición y gestión del sistema operativo)
- Flexibilidad (por ejemplo, para hacer frente a cambios futuros en los requisitos)
- Reducción de huella: reduzca el tamaño de los archivos exe
- Integrabilidad (por ejemplo, capacidad para integrar componentes)
- Internacionalización y localización
- Interoperabilidad
- Cuestiones legales y de licencias o evitabilidad de infracción de patentes
- Mantenibilidad (por ejemplo , tiempo medio de reparación – MTTR)
- Gestión
- Optimización de la memoria
- Modificabilidad
- Topología de la red
- Fuente abierta
- Operabilidad
- Rendimiento /tiempo de respuesta ( ingeniería de rendimiento )
- Compatibilidad de plataforma
- Privacidad (cumplimiento de las leyes de privacidad )
- Portabilidad
- Calidad (por ejemplo, fallas descubiertas, fallas detectadas, eficacia en la eliminación de fallas )
- Legibilidad
- Fiabilidad (por ejemplo , tiempo medio entre/hasta fallos – MTBF/MTTF)
- Informes
- Resiliencia
- Restricciones de recursos (velocidad del procesador, memoria, espacio en disco, ancho de banda de la red, etc.)
- Tiempo de respuesta
- Reutilizabilidad
- Robustez
- Seguridad o factor de seguridad
- Escalabilidad (horizontal, vertical)
- Seguridad (cibernética y física)
- Software, herramientas, estándares, etc. Compatibilidad
- Estabilidad
- Soportabilidad
- Capacidad de prueba
- Rendimiento
- Transparencia
- Usabilidad (factores humanos) por comunidad de usuarios objetivo
- Prueba de volumen
Ver también
Referencias
- ^ Chen, Lianping; Ali Babar, Mahoma; Nuseibeh, Bashar (2013). "Caracterización de requisitos arquitectónicamente significativos". Software IEEE . 30 (2): 38–45. doi :10.1109/MS.2012.174. hdl : 10344/3061 . S2CID 17399565.
- ^ Stellman, Andrés; Greene, Jennifer (2005). Gestión de Proyectos de Software Aplicado. Medios O'Reilly . pag. 113.ISBN _ 978-0-596-00948-9. Archivado desde el original el 9 de febrero de 2015.
- ^ Amblador, Scott. "Requisitos técnicos (no funcionales): una introducción ágil". Modelado ágil . Ambysoft Inc. Consultado el 5 de octubre de 2018 .
- ^ Wiegers, Karl; Beatty, alegría (2013). Requisitos de software, tercera edición . Prensa de Microsoft. ISBN 978-0-7356-7966-5.
- ^ Joven, 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, Martín (2008). "Un enfoque de los requisitos de calidad basado en el riesgo y orientado al valor" (PDF) . Software IEEE . 25 (2): 34–41. doi :10.1109/MS.2008.31. S2CID 19015424.
enlaces externos
- Petter LH Eide (2005). “Cuantificación y Trazabilidad de Requerimientos”. CiteSeerX 10.1.1.95.6464 .
- Dalbey, John. "Requerimientos no funcionales". Csc.calpoly.edu . Consultado el 3 de octubre de 2017 .
- "Modelado de aspectos no funcionales en arquitectura orientada a servicios" (PDF) . Cs.umb.edu . Archivado desde el original (PDF) el 24 de julio de 2011 . Consultado el 3 de octubre de 2017 .
- "Requisitos no funcionales: ¿realmente ayudan las historias de usuarios?". Methodsandtools.com . Consultado el 3 de octubre de 2017 .
- "Los requisitos no funcionales están aquí - CISQ - Consorcio para la calidad del software de TI". it-cisq.org . Consultado el 3 de octubre de 2017 .
- ""¿Las arquitecturas de software cumplen con requisitos extra funcionales o no funcionales? ". 19 de noviembre de 2020.