Administracion de Requerimientos

1

Administración de Requerimientos (REQM)

© 2008 por ITESM. SIE Center México. Documento de carácter confidencial

Administración de RequerimientosAdministración de Requerimientos

ITESIREQMAbril, 2010

ITESIREQMAbril, 2010® Capability Maturity Model Integration esta registrada en la oficinade U.S. Patent and Trademark por la Universidad de Carnegie Mellon.

La distribución de este material está limitada por el SIE Center de México a los participantes de esta sesión.

© 2008 por ITESM. SIE Center México. Documento de carácter confidencial 2


PropósitoPropósito

Entender el concepto de Administración de Requerimientosdesde la perspectiva del modelo CMMI, asícomo los factores a considerar para lograr una implementación exitosa.



Objetivos - 1Objetivos - 1

• Identificar dos tipos de requerimientos: 1) del cliente y 2) del producto o componente

• Revisar algunas técnicas para entender ambos tipos de requerimientos

• Facilitar el compromiso con los requerimientos

• Aplicar el concepto de rastreo de requerimientos

• Aplicar a los requerimientos, aspectos críticos del control de cambios: justificación análisis de impacto, aprobación y desarrollo



Objetivos - 2Objetivos - 2

• Entender el contexto de los procesos de REQM en el ciclo de vida de los proyectos

• Entender la interdependencia entre REQM y otras áreas de ingeniería y administración

• Interpretar los objetivos de REQM y aplicar sus prácticas específicas y genéricas

5



Administración de Requerimientos CMMI

Administración de Requerimientos CMMISG 1 Administrar los requerimientosGG 2 Institucionalizar un proceso

administrado

SG 1 Administrar los requerimientosGG 2 Institucionalizar un proceso

administrado



Propósito REQMPropósito REQM

Utilizar los requerimientos de los productos y componentes del producto del proyecto

Identificar inconsistencias entre dichos requerimientos, los planes del proyecto y los productos de trabajo



Importancia de los Requerimientos - 1Importancia de los Requerimientos - 1

• El proyecto no puede terminar mientras haya cambios

• El producto debe satisfacer las necesidades del cliente

• La solución no funciona si el problema no se entiende

• Los productos deben hacerse sólo una vez• La generación de productos basados en un

pobre entendimiento del problema y cotizados con base en ese entendimiento, conlleva a pérdidas para el negocio

�



Importancia de los Requerimientos - 2Importancia de los Requerimientos - 2

• Los requerimientos inadecuados (incompletos, incorrectos e inconsistentes) son el factor principal del fracaso de los proyectos de software, pues no hay consistencia entre la funcionalidad y los costos planeados del proyecto

�



REQM incluye …REQM incluye …

• Administrar todos los requerimientos recibidos o generados por el proyecto, incluyendo los técnicos, los no técnicos y aquellos agregados por la organización

• Lograr acuerdos con los clientes con respecto al significado e intención de los requerimientos

• Lograr el compromiso de los participantes del proyecto con los requerimientos

• Administrar los cambios a los requerimientos (internos y externos) durante el proyecto

• Identificar inconsistencias entre los requerimientos, los planes de proyecto, y los productos de trabajo



Cuando no hay REQM Cuando no hay REQM

• El cliente y el desarrollador tienen diferentes entendimientos sobre el conjunto de requerimientos

• El equipo trabaja en proyectos que técnicamente no cree factibles

• No hay un registro de los cambios y sus justificaciones

• No pude garantizarse que el código incluya los requerimientos originales y sus cambios aprobados

�



Contexto de REQM – 1 Contexto de REQM – 1

SG1 Administrar los RequerimientosSP 1.1 Obtener el Entendimiento de los

RequerimientosSP 1.2 Obtener el Compromiso a los RequerimientosSP 1.3 Administrar los Cambios a los RequerimientosSP 1.4 Mantener el Rastreo Bidireccional de los

