Gestión de requisitos antes que definición de requisitos

El modelo CMMI DEV en su representación por etapas establece REQM a nivel 2 de madurez antes que RD que aparece a nivel 3. Para el orden de implementación de las áreas de proceso, le da mayor prioridad a la gestión de requisitos que a la definición de requisitos. Esto es una duda, sino en todos, en la gran mayoría de los cursos de Introduction to CMMI.
En principio el modelo va de un proceso caótico y reactivo a un proceso de mejora continua definido, controlado y proactivo. En ese orden iniciamos poniendo orden a lo que se está haciendo para luego hacerlo mejor hasta intentar alcanzar la perfección o excelencia en lo que se hace.

REQM y RD, juntos pero no revueltos
Con REQM se establecen prácticas que permiten aceptar requisitos de fuentes autorizadas, acordar y comprometer los requisitos que se van a trabajar y en caso de necesitar modificaciones, con herramientas de análisis de impacto y control de los cambios, poder controlar lo que se está haciendo en el proyecto. Mientras esto no se haga se seguirán aceptando requisitos sin cumplir los criterios mínimos, incluyendo que vengan de una fuente autorizada o peor que se aceptan cambios que no han sido evaluados, lo que provoca que en el proyecto no se sepa lo que se está haciendo.
RD permite definir y evolucionar los requisitos durante el ciclo de vida del producto. Es la parte de ingeniería de requisitos que se complementa con la función de gestión. Mientras no se tenga un adecuado control sobre lo que se hace en el proyecto, la actividad de ingeniería se ve rebasada durante los tiempos de "crisis" del proyecto y se regresa a las prácticas de obtener resultados y "luego vemos como lo arreglamos".
Lo que se establece en las prácticas de REQM no implica que no exista una definición de requisitos pero, haciendo una lectura del propósito en cada nivel de madurez, lo que se espera es que el enfoque sea en la función de control y seguimiento, más que en la ingeniería. Posiblemente, con lo mismo que se había estado haciendo, pero con orden y control, podemos tener mejores resultados que intentar cambiar lo que hacemos al mismo tiempo que se ordena y controla.
Al agregar a este enfoque las prácticas de RD, tenemos un terreno controlado y disciplinado donde hay mayor posibilidad de que las nuevas técnicas y métodos puedan prosperar. La estabilidad en los proyectos nos puede dar el respiro para mejorar las prácticas existentes y  cambiar la ingeniería del desarrollo del producto.
Esta separación no es una barrera estricta. Existen organizaciones con una buena madurez en la gestión de los requisitos que se pueden beneficiar de ciertas prácticas de ingeniería, o al revés. Al fin de cuentas, el modelo sugiere una ruta que cada organización decide adoptar en su beneficio y en cada caso se harán las consideraciones necesarias.