REQUIREMENTS MANAGEMENT

INICIO

Propósito

• Gestionar los requerimientos de el o los productos del proyecto y de los componentes de dichos productos

• Identificar las inconsistencias entre estos requerimientos y el plan y work products del proyecto

Metas y prácticas específicas

Inicio

Meta específica 1/2

• Los requerimientos son gestionados y las inconsistencias con el plan y los productos del proyecto son identificadas

• El proyecto mantiene un conjunto de vigentes y aprobados requerimientos durante todo el ciclo de vida del proyecto

Meta específica 2/2

• Para la disciplina de Software Engineering los requerimientos de software pueden ser un subconjunto de todos los requerimientos del producto o bien ser el total de los requerimientos

• En el primer caso se habla de requerimientos alocados al software

Specific Practices 1/2

• 1.1Obtener una entendimiento compartido de los requerimientos

• 1.2 Obtener commitments para los requerimientos

• 1.3 Gestionar cambios en los requerimientos

• 1.4 Mantener trazabilidad bidireccional de los requerimientos

Specific Practices 2/2

• 1.5 Identificar inconsistencias entre los work products del proyecto y los requerimientos

SP 1.1: Obtener un entendimiento compartido de los requerimientos

• Durante el desarrollo del proyectos todas las tareas reciben requerimientos

• Se establecen criterios o canales oficiales para recibir requerimientos (Key Users)

• Los Ingenieros de Requerimientos analizan los pedidos con los Key Users para asegurar que se alcanza una correcta y compartida especificación de requerimientos

SP1.1 Work products

• Key Users seleccionados utilizando criterios establecidos

• Requerimientos evaluados y aceptados o rechazados utilizando criterios objetivos– Por ejemplo utilizar IEEE-std 830

• Alcanzar con los Key Users una comprensión de los requerimientos que permita obtener commitments para la realización de los mismos

• Expresar esta comprensión utilizando documentos estandar (Modelo de Requerimientos)

SP1.2 Obtener compromisos para los requerimientos aceptados

• Dirigida a que el equipo que implementará los requerimientos acordados con los Key Users los acepte y se comprometan para su realización

• Estos compromisos se describen en el plan y work products del proyecto

• Los requerimientos evolucionan y es necesario lograr que el equipo acepte estos cambios y su impacto en el plan y work products del proyecto

SP1.2 Work Products

• Evaluar el impacto de los requerimientos sobre los compromisos existentes

• Modelo de Requerimientos actualizado

• Plan y Work Products del proyecto actualizados

• Aprobación del Modelo y del Plan por quienes tienen autoridad para hacerlo

SP 1.3 Gestionar cambios en los requerimientos

• Utilizar un workflow aprobado para gestionar los cambios a los requerimientos– Recibido– Revisado– Acordado con Key User– Evaluado el impacto sobre el proyecto– Aceptado por el equipo del proyecto– Autorizado

SP 1.3 Gestionar cambios en los requerimientos

– Modelo de Requerimientos actualizado– Plan del proyecto actualizado– Requerimiento implementado

• Conocer el status de cada cambio propuesto a los requerimientos

• Mantener la historia de los cambios en los requerimientos– Ayuda a medir la volatilidad

SP 1.3 Work Products

• Base de datos con la historia de los cambios a los Requerimientos

• Mantener esta base es una las tareas del workflow

SP1.4 Mantener trazabilidad bidireccional de los requerimientos

• A medida que se avanza en el desarrollo de los requerimientos o de la solución técnica del producto y se identifican componentes, se generan requerimientos derivados para los componentes

• Se denominan requerimientos fuentes (sources) los acordados con los Key Users

SP1.4 Mantener trazabilidad bidireccional de los requerimientos

• Dos tipos de trazabilidad– De los requerimientos fuentes a los

requerimientos derivados, hasta el último nivel de ellos

– De los requerimientos derivados a otros work products del proyecto

SP1.4 Mantener trazabilidad bidireccional de los requerimientos

• Otros Work Products del proyecto– Modelos de Análisis– Modelos de Diseño– Modelos de Despliegue– Modelos de Componentes de Software– Códigos fuente y ejecutable– Planes y resultados de Verificación– Planes y resultados de Validación

SP 1.4 Work products

• Matriz de Requerimientos fuentes y derivados

• Matriz de Requerimientos derivados y otros work products del proyecto

SP1.5 Especificar inconsistencias entre Requerimientos y Plan

• Buscar y encontrar las inconsistencias entre requerimientos y el plan y work products del proyecto

• Identificar e iniciar las acciones correctivas necesarias

SP1.5 Especificar inconsistencias entre Requerimientos y Plan

• Revisar plan, tareas y work products del proyecto para identificar inconsistencias con los requerimientos y los cambios realizados a los mismos

• Identificar las fuentes de las inconsistencias y su explicación

SP1.5 Especificar inconsistencias entre Requerimientos y Plan

• Identificar los cambios que deben ser realizados en el plan y los work products como consecuencia al cambio en la linea de base de los requerimientos

• Iniciar las acciones correctivas

SP1.5 Work Products

• Documentación de las Inconsistencias

• Plan para corregirlas

Metas y prácticas específicas

Terminación

REQUIREMENTS MANAGEMENT

Terminación