RequerimientosSP 1.5 Identificar Inconsistencias entre el Trabajo del

Proyecto y los Requerimientos



Contexto de REQM – 2 Contexto de REQM – 2

Adaptado de (Software Engineering Institute, 2006)

Obtener el Entendimiento

de los Requerimientos

Obtener el Compromiso a

los Requerimientos

Administrar los Cambios a los

Requerimientos

Identificar Inconsistencias entre el Trabajo

del Proyecto y los Requerimientos

Mantener el Rastreo

Bidireccional de los

Requerimientos

Requerimientos

Rastreabilidad



Relación con otras Áreas de Proceso - 1 Relación con otras Áreas de Proceso - 1

Adaptado de (CMMI Product Team, 2006)

Adaptado de (Software Engineering Institute, 2006)

RD PI

VAL

ClienteTS

VER

REQMRequerimientos

Necesidades del cliente y usuarios

Requerimientos de producto y componentes

Reportes de verificación y validación de los componentes y productos de trabajo

Componentesdel producto

Alternativas de solución

Requeri-mientos

Producto

14



Administrar los RequerimientosAdministrar los Requerimientos

SP 1.1 Obtener el Entendimiento de los Requerimientos

SP 1.2 Obtener el Compromiso a los RequerimientosSP 1.3 Administrar los Cambios a los RequerimientosSP 1.4 Mantener el Rastreo Bidireccional de los



SP 1.1 Obtener el Entendimiento de los Requerimientos

SP 1.2 Obtener el Compromiso a los RequerimientosSP 1.3 Administrar los Cambios a los RequerimientosSP 1.4 Mantener el Rastreo Bidireccional de los





SG1: Administrar los RequerimientosSG1: Administrar los Requerimientos

Los requerimientos se administran y se identifican las inconsistencias con los planes y productos de trabajo



SP1.1 Obtener el Entendimiento con los Requerimientos – 1SP1.1 Obtener el Entendimiento con los Requerimientos – 1Desarrollar con los proveedores de

requerimientos el entendimiento del significado de los requerimientos



SP1.1 Obtener el Entendimiento con los Requerimientos – 2SP1.1 Obtener el Entendimiento con los Requerimientos – 2Subprácticas:

– Establecer criterios para distinguir a los proveedores adecuados de requerimientos

– Establecer criterios objetivos para la evaluación y aceptación de requerimientos

– Analizar los requerimientos para asegurar que se cumple con los criterios establecidos

– Lograr un entendimiento de los requerimientos con sus proveedores, de tal forma que los participantes del proyecto puedan comprometerse con ellos



Evidencias sugeridas:– Lista de criterios para distinguir los

proveedores apropiados de requerimientos– Criterios para la evaluación y aceptación de

los requerimientos

SP1.1 Obtener el Entendimiento con los Requerimientos – 3SP1.1 Obtener el Entendimiento con los Requerimientos – 3

19



TécnicasTécnicas

Ingeniería de RequerimientosIngeniería de Requerimientos



Ingeniería de Requerimientos – 1Ingeniería de Requerimientos – 1

1. Obtención (elicitation)2. Análisis3. Especificación4. Validación5. Administración

�



Dualidad del Rol del AnalistaDualidad del Rol del Analista�

Diseño y Codificación

Habilidades de comunicación

Poder de abstracción, uso de modelos

Usuarios Analista Analista

Lista de necesidades Especificación Técnica

22



TécnicasTécnicas

Obtención de requerimientosObtención de requerimientos



Obtención de Requerimientos (Elicitation)Obtención de Requerimientos (Elicitation)

Para lograr un correcto entendimiento del problema pueden utilizarse las técnicas siguientes:

• Entrevistas• Cuestionarios• Observación• Maestro – Alumno• Prototipos• Descripción Operacional

– Concepto de Operaciones– Casos de uso

�



EntrevistaEntrevista

ObjetivoEnterarse de opiniones y sentimientos acerca del sistema, la organización y las metas personales

