Requisito no funcional
Tipo de requerimiento en ingeniería de sistemas

En ingeniería de sistemas e ingeniería de requisitos , un requisito no funcional ( NFR ) es un requisito que especifica criterios que se pueden utilizar 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íficos. El plan para implementar 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 suelen ser requisitos arquitectónicamente significativos . [1]

En la arquitectura de software , los requisitos no funcionales se conocen como "características arquitectónicas". Nótese que la comunicación sincrónica entre los componentes arquitectónicos del software los entrelaza y deben compartir las mismas características arquitectónicas. [2]

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 , un modelo funcional de entrada, salida, proceso y control de descripción de caja negra o 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 si el proyecto de desarrollo ha tenido éxito o ha fracasado.

Los requisitos no funcionales se denominan a menudo " atributos de calidad " de un sistema. Otros términos para los requisitos no funcionales son "cualidades", "objetivos de calidad", "requisitos de calidad del servicio", "restricciones", "requisitos no conductuales" [3] o "requisitos técnicos". [4] De manera informal, a veces se los denomina "capacidades", a partir de atributos como la estabilidad y la portabilidad. Las cualidades, es decir, los requisitos no funcionales, se pueden dividir en dos categorías principales:

  1. Cualidades de ejecución, como seguridad, protección y facilidad de uso, que son observables durante la operación (en tiempo de ejecución).
  2. Cualidades evolutivas, como la capacidad de prueba , mantenibilidad, extensibilidad y escalabilidad, que están incorporadas en la estructura estática del sistema. [5] [6]

Es importante especificar los requisitos no funcionales de una manera específica y medible. [7] [8]

Ejemplos

Es posible que se requiera que un sistema presente al usuario una pantalla con la cantidad de registros en una base de datos. Este es un requisito funcional. La actualización de 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 el sistema sea capaz de mostrar el recuento de registros dentro de un intervalo aceptablemente corto a partir del cambio en la cantidad de registros.

Es posible que un sistema no tenga un ancho de banda de red suficiente. Otros ejemplos son:

Véase también

Referencias

  1. ^ 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.
  2. ^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . 2020. ISBN 978-1492043454.
  3. ^ Stellman, Andrew; Greene, Jennifer (2005). Gestión de proyectos de software aplicado. O'Reilly Media . p. 113. ISBN 978-0-596-00948-9. Archivado desde el original el 9 de febrero de 2015.
  4. ^ Ambler, Scott. "Requerimientos técnicos (no funcionales): una introducción ágil". Modelado ágil . Ambysoft Inc. Recuperado el 5 de octubre de 2018 .
  5. ^ Wiegers, Karl; Beatty, Joy (2013). Requisitos de software, tercera edición . Microsoft Press. ISBN 978-0-7356-7966-5.
  6. ^ Young, Ralph R. (2001). Prácticas de requisitos eficaces . Addison-Wesley. ISBN 978-0-201-70912-4.
  7. ^ Zimmermann, Olaf; Stocker, Mirko (2021). Repositorio de prácticas de diseño. LeanPub.
  8. ^ 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.
  • Petter LH Eide (2005). "Cuantificación y trazabilidad de 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 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 usuario?". Methodsandtools.com . Consultado el 3 de octubre de 2017 .
  • "Los requisitos no funcionales deben estar 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 requisitos extrafuncionales o no funcionales?". 19 de noviembre de 2020.
Obtenido de "https://es.wikipedia.org/w/index.php?title=Requisito_no_funcional&oldid=1251742712"