METODOLOGÍA GESTIÓN DE REQUERIMIENTOS

PRESENTADO POR:

MARÍA PERAFAN MUÑOZ

LUIS DAVID BERMEO URRIAGO

PRESENTADO A: HUGO FERNANDO POLANIA DUSSAN

SENA

(SERVICIO NACIONAL DE APRENDIZAJE)

TECNOLOGO EN ANALISIS Y DESARROLLO EN SISTEMAS DE

INFORMACION

866036

2015

Tabla de contenido Introducción ........................................................................................................................2

Objetivos .............................................................................................................................3

Capítulo 1 identificación de necesidades con el cliente ...........................................................4

Capítulo 2 TÉCNICAS PARA IDENTIFICAR REQUERIMIENTOS ....................................................4

TECNICAS PARA DEFINIR REQUISITOS ................................................................... 14

Capitulo n 4 ...................................................................................................................... 14

Capítulo 5 PRUEBAS DE REQUERIMIENTOS .......................................................................... 19

Capítulo 6 GESTIÓN DE CAMBIOS ........................................................................................ 20

Capítulo 7 GESTIÓN DE REQUERIMIENTO. ............................................................................ 22

Conclusión ......................................................................................................................... 25

Introducción La Metodología de gestión de requerimientos es con el único fin de dejar más claro las

técnicas are alisar en la recolección de in formación, para conocer las necesidades del cliente,

y tener un 100% de manejo de la gestión de requerimientos.

Objetivos

Promover la lectura

Adquirir mayor conocimiento de la metodología de gestión de

requerimientos.

Fortalecer el conocimiento.

Tener claro el tema

Un manejo correcto de la información

Capítulo 1 identificación de necesidades con el cliente Es muy importante tener en claro cada palabra de este capítulo 1 para poder realizar una

buena recolección de información. Ya que es de suma importancia una correcta información

para satisfacer las necesidades del cliente, que los datos que adquirimos del cliente sea legible

para satisfacer la demanda del cliente; que no haya ni el más mínimo error en la información.

Conocer las verdaderas necesidades del cliente, si el cliente tiene una discapacidad para el

manejo del software es bueno tenerlo en cuenta.

También sede ve de tener en cuenta el alcance del proyecto de donde comienza hasta donde

llega, que el software que estamos creando no estorbe otros software, si no que sea el

comienzo de un nuevo software.

Es importante mostrar la entrevista, o encuesta, al entrevistado o, con el fin de corregir

cualquier error en la información. Guardar una copia de toda la información que se adquiera

para este software es de suma importancia.

Hay que definir claramente que actividades y procesos aceparte del proyecto, si la información

que tenemos es la suficiente o no, si no es la suficiente entonces se deberá de obtener mas

información acerca de la necesidad del cliente y del proyecto realizar. Si hay algún error en la

información se deberá de modificar la información. Será necesario trabajar de la mano del

cliente con el fin desrealizar un buen producto, que cumpla con la petición del cliente en todo.

Capítulo 2 TÉCNICAS PARA IDENTIFICAR REQUERIMIENTOS Como sabemos, un área de conocimiento es de gran importancia en el desarrollo de software,

es necesario identificar los requerimientos sede ven de usar estrategias para para identificar

los requerimientos.

El proceso de obtención de requerimientos, cuya f inalidad es sacar a la luz los requisitos. no

solo es un proceso, sino también un proceso social que envuelve a diferentes personas. El

capítulo 2 es bastante es tenso así que lo dividiremos en 4 técnicas, para en tenderlo mejor.

1. Técnicas generales par a la identificación de requerimientos

Es súper necesario llevar acabo esta primera técnica ya que dentro de esta técnica en con

tramos las claves para sacar la mayor información posible del cliente, ¿y cómo lo asemos? lo

asemos gracias, a las entrevistas, alas lluvia de ideas, y el cuestionario; veamos un poco de

cada uno de ellas.

La entrevista: esta una técnica muy utilizada por los periodistas, sicólogos, programadores etc.

Por qué es la más precisa para recoger información, ya que entrega información directa e

indirecta, cundo se hacen preguntas abiertas y serradas nos da información del punto de vista

del entrevistado y de las necesidad del cliente, de los problemas que muchas veces pueden

surgir, la entrevista nos aclara muchas dudas, por eso es la más utilizada.

Lluvia de ideas: es con el fin de obtener nuevas ideas para mejóralas para unir las mejores