Ventajas– Permite conocer a los posibles usuarios en un ambiente controlado

DesventajasLas personas no siempre están dispuestas a ser entrevistadas:

– Temen hacer un mal papel o perder poder si revelan lo que saben

– No se sienten en confianza con el analista (especialmente si es de otro departamento o ajeno a la empresa)

– Se saltan pasos “básicos” al describir los procesos

�



CuestionarioCuestionario

Objetivo:Obtener detalles sobre la implementación de las actividades

Ventajas:– Cuando la gente se encuentra dispersa– Cuando hay mucha gente involucrada en el sistema de software– Para conocer y sensibilizar a los interesados antes de proceder

con las entrevistas

Desventajas:– El lenguaje utilizado debe ser muy preciso, por lo que debe

hacerse un análisis previo del dominio del problema (círculo vicioso)

– Se necesita bastante práctica en la elaboración de un buen cuestionario

�



ObservaciónObservación

Objetivo:Utilizado para profundizar en lo que realmente se estáhaciendo, viendo de primera mano la relación del usuario con la organización y su medio ambiente físico

Ventajas:– Revela detalles que difícilmente se habrían descubierto con

otros métodos

Desventajas:– A algunos usuarios no les gusta ser observados– El tiempo necesario para lograr una buena observación es largo– Es difícil permanecer en calidad de observador

�



Otras TécnicasOtras Técnicas

• Maestro – AlumnoTrabajar junto al personal que realiza las tareas para aprender acerca de la tarea y como se cumple

• PrototiposRepresentación limitada del diseño de un producto que permite comprender el problema y clarificar los requerimientos

�

28



TécnicasTécnicas

Documentación del problema (ConOps)Descripción operacional(Casos de Uso)

Documentación del problema (ConOps)Descripción operacional(Casos de Uso)



Concepto de Operaciones (ConOps)Concepto de Operaciones (ConOps)

Describe los resultados del análisis conceptual con:

– El sistema o situación actual– Las necesidades de desarrollo o de modificación– Los modos de operación del sistema propuesto– Las clases de usuarios y sus características– Las características operacionales (prioridades)– Los escenarios operacionales – Las limitaciones de la aproximación (enfoque)– El Análisis de impacto

�



Proveer un puente entre las necesidades del usuario y los requerimientos técnicos (desarrolladores)

Documento ConOpsDocumento ConOps

Documento orientado al usuario que le permite describir los conceptos de un sistema:

– Ayuda a los usuarios a expresar sus distintos puntos de vista y expectativas

– Provee una descripción de las necesidades y deseos del usuario

– Ayuda en general al usuario en su trabajo

�



Un servicio puede requerir múltiples funciones e interactuar con múltiples actores

Casos de Uso (CU)Casos de Uso (CU)

• Es una técnica para especificar escenarios operacionales

• Es un modelo de lo que un sistema debe hacer y de la interacción con entidades externas

• Elementos principales:– Actor: Elemento externo interactuando con el sistema– Caso de Uso: Servicios provistos por los actores– Escenario: Secuencia de eventos que describen cómo se lleva

a cabo un servicio

�



CU: PropósitoCU: PropCU: Propóósitosito

• Definir el alcance del sistema– Identificar las interacciones del sistema con

entidades externas– Identificar los servicios provistos por el

sistema• Validar el entendimiento del desarrollador

sobre el sistema

�



Diagrama de Casos de UsoDiagrama de Casos de UsoDiagrama de Casos de Uso

��

��

��

��

��

��

��

��

�



¿Qué es un Actor?¿¿QuQuéé es un Actor?es un Actor?

� Los actores no son parte del sistema� Los actores representan los roles que

puede tomar un usuario� Un actor puede representar una

persona, dispositivo o sistema� Un actor puede intercambiar

activamente información con el sistema

� Un actor puede proporcionar información

