El objetivo principal de este proceso es gestionar los requisitos del sistema software a desarrollar, ocupándose principalmente de la gestión del estado de los requisitos establecidos tras la fase de Validación. También es parte de este proceso, el mantener la trazabilidad de requisitos durante todo el ciclo de vida del proyecto de software.

Como consecuencia de esta tarea, se generarán nuevas versiones del documento de Requisitos y se crearán, modificarán o se eliminarán las historias existentes en JIRA para representar los requisitos.

Los siguientes son los roles participantes en este proceso:

Esta tarea se centra en los pasos a realizar cuando se recibe una petición de cambio en los requisitos actuales del proyecto. El Jefe de proyecto debe tomar una serie de decisiones y realizar las modificaciones adecuadas para que estos cambios se plasmen en el proyecto.

Partiendo del documento de requisitos actual, el Ingeniero de Requisitos generará una nueva versión del documento en el que se reflejarán los cambios solicitados desde control del cambio.

Su modificación puede implicar la creación / modificación y/o eliminación de la siguiente documentación:

• Casos de Uso
• Historias
• Requisitos No funcionales

La modificación del documento de requisitos implica que sea necesario realizar cambios en las historias que representan cada uno de los requisitos. Es responsabilidad del Jefe de Proyecto analizar el impacto de cada uno de estos cambios.

Vamos a distinguir las distintas situaciones para cada una de las historias afectadas:

• Añadir nuevas historias (Requisitos). En este caso, se añadirán las historias a Jira y se tendrán en cuenta para incorporar a posteriores iteraciones en el desarrollo de la aplicación.

• Modificación / Eliminación de una historia NO iniciada. Es decir, que aún no se ha comenzado su planificación / desarrollo. En este caso, se harán las modificaciones pertinentes, y se continuará con su planificación y posterior desarrollo.

• Eliminación de historias INICIADAS. En este caso, se anulará la historia y todas las tareas dependientes de la misma.

• Modificación de historias INICIADAS. En este caso, el Jefe de Proyecto deberá decidir si procede a la anulación de la historia o se asume el esfuerzo en las tareas actuales de desarrollo.

La trazabilidad de requisitos es, por definición, la correspondencia entre cada requisito del software y/o uno o más requisitos del usuario (que se encuentran en el Documento de Visión) u otras fuentes (trazabilidad hacia atrás) o una o varias partes del diseño o la implementación (trazabilidad hacia adelante).

Al realizarse modificaciones en los requisitos actuales, hay que mantener la trazabilidad en ambas direcciones.

Si se modifican los requisitos de manera que cambia el requisito de usuario (en el documento de visión) asociado, nos tenemos que asegurar de modificar en el Documento de Requisitos (bien Historia, Caso de Uso o Requisito No funcional) el campo “Visión”, que hace referencia al requisito de alto nivel que se corresponde con el requisito actual.

Al realizar modificaciones a nivel de Requisitos (Historias, Casos de Uso o Requisitos No funcionales), debemos mantener actualizado el campo “Requisito” en los JIRA creados. Este campo es el identificador del requisito actual.

Las métricas del proyecto se guardarán dentro de la carpeta del proyecto en Proyecto/Documentacion/1.Gestionproyecto/1.4.Metricas. Las métricas de este proceso en concreto se almacenan en la Hoja REQ.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-REQ-Elicitar Requisitos

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.