ideas con el fin de crear una súper idea, que sea útil para el proyecto, sede ve detener una

claridad del tema para una buena recolección de ideas.

Cuestionario: obtener información acerca de cómo ciertas personas se sienten acerca de

problemas, productos o servicios específicos. Los cuestionarios nos da información de un sí o

un No, El cuestionario no permite justificar las respuestas.

2. Técnicas específicas para la identificación de requerimientos.

Hay técnicas que nos sirven para conocer una verdadera información,, las cuales no se pueden

dejar pasar por alto.

Observación: esta técnica permite tener información clara, de la forma en que serializan las

actividades, de conocer si hay alguna error o falla en la información .

Escenarios: permite conocer las dificultades, o problemas que puedan surgir en la producción

del software, y el tener un plan.

3. Técnicas para Identificar Requisitos Funcionales y No Funcionales.

la técnica N 3 tiene otros subniveles los cuales veremos poco a poco; y nos a aclarar la técnica

N 3.

1 sud nivel: Identificación de Requerimientos funcionales .

(Funcionales que afectan directamente o indirectamente un producto)

Son de aclaraciones del servicio que ejecutar el sistema y de la manera que esta reaccionara

frente a entradas de información, en algunos casos también de clara lo que el sistema no debe

hacer o no debe ejecutar. Muchos de los problemas que surgen en la en la inguinaria de

software se debe a una incorrecta especificación en la información.

En principio, la especificación de requerimientos funcionales de un sistema debe estar

completa y ser consistente. La compleción significa que todos los servicios solicitados por el

usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones

contradictorias.

2 sud nivel: Identificación de Requerimientos no funcionales.

(No funcionales son aquellos que no afectan el producto)

Son aquellos requerimientos que no tienen una entrada directa, con las funciones específicas

del sistema. De fine las restricciones del sistema como la capacidad de los dispositivos de

entrada y de salida, los requerimientos no funcionales surgen de la necesidad del usuario

debido al presupuesto a las políticas de la organización, a la necesidad de interoperabilidad

con otros sistemas de software o hardware o a factores externos como los reglamentos de

seguridad, o las políticas de privacidad.

Aspectos a tener en cuenta en la identificación de requerimientos funcionales y no funcionales

Requerimientos básicos: se estructura su identificación al buscar respuestas a preguntas como:

• ¿Cuál es el proceso básico de la empresa?

• ¿Qué datos utiliza o produce este proceso?

• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?

• ¿Qué controles de desempeño utiliza?

Las siguientes preguntas son de utilidad para adquirir la comprensión necesaria:

• ¿Cuál es la finalidad de la actividad dentro de la empresa?

• ¿Qué pasos se siguen para realizarla?

• ¿Dónde se realizan estos pasos?

• ¿Quiénes los realizan?

• ¿Cuánto tiempo tardan en efectuarlos?

• ¿Con cuánta frecuencia lo hacen?

• ¿Quiénes emplean la información resultante?

Identificación de elementos

Durante esta, se debe identificar muy claramente los siguientes elementos:

• Procesos

• Flujos de datos entre procesos

• Datos de cada flujo de datos

• Bases de datos

• Datos de las bases de datos

Creo que es muy importante tener en cuenta etas pregunta, por eso instructor tome la

decisión de copiarlas tal como están en la página web.

4. Técnicas de investigación de los atributos de las necesidades de los clientes.

En realidad quien conoce una necesidad mejor que la misma persona es el cliente, el usuario la

persona con el problema es la mejor persona para preguntarle a cerca del tema que piensa,

que dificultades tiene la empresa. Con el único fin de hallar la respuesta la solución más

adecuada y precisa. ¿ y cómo se consigue una solución a un problema; una respuesta a una

pregunta? investigando obteniendo información y quien mejor para dar esa información que el

cliente o usuario.

Grupos focales: se forman reuniendo a un grupo seleccionados de clientes con un moderador

que es el que va a dirigir el debate con el único fin de obtener información precisa, lo más

preciso seria que no queden dudas, que el grupo de seleccionados expongan con toda claridad,

sus ideas, sus preguntas, las dudas que van a surgir en el debate, gracias a esto se puede

conseguir una mejor información, de mayor calidad que la encuesta ya que se estaría contado

con un grupo de profesionales en el tema.

Entrevista individual: esta es una herramienta que permite obtener mucha información,

valiosa del tema tratado. Pero que esta información sea legible, un 100% de pende de la a

