Respuesta.

Históricamente, los proyectos de IT han centrado su atención en los requisitos funcionales: qué debe hacer el sistema. Mientras tanto, cuestiones como el rendimiento, la fiabilidad, la escalabilidad, la disponibilidad, la seguridad y el mantenimiento (características que se agrupan bajo el término "requisitos no funcionales", RNF) han quedado en un segundo plano y, a menudo, no se han formalizado en absoluto.

Problema

La ignorancia o la descripción formal de los RNF conduce a problemas significativos en la operación: el sistema no está preparado para las cargas esperadas, no resiste ciberataques, es complicado de mantener y escalar, o no está disponible para el número necesario de usuarios.

Solución

Un analista de sistemas moderno debe iniciar, formalizar, analizar y documentar los RNF. Esto incluye:

Interactuar con arquitectos, equipos de DevOps y de operación para identificar limitaciones tecnológicas e infraestructurales;
Recopilar requisitos del negocio (por ejemplo, según SLA);
Elaborar una lista exhaustiva de RNF con valores umbral específicos;
Implementar medidas de control durante la fase de implementación y soporte;
Documentar los requisitos en secciones separadas de las especificaciones.

Características clave:

Los RNF son obligatorios para cualquier proyecto grande.
Se definen conjuntamente con partes interesadas técnicas y comerciales.
Deben ser inequívocos, verificables y estar alineados con los objetivos del negocio.

Preguntas trampas.

¿Cuál es la diferencia entre "calidad del producto" y "requisitos no funcionales"?

La calidad del producto es un concepto más amplio que incluye no solo parámetros que se pueden formalizar, sino también evaluaciones subjetivas (por ejemplo, comodidad UX/UI). Los RNF son características claramente medibles (rendimiento, fiabilidad, etc.) que deben ser validadas automáticamente.

¿Puede un analista delegar la definición de todos los requisitos no funcionales a un arquitecto?

No, el analista debe, junto con el arquitecto y el negocio, identificar estos requisitos en la fase de análisis; de lo contrario, los requisitos serán incompletos o se describirán solo en términos técnicos, sin tener en cuenta las necesidades comerciales.

¿Se pueden formular requisitos no funcionales solo en forma de frases generales ("el sistema debe ser confiable")?

No, tales formulaciones son inapropiadas para el control y las pruebas. Se requiere una especificación más concreta: por ejemplo, "el tiempo de recuperación del servicio después de una falla no debe exceder los 10 minutos".

Errores comunes y anti-patrones

Formulación de requisitos sin criterios verificables ("rápido", "genial", "confiable").
Omitir clases enteras de RNF (por ejemplo, seguridad para sistemas internos).
Inconsistencia de requisitos entre el cliente y el soporte.

Ejemplo de la vida real

Caso negativo: El proyecto del portal nacional de servicios gubernamentales no formalizó los requisitos relacionados con las cargas máximas. El sistema "fallaba" en los días de lanzamiento de servicios populares, surgiendo incidentes de seguridad.

Ventajas:

MVP rápido

Desventajas:

Altos costos de mejoras
Pérdida de confianza de los usuarios
Dificultades en el soporte

Caso positivo: Un analista al inicio del proyecto de una fábrica de automatización industrial identificó junto con la operación que el tiempo de inactividad del sistema era más importante que nuevas funciones. Desarrolló el SLA, escenarios de emergencia y especificó métricas concretas.