Elicitación de requerimientos: 5 buenos hábitos
Los requisitos, como los sistemas que pretenden crear, pueden ser bastante complejos.
Esta complejidad emana de sus dependencias, naturaleza dinámica y los entornos en los que deben implementarse, que suelen estar cargados de limitaciones políticas, económicas y tecnológicas, por mencionar algunas.
Un requisito no existe de forma aislada y, a menudo, depende de uno o más requisitos. Por ejemplo, un requisito puede ser necesario o redundante debido a otro. Se espera que los BA detecten estas dependencias como parte de la gestión de requisitos para evitar el desperdicio de los recursos limitados de la organización.
Además, los requisitos por su propia naturaleza son dinámicos: cambian con el tiempo. Un excelente requerimiento hoy puede volverse fácilmente redundante en el futuro si las circunstancias o el entorno requieren ese requerimiento. Las empresas que adoptan una cultura de mejora continua son más proactivas y, por lo tanto, están más capacitadas para adaptarse a las necesidades cambiantes de las empresas.
Los requisitos también varían según el actor con el que se relacione. Por eso es importante identificar a los interesados que pueden hacer o deshacer su proyecto desde el inicio.
Aunque la obtención de requisitos mejora con el tiempo y la experiencia, tomar nota de esta recopilación de consejos y prácticas recomendadas garantizará que se mantenga al tanto de ellos desde el primer momento y que los requisitos que obtenga reflejen las necesidades comerciales reales.
Visualizar
Tenga en mente la visión del producto final cuando obtenga los requisitos. La visualización es una técnica poderosa que debes aplicar tanto como sea posible. Le ayudará a identificar qué preguntas formular a las partes interesadas y proporcionará un marco de referencia a partir del cual se pueden extraer los requisitos.
Aunque algunos argumentarían que las BA no deberían participar en el diseño del sistema, el proceso de visualización se puede lograr cuando se crea una imagen mental de "cómo" se podría implementar el requisito.
Alcance
Asegúrese de que el alcance del proyecto esté debidamente documentado.
No hay nada que pueda descarrilar un proyecto más rápido que excluir los requisitos que deberían estar dentro del alcance o incluir los requisitos que no están dentro del alcance de lo que debería implementarse.
Saber cuál es el alcance definido y aplicarlos frente a las partes interesadas con intereses y opiniones divergentes son dos cosas diferentes. El BA no necesita trabajar solo, sin embargo. El rol del gerente de proyecto involucra la administración del alcance, mientras que el patrocinador asegura que los objetivos del proyecto estén claros desde el principio. Cuando estas partes clave están alineadas, es mucho más fácil identificar los requisitos que deben tratarse con menos prioridad.
Participar
Es importante asegurarse de que las partes interesadas relevantes estén involucradas en todas las etapas del proyecto. Desarrolle un plan de comunicación que garantice que las partes interesadas estén informadas regularmente de los cambios que se esperan. Seamos realistas, los interesados son humanos.
Es posible que no comprendan de inmediato las implicaciones completas de un cambio inminente hasta que se acerque la fecha de vigencia, aunque tarde en el día. Para reducir la magnitud de la sorpresa y evitar los requisitos faltantes, la licenciatura debe involucrar a las partes interesadas activamente, validar los requisitos con la mayor frecuencia posible y señalar lo que crea que falta.
Los requisitos también deben ser revisados por el equipo técnico para garantizar que puedan implementarse dentro de los límites de la tecnología disponible. Para que los requisitos se implementen con éxito, el BA debe aprender a encontrar el equilibrio adecuado entre los requisitos en conflicto.
Modelo
Use modelos para aumentar su comprensión de lo que se necesita. Con el tiempo, descubrí que mientras se usa el texto para representar los requisitos, al mostrar estos mismos requisitos a través de otros modelos, por ejemplo, diagramas de procesos de negocios o incluso el uso de maquetas, se revelan otros aspectos de los requisitos que no se habrían identificado de forma inmediata a través del texto solo. Lo mismo se aplica a las partes interesadas y al equipo técnico. Los diferentes modelos se centran en diferentes aspectos de los requisitos y deben utilizarse para complementarse entre sí. Por ejemplo, un diagrama de relaciones de entidades sería más atractivo para el equipo de desarrollo que para un diagrama de casos de uso, con el que los actores comerciales pueden relacionarse más fácilmente.
Simplificar
Los requisitos que son "superfluos" deben eliminarse para garantizar que la simplicidad se mantenga.
Además, las BA deben garantizar que sus requisitos y diseños resultantes sean prácticos, ¿se utilizarán realmente en escenarios de la vida real? Si bien un requisito puede parecer necesario y factible en el punto de obtención, puede que no sea práctico implementarlo. Por ejemplo, supongamos que está creando un software de archivo que implica especificar criterios de búsqueda obligatorios para encontrar un documento. Un criterio de búsqueda como "período de retención", aunque útil como atributo de documento, no es tan práctico como "tipo de documento" o "fecha del documento".
Los analistas de negocios desempeñan un papel relevante en la determinación de qué funcionalidad debe o no debe tener un sistema. Si puede hacer estas preguntas de cada requerimiento, la solución implementada tendrá una mayor posibilidad de aceptación:
- Visión: ¿Cómo funcionará el sistema para cumplir con este requisito?
- Alcance: ¿Este requisito está dentro del alcance de lo que el proyecto pretende lograr?
- Participar: ¿He discutido este requisito con TODAS las partes interesadas relevantes?
- Modelo: ¿He presentado este requisito de una manera que sea fácil de entender para TODOS?
- Simplifique: ¿Es este requisito necesario y práctico?¿Qué otros hábitos crees que deberían tener los analistas de negocios al administrar y obtener los requisitos?