valida del entrevistador y de la persona que haya tomado para entrevistar, ya que si se

realizas una entrevista aúna persona que no tenga un real conocimiento del tema esa

información no va ser muy real y va atraer con secuencias graves para el producto.

Análisis contextual: con esta tenga se ase que el cliente cuente sus experiencias, la forma en la

que utilizaría el producto, sus dudas e saldrían a relucir.

Clientes piloto: son clientes de prestigios y no es fácil de conseguir los clientes piloto los

Cuales cumplen la función de exigir un rendimiento, son gente de experiencia. Su objetivó es

contribuir a crear estructuras operativas eficaces, consistentes y dinámicas con las que

afrontar la creciente diversidad y dificultad de los mercados.

METODOLOGÍA DE GESTIÓN DE REQUERIMIENTOS

Capítulo 3

Definición de requerimientos

• Es importante que los requerimientos sean claros para definirlos, para esto es

importante tener en cuenta lo siguiente:

• Debemos tener en cuenta las indicaciones del usuario y su objetivo

• Se debe documentar los requerimientos de una forma clara y correcta.

Clasificación de los requerimientos

Requerimientos funcionales

Estos requerimientos se utilizan para determinar que hará el Software definiendo las

relaciones de su operación y su funcionamiento debe ser claro en lo que el sistema no

debe hacer y que validaciones se deben realizar, teniendo en cuenta cual será el

comportamiento del sistema.

Requerimientos funcionales se pueden dividir en dos puntos de vista:

El primero tiene la relación con el usuario donde se identifica la relación del usuario

con el sistema desde el punto de vista del mismo;

El segundo relación con el sistema dando respuesta al usuario, es decir desde el

punto de vista de lo que realiza el sistema.

Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento

ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo

que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer

cambios al sistema, retrasando la entrega de éste e incrementando el costo. En

principio, la especificación de requerimientos funcionales de un sistema debe estar

completa y ser consistente con lo solicitado por el usuario

Requerimientos no funcionales

Estos requerimientos se basan en las restricciones de los servicios o funciones

ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de

desarrollo, estándares, usabilidad, portabilidad, entre otros.

Los Requerimientos funcionales son los requerimientos que no se refieren

directamente a las funciones específicas que entrega el sistema, sino a las

propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la

capacidad de almacenamiento.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las

restricciones en el presupuesto, a las herramientas utilizadas, a las políticas de la

organización, a la necesidad de interoperabilidad con otros sistemas de software o

hardware o a factores externos como los reglamentos de seguridad, las políticas de

privacidad, etcétera.

Los dos tipos de requerimientos especificados son de gran importancia para el

desarrollo de una aplicación en software, por lo tanto siempre deben ser escritos con

claridad, contener la mayor especificación de las necesidades expuestas por el cliente,

esto con el fin de tener un soporte base desde el cual se trabajaran y no presentar

ambigüedades en la definición y el resultado del producto. La figura a continuación

muestra los inconvenientes que se pueden presentar cunado no se hace una

identificación correcta de los requerimientos.

Para la verificación de requisitos se deben añadir criterios de aceptación por cada

requisito, una tarea de la calidad es asegurarse de que cada requisito cumple con los

criterios asignados, este criterio es una medida del requisito que lo hace entendible y

con capacidad de ser probado.

Para la verificación de requisitos se debe validar lo siguiente

Revisión de Requisitos Vs Especificación

Una vez ya identificado los requerimientos, documentados y verificados se procede a

realizar la revisión de los mismos con base a la información recolectada con los

usuarios del sistema, en esta revisión participa los analistas del equipo de trabajo y los

usuarios necesarios para esta revisión de debe chequear que:

A continuación se presenta el proceso para la verificación de los requerimientos.

Preparar plan de revisión:

En la preparación del plan de reunión de debe planear quienes deben asistir que se va

a hablar y cuánto tiempo se va a gastar.

Documentos de requisitos a revisar:

Identificar cuáles son los documentos de especificación de requisitos que se va a

revisar

Preparar reunión:

Se debe confirmar el lugar en el cual realizará la reunión y se deben prepara los

materiales necesarios para la reunión (lápices, hojas, elementos visuales… etc).

Realizar reunión:

Se revisa el entendimiento de la especificación por parte de los interesados y se valida

que lo especificado si cumple con la necesidad del cliente y con lo solicitado.

Identificar de defectos de la especificación:

