Respuesta.

Historia del tema:

Inicialmente, el enfoque al formalizar requisitos estaba en las características funcionales, pero con el tiempo se hizo evidente que los criterios "invisibles" a primera vista (rendimiento, seguridad, tolerancia a fallos, etc.) son cruciales para la implementación exitosa y la viabilidad de los productos. Ignorarlos conducía a fallos y comportamientos impredecibles del software después de su lanzamiento.

Problema:

A menudo, los requisitos no funcionales se fijan de manera estándar, sin estudiar el contexto. Se indican por la obligatoriedad o se forman de manera demasiado abstracta, por ejemplo: "El sistema debe ser conveniente" o "El sistema debe ser rápido". Esto no proporciona a los desarrolladores, arquitectos y testers un KPI claro.

Solución:

El analista de sistemas realiza sesiones con el negocio, TI y especialistas en operaciones para identificar restricciones reales, fija métricas numéricas (por ejemplo, SLA, TPS, indicadores de latencias), describe los requisitos no funcionales de manera explícita en las especificaciones y luego asegura su testabilidad mediante la vinculación con casos de prueba y artefactos arquitectónicos del proyecto.

Características clave:

Uso de características cuantitativas (¡medibles!).
Inclusión de una etapa de formalización y justificación a través de la alineación con expertos clave en TI.
Vinculación de requisitos con métodos de prueba.

Preguntas capciosas.

¿Se pueden dejar grupos de requisitos simplemente como "El sistema debe estar disponible 24/7" sin detalles?

No, es necesario aclarar los parámetros de disponibilidad (por ejemplo, 99.95%) y las condiciones de recuperación.

¿Es suficiente indicar "el tiempo de respuesta debe ser rápido"?

No, formulaciones como esta no funcionan. Es necesario indicar, por ejemplo: Tiempo de respuesta < 3 segundos para el 95% de las solicitudes con una carga X.

¿Están formalizados los requisitos no funcionales si solo están escritos en el pliego de condiciones sin más detalles?

No, deben descomponerse y vincularse con soluciones arquitectónicas y planes de prueba, de lo contrario, quedarán inejecutables o no validables.

Errores típicos y anti-patrones

Dejar formulaciones vagas que no permiten realizar pruebas.
Copiar indicadores requeridos de otros proyectos sin analizar la especificidad.
Ignorar consultas con TI/SRE y operaciones.

Ejemplo de la vida real

Caso negativo: El proyecto de e-banking se lanzó con el requisito de "disponibilidad 24/7, funcionamiento rápido", sin aclarar el SLA.

Ventajas:

Preparación rápida de requisitos.

Desventajas:

Fallos frecuentes, disputas irresolubles con el outsourcer.
Quejas de los clientes.

Caso positivo: El analista trabajó con el departamento de operaciones, fijó un 99.9% de tiempo de actividad, un tiempo máximo de respuesta de 2 seg, describió escenarios de degradación.