Este documento presenta la metodología de gestión de requerimientos. Explica técnicas para identificar requerimientos funcionales y no funcionales como entrevistas, cuestionarios y observación. También describe cómo definir, clasificar y verificar los requerimientos para asegurar que satisfacen las necesidades del cliente. El proceso incluye revisar los requerimientos con los usuarios para identificar defectos y realizar correcciones.

1. 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

2. 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 alisarenla recolecciónde información,paraconocerlasnecesidadesdel cliente,
y tener un 100% de manejo de la gestión de requerimientos.

3. 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

4. Capítulo 1 identificación de necesidades con el cliente
Es muy importante tenerenclarocada palabrade este capítulo1 para poderrealizaruna
buenarecolecciónde información. Yaque esde suma importanciaunacorrecta información
para satisfacerlasnecesidadesdel cliente,que losdatosque adquirimosdelcliente sealegible
para satisfacerlademandadel cliente;que nohayani el másmínimoerror enla información.
Conocerlasverdaderasnecesidadesdel cliente,si el cliente tieneunadiscapacidadparael
manejodel software esbuenotenerloencuenta.
Tambiénsede ve de tenerencuentael alcance del proyectode donde comienzahastadonde
llega,que el software que estamoscreandonoestorbe otrossoftware,si noque seael
comienzode unnuevosoftware.
Es importante mostrarlaentrevista,oencuesta,al entrevistadoo,conel finde corregir
cualquiererrorenla información. Guardaruna copia de toda lainformaciónque se adquiera
para este software esde sumaimportancia.
Hay que definirclaramente que actividadesyprocesosaceparte del proyecto,si lainformación
que tenemoseslasuficienteono,si no esla suficienteentoncesse deberáde obtenermas
informaciónacercade la necesidaddel clienteydel proyectorealizar.Si hayalgúnerrorenla
informaciónse deberáde modificarlainformación. Seránecesariotrabajarde lamano del
cliente conel findesrealizarunbuenproducto,que cumplaconla peticióndel clienteentodo.
Capítulo 2 TÉCNICAS PARAIDENTIFICAR REQUERIMIENTOS
Comosabemos,unárea de conocimientoesde granimportanciaenel desarrollode software,
esnecesarioidentificarlosrequerimientossede vende usarestrategiasparaparaidentificar
losrequerimientos.
El procesode obtenciónde requerimientos,cuyafinalidadessacara la luzlosrequisitos.no
soloesun proceso,sinotambiénunprocesosocial que envuelveadiferentespersonas.El
capítulo2 esbastante estensoasí que lodividiremosen4técnicas,para entenderlomejor.
1. Técnicas generales para la identificación de requerimientos
Es súpernecesariollevaracaboestaprimeratécnicayaque dentrode esta técnicaencon
tramos lasclavespara sacar la mayor informaciónposibledel cliente, ¿ycómoloasemos?lo

5. asemosgracias,a las entrevistas,alaslluviade ideas,yel cuestionario;veamosunpocode
cada uno de ellas.
La entrevista:estaunatécnicamuyutilizadaporlosperiodistas,sicólogos,programadoresetc.
Por qué esla más precisapara recogerinformación,yaque entregainformación directae
indirecta,cundo se hacenpreguntasabiertasyserradasnos da informacióndel puntode vista
del entrevistadoyde lasnecesidaddel cliente,de losproblemasque muchasvecespueden
surgir,la entrevistanosaclaramuchasdudas,por esoesla más utilizada.
Lluviade ideas:escon el finde obtenernuevasideasparamejóralasparaunirlasmejores
ideasconel finde crear unasúperidea,que seaútil para el proyecto,sede ve deteneruna
claridaddel temapara una buenarecolecciónde ideas.
Cuestionario:obtenerinformaciónacercade cómo ciertaspersonasse sientenacercade
problemas,productososerviciosespecíficos.Loscuestionariosnosdainformaciónde unsí o
un No,El cuestionarionopermite justificarlasrespuestas.
2. Técnicas específicas para la identificación de requerimientos.
Hay técnicasque nos sirvenpara conoceruna verdaderainformación,,lascualesnose pueden
dejarpasar por alto.
Observación:estatécnicapermite tenerinformación clara,de laformaenque serializanlas
actividades,de conocersi hayalgunaerror o fallaenla información .
Escenarios:permite conocerlasdificultades,oproblemasque puedansurgirenla producción
del software,yel tenerunplan.
3. Técnicas para Identificar Requisitos Funcionales y No Funcionales.
la técnicaN 3 tiene otros subniveles loscualesveremospocoapoco; y nos a aclarar la técnica
N 3.
1 sud nivel: Identificación de Requerimientos funcionales.
(Funcionales que afectan directamenteoindirectamenteunproducto)
Son de aclaraciones del servicioque ejecutarel sistemayde lamaneraque esta reaccionara
frente aentradas de información,enalgunoscasos tambiénde claraloque el sistemano debe
hacer o nodebe ejecutar.Muchosde losproblemasque surgenenlaenla inguinariade
software se debe auna incorrectaespecificación enlainformación.
En principio,laespecificaciónde requerimientosfuncionalesde unsistemadebe estar
completayser consistente.Lacompleciónsignificaque todoslosserviciossolicitadosporel

