¿Qué es un requisito no funcional?

Los requisitos no funcionales o NFR describen características del software que no están definidas en términos de funcionalidad. Generalmente estos son atributos o restricciones del sistema que terminan con '-ilidad' o '-ilidades'. Por ejemplo:

  • mantenibilidad
  • escalabilidad
  • usabilidad

Tipos de requisitos no funcionales

Hay potencialmente docenas de tipos NFR. La importancia de cada tipo de NFR dependerá del tipo de software, el contexto y el caso de uso. Algunos de los tipos de NFR más comúnmente considerados son:

  • Seguridad
  • Actuación
  • Escalabilidad
  • Fiabilidad
  • Usabilidad
  • Legal
  • Mantenibilidad
  • Portabilidad

A lista completa de NFR está disponible en Wikipedia.

Seguridad: un caso especial

Vale la pena examinar más de cerca la seguridad como NFR. Aunque comúnmente se considera que la seguridad no es funcional, en realidad la mayoría de los requisitos de seguridad son funcionales. Por ejemplo, es probable que las comprobaciones de permisos antes de ejecutar un proceso sean un requisito funcional. En nuestros estudios, más de 90% de todos los requisitos de seguridad son funcionales.

Los beneficios de la detección automática de NFR

Los requisitos no funcionales son una dimensión importante del software. A menudo se pasan por alto o son de mala calidad (inespecíficos, incompletos o inconsistentes). Los NFR pueden tener un impacto significativo en el trabajo de entrega de un software. Descuidarlos puede generar un mayor riesgo para un proyecto.

Cuando utiliza ScopeMaster para analizar sus requisitos para posibles NFR, puede crear una lista de verificación para garantizar que los NFR estén cubiertos correcta y adecuadamente. Esto reducirá el riesgo para su proyecto. También desea evitar mezclar requisitos funcionales con no funcionales a menos que sea necesario hacerlo.

detección NFR, Automatizado

ScopeMaster escanea sus requisitos (o historias de usuario) en busca de pistas sobre requisitos no funcionales importantes.

Análisis CRUD con ScopeMaster: captura de pantalla

ScopeMaster analiza el texto de sus requisitos de software. Él detecta los requisitos no funcionales más probables desde dentro de cada requisito.

Determina una probabilidad de si cada requisito es o contiene un requisito no funcional.

Casos de uso de ejemplo

La mayoría de los NFR están “enterrados” dentro de otros requisitos y son difíciles de detectar. Los arquitectos a menudo tienen que examinar cientos de requisitos para intentar filtrar los NFR que podrían afectar la arquitectura de un sistema. Si no se identifican con suficiente antelación, se podrían tomar decisiones de diseño inapropiadas. Estas decisiones de diseño pueden generar costosas retrabajos o deuda técnica. La capacidad de ScopeMaster para detectar estos NFR desde el principio ayuda a exponerlos antes de que se haya realizado el trabajo de diseño. Casos de uso típicos:

  • Tiene muchos requisitos y está intentando detectar todos los NFR de una categoría en particular.
  • Tiene muchos requisitos y no está seguro de haber incluido algún NFR dentro de ellos.
  • Debe verificar si hay NFR potencialmente conflictivos
  • Varias personas han recopilado sus requisitos y necesita armonizar los NFR.

ScopeMaster detecta la fraseología probable a partir de los requisitos que pueden ser o inferir un requisito no funcional.

Requisitos no funcionales de calidad

¿Qué hace que los NFR sean de alta calidad? Siempre debes intentar cuantificar los requisitos no funcionales en términos cuantificables que tengan sentido para el equipo y con los que el cliente pueda identificarse. Estos deberían brindarle el “nivel de aceptabilidad” de cualquier NFR determinado. Por ejemplo, Todas las páginas web deben cargarse en 1,5 segundos, listas para que el usuario interactúe.  

Ejemplos de requisitos no funcionales

Aquí hay algunos ejemplos de NFR, tenga en cuenta la especificidad de cada uno. Se incluyen criterios inequívocos de aprobación/rechazo con cada uno:

Actuación – Todas las páginas web se cargarán para interactuar en 2 segundos con una conexión de 5 MB desde cualquier parte del mundo.

Capacidad – Con cambios insignificantes, el software debería poder hacer frente a 3 millones de registros de transacciones.

Legal – El sistema deberá cumplir con la legislación GDPR, incluida la capacidad de informar y/o eliminar registros personales sujetos a una solicitud específica.

Usabilidad – El sitio web deberá cumplir con WCAG 2.2 nivel A.