identificación de necesidades
Post on 18-Jul-2015
42 Views
Preview:
TRANSCRIPT
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.
top related