6. usuarioestándefinidos.Laconsistenciasignificaque losrequerimientosnotienendefiniciones
contradictorias.
2 sud nivel: Identificación de Requerimientos no funcionales.
(Nofuncionalessonaquellosque noafectanel producto)
Son aquellos requerimientos que notienenunaentradadirecta,conlasfunciones específicas
del sistema. De fine las restricciones del sistemacomolacapacidadde los dispositivos de
entraday de salida,losrequerimientosnofuncionalessurgende la necesidaddel usuario
debido al presupuesto alaspolíticasde laorganización,ala necesidadde interoperabilidad
con otros sistemasde software ohardware oa factoresexternoscomolosreglamentosde
seguridad,olaspolíticasde privacidad.
Aspectosa tenerencuentaenla identificaciónde requerimientosfuncionalesynofuncionales
Requerimientosbásicos:se estructurasuidentificaciónal buscarrespuestasapreguntascomo:
• ¿Cuál esel procesobásicode la empresa?
• ¿Qué datosutilizaoproduce este proceso?
• ¿Cuálessonloslímitesimpuestosporel tiempoylacarga de trabajo?
• ¿Qué controlesde desempeñoutiliza?
Las siguientespreguntassonde utilidadparaadquirirlacomprensiónnecesaria:
• ¿Cuál esla finalidadde laactividaddentro de laempresa?
• ¿Qué pasosse siguenpara realizarla?
• ¿Dónde se realizanestospasos?
• ¿Quiéneslosrealizan?
• ¿Cuántotiempotardanenefectuarlos?
• ¿Concuánta frecuencialohacen?
• ¿Quiénesempleanlainformaciónresultante?
Identificaciónde elementos
Durante esta,se debe identificarmuyclaramente lossiguienteselementos:
• Procesos

7. • Flujosde datosentre procesos
• Datosde cada flujode datos
• Basesde datos
• Datosde lasbasesde datos
Creo que esmuy importante tenerencuenta etaspregunta,poreso instructortome la
decisión de copiarlastal como estánenla páginaweb.
4. Técnicasde investigaciónde losatributosde lasnecesidadesde losclientes.
En realidad quienconoce unanecesidad mejorque lamismapersonaesel cliente, el usuariola
personacon el problemaesla mejorpersonaparapreguntarle a cerca del temaque piensa,
que dificultadestienelaempresa. Conel únicofinde hallarlarespuestala solución más
adecuaday precisa.¿ y cómose consigue unasolución aunproblema;unarespuestaauna
pregunta?investigando obteniendo información yquienmejorparadar esa información que el
cliente ousuario.
Grupos focales:se formanreuniendoaungrupo seleccionados de clientesconunmoderador
que esel que va a dirigirel debate conel únicofinde obtenerinformación precisa,lo más
precisoseriaque no queden dudas,que el grupode seleccionados expongancontodaclaridad,
sus ideas,suspreguntas,las dudasque van a surgiren el debate,graciasa estose puede
conseguirunamejorinformación,de mayorcalidadque laencuestayaque se estaría contado
con un grupode profesionales enel tema.
Entrevistaindividual:estaesuna herramientaque permiteobtenermuchainformación,
valiosadel tema tratado.Peroque estainformación sealegible,un100% de pende de la a
validadel entrevistador yde lapersonaque haya tomadopara entrevistar,yaque si se
realizas unaentrevistaaúnapersonaque notengaunreal conocimientodel temaesa
información novaser muyreal y va atraer con secuencias gravesparael producto.
Análisis contextual:conestatengase ase que el cliente cuente susexperiencias,laformaenla
que utilizaríael producto,susdudase saldríana relucir.
Clientes piloto:sonclientesde prestigios ynoes fácil de conseguir losclientespilotolos
Cualescumplenlafunción de exigirunrendimiento,songente de experiencia.Suobjetivó es
contribuira crear estructurasoperativaseficaces,consistentesydinámicasconlasque
afrontarla creciente diversidadydificultadde losmercados.