� Un actor puede ser recibidor pasivo de informaciónActorActor

�

35



Mejora y Generación de Productos de Trabajo

Mejora y Generación de Productos de Trabajo



Canal de ComunicaciónCanal de Comunicación

• Definir al proveedor válido de requerimientos

• Definir un responsable en caso de múltiples proveedores

• Definir quién debe aceptar los requerimientos por parte de la empresa de desarrollo

�



• Las características que debe tener un requerimiento para ser aceptado en el proyecto– Completo– Consistente– Verificable (puede asociarse a una prueba)– Claro (no ambiguo)– Técnicamente factible

• Los criterio de aceptación del producto por parte del cliente

Criterios de Aceptación – 1 Criterios de Aceptación – 1 �



Criterios de Aceptación – 2Criterios de Aceptación – 2

• Correcto: si todo requerimiento escrito representa algo requerido por el sistema a construirse

• No ambigüo: si todo requerimiento escrito tiene una sola interpretación– Evita frecuencias, administrar operador lógico

• Completo: si se incluyen las respuestas del sistema a todas las posibles entradas de datos en todas las posibles situaciones

�



• Verificable: un requerimiento escrito es verificable si existe algún proceso finito y costeable con el cual una persona o máquina pueda confirmar que el software a ser construido cumple con el requerimientoEjemplos de requerimientos que no son verificables:– El producto debe tener una interfase fácil de usar– El programa no debe entrar en un ciclo infinito

Criterios de Aceptación – 3 Criterios de Aceptación – 3

Evitar palabras comousualmente, frecuentemente, rápido.

�



• Consistente: si ningún requerimiento escrito está en conflicto con otro previamente documentado– Conflicto de comportamiento: cuando se especifica

un estímulo diferente para inducir una o varias respuesta diferentes al mismo estímulo

– Conflicto de términos: cuando se usan términos en diferentes contextos que significan la misma cosa

– Conflicto en características: cuando el producto exhibe características contradictorias

– Inconsistencia en tiempos: cuando se pide que el producto entregue tiempos de respuesta contradictorios

Criterios de Aceptación – 4 Criterios de Aceptación – 4 �



Análisis de Factibilidad Análisis de Factibilidad

• La posibilidad de construir el software con el hardware y software existentes

• La estimación del costo contra los beneficios que el software brindará a la empresa

• Se realiza después de que se establecieron las necesidades del sistema

• Permite tomar la decisión de si es factible realizar el sistema propuesto o no

�



SP1.2: Obtener el Compromiso a los Requerimientos – 1


Lograr el compromiso a los requerimientos por parte de los participantes del proyecto





Subprácticas:– Evaluar el impacto de los requerimientos en

los compromisos existentes– Negociar y registrar los compromisos





Evidencias Sugeridas:– Evaluaciones de impacto de los

requerimientos– Compromisos documentados a los

requerimientos y a sus cambios



Compromiso a los RequerimientosCompromiso a los Requerimientos

• Los requerimientos definen el alcance del sistema• El equipo de desarrollo debe comprometerse a

desarrollar el sistema descrito por los requerimientos

• La empresa de desarrollo se compromete con el cliente a desarrollar el sistema descrito en los requerimientos

• El equipo de desarrollo debe hacer un análisis de impacto de los requerimientos antes de comprometerse a ellos

�



SP1.3: Administrar los Cambios a los Requerimientos – 1


Administrar los cambios a los requerimientos conforme vayan desarrollándose en el proyecto





Subprácticas:– Documentar todos los requerimientos y los

cambios a los requerimientos generados por el proyecto

– Mantener un historial de los cambios a los requerimientos con su justificación

– Evaluar el impacto de los cambios a los requerimientos desde el punto de vista de los involucrados relevantes

– Mantener disponibles para el proyecto los datos de los requerimientos y de sus cambios





Evidencias Sugeridas:– Estatus de requerimientos– Base de datos de requerimientos– Base de datos de las decisiones tomadas

