Respuesta.

Historia de la pregunta: En las primeras etapas del proyecto, el cliente a menudo formula requisitos vagos o contradictorios que el analista debe convertir en claros y verificables para su posterior implementación.

Problema: Los requisitos vagos llevan a una falta de coincidencia en la comprensión entre el negocio y el equipo de desarrollo, lo que aumenta la cantidad de devoluciones de tareas, errores y usuarios insatisfechos.

Solución:

Realización de talleres y sesiones de aclaración: el analista facilita una reunión con el cliente, utiliza técnicas de aclaración (Example Mapping, Event Storming, Story Mapping).
Uso de prototipos y wireframes: la modelización visual ayuda al negocio a expresar más precisamente sus expectativas.
Aclaración por etapas hasta los criterios de preparación (Definition of Ready): descomposición en subtareas, formalización de escenarios, recopilación de edge-cases.

Características clave:

La aclaración gradual es un proceso continuo que incluye ciclos de preguntas y rápidas verificaciones (feedback loop).
Involucrar a varios participantes para considerar diferentes puntos de vista.
El analista documenta opciones y limitaciones, incluso junto con requisitos "crudos".

Preguntas capciosas.

"¿Se puede confiar solo en las palabras del cliente al recopilar requisitos vagos?"

No, es importante usar ejemplos, diagramas, maquetas y hacer preguntas adicionales para identificar las verdaderas necesidades.

"¿Es suficiente acordar las aclaraciones de requisitos una sola vez?"

No, el acuerdo es un proceso iterativo: a medida que aparecen detalles, es necesario volver a acordar los requisitos.

"¿Siempre se pueden clarificar requisitos sin involucrar a los usuarios finales?"

No, la participación de usuarios reales a veces es crítica para identificar edge-cases y escenarios de uso que no son evidentes ni para el negocio ni para IT.

Errores comunes y anti-patrones

Intentar implementar un requisito vago sin formalización.
Ignorar las sesiones de aclaración.
Documentar requisitos solo en texto, sin visualización ni ejemplos.

Ejemplo de la vida real

Caso negativo: El cliente pidió un "mecanismo de búsqueda conveniente" — se documentó y se comenzó a implementar "como es habitual".

Ventajas:

Inicio rápido de la tarea.

Desventajas:

El resultado no satisfizo al usuario; se requería otra búsqueda y filtrado.

Caso positivo: En una tarea similar, el analista realizó un taller, recopiló escenarios de usuario y dibujó prototipos.