Actividad: Gestionar cambios de requisitos
Esta actividad gestiona los cambios en los requisitos y valora su impacto global.
DescripciónEstructura de desglose de trabajoAsignación de equiposUtilización del producto de trabajo
Objetivo
La finalidad de esta actividad es evaluar el impacto de los cambios solicitados en los requisitos, y gestionar el impacto en sentido descendente de los cambios cuya implementación se ha aprobado.
Relaciones
Actividades principales
Descripción

Esta actividad aborda los aspectos siguientes:

Los cambios en los requisitos tienen un impacto natural en los artefactos en sentido descendente (por ejemplo, los productos de trabajo de análisis y diseño, los productos de trabajo de prueba, los artefactos de despliegue, etc.). La rastreabilidad identificada y documentada durante la gestión las dependencias define explícitamente las relaciones entre los requisitos y los otros productos de trabajo. Estas relaciones son la clave para comprender el impacto de los cambios de requisitos.

Propiedades
Condicionado por sucesosYes
Varias apariciones
Continuo
Opcional
Planeado
Se puede repetir
Personal

Implique a todo el equipo (interesados: representantes de los clientes, expertos en el dominio y otros). Incluya como revisor técnico a cualquier miembro del equipo del proyecto de software cuyo trabajo se vea afectado por el cambio. Gestione los recursos de revisión con eficacia. No incluya a la totalidad del equipo a menos que pueda garantizar que añade valor al proyecto.

El equipo completo debe incorporar un buen conocimiento del dominio del problema, las dificultades técnicas del proyecto, así como habilidades en la gestión de requisitos y en el modelo de caso de uso .

Utilización
Instrucciones de utilización

Esta actividad debe efectuarse siempre que se perfeccionen los requisitos.

Deben realizarse revisiones regulares, junto con actualizaciones a los atributos y dependencias de requisitos, siempre que se actualicen los requisitos.

Es recomendable que organice una revisión del Modelo de caso de uso  por iteración en las fases inicial y de elaboración, donde revise el trabajo en curso. Inicialmente, esto lo efectúan y lo aprueban los usuarios antes de desarrollar cualquiera de los Casos de uso de forma detallada, y es un objetivo muy importante para que los recursos no se utilicen para desarrollar casos de uso incorrectos. Al final de la fase de elaboración, debería organizar una revisión detallada del modelo de caso de uso . Recuerde que al final de la fase de elaboración, debería tener un modelo de caso de uso , y posiblemente un modelo de dominio que represente el Glosario, que está completado al 80 %. También debería organizar una revisión del modelo de caso de uso por iteración en las fases de construcción y de transición cuando se perfeccione el modelo de caso de uso . La revisión debe concentrarse en la parte del modelo de caso de uso que se está desarrollando para la iteración.

Factores clave

El equipo de desarrollo principal debe llevar a cabo varias rondas de revisión interna: ensayos para eliminar las incoherencias innecesarias antes de que su trabajo reciba una inspección y una revisión más formal por parte de todo el equipo.

Debe dividir el material de forma que el equipo no revise todo a la vez. Una reunión de revisión no debe llevar más de un día. Por ejemplo, puede llevar a cabo revisiones por separado de la interfaz de usuario y de los casos de ejemplo de comportamiento, o podría revisar todos los artefactos de requisitos relacionados con un subsistema determinado.

Otra consideración importante es el seguimiento del historial de requisitos. Al capturar la naturaleza y los fundamentos de los cambios de requisitos, los revisores reciben la información necesaria para responder a los cambios de forma adecuada.