Si revisa si se encuentran defectos con respecto a lo solicitado o si hace falta alguna

especificación requerida.

Realización de correcciones a los documentos:

Si en la etapa anterior se encuentran defectos en la especificación el analista del

sistema debe realizan las debidas correcciones al documento.

Informar modificaciones a los interesados:

Una vez los defectos en la especificación han sido subsanados, se debe enviar un

breve resumen informando las tareas realizadas para la corrección de los documentos

especificados junto con los documentos corregidos a los participantes en la reunión

para dar su aprobación

Cierre de los requerimientos:

Por último se da por cerrado y entendido la el requerimiento se firma la aprobación por

parte de los interesados y se procede a enviarse un correo con la aprobación del

requerimiento.

TECNICAS PARA DEFINIR REQUISITOS

Capitulo n 4

Para obtener los requisitos del cliente se pueden emplear varias técnicas.

Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con

grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos,

y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación

de estos métodos para establecer los requisitos exactos de las personas implicadas,

para producir un sistema que resuelva las necesidades del negocio.

De acuerdo a las necesidades de los clientes específicos a los cuales se va a aplicar

la metodología propuesta, se han definido las siguientes:

Definición de diagramas

Cuando se inicia con el desarrollo de un sistema por lo general nos encontramos con

la dificultad de no saber cómo dar inicio a la especificación y descripción de la

funcionalidad en general que buscamos apoyar con dicha herramienta, para ello hay

muchas herramientas en el mercado que buscan apoyar dicha tarea.

De manera general se recomienda el uso de los diagramas UML, pero cuándo utilizar

diagramas UML? y cuándo no hacerlo?.

Veamos de manera didáctica cuándo utilizar y no utilizar los diagramas UML

Cuando no Utilizar Diagramas

No dibujar diagramas porque el proceso te lo dice

Porque te sientes culpable de no hacerlo o porque piensas que es buen diseño

hacerlo. Los buenos diseñadores escriben código y dibujan diagramas solamente

cuando es necesario.

Dibujar diagramas para que otra persona codifique

Cuando Utilizar los Diagramas

Utilizar los diagramas cuando varias personas necesiten entender la estructura de una

parte particular del diseño, porque todos ellos lo estarán trabajando simultáneamente.

Deténgase cuando todos ellos estén de acuerdo que lo han entendido

Cuando dos o más personas estén en desacuerdo con un elemento particular que

debería ser diseñado, y quieres un consenso del equipo. Detente cuando la decisión

haya sido tomada

Cuando quieras jugar con una idea de diseño, y los diagramas pueden ayudarte a

entenderlo. Detente cuando hayas conseguido finalizar el punto que querías codificar

Cuando necesites exponer una estructura de alguna parte del código a alguien más o

a ti mismo.

Los diagramas que se utilizan son los siguientes:

De estados:

Estos diagramas nos muestra los diferentes estados de un objeto durante su vida.

De secuencia:

Estos nos muestran el intercambio de mensajes (es decir la forma en que se invocan)

en un momento dado los diagramas de secuencia ponen especial énfasis en el

orden y el momento en que se envían los mensajes a los objetos.

De caso de uso:

Los diagramas de casos de uso describen las relaciones y las dependencias entre un

grupo de casos de uso y los actores participantes en el proceso. Los diagramas de

casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.

Definición de Casos de uso

Para la correcta definición de los casos de uso a emplear en la especificación de los

requisitos, se deben tener en cuenta algunos aspectos como:

La identificación de actores:

Esto nos permite categorizar los diferentes grupos de actores, es decir identificar

características comunes de los actores que intervienen en el sistema, en esta

identificación de actores debemos tener en cuenta que dichos actores pueden llegar a

ser un usuario, un humano u otro sistema o dispositivo de hardware, también debemos

hacernos las siguientes preguntas:

• Quién o qué inicia eventos con el sistema?

• Quién proveerá, usará o quitará información?

• Quién usará esta funcionalidad?

• Quién está interesado en cierto requerimiento?

• En que parte de la organización será usado el sistema?

• Quién dará soporte y mantendrá el sistema?

• Cuales son los recursos externos del sistema?

• Qué otros sistemas necesitarán interactuar con este sistema?

Al definir los actores que intervienen en un caso de uso se debe considerar que una

persona puede ejecutar distintos roles en el sistema. Hay actores principales, que son

los que usan el sistema directamente; para quienes desarrollamos el sistema. Y hay

