Respuesta.

Historia de la pregunta:

Con el aumento de la complejidad de los proyectos de TI y el número de especialistas involucrados, surgió un problema: los interesados en el negocio exigen descripciones claras, mientras que el equipo técnico quiere detalles y precisión técnica. No existe un estándar universal, y históricamente el analista de sistemas se ha convertido en un "traductor" entre los mundos, adaptando el nivel de formalización de los requisitos según el público objetivo.

Problema:

El negocio tiene dificultades para leer diagramas y especificaciones, y no comprende los términos UML/BPMN. Por otro lado, a los desarrolladores no les bastan las historias de usuario y la visión general; necesitan criterios claros, diagramas, descripciones de API y formatos de datos. Si el analista elige un formato de requisitos incorrecto, surgen riesgos de malentendidos, descoordinación de funcionalidades y retrasos en los plazos.

Solución:

Identificar roles/personas clave entre las partes interesadas y realizar una serie de entrevistas o encuestas para conocer su experiencia, expectativas y necesidades.
Para el cliente empresarial: utilizar escenarios (historias de usuario), diagramas BPMN, glosarios de términos, maquetas y wireframes interactivos. Evitar la sobre-detalización en la medida de lo posible.
Para el desarrollo: preparar especificaciones técnicas estructuradas (SRS, diagramas de clases, diagramas ER, descripciones de API, criterios de aceptación) y asegurar una interpretación unívoca.
Para la implementación y pruebas: listas de verificación separadas, criterios de aceptación, casos de prueba y diagramas de interacción.

Clave: Formalizar el mismo conjunto de requisitos en un formato cómodo para cada grupo objetivo, evitando ambigüedades.

Características clave:

Adaptación del formato de requisitos a las competencias y expectativas del público
Uso de múltiples representaciones acordadas para los mismos requisitos
Elección de un "punto medio" entre la exhaustividad y la sobre-detalización

Preguntas engañosas.

¿Se puede tomar una plantilla SRS (Especificación de Requisitos de Software) y entregar a todos los participantes del proyecto sin cambios?

No. Un mismo documento no es efectivo para diferentes roles: un SRS será poco comprensible para el cliente empresarial, y el equipo de implementación puede carecer de los detalles necesarios. Los requisitos deben ser adaptados para cada audiencia específica.

A menudo se escucha: "Los diagramas BPMN y UML reemplazan completamente la descripción escrita de requisitos: ¿es esto cierto?"

No. Los diagramas son un poderoso complemento visual, pero siempre deben ir acompañados de explicaciones, ya que muchos interesados (especialmente en el negocio) no conocen las notaciones. Sin un bloque descriptivo, quedan muchos matices sin entender.

¿Se pueden mezclar requisitos empresariales y técnicos en una misma sección?

No se recomienda. Esto dificulta la búsqueda y comprensión de la información para diferentes roles y conduce a errores en la etapa de implementación. Es necesario estructurar la documentación claramente, diferenciando entre requisitos empresariales, especificaciones técnicas, expectativas no funcionales y criterios de aceptación.

Errores comunes y anti-patrones

Uso de un solo formato de requisitos para todos los roles
Sobre-detalización donde no es necesaria ("toneladas de diagramas" para el negocio)
Abuso de jerga profesional
Falta de un glosario de términos, lo que lleva a ambigüedades

Ejemplo de la vida real

Caso negativo

El analista preparó un enorme documento SRS de varias páginas en inglés, que contenía complicados diagramas UML. Los interesados en el negocio ni siquiera lo abrieron, y el equipo de implementación hizo suposiciones a ojo, resultando en defectos en la integración.

Ventajas:

Formalmente, toda la documentación estaba ahí

Desventajas:

El negocio no entendió las funciones
Muchos retornos y retrabajos
Los desarrolladores ignoraron parte de los requisitos

Caso positivo

Para el negocio, se creó una presentación con prototipos interactivos y términos empresariales clave; para el equipo técnico, una especificación técnica separada y un pipeline de API. La documentación se mantenía en Confluence con estados de discusión.