¿Cuántas veces hemos oído o leído que el principal factor de éxito o de fracaso de un proyecto está relacionado con la Gestión y Definición de Requisitos? Seguramente muchas… Sin embargo, son demasiadas las organizaciones que continúan sin dar el paso definitivo para solucionar sus problemas relacionados con la Ingeniería de Requisitos (IR). El motivo, sin duda, son algunos mitos que rodean a esta disciplina clave en el Ciclo de Vida de Desarrollo de Software. Analicemos algunos de ellos:
“Escribir requisitos es sencillo”. Del mismo modo que no todo el mundo es capaz de redactar un documento jurídico de forma correcta, escribir una especificación de requisitos requiere aplicar un conjunto de técnicas que a menudo se desconocen. Descubrir, seleccionar y aplicar técnicas de escritura de requisitos permitirá que nuestras especificaciones sean no ambiguas, factibles, completas, consistentes, verificables y fácilmente entendibles.
“Capturar requisitos es sencillo”. Al igual que aplicamos técnicas específicas para entrevistas de trabajo, la captura de requisitos requiere de la aplicación de técnicas maduras y probadas para garantizar que estamos capturando en su totalidad las necesidades de negocio y de los usuarios.
“Los requisitos siempre cambian. Tenemos que convivir con ello”. Cuanto mejor hayamos capturado las necesidades de un sistema, menos cambios sufriremos. Es evidente que siempre habrá cambios, pero el reto es saber gestionarlos, controlarlos, priorizarlos y estimar su impacto.
“Mi organización es CMMI L3. Eso nos garantiza ser buenos en requisitos”.
La madurez del proceso de desarrollo es independiente de la madurez en requisitos. Las prácticas de las áreas de proceso de REQM y RD de CMMI no cubren muchos aspectos clave de la IR y no entran en las técnicas a aplicar.
“Usamos SCRUM y no nos hacen falta los requisitos”.
Independientemente de la metodología de desarrollo que se utilice, es obvio que el primer paso es conocer bien las necesidades a implementar en el sistema. Recientes estudios indican que la probabilidad de éxito o fracaso de un proyecto poco tiene que ver con la metodología de desarrollo elegida, sino de la madurez en la IR de la organización.
“Documentar requisitos es gestionarlos”.
Documentar requisitos es únicamente una actividad de la IR, que por lo general es automatizada por las herramientas más maduras del mercado. La colaboración, el acceso concurrente y distribuido, la gestión del cambio individualizada del requisito, la gestión y análisis de la trazabilidad, la validación de la calidad semántica, etc… son difícilmente realizables cuando se trabaja con documentos como elemento de gestión.
“Hemos implementado una herramienta de Gestión de Requisitos. Todo solucionado”. Se lo dice un fabricante: no confíe en aquellos que les digan que implementar una herramienta soluciona todos los problemas de la IR. Primero, deberá de implementar un proceso basado en técnicas maduras y especializadas. La herramienta deberá de automatizar esas técnicas. Sazonemos con un poco de capacitación especializada y una buena gestión del cambio organizativo… y daremos con la receta correcta.
“Mi proceso de QA es maduro, eso garantiza la calidad del sistema entregado”.
El principal criterio de medición de la calidad de un sistema debería ser la satisfacción del usuario. Y no hay nada que odien más los usuarios que ver que el software no cumple sus necesidades y expectativas, por muy probado y libre de errores que esté.
“Hemos llegado a la conclusión de que estamos condenados a que los requisitos siempre tengan carencias”. ¡No se rinda tan pronto! Les puedo asegurar que un mundo mejor es posible. Para una enfermedad tan crítica y con tanto impacto en el negocio, lo mejor debería ser poner al enfermo en manos de profesionales especialistas … ¿no cree?
