Respuesta

En la historia del análisis de sistemas, una de las tareas más difíciles es identificar y formalizar requisitos no evidentes, vagos o ocultos. A menudo, el cliente no puede explicar con claridad lo que necesita o utiliza términos sin revelar sus expectativas reales.

Características clave:

• Los requisitos implícitos se identifican a través de análisis, escucha activa, preguntas aclaratorias, entrevistas y observación.
• La formalización se realiza en un lenguaje que sea comprensible tanto para el cliente como para los desarrolladores (por ejemplo, utilizando user stories, escenarios BPMN).
• Es necesario documentar y acordar las formulaciones aclaradas con el cliente para evitar ambigüedades.

Historia de la cuestión

El problema de los requisitos no formalizados es conocido desde los primeros proyectos de implementación. Inicialmente, se utilizaban entrevistas simples, ahora también se aplican mapeo de historias de usuario, prototipado y facilitación.

Problema

Los requisitos implícitos llevan a una formulación incorrecta de las tareas, esfuerzos laborales innecesarios y conflictos entre las partes.

Solución

Utilizar técnicas de entrevista, visualización (mapas de procesos, prototipos), facilitación y documentación clara de los resultados. Verificar la retroalimentación después de cada etapa de formalización de requisitos.

Preguntas engañosas.

¿Se pueden formalizar todos los requisitos por adelantado antes de comenzar el proyecto?

No, muchos requisitos se aclaran e identifican a medida que se trabaja en el prototipado y la clarificación del proyecto.

¿Deben registrarse solo los deseos expresados explícitamente por el cliente?

No, el analista debe trabajar también con las expectativas implícitas, analizar los objetivos comerciales e identificar necesidades ocultas.

¿Es la tarea del analista de sistemas solo traducir requisitos en un documento técnico?

No, el analista también es responsable de la formalización, acuerdo y aclaración de requisitos, así como de identificar contradicciones.

Errores típicos y anti-patrones

• No documentar los acuerdos intermedios.
• Considerar todos los requisitos igualmente importantes.
• Documentar solo lo que se dice explícitamente, sin analizar los procesos reales.

Ejemplo de la vida real

Caso negativo:
El analista registró todo lo que dijo el cliente en el proyecto sin aclarar detalles. Ventajas: el desarrollo comenzó rápidamente, ahorro de tiempo en el análisis.
Desventajas: muchas retrabajos, conflictos con el cliente debido a expectativas incorrectas.

Caso positivo:
El analista creó prototipos, llevó a cabo sesiones de aclaración y documentó requisitos implícitos junto con el cliente.
Ventajas: alta precisión en los requisitos, cliente satisfecho, menos conflictos.
Desventajas: costos en facilitación y recopilación de retroalimentación.