Gestión de requerimientos adentro

Hoy en día nadie duda que el desarrollo de aplicaciones y especificamente el desarrollo de aplicaciones de sistemas de información resultan bastante más complejos que ayer, hace un año, 10 o 20. De esta afirmación no hay dudas.
Casi todos los desarrollos padecen del riesgo de requerimientos inestables y/o requerimientos incompletos, e independientemente del ciclo de vida en el que este basado, en el proyecto tarde o temprano volvemos sobre un requerimiento ya pensados. 
Puede parecer que la causa de esto sea que el cliente no tenga claro que necesita o una baja capacidad del analista en entender lo que el cliente intenta transmitir, pero quizás en muchos casos sea que todos estamos aprendiendo cuales son los requerimientos verdaderos. Entonces no podemos dejar de volver ya que encontramos inconsistencias o mejoras a las luz de nuevos conocimientos.
Si a lo anterior le agregamos escala o volumen, equipos de varios analistas, múltiples actores y docenas de puntos de vista, no cabe duda que alguien debe tomar el toro por las astas y guiar el trabajo, esa guía debe realizarse a través de la aplicación de la gestión de los requerimientos.

Definición: Gestionar requerimientos CMMI
El propósito de la Gestión de requerimientos (REQM) es gestionar los requerimientos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requerimientos y los planes y productos de trabajo del proyecto.

Prefiero entender las gestión de los requerimientos de la siguiente manera:

1. identificar requerimientos, 
2. determinar las relaciones que existen entre ellos, 
3. evaluar el impacto de un cambio, agregado o eliminación de un requerimiento, 
4. visualizar el cambio de alcance del desarrollo o mantenimiento,
5. controlar completitud e inconsistencas respecto de un plan de proyecto / trabajo o cualquier sinónimo del mismo y respecto de requerimientos versus requerimientos.
6. mantener la trazabilidad de las relaciones entre ellos.
7. monitorear el desarrollo de los requerimientos a lo largo de todo el proyecto y vida del producto.

Para hacer gestión se necesita un responsable. El responsable no es el lider de proyecto bajo ningún término. El responsable de la gestión de requerimiento trabajará desde la definción de los requerimientos como un lider en el analisis y verificador cuando se avance sobre otras areas/fases de desarrollo. Su rol, si se quiere es el de guardián de requerimientos. El intentará protegerlos de la exageración, el fanatismo y del olvido del resto del equipo (incluido el cliente). Algo que invariablemente sucederá.

No hacer gestión de requerimientos solo genera tensiones inútiles, inconsistencias, olvidos e incompletitudes, perdida de tiempo y perdida del por qué o para qué se hace lo que se hace.
Si en tu proyecto "mediano" no hay un responable de gestion de requerimientos al menos, considera que tenés un riesgo con alta probabilidad de ocurrencia.
No ahorrés dinero donde no conviene.