sobre requerimientos



Técnicas de Análisis de ImpactoTécnicas de Análisis de Impacto

• Análisis de factibilidad• Prototipos técnicos• Matriz de requerimientos (cambios)• Simulación

�



Control de Cambios - AtributosControl de Cambios - Atributos

• Registro del cambio• Razón del cambio• Resultado de la evaluación del impacto

– Requerimientos afectados (nuevos, modificados, cancelados)– Impacto en productos de trabajo – Esfuerzo, calendario y costo

• Decisión del cambio– Decisión y razón de la decisión

• Actualización el historial del requerimiento• Comunicar, planear y proceder al cambio conforme a la

decisión

�



SP1.4: Mantener el Rastreo Bidireccional de los Requerimientos – 1


Mantener el rastreo bidireccional entre los requerimientos y los productos de trabajo





Subprácticas:– Mantener el rastreo de los requerimientos para

asegurar que los requerimientos de menor nivel estén documentados

– Mantener el rastreo desde el requerimiento original hasta sus requerimientos derivados y la ubicación de sus funciones, interfaces, objetos, personas, procesos y productos de trabajo

– Generar la matriz de rastreo de los requerimientos





Evidencias Sugeridas :– Matriz de rastreo de requerimientos– Sistema de rastreo de requerimientos

54



TécnicasTécnicas

RastreoRastreo BidireccionalMatriz de Rastreabilidad

RastreoRastreo BidireccionalMatriz de Rastreabilidad



Definiciones – 1Definiciones – 1

Rastreo

Es una asociación entre dos o más entidades lógicas como: requerimientos, elementos del sistema, verificaciones o tareas

[CMMI-DEV, v1.2 CMU/SEI-2006-TR-008]



Rastreo (Traceability)Rastreo (Traceability)

Lista de Lista de requerimientosrequerimientos

1.

2.

3.

4.

…

n

Fases / Fases / Productos de Productos de

TrabajoTrabajo

1.

2.

3.

4.

…

n

HaciaHacia

DesdeDesde

�




Rastreo de RequerimientosEs una asociación entre los requerimientos originales y los requerimientos relacionados, implementados, y verificados

Rastreo BidireccionalEs una asociación entre dos o más entidades lógicas, definida y congruente en cualquier dirección (es decir, hacia y desde la entidad)




Rastreo BidireccionalRastreo Bidireccional

AnAnáálisislisis DiseDiseññoo CCóódigodigo PruebasPruebasHH

DD

H: HaciaD: Desde

HH

DD

HH

DD

�




Requerimientos Derivados• Requerimientos que no fueron explícitamente

definidos pero que son inferidos de los requerimientos del cliente a partir de:1) el contexto de los requerimientos (p. ej., estándares

aplicables, leyes, políticas, prácticas comunes y decisiones gerenciales) o

2) de los requerimientos necesarios para especificar un componente del producto

• También pueden surgir durante el análisis y el diseño de los componentes del producto o del sistema




Requerimiento DerivadoRequerimiento Derivado

AnAnáálisislisis DiseDiseññoo

ReqReq. Derivado. Derivado

ReqReq. Derivado. Derivado

5. – Desplegar resultados en página Web

5.1 – Contratar servicio de Internet

5.2 – Instalar servidor de WEB

RDRD

RDRD

Es posible que un requerimiento derivado NO esté ligado a un requerimiento en particular,

sino al sistema (o producto) en general

�




Rastreo VerticalIdentifica el origen y la trayectoria del desarrollo del requerimiento, a través de las diferentes actividades y productos del proyecto




DiseDiseññoo

CCóódigodigo

PruebasPruebas

Modelo de CascadaModelo de Cascada

Ras

treo

Ver

tical

*R

astr

eo V

ertic

al *

* Entre diferentes fases* Entre diferentes fases

AnAnáálisislisis