actores secundarios, que son aquellos de los que el sistema necesita ayuda para

poder cumplir con el objetivo del caso de uso

Intereses de los actores:

La identificación de estos intereses nos permiten priorizar desarrollo de los casos de

uso, planificar mejor las interacciones y reconocer cuales son los usuarios con los que

debemos levantar los casos de uso.

La identificación de eventos y escenarios que este podría llegar a tener:

La identificación de eventos y escenarios es necesarios para poder determinar cual es

la interacción entre el sistema y los actores, que puede ser descrito mediante una

secuencia de mensajes, es una descripción narrativa de lo que la gente hace al

intentar utilizar la aplicación.

Especificación de Casos de uso

Los casos de uso deben ser relatos secuenciales que especifiquen una funcionalidad

determinada del sistema que se desea desarrollar, así que debe describir como inicia y

termina el caso de uso, que datos se intercambian entre el actor y el caso de uso, el

flujo de eventos, no solo la funcionalidad, para reforzar esto debe comenzar cada

acción con la frase “El actor...”, describir solo los eventos que pertenecen a ese caso

de uso, y no lo que pasa en otros casos de uso o fuera del sistema.

De la misma manera se debe tener especial cuidado de no utilizar los siguientes

detalles:

No describir detalles de la interfaz del usuario, a menos que sea necesario para

entender el comportamiento del sistema.

Evitar terminología vaga tal como “por ejemplo” “etc” “información”.

Evite dejar en el texto del caso de uso ambigüedades o preguntas que se debieron

resolver en el levantamiento de información.

Los casos de uso deben contar con los siguientes elementos

El conjunto de todos los casos de uso, debe cubrir los requerimientos del sistema en

su totalidad.

Se pueden definir casos de uso en diferentes niveles.

A nivel de sistema de Negocio

A nivel de sistema de Software

Las descripciones de los casos de uso son cruciales para la comprensión del sistema.

Debe contar con Pre y Post Condiciones, una Pre-Condición es una restricción sobre

cuando un caso de uso puede empezar. que necesita para poder ser ejecutado, la

Post-Condición para un caso de uso debe ser verdadera, independientemente de cual

flujo sea ejecutado. Si algo puede fallar, debería cubrirse en la post condición diciendo:

“La acción se ha completado o si algo ha fallado, la acción no se ha realizado”, en

lugar de decir “La acción se ha completado”.

Prototipos

Los prototipos son modelos a escala o facsímil de lo real, pero no tan funcional para

que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones

necesarias del sistema final.

Es importante definir un objetivo para los prototipos, ya que puede ser útil en

diferentes fases del proyecto, por ello su objetivo debe ser claro. Es decir durante

diferentes etapas del ciclo de vida se pueden utilizar para diferentes necesidades, por

ejemplo durante la fase de análisis se usa para obtener los requerimientos del usuario,

en la fase de diseño se usa para ayudar a evaluar muchos aspectos de la

implementación seleccionada y así de acuerdo a la necesidad de cada etapa.

Características de un prototipo

El prototipo es una aplicación que puede no funcionar(conjunto de dibujos por ejemplo,

una presentación de escenarios) o que puede funcionar (conjunto de pantallas que

proporcionan un modelo dinámico).

Los prototipos se crean con rapidez

Los prototipos evolucionan a través de un proceso iterativo.

Los prototipos tiene un costo bajo desarrollo.

Definición de criterios de aceptación

Estos criterios nos permiten asegurar que los requisitos satisfacen la funcionalidad

requerida y al mismo tiempo que el producto es de calidad, nos ayuda a obtener un

nivel de aceptación realista tanto para el cliente como la empresa que los desarrolla.

para la definición de criterios de aceptación se presenta el siguiente modelo:

Se debe encontrar el documento de requisito terminado, revisado y aprobado por las

diferentes partes, implicadas.

El requisito no debe tener escenarios ambiguos

El requisito debe hacer que dice el documento de especificación ni mas, ni menos y

cumplir con todos los escenarios.

El requisito debe ser medible, es fácil identificar si cumple o no cumple.

No existen contraindicaciones con otros requisitos

El requisito debe haber sido probado y aceptado por este proceso.

Se debe entregar el requisito dentro de las fechas establecidas.

El requisito aparte de cumplir con los anteriores pasos, puede haber otros criterios que

el cliente solicite.

