El analista de negocios utiliza diversos métodos para identificar y documentar requisitos, en función de la especificidad del proyecto, la composición de los interesados y los resultados deseados. Los métodos incluyen entrevistas, talleres, observación, cuestionarios, análisis de documentación, prototipado y análisis de datos. La elección del método depende de factores como la complejidad de los requisitos, la disponibilidad de expertos e interesados, la madurez de los procesos de negocio y los presupuestos de tiempo.
La documentación de requisitos se lleva a cabo utilizando herramientas formalizadas (SRS, BRD, Historias de Usuario) y no formalizadas (mapas mentales, diagramas, esquemas). Es importante asegurar la claridad, la integridad, la trazabilidad y la actualidad de los requisitos en todas las etapas del proyecto. El analista de negocios elige el formato en función de la audiencia objetivo, la facilidad de mantenimiento y la especificidad del producto.
Características clave:
¿Cuál de los métodos de recolección de requisitos siempre es adecuado para proyectos de TI?
Ningún método es universal. Por ejemplo, las entrevistas son útiles en algunos casos, mientras que en un gran equipo distribuido, es más efectivo utilizar cuestionarios o análisis de documentación. Todo depende de la situación.
¿Se puede limitar a sólo historias de usuario para todos los tipos de requisitos?
No, las historias de usuario son buenas para proyectos ágiles, pero para sistemas de TI complejos se necesitan especificaciones técnicas, requisitos no funcionales y otros formatos.
¿Debería el analista de negocios documentar solo los deseos expresados del cliente?
No, el analista debe identificar requisitos ocultos y contradictorios, analizar las necesidades del negocio y justificar la viabilidad de implementar ciertas funciones.
Caso negativo: El analista recogió requisitos exclusivamente a través de un cuestionario, sin discutir los detalles con el equipo y el cliente. Como resultado, muchos requisitos resultaron irrelevantes. Pros: Se recopiló rápidamente una base de requisitos, Contras: Los requisitos se desactualizaron, no se identificaron tareas críticas y matices.
Caso positivo: El analista utilizó una combinación de talleres, entrevistas y prototipado, asegurando la validación de los requisitos desde el punto de vista técnico y de negocio. Pros: Requisitos precisos y consensuados, ajustes rápidos a lo largo del proyecto. Contras: Se requerían más recursos y tiempo para la sincronización.