Rastreo HorizontalIdentifica las relaciones entre los requerimientos para evitar problemas potenciales antes de la integración del producto (revisar relaciones entre interfaces)




Requerimiento Asignado(Allocated Requirement)

Es un requerimiento que impone todo o parte del desempeño y funcionalidad de un requerimiento de alto nivel, en un elemento arquitectónico o componente del diseño de bajo nivel



Rastreo de Requerimientos RelacionadosRastreo de Requerimientos Relacionados

1.-

2.-

3.-

4.-

�



Rastreo Bidireccional en CMMIRastreo Bidireccional en CMMI

RequerimientosRequerimientos

Ejemplos de Productos de TrabajoEjemplos de Productos de Trabajo

Documentos de DiseDocumentos de DiseññooCasos de PruebaCasos de PruebaCCóódigodigo

Actividades Actividades en el Planen el Plan

HH

HH

DD

DD

H: Hacia D: Desde

Productos Productos de Trabajode TrabajoRelevantesRelevantes

ProductoProductoFinalFinal

RequerimientosRequerimientosDerivadosDerivados

HH DD

�



Matriz de RastreabilidadMatriz de Rastreabilidad

…

Req3

Req2

Req1

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

�



SP 1.5 Identificar Inconsistencias entre el Trabajo del Proyecto y los Requerimientos – 1 SP 1.5 Identificar Inconsistencias entre el Trabajo del Proyecto y los Requerimientos – 1

Identificar las inconsistencias entre los planes de proyecto, los productos de trabajo y los requerimientos



SP 1.5 Identificar Inconsistencias entre el Trabajo del Proyecto y los Requerimientos – 2SP 1.5 Identificar Inconsistencias entre el Trabajo del Proyecto y los Requerimientos – 2

Subprácticas:– Revisar los planes del proyecto, las actividades y los

productos de trabajo buscando inconsistencias con los requerimientos y sus cambios

– Identificar la fuente de la inconsistencia y su razonamiento

– Identificar los cambios a los planes y productos de trabajo que requieren realizarse como resultado de los cambios a los requerimientos de la línea base

– Iniciar las acciones correctivas



SP 1.5 Identificar Inconsistencias entre el Trabajo del Proyecto y los Requerimientos – 3SP 1.5 Identificar Inconsistencias entre el Trabajo del Proyecto y los Requerimientos – 3

Evidencias Sugeridas:– Documentación de inconsistencias,

incluyendo las fuentes, las condiciones y el razonamiento

– Acciones correctivas

71



HerramientasHerramientas

InconsistenciasAcciones CorrectivasInconsistenciasAcciones Correctivas



Identificar Inconsistencias – 1 Identificar Inconsistencias – 1

• Revisar inconsistencias entre los planes, productos de trabajo y los requerimientos, identificando causa y razón de las mismas, así como las acciones correctivas necesarias

�



RequerimientosRequerimientos

Ejemplos de Productos de TrabajoEjemplos de Productos de Trabajo

Documentos de DiseDocumentos de DiseññooCasos de PruebaCasos de PruebaCCóódigodigoActividades Actividades

en el Planen el Plan

HH

DD

H: HaciaD: Desde

Productos Productos de Trabajode TrabajoRelevantesRelevantesRequerimientosRequerimientos

DerivadosDerivados

HH DD

Identificar Inconsistencias – 2 Identificar Inconsistencias – 2 �



Identificar las Causa de InconsistenciaIdentificar las Causa de Inconsistencia

• El trabajo realizado o planeado no incluye todo lo solicitado

• El trabajo realizado o planeado incluye más de lo solicitado (gold plating)

• Los cambios generan inconsistencias en algún producto ya liberado

�



Acciones CorrectivasAcciones Correctivas

• Determinar las acciones correctivas necesarias para resolver las inconsistencias

• Asignar un responsable a cada acción correctiva• Incluir las acciones correctivas en la lista de

actividades a monitorear (actividades del proyecto, agenda para la junta de estatus, etc.)

