Requisitos no funcionales

Elaborado por: *Salomé Rodríguez Barletta*

Los **requerimientos no funcionales** representan características generales y restricciones de la aplicación o sistema que se esté desarrollando. Suelen presentar dificultades en su definición dado que su conformidad o no conformidad podría ser sujeto de libre interpretación, por lo cual es recomendable acompañar su definición con criterios de aceptación que se puedan medir (University of Toronto, s.f.).

## Como se clasifican

En un primer nivel estos pueden clasificarse en requerimientos de producto, organizacionales y externos.

En un segundo nivel, los requerimientos de producto pueden clasificarse en requerimientos de usabilidad, eficiencia, dependibilidad y seguridad. A su vez, los requerimientos organizacionales pueden clasificarse en requerimientos de entorno, organizacionales y de desarrollo. Asimismo, los requerimientos externos pueden clasificarse en requerimientos regulatorios, éticos y legislativos (University of Toronto, s.f.).

## Ejemplos de requerimientos no funcionales de producto

### **Eficiencia**

* Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en menos de 5 segundos.
* El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con sesiones concurrentes.
* Los datos modificados en la base de datos deben ser actualizados para todos los usuarios que acceden en menos de 2 segundos. (Cohn, 2022).

### **Seguridad lógica y de datos**

* Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador de acceso a datos.
* Todos los sistemas deben respaldarse cada 24 horas. Los respaldos deben ser almacenados en una localidad segura ubicada en un edificio distinto al que reside el sistema.
* Si se identifican ataques de seguridad o brecha del sistema, el mismo no continuará operando hasta ser desbloqueado por un administrador de seguridad (University of Toronto, s.f.).

### **Seguridad industrial**

* El sistema no continuará operando si la temperatura externa es menor a 4 grados Celsius.
* El sistema no continuará operando en caso de fuego (Ej. Un ascensor). (University of Toronto, s.f.).

### **Usabilidad**

* El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas
* El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario final.
* El sistema debe contar con un módulo de ayuda en línea.
* El sistema debe poseer interfaces gráficas bien formadas (University of Toronto, s.f.).

### **Dependibilidad**

* El sistema debe tener una disponibilidad del 99,99% de las veces en que un usuario intente accederlo.
* El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 5 minutos.
* El sistema debe tener una disponibilidad del 99,99% de las veces en que un usuario intente accederlo.
* El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 5 minutos. (Cohn, 2022).

### **Otros ejemplos de requerimientos de producto**

* El sistema será desarrollado para las plataformas PC y Macintosh.
* La aplicación debe ser compatible con todas las versiones de Windows, desde Windows 95.
* La aplicación no podrá ocupar más de 2 GB de espacio en disco.
* La interfaz de usuario será implementada para navegadores web únicamente con HTML5 y JavaScript (University of Toronto, s.f.).

## Ejemplos de requerimientos no funcionales organizacionales

* El procedimiento de desarrollo de software a usar debe estar definido explícitamente (en manuales de procedimientos) y debe cumplir con los estándares ISO 9000.
* Cada dos semanas deberán producirse reportes gerenciales en los cuales se muestre el esfuerzo invertido en cada uno de los componentes del nuevo sistema.
* El sistema debe ser desarrollado utilizando las herramientas CASE XYZ.
* Debe especificarse un plan de recuperación ante desastres para el sistema a ser desarrollado (University of Toronto, s.f.).

## Ejemplos de requerimientos no funcionales externos

* Sistemas de datos médicos: El nuevo sistema y sus procedimientos de mantenimiento de datos deben cumplir con las leyes y reglamentos de protección de datos médicos.
* El nuevo sistema se acogerá a las reglas de las licencias generales públicas (GNU), es decir será gratuito, código abierto en el que cualquiera podrá cambiar el software, sin patentes y sin garantías.
* El sistema no revelara a sus operadores otros datos personales de los clientes distintos a nombres y números de referencia (University of Toronto, s.f.).

## Acerca de los requerimientos no funcionales

Los requerimientos no funcionales suelen expresarse de una manera general y sin hacer referencia a algún modulo, transacción o característica del sistema, pues sino pasarían a ser **requerimientos funcionales**. Por ejemplo: *El sistema debe asegurar que los datos estén protegidos del acceso no autorizado*

Los requerimientos no funcionales pueden a su vez derivar en requerimientos funcionales, tomando como ejemplo el anterior: *El sistema incluirá un procedimiento de autorización de usuarios, en el cual los usuarios deben identificarse usando un nombre de usuario y contraseña. Sólo los usuarios autorizados de esta forma podrán acceder a los datos del sistema.* Escrito de esta forma, el requerimiento pasa a ser funcional. Sin embargo, no todos los requerimientos no funcionales pueden derivarse en requerimientos funcionales, por lo cual es muy importante definir los criterios de aceptación (University of Toronto).

## Referencias

Cohn, M. (2022). Non-functional Requirements as User Stories. *Mountain Goat Software*. https://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories

University of Toronto. (s. f.). *Lecture 18: Non-Functional Requirements (NFRs)*. Department of Computer Science. https://www.cs.toronto.edu/~sme/CSC340F/2005/slides/18-NFRs.pdf