Respuesta.

El analista de negocios es responsable de la recopilación completa, la alineación y la documentación no solo de los requisitos funcionales, sino también de los requisitos no funcionales: velocidad de funcionamiento del sistema, seguridad, escalabilidad, disponibilidad, usabilidad de la interfaz. Para esto, trabaja en estrecha colaboración con los interesados (especialmente con el negocio y TI), utiliza escenarios y analiza estándares. Debe no solo recopilar expectativas explícitas, sino también identificar requisitos ocultos (por ejemplo, regulaciones sobre protección de datos). Al final, el analista formaliza los requisitos no funcionales en la documentación, los alinea con el equipo de proyecto y técnico, y también controla el cumplimiento de esos requisitos durante todo el proyecto.

Características clave:

• Identificación de requisitos ocultos y específicos a través de entrevistas y análisis de estándares
• Asegurar la documentación y alineación de los requisitos no funcionales
• Controlar la conformidad de la implementación con los criterios no funcionales acordados

Preguntas capciosas.

¿Es suficiente simplemente describir los requisitos no funcionales en texto sin métricas y concreciones?

No, las formulaciones abstractas ("rápido", "seguro") no son adecuadas para la validación. Se requieren parámetros claros: por ejemplo, el tiempo de respuesta no debe ser superior a 2 segundos.

¿Son los requisitos no funcionales únicamente preocupación de los técnicos?

No, el analista debe identificar y formalizar tales requisitos junto con el negocio, ya que su incumplimiento llevará a intereses clave del negocio insatisfechos.

¿Es posible aplazar el trabajo con los requisitos no funcionales hasta las etapas finales del proyecto?

No, tales requisitos son a menudo críticos para la arquitectura de la solución. Identificarlos en etapas tardías conduce a retrabajos y altos costos.

Errores típicos y anti-patrones

• Descripción implícita, formal o demasiado general de las características no funcionales
• Ignorar estándares de seguridad, SLA, requisitos legales
• Identificación tardía de requisitos no funcionales con el riesgo de retrabajos significativos

Ejemplo de la vida real

Caso negativo: Se describió en el TDR la "usabilidad" y "rapidez" esperadas, sin fijar métricas concretas. Ventajas: Menos costoso en el momento de redacción del documento Desventajas: No se pudieron presentar quejas al equipo cuando el resultado no cumplió con el pedido del cliente

Caso positivo: Acordado: "La velocidad de carga de la página es de hasta 2 segundos con una carga de hasta 1000 usuarios, nivel de SLA - 99,95%". Se formalizaron los requisitos de protección de datos personales. Ventajas: Verificación clara del resultado, reducción de riesgos de retrabajo, transparencia para todos los participantes Desventajas: Requirió tiempo y acuerdos con TI y abogados