Capítulo 5 PRUEBAS DE REQUERIMIENTOS El propicito de las pruebas de requerimiento es buscar falencias, fallas en el producto y para

esto se cumple algunas fases.

Planeación: en esta fase define el al case e ilimitaciones de las de la prueba, la estructura que

se va a ejecutar para las pruebas las normas para poder realizar la prueba son: documentación,

recurso humano y recurso tecnológico, los tiempos de estimados de duración de la misma y los

criterios para terminación.

Diseño de casos de prueba: en este punto se define las características a evaluar, algunas de

las características para evaluar dicho requerimientos.

Completo: todos los itmes (itmes se utiliza para definir las herramientas del capítulo que se

está estudiando) están incluidos.

Correcto: cada item está sin errores

Preciso: cada ítem es exacto y navajo

Consistente: ningún ítem entra en conflicto con otros.

Relevante: cada ítem es preciso al problema y su solución.

Probable: durante el desarrollo del programa y la prueba, es posible determinar si el ítem a

que dado satisfecho.

Factible: cada ítem puede ser implementado con las herramientas, recursos y personal

disponible.

Registravilidad: cada ítem puede ser seguido durante cada etapa.

Libre de detalle de diseño: son declaraciones de los requerimientos que sede ven satisfacer,

por la solución del problema y no se deben ocultar por soluciones del problema.

Ejecución de casos de prueba: definidos como casos de prueba conciso, contraposición,

ambigüedad y completitud, entre otras se reportaran las consideraciones, errores,

sugerencias, y se realizaran reuniones para hacer aclaraciones y definir si las consideraciones

planteadas van a ser solucionadas o si el requerimiento es correcto como esta.

cierre: fase una vez se haya completados la ejecución con resultados satisfactorios y ajustes

correspondientes, se realizara el cierre de la prueba donde se dará el visto bueno sobre los

requisitos evaluado.

Capítulo 6 GESTIÓN DE CAMBIOS Como su nombré lo dice es de cambios es muy complejo ya que para cambiar algo grande se

tiene que ser consciente de que cualquier cambio, puede afectar el producto se tiene que ye

bar un proceso adecuado.

Identificación Control de cambios

Para una buena ejecución del control de cambios se llevan las siguientes actividades:

Análisis de la solicitud: uno de los puntos importantes para analizar son el al canse y el tiempo,

con el único fin de saber si la solicitud es viable.

Valorar el cambio: Otro punto importante es valorar la factibilidad de la solicitud realizada ya

sea por un cliente interno o uno externo. Para ello se deberá recorrer todo el árbol de

requisitos viendo como les afecta el cambio.

Analizar modificación: en esta parte se analiza el impacto que tendrá un cambio, que severa

afectado por dicho cambio, y identificara puntual mente las modificaciones.

Documentar cambios: en este punto se crea un documento de los cambios rea lisar.

Aprobación control de cambios.

Aprobar cambios: una vez realizado el impacto del cambio; se tomara la decisión si se aceptan

los cambios o no.

Planear cambios: dé pues de una aprobación formal de los cambios, se planeara el tiempo y los

recursos necesarios para dicho cambio.

Realizar cambios: se lleva acabo las modificaciones.

Revisar cambios: se verifica Silos cambios si los cambios está funcionando a adecuadamente.

Actualizar Línea Base: Es recomendable utilizar el nuevo requerimiento como línea base,

esto con el fin de trabajar siempre sobre la última versión del requerimiento.

Informar: se le informa a los interesados que el cambio esta echo, para que el cliente lo

compruebe.

Capítulo 7 GESTIÓN DE REQUERIMIENTO.

Nos permite registrar los cambios, ejecutados en el producto.

Cumple con los requisitos

No Cumple= N, El color rojo es para dar una señal de alerta informando que el requisito no está

cumpliendo correctamente con el criterio de aceptación y que se debe revisar porque razón

esto pasando esto y tomar las medidas de control necesarias.

No aplica= En caso que el criterio no aplique en ese caso para el requisito se mostrar en amarillo informando que no hay problema.

N

C

n/a

C

C

N

C

n/a

N

n/a

C

C

N

C

n/a

C

C

La matriz de documentación nos habla de funcionales y no funciónales. Funcionales que

afectan directamente o indirectamente el producto. Y no funcionales que no afectan al

producto.

Conclusión La metodología de gestión de requerimientos es muy importante ya que nos aclara dudas, de

las técnicas de información, nos da un mejor manejo del tema.