Un analista de negocio efectivo utiliza tanto técnicas estándar como entrevistas, encuestas y sesiones de lluvia de ideas, así como métodos más avanzados para identificar necesidades ocultas: observación de procesos de trabajo (job shadowing), creación de mapeos de procesos actuales (análisis AS-IS) y análisis de quejas/errores en el sistema vigente. Además, se aplican técnicas de "los cinco porqués" y modelado de escenarios (storyboarding), que permiten llegar al fondo de los problemas que los stakeholders pueden ni siquiera sospechar.
Características clave:
¿Se puede limitar solo a entrevistas con los principales stakeholders?
No, las entrevistas a menudo iluminan tareas evidentes, pero los problemas reales solo se manifiestan al observar a los usuarios y analizar incidentes.
¿Las necesidades ocultas deben estar necesariamente especificadas en la descripción de requisitos?
Sí, es necesario formalizarlas; de lo contrario, el equipo no las implementará: hay que traducir patrones ocultos en tareas claras.
¿Se puede considerar que los requisitos no expresados directamente no son obligatorios de implementar?
No, a menudo el éxito del proyecto depende en gran medida de qué tan bien el equipo consideró las expectativas y necesidades implícitas.
Caso negativo: El analista recopiló requisitos solo del jefe del departamento, sin analizar las quejas de los usuarios finales. Pros: El proyecto comenzó rápidamente, menos trabajo al inicio. Contras: La solución inicial no abordó la mayoría de los "dolores" reales del personal, se tuvo que hacer una costosa refactorización.
Caso positivo: El analista realizó observaciones de los usuarios, identificó "puntos de dolor" en los procesos y los tradujo en requisitos. Pros: La solución satisfizo a todos los usuarios desde el principio. Contras: Más tiempo y recursos en la fase de análisis.