8. METODOLOGÍA DE GESTIÓN DE REQUERIMIENTOS
Capítulo 3
Definición de requerimientos
• Es importante que losrequerimientosseanclarosparadefinirlos,paraestoes
importante tenerencuentalosiguiente:
• Debemostenerencuentalasindicacionesdel usuarioysuobjetivo
• Se debe documentarlosrequerimientosde unaformaclaray 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
Requerimientosno 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.

9. 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

10. Revisión de Requisitos Vs Especificación

11. 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.

12. 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:

13. 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.

14. 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.

15. 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:

16. 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:

17. 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.

18. 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:

19. 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 propicitode laspruebasde requerimientoesbuscarfalencias,fallasenel productoypara
estose cumple algunasfases.
Planeación:enestafase define el al case e ilimitacionesde lasde laprueba,laestructura que
se va a ejecutarparalas pruebaslasnormaspara poder realizarlapruebason: documentación,
recursohumanoy recursotecnológico,lostiemposde estimadosde duraciónde lamismay los
criteriosparaterminación.
Diseñode casos de prueba:en este puntose define las características a evaluar,algunasde
lascaracterísticas para evaluardichorequerimientos.
Completo:todoslositmes (itmesse utilizaparadefinirlasherramientasdelcapítuloque se
estáestudiando) estánincluidos.
Correcto:cada itemestásin errores
Preciso:cada ítemes exactoynavajo
Consistente:ningún ítementraenconflictoconotros.
Relevante:cadaítemesprecisoal problemay su solución.
Probable:durante el desarrollodel programaylaprueba,es posible determinarsi el ítema
que dado satisfecho.
Factible: cada ítempuede serimplementadoconlasherramientas,recursosypersonal
disponible.
Registravilidad:cadaítempuede serseguidodurante cadaetapa.

20. Libre de detalle de diseño:sondeclaracionesde losrequerimientosque sede ven satisfacer,
por la solución del problemaynose deben ocultarpor solucionesdel problema.
Ejecuciónde casosde prueba: definidoscomocasosde pruebaconciso,contraposición,
ambigüedadycompletitud,entre otrasse reportaranlasconsideraciones,errores,
sugerencias,yse realizaranreunionesparahaceraclaracionesydefinirsi lasconsideraciones
planteadasvana sersolucionadasosi el requerimientoescorrectocomo esta.
cierre:fase unavezse hayacompletadoslaejecuciónconresultadossatisfactoriosyajustes
correspondientes,se realizarael cierre de lapruebadonde se daráel vistobuenosobre los
requisitosevaluado.
Capítulo 6 GESTIÓN DE CAMBIOS
Comosu nombré lodice esde cambiosesmuy complejoya que para cambiar algogrande se
tiene que serconsciente de que cualquiercambio,puede afectarel productose tiene que ye
bar un procesoadecuado.

21. IdentificaciónControl de cambios
Para una buenaejecución del control de cambiosse llevanlassiguientes actividades:
Análisis de lasolicitud:unode los puntosimportantespara analizarsonel al canse y el tiempo,
con el únicofinde sabersi la solicitud esviable.
Valorarel cambio: Otropunto importante esvalorarlafactibilidadde lasolicitudrealizadaya
seapor un cliente internoounoexterno.Paraellose deberá recorrertodoel árbol de
requisitosviendocomolesafectael cambio.
Analizarmodificación:enestaparte se analizael impactoque tendráuncambio,que severa
afectadopor dichocambio,y identificarapuntual mente lasmodificaciones.
Documentarcambios:eneste punto se crea un documentode loscambiosrea lisar.

22. Aprobación control de cambios.
Aprobarcambios:una vezrealizado el impactodel cambio;se tomarala decisión si se aceptan
loscambioso no.
Planearcambios:dé puesde unaaprobación formal de los cambios, se planearael tiempoylos
recursosnecesarios paradichocambio.
Realizarcambios:se llevaacabolasmodificaciones.
Revisarcambios:se verifica Siloscambiossi loscambios estáfuncionandoaadecuadamente.
ActualizarLíneaBase: Es recomendableutilizarel nuevorequerimientocomolíneabase,
estocon el finde trabajar siempre sobre laúltimaversióndel requerimiento.
Informar:se le informaa losinteresadosque el cambioestaecho,paraque el cliente lo
compruebe.
Capítulo 7 GESTIÓN DE REQUERIMIENTO.
Nospermite registrarloscambios,ejecutadosenel producto.
Cumple con los requisitos
      

23. 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

24. La matrizde documentaciónnoshablade funcionalesynofunciónales.Funcionalesque
afectandirectamente oindirectamente el producto.Ynofuncionalesque noafectanal
producto.
  

25. Conclusión
La metodologíade gestiónde requerimientos esmuyimportanteyaque nosaclara dudas,de
lastécnicasde información, nosdaunmejormanejodel tema.