Comprension de los requerimientos
Este es un mapa mental del capitulo 5 del libro Ingenieria del Software de Pressman
1. 5.3 Indagacion de los requerimientos
1.1. Recabacion de los requerimientos en forma colaborativa: La meta es identificar el problema, proponer elementos de la solucion, negociar distintos enfoques y especificar un conjunto preliminar de requerimientos de la solucion en una atmosfera que favorezca el logro de la meta. En esta estapa, estan estrictamente prohibido las criticas y el debate.
1.2. Despliegue de la funcion de calidad: Traduce las necesidades del cliente en requerimientos tecnicos para el software. El DFC se concentra en maximizar la satisfaccion del cliente a partir del proceso de ingenieria de software.
1.2.1. Requerimientos normales: Objetivos y metas que se establecen para un producto o sistema durante las reuniones con el cliente.
1.2.2. Requerimientos esperados: Estan implicitos en el producto o sistema y quiza sea tan importantes que el cliente no los mencione de manera explicita.
1.2.3. Requerimientos emocionantes: Estas caracteristicas van mas alla de las expectativas del cliente y son muy satisfactorias se estan presentes.
1.3. Escenarios de uso: A menudo se llaman casos de uso, proporcionan la descripcion de manera en la que se utilizara el sistema.
1.4. Indagacion de los productos del trabajo: Los productos del trabajo generados como consecuencia de la indagacion de los requerimientos variaran en funcion del tamanio del sistema o producto que se va a construir.
2. 5.4 Desarrollo de casos de uso
2.1. Describ el comportamiento del sistema en distintas condiciones en las que el sistema responde a una peticion de alguno de sus participantes . Los casos de uso son mas elaborados a fin de que brinden muchos mas detalles sobre la interaccion.
3. 5.5 Elaboracion del modelo de requerimientos
3.1. Elementos del modelos de requerimientos
3.1.1. Elementos basados en el escenario: El sistma describe desde el punto de vist del usuario con el empleo de un enfoque basado en el escenario.
3.1.2. Elementos basados en clases: Cada escenario de uso implica un conjunto de objetos que se manipulan cuando un actor interactua con el sistema.
3.1.3. Elementos de comportamiento: El diagrama de estado es un metodo de representacion del comportamiento de un sistema que ilustra sus estados y los eventos que ocasionan que el sistema cambie de estado.
3.1.4. Elementos orientados al flujo: La informacion se transforma cuando fluye a traves de un sistema basado en computadora.
3.2. Patrones de analisis: Se integran en el modelo del analisis, haciendo referencia al nombre del patron. Tambien se guardan en un medio de almacenamiento de modo que los ingenieros de requerimientos usen herramientas de busqueda para encontrarlos y aplicarlos. La informacion sobre el patron de analisis se representa en un formato estandar.
4. 5.7 Validacion de los requerimientos
4.1. Se estudia para detectar inconsistencias, omisiones y ambiguedades. Los participantes asignan prioridades a los requerimientos representados por el modelo y se agrupan en paquetes de requerimientos que se implementaran como incrementos del software.
5. 5.1 Ingenieria de requerimientos
5.1. Elaboracion: Esta tarea se centra en desarrollar un modelo refinado de los requerimientos que identifique distintos aspectos de la funcion del software, su comportamiento e informacion.
5.2. Negociacion: Se pide a clientes, usuarios y otros participantes que ordenen sus requerimientos segun su prioridad y que despues analicen los conflictos.
5.3. Especificacion: En el contexto de los sitemas basados en computadora(y software), el termino especificacion tiene diferentes significados para distintas personas.
5.4. Validacion: La calidad de los productos del trabajo que se generan como consecuencia de la ingenieria de los requerimientos se evalua durante el paso de la validacion. Este se hace para la correccion de distintas ambiguedades para hacer la mejora del prpducto.
5.5. Administracion de los requerimientos: Es el conjunto de actividades que ayudan al equipo del proyecto a identificar, controlar y dar seguimiento a los requerimientos y a sus cambios en cualquier momento del desarrollo del proyecto.
6. 5.2 Establecer las bases
6.1. Identificacion de los participantes: Cualquier persona que se beneficie en forma directa o indirecta del sistema en desarrollo.
6.2. Reconocer los multiples puntos de vista: Debe clasificarse toda la informacion de los participantes en forma que permita a quienes toman las decisiones escoger para el sistema un conjunto de requerimientos que tenga coherenia interna.
6.3. Trabajar hacia la colaboracion: Si en un proyecto de software hay involucrados, se verian varios puntos de vista y sus distintas perspectivas.
6.4. Hacer las primeras preguntas: Las preguntas que se hacen en la concepcion del proyecto deben estar "libres de contexto". El primer conjunto de ellas se centran en el cliente y en otros participantes, en las metas y beneficios generales.
7. 5.6 Requerimientos de las negociaciones
7.1. Define un conjunto de actividades de negociacion al principio de cada iteracion del proceso de software. En lugar de una sola actividad de comunicacion con el cliente, se definen las actividades:
7.1.1. Identificacion de los participantes clave del sistema o subsistema.
7.1.2. Determinacion de las "condiciones para ganar" de los participantes.
7.1.3. Naegociacion de las condiciones para ganar de los participantes.