• Analizar los resultados de las acciones correctivas– ¿Se terminó?– ¿Se resolvió el problema?– ¿Se requiere otra acción correctiva?

�

76



Prácticas GenéricasPrácticas Genéricas

GG2 Institucionalizar un Proceso AdministradoGG2 Institucionalizar un Proceso Administrado



GG 2 Institucionalizar un Proceso Administrado

GG 2 Institucionalizar un Proceso Administrado

GP 2.1 Establecer una política organizacionalGP 2.2 Planear el procesoGP 2.3 Proveer recursosGP 2.4 Asignar responsabilidadesGP 2.5 Capacitar al personalGP 2.6 Administrar la configuraciónGP 2.7 Identificar e involucrar a los agentes

relevantesGP 2.8 Monitorear y controlar el procesoGP 2.9 Evaluar adherencia en forma objetivaGP 2.10 Revisar estatus con alta gerencia



© SIE Center México, Documento de Carácter Confidencial 78

• Tener una política que considere aspectos de REQM• Incluir las actividades de REQM en el plan del proyecto

o en un calendario alterno• Proveer capacitación en procesos y habilidades para

llevar a cabo competentemente el proceso • Identificar recursos necesarios para ejecutar REQM• Generar la carpeta, control de accesos y niveles de

administración para los Criterios y Catálogo de Proveedores de Requerimientos, Criterios de aceptación, Descripción, Compromiso y Solicitud de Cambios de los Requerimientos, Matriz de Rastreo y Reporte de Inconsistencias

• Lista de involucrados en las actividades principales de REQM

GP - Evidencias Sugeridas GP - Evidencias Sugeridas �



© SIE Center México, Documento de Carácter Confidencial 79

• Monitorear el plan de REQM y sus acciones correctivas

• Criterios de adherencia a REQM aplicados al líder del proyecto

• Reporte de utilidad de procesos de REQM mandado a la alta gerencia

GP - Evidencias Sugeridas GP - Evidencias Sugeridas �



REQM: Procesos PrincipalesREQM: Procesos Principales�

��

��

��

��

��

�� !�� "��

��#�� "�� "��



REQM: Arquitectura de ProcesosREQM: Arquitectura de Procesos�

��

��#��"�� "��

82



ResumenResumen

Factores de éxitoRecapitulaciónFactores de éxitoRecapitulación



Factores de ÉxitoFactores de Éxito

• Identificar al proveedor válido de requerimientos y de peticiones de cambios

• Validar los requerimientos con base en los criterios de aceptación

• Identificar e involucra a las personas u organismos que afectan o son afectados por el nuevo sistema, durante la aceptación de los requerimientos

• Automatizar el registro y el rastreo de los requerimientos



Recapitulación de REQMRecapitulación de REQM

• Valide su entendimiento de los requerimientos con sus clientes

• Comprometa a la gente que participa en el proyecto con los requerimientos

• Realice un análisis de impacto antes de aceptar las peticiones de cambio

• Registre el rastreo de los requerimientos hacia los Productos de Trabajo (PT) predeterminados

• Aplique acciones correctivas cuando se identifiquen inconsistencias entre los PT y los requerimientos



¿Comentarios?¿Preguntas?



¡Muchas Gracias!

Ing. Vilma C. Escarria Rodríguez

[email protected]

http://siecenter.itesm.mx



ReferenciasReferencias

• Software Engineering Institute (2006). Introduction to CMMI v1.2 [Powerpoint presentation]. Pittsburgh, PA: Carnegie Mellon University. Distributed to Introduction to CMMI v1.2 course participants at specific course location.

• CMMI Product Team (2006). CMMI for development, version 1.2(Tech. Rep. No. CMU/SEI-2006-TR-008). Pittsburgh, PA: Carnegie Mellon University. Available at: http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf

Administracion de Requerimientos

Documents

Transcript of Administracion de Requerimientos