Gestión de Requerimientos

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
Gestión de Requerimientos por Mind Map: Gestión de Requerimientos

1. 1. Comprensión de los Requerimientos

1.1. Proporciona el mecanismo apropiado para entender lo que desea el cliente, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la especificación y administrar los requerimientos a medida de que se transforman en un sistema funcional. Incluye siete tareas diferentes:

1.1.1. 1. Concepción

1.1.2. 2. Indagación

1.1.3. 3. Elaboración

1.1.4. 4. Negociación

1.1.5. 5. Especificación

1.1.6. 6. Validación

1.1.7. 7. Administración

2. 2. Establecer las Bases

2.1. En el caso ideal, los participantes e ingenieros de software trabajan juntos en el mismo equipo. En esas condiciones, la ingeniería de requerimientos tan sólo consiste en sostener conversaciones significativas con colegas que sean miembros bien conocidos del equipo. Etapas requeridas para establecer las bases:

2.1.1. 1. Identificación de los Participantes

2.1.2. 2. Reconocer los múltiples puntos de vista

2.1.3. 3. Trabajar hacia la colaboración

2.1.4. 4. Hacer las primeras preguntas

3. 3. Indagación de los Requerimientos

3.1. Combina elementos de la solución de problemas, elaboración, negociación y especificación. A fin de estimular un enfoque colaborativo y orientado al equipo, los participantes trabajan juntos para identificar el problema, proponer elementos de la solución, negociar distintas visiones y especificar un conjunto preliminar de requerimientos para la solución. Entre ellos están:

3.1.1. 1. Recabación de los requerimientos en forma colaborativa

3.1.2. 2. Despliegue de la función de calidad. El DFC identifica tres tipos de requerimientos:

3.1.2.1. 1. Requerimientos Normales

3.1.2.2. 2. Requerimientos Esperados

3.1.2.3. 3. Requerimientos Emocionantes

3.1.3. 3. Escenarios de uso

3.1.4. 4. Indagación de los productos del trabajo

4. 4. Desarrollo de Casos de Uso

4.1. En esencia, un caso de uso narra una historia estilizada sobre cómo interactúa un usuario final (que tiene cierto número de roles posibles) con el sistema en circunstancias específicas. La historia puede ser un texto narrativo, un lineamiento de tareas o interacciones, una descripción basada en un formato o una representación diagramática. Sin importar su forma, un caso de uso ilustra el software o sistema desde el punto de vista del usuario final.

5. 5.Modelo de los Requerimientos

5.1. El objetivo del modelo del análisis es describir los dominios de información, función y comportamiento que se requieren para un sistema basado en computadora. El modelo cambia en forma dinámica a medida que se aprende más sobre el sistema por construir, y otros participantes comprenden más lo que en realidad requieren. Por esa razón, el modelo del análisis es una fotografía de los requerimientos en cualquier momento dado. Existen dos formas:

5.1.1. 1. Elementos del modelo de requerimientos

5.1.1.1. 1. Elementos Basados en el Escenario.

5.1.1.2. 2. Elementos Basados en Clases.

5.1.1.3. 3. Elementos de Comportamiento.

5.1.1.4. 4. Elementos Orientados al Flujo

5.1.2. 2. Patrones de análisis

6. 6. Requerimientos de las Negociaciones

6.1. se tiene que entrar en negociaciones con uno o varios participantes. En la mayoría de los casos, se pide a éstos que evalúen la funcionalidad, desempeño y otras características del producto o sistema, en contraste con el costo y el tiempo para entrar al mercado. El objetivo de esta negociación es desarrollar un plan del proyecto que satisfaga las necesidades del participante y que al mismo tiempo refleje las restricciones del mundo real, que se hayan establecido al equipo del software. Las mejores negociaciones buscan un resultado “ganar-ganar”. Actividades para una buena negociación:

6.1.1. 1. Identificación de los participantes clave del sistema o subsistema.

6.1.2. 2. Determinación de las “condiciones para ganar” de los participantes.

6.1.3. 3. Negociación de las condiciones para ganar de los participantes

7. 7. Validación de los requerimientos

7.1. A medida que se crea cada elemento del modelo de requerimientos, se estudia para detectar inconsistencias, omisiones y ambigüedades. Los participantes asignan prioridades a los requerimientos representados por el modelo y se agrupan en paquetes de requerimientos que se implementarán como incrementos del software.