Los requerimientos no funcionales describen condiciones de calidad, restricciones y características que el sistema debe cumplir. No indican una función específica como "registrar cliente" o "generar reporte", sino cómo debe comportarse el sistema al ofrecer sus funciones.
Un sistema puede tener todas las funciones solicitadas y aun así ser inaceptable si es lento, inseguro, difícil de usar, poco disponible, imposible de mantener o incapaz de crecer.
Por eso, los requerimientos no funcionales son esenciales para definir la calidad esperada del producto.
Podemos definirlos así:
Estos requerimientos suelen estar relacionados con rendimiento, seguridad, usabilidad, disponibilidad, confiabilidad, mantenibilidad, escalabilidad, accesibilidad, compatibilidad y cumplimiento normativo.
Los requerimientos funcionales describen qué debe hacer el sistema. Los no funcionales describen cómo debe hacerlo o bajo qué condiciones debe funcionar.
| Funcional | No funcional relacionado |
|---|---|
| El sistema debe permitir iniciar sesión. | Después de 5 intentos fallidos, la cuenta debe bloquearse durante 15 minutos. |
| El sistema debe permitir consultar productos. | La consulta debe responder en menos de 2 segundos para catálogos de hasta 50.000 productos. |
| El sistema debe generar reportes de ventas. | Los reportes deben poder exportarse en PDF y conservarse durante 5 años. |
| El sistema debe permitir registrar reclamos. | La pantalla de registro debe poder usarse desde teléfonos móviles. |
Ambos tipos de requerimientos se complementan y deben analizarse juntos.
Los requerimientos no funcionales son importantes porque afectan directamente la aceptación y utilidad del sistema.
Si se ignoran, pueden aparecer problemas como:
Muchos de estos problemas son caros de corregir si se descubren tarde.
Los atributos de calidad son características que permiten evaluar qué tan bueno es un producto de software en distintos aspectos.
| Atributo | Pregunta principal |
|---|---|
| Rendimiento | ¿Responde en tiempos aceptables y usa recursos razonablemente? |
| Seguridad | ¿Protege datos, accesos y operaciones sensibles? |
| Usabilidad | ¿Puede ser usado con facilidad por sus usuarios? |
| Disponibilidad | ¿Está operativo cuando se lo necesita? |
| Confiabilidad | ¿Funciona de manera estable bajo condiciones previstas? |
| Mantenibilidad | ¿Puede modificarse, corregirse y evolucionar sin esfuerzo excesivo? |
| Escalabilidad | ¿Puede crecer ante más usuarios, datos o transacciones? |
| Accesibilidad | ¿Puede ser usado por personas con distintas capacidades y dispositivos? |
El rendimiento describe qué tan rápido responde el sistema y cuántos recursos consume. Puede medirse mediante tiempos de respuesta, cantidad de transacciones, uso de memoria, uso de procesador o volumen de datos soportado.
Ejemplos de requerimientos de rendimiento:
Frases como "el sistema debe ser rápido" no son suficientes porque no indican cómo medir el rendimiento.
La seguridad se relaciona con proteger datos, usuarios, permisos y operaciones. Incluye autenticación, autorización, confidencialidad, integridad, auditoría y protección frente a accesos indebidos.
Ejemplos:
La seguridad debe considerarse desde el inicio, no agregarse solo al final.
La usabilidad indica qué tan fácil, eficiente y comprensible es el sistema para sus usuarios. Un sistema puede ser funcionalmente correcto, pero difícil de usar.
Ejemplos de requerimientos de usabilidad:
La usabilidad debe analizarse según los usuarios reales y su contexto de trabajo.
La disponibilidad indica cuánto tiempo el sistema debe estar operativo. La confiabilidad indica qué tan estable y correcto debe ser su comportamiento durante el uso.
Ejemplos:
Estos requerimientos son críticos en sistemas donde una interrupción afecta operaciones importantes.
La mantenibilidad expresa qué tan fácil será corregir, adaptar y mejorar el sistema después de su entrega. Aunque parece un tema interno del equipo técnico, puede afectar costos y evolución del producto.
Ejemplos:
Un sistema poco mantenible puede volverse caro y riesgoso, aunque al principio funcione correctamente.
La escalabilidad describe la capacidad del sistema para crecer ante más usuarios, datos, operaciones o carga de trabajo.
Ejemplos:
La escalabilidad debe definirse según expectativas reales. Pedir escalabilidad ilimitada no es útil ni verificable.
La accesibilidad busca que el sistema pueda ser usado por personas con distintas capacidades, dispositivos y condiciones de uso. La compatibilidad indica en qué ambientes, navegadores, sistemas operativos o dispositivos debe funcionar.
Ejemplos:
Estos aspectos afectan la experiencia real de uso y deben considerarse al definir el producto.
Algunos sistemas deben cumplir leyes, normas, contratos o políticas internas. Estos requerimientos pueden ser no funcionales o restricciones, según cómo se expresen.
Ejemplos:
Cuando hay cumplimiento normativo, conviene involucrar a áreas legales, auditoría o seguridad desde el inicio.
Un problema común es redactar requerimientos no funcionales de forma vaga. Para que sean útiles, deben poder verificarse.
| Redacción débil | Problema | Redacción más medible |
|---|---|---|
| El sistema debe ser rápido. | No indica operación, carga ni tiempo esperado. | La búsqueda de productos debe responder en menos de 2 segundos para hasta 50.000 productos. |
| El sistema debe ser seguro. | No define controles concretos. | El sistema debe bloquear la cuenta durante 15 minutos luego de 5 intentos fallidos de inicio de sesión. |
| El sistema debe ser fácil de usar. | No indica tarea, usuario ni criterio observable. | Un usuario administrativo capacitado debe poder registrar una inscripción completa en menos de 5 minutos. |
| El sistema debe estar siempre disponible. | "Siempre" no es realista ni verificable. | El sistema debe estar disponible el 99,5% del tiempo durante días hábiles de 8 a 18 horas. |
Los requerimientos no funcionales influyen fuertemente en decisiones de arquitectura y diseño. Por ejemplo, alta disponibilidad, seguridad estricta o gran volumen de datos pueden requerir decisiones técnicas distintas a las de un sistema pequeño de uso interno.
Algunas decisiones afectadas por estos requerimientos son:
Por eso deben conocerse temprano. Si aparecen tarde, pueden obligar a rediseñar partes importantes del sistema.
Los atributos de calidad pueden entrar en tensión. Mejorar uno puede afectar otro.
Ejemplos:
Estos conflictos deben discutirse con interesados para decidir prioridades realistas.
Para un sistema de pedidos, los requerimientos funcionales podrían indicar registrar pedidos, consultar stock y generar reportes. Los no funcionales agregan condiciones de calidad:
Estas condiciones pueden cambiar completamente el esfuerzo necesario para construir la solución.
Al trabajar con requerimientos no funcionales, suelen cometerse estos errores:
Algunas buenas prácticas son:
Los requerimientos no funcionales definen la calidad esperada del sistema. Sin ellos, el equipo puede construir funciones correctas pero insuficientes para el contexto real de uso.
La clave está en expresarlos con precisión: qué atributo importa, en qué operación, bajo qué condiciones y cómo se verificará. Esto permite diseñar, construir y probar con expectativas compartidas.
En el próximo tema estudiaremos las reglas de negocio y las políticas de la organización, que muchas veces condicionan directamente el comportamiento del sistema.