Respuesta.

Historia del asunto:

En proyectos clásicos y ágiles, los requisitos para los artefactos analíticos difieren: en algunos casos se necesitan especificaciones detalladas y diagramas de clases, en otros son suficientes tablas o bocetos simples. Muchas organizaciones tienen sus propias plantillas, pero la verdadera utilidad de la documentación se determina por su relevancia y aplicabilidad.

Problema:

La falta de un conjunto estándar de artefactos lleva a la confusión ("¿qué dibujar y cuándo?"), y su exceso resulta en burocracia y documentación obsoleta que no utiliza el equipo. A menudo, los analistas crean artefactos "solo por cumplir" sin consultar a los desarrolladores y testers.

Solución:

Un analista de sistemas competente:

Realiza reuniones iniciales con el equipo y el cliente, indagando sobre sus problemas y formatos de artefactos convenientes.
Forma una matriz de responsabilidades (RACI) para la documentación: quién necesita qué artefacto, quién lo mantiene y en qué etapa.
Junto con el arquitecto y los líderes, decide dónde es necesario usar, por ejemplo, diagramas de clases (para lógica compleja), y dónde es suficiente un proceso BPMN o un mockup.
Constantemente aclara y revisa el conjunto de artefactos a lo largo del proyecto: la relevancia es más importante que la totalidad.

Características clave:

No hay un conjunto universal de artefactos: diferentes proyectos requieren documentos distintos.
La comunicación y el acuerdo mutuo son la base del éxito (shared ownership).
Cada artefacto debe resolver una tarea específica, ser dinámico y mantenido.

Preguntas capciosas.

¿Se puede usar solo un tipo de diagramas (por ejemplo, solo BPMN) para todas las situaciones?

No, cada tipo de diagrama o documento revela un aspecto diferente del sistema: BPMN para procesos, UML para objetos e interacciones, tablas para diccionarios. Combinarlos es la mejor práctica.

¿Siempre se necesita un documento detallado de especificaciones de requisitos?

No siempre. En startups, pilotos y proyectos ágiles (Agile), puede ser suficiente con documentos ligeros basados en el backlog: lo principal es que el equipo entienda las tareas.

¿Puede un analista exigir al equipo que siga su plantilla de documentación?

No. Los formatos y plantillas de documentación deben surgir en el proceso de discusión y acuerdo con el equipo y el cliente, y ser convenientes para todos los involucrados.

Errores comunes y anti-patrones

Copiar mecánicamente todo el paquete de documentos de otros proyectos.
Crear documentación "por crear documentación".
Ignorar la retroalimentación del equipo, negarse a trabajar con artefactos relevantes.

Ejemplo de la vida real

Caso negativo: Un analista de sistemas implementó 6 diagramas diferentes para cada proceso en un proyecto corporativo. El equipo se ahogó en la documentación, nadie la leía, trabajaban con tareas verbales.

Ventajas:

Deseo de formalizar el sistema a un alto nivel.

Desventajas:

Pérdida de tiempo, confusión.
Documentación inexacta en el momento de implementación.

Caso positivo: En otro proyecto, el analista documentó solo un esquema BPMN y una tabla corta de atributos, y los actualizaba regularmente a partir de las reuniones con los desarrolladores.