Respuesta.

Historia de la pregunta:

Con el crecimiento en la escala y complejidad de los proyectos de TI, ha surgido repetidamente la situación en la que los requisitos del cliente de negocios llegaban en forma de deseos abstractos, que al ser transmitidos al equipo de desarrollo se convertían en algo diferente. La causa radica en la brecha en la terminología, expectativas y nivel de abstracción entre el negocio y TI.

Problema:

Si no se piensa en la etapa de descomposición, los requisitos se vuelven incompletos (se omiten detalles críticos), excesivamente vagos (es imposible evaluar y realizar) o se distorsionan debido a trampas léxicas, terminología no considerada y ambigüedades.

Solución:

El analista de sistemas descompone secuencialmente cada requisito: formaliza los términos de negocio, traduce los objetivos de negocio en funciones y tareas, describe escenarios de usuario y comportamiento del sistema, vincula a criterios de aceptación/casos de prueba. Es importante usar modelos (UML, BPMN), glosarios, listas de verificación y revisiones directas entre equipos.

Características clave:

Elaboración de un glosario de términos junto con el cliente
Uso de diagramas y formulaciones atómicas de requisitos
Traducción de requisitos al lenguaje de criterios de aceptación y casos de prueba

Preguntas con trampa.

¿Se pueden dejar los deseos de negocio en forma libre para su posterior desarrollo en la etapa de desarrollo?

No, hay un alto riesgo de malentendidos y errores de implementación.

¿Es necesario detallar la implementación (por ejemplo, cómo almacenar datos) en la etapa de análisis?

No, el análisis se refiere a "qué" y "por qué", no a "cómo". Los detalles técnicos son responsabilidad de la arquitectura y el desarrollo.

¿Siempre una entrada de requisito = un módulo/característica?

No, a menudo se requiere descomposición: requisitos grandes se dividen en sub-funciones e historias de usuario con criterios de aceptación separados.

Errores típicos y anti-patrones

Mezcla de lenguaje comercial y términos técnicos sin glosario
Descripción de requisitos en forma de "deseos vagos"
Violación de la atomicidad: un requisito contiene múltiples entidades diferentes

Ejemplo de la vida real

Caso negativo: El cliente envió una lista de deseos "El usuario debe ver toda la analítica de ventas", que se copió en el documento de requisitos sin cambios.

Ventajas:

Rapidez en la preparación de la documentación

Desventajas:

No está claro qué métricas específicas y en qué desglose son necesarias
Constantes modificaciones

Caso positivo: El analista preguntó al cliente, compuso una lista de métricas necesarias, definió los roles de los usuarios, desarrolló prototipos de reportes, acordó el glosario de términos.