La metodología de gestión de requerimientos es una ingeniería de requerimientos que cumple con las necesidades de los usuarios

1. Metodología de la
gestión de
requerimientos
Centro agro empresarial y desarrollo pecuario del Huila
SENA 866036
03/03/15
Presentado por:
Jampier Vidarte
Sofía Borrero Llanos
Presentado al instructor:
Hugo Fernando Polania Dussan
Presentado por:
Sofía Borrero Llanos
Presentado al instructor:
Hugo Fdo. Polania Dussan
Metodología de
gestión de
requerimientos

2. TABLA DE CONTENIDOS
Tema: pag
Capítulo 1: identificación de necesidades del cliente………………………… 4
Capítulo 2: técnicas para identificar requerimientos ………………………… 6
 Técnicas de identificación de requerimientos…………….. 6
 Técnicas específicas para la para la identificación de
requerimientos………………………………………………… 7
 Técnicas para identificar requisitos funcionales y no
funcionales…………………………………………………….. 8
 Técnicas de identificación de los atributos de las necesidades
del cliente………………………………………………………. 9
Capítulo 3: definición requerimientos…………………………………………... 11
Capítulo 4: técnicas para definir requerimientos……………………………… 14
Capítulo 5: prueba de requerimientos………………………………………….. 17
Capítulo 6: gestión de cambios…………………………………………............ 18
Capítulo 7: gestión de requerimientos………………………………………….. 22

3. Introducción
La metodología de gestión de requerimientos es una
ingeniería de requerimientos que cumple con las
necesidades de los usuarios, por medio de la recolección
de datos, analizando las diferentes necesidades que están
a su alcance, por medio de ella se implementa una
documentación de los procesos como parte de las
evidencias.
Objetivo
- Promover la recolección de información acerca del
tema
- Fortalecer el conocimiento
- Dar a conocer temas de interés social

4. 1 CAPITULO
IDENTIFICACION DE NECESIDADES DEL CLIENTE
Existen requerimientos para las necesidades del cliente, esto ocurre mediante
entrevistas con el cliente, u obteniendo una documentación que nos lleve a
saber todo acerca del software y su función como tal.
Para entender más detalladamente el funcionamiento de este, a continuación
un diagrama.
Para optimizar y analizar los requerimientos del cliente se pueden implementar
una serie de técnicas de requerimientos para darle un mayor análisis al tema.

5. Las fuentes de información claves:
En caso de que la información no esté completa se debe buscar ayuda por
parte del patrocinador para mayor información eficaz y confiable.
Si tienen proyectos hay que tenerlos en cuenta ya que serán útil para el
funcionamiento de documentos de mayor necesidad.
Dar especificaciones detalladas sobre el proceso a realizar con sus actividades
para que haya un mayor resultado en cuanto al proyecto a realizar.
Dar información sobre las herramientas que se utilizaran para que el proyecto
al finalizar sea exitoso y sin complicaciones.
Beneficios de una buena definición:
El alcance nos ayuda a formar unas condiciones para el mejoramiento de
nuestro proyecto, nos ayuda a estimular nuestro proyecto en cuanto a costos,
tiempo y recursos utilizados, a definir nuestro desempeño en el proyecto, dar a
entender por parte del cliente y equipo del proyecto, en que consiste el
proyecto y cuál es su finalidad.

6. CAPITULO 2
TECNICAS PARA IDENTIFICAR REQUERIMIENTOS
En la actualidad las organizaciones que trabajan en el desarrollo del software,
tienen como fin herramientas para la identificación de requerimientos, estas
herramientas nos rindan mayor rendimiento y entendimiento en la evolución de
los sistemas.
A continuación se implementaran unas herramientas que podrán ser útil para
nuestro desarrollo del proyecto.
1. Técnicas de identificación de requerimientos:
Estas técnicas deben ser orientadas para el mayor funcionamiento del
proyecto, estas técnicas deben tener un dialogo abierto entre el equipo
de desarrollo de software y la empresa cliente.
Una de las características de las técnicas de identificación de
requerimientos son la entrevista, la cual a continuación haremos una
breve descripción:
La entrevista:
Esta técnica es muy utilizada ya que podemos recolectar información
acera de las opiniones y sugerencias de las diferentes actividades a
realizar, debe haber plena comunicación con el cliente para generar
mayor confianza para una mejor estabilidad en el proyecto.

7. A continuación mencionaremos algunas recomendaciones para realizar
una entrevista adecuada para el funcionamiento del proyecto.
- Investigar todo acerca sobre la persona a la que se entrevistara.
- Investigar que la persona a entrevistar tenga un mayor conocimiento
sobre el proyecto a realizar.
- Obtener mayor información sobre los conocimientos de
requerimientos para la realización del proyecto.
Lluvia de ideas
Esta es una técnica abierta y es utilizada para información leve sobre la
realización el proyecto.
Les daremos algunas recomendaciones para el desarrollo de una lluvia
de ideas:
- Tomar una iniciativa para enfocar una relación de confianza con el
cliente.
- Tomar apuntes sobre las ideas que plantean los equipos de trabajo
2. Técnicas específicas para para la identificación de requerimientos
Las técnicas específicas para la información son un complemento de las demás
técnicas generales, esto se realiza con el fin de que sea más detallada la
información.
A continuación se mencionaran algunas de las características que
complementan esta segunda técnica y que es muy importante saberlas para
nuestro proyecto.

8. - Observación:
Esta técnica permite realizar detalladamente la información, en caso de
que sea errónea se corrige, esto se puede realizar con el consentimiento
del cliente y si el equipo del proyecto lo amerita.
- Escenarios:
Esta técnica permite revisar el comportamiento del producto antes de ser
presentado ante el cliente, ya que puede haber algunos errores en el
sistema.
3. Técnicas para identificar requisitos funcionales y no funcionales
Los requerimientos del software están clasificados en funcionales y no
funcionales, entonces estudiaremos algunas técnicas que nos ayudara para
una identificación correcta.
Identificación de requerimientos funcionales
Para la identificación de requerimientos de sistemas se debe estar completo y
bien estructurado. Los problemas que ocurren son una imprecisión en la
identificación de requerimientos, los problemas finalizan después de que se
hace un análisis profundo sobre el daño que ocasiono que el sistema fallara.
Identificación de requerimientos no funcionales
Son aquellas que no se asimilan a la funciones del sistema como tal sino a las
propiedades del sistema, los requerimientos no funcionales surgen cuando el
usuario necesita de ellos, debido al presupuesto a las necesidades que tiene
como usuario.
Esos requerimientos se clasifican según sus implicaciones: se especifican en el
comportamiento del producto, es decir el modo en que se usara, buen
funcionamiento para el cliente, su rapidez de sistema, En el desarrollo del
proceso del sistema, organización de parte del cliente como del equipo del
proyecto, etc.
Aspectos a tener en cuenta en la identificación de
requerimientos funcionales y no funcionales
Siempre se debe iniciar con preguntas básicas y con una sola finalidad, se
deben realizar preguntas acerca de los sistemas o del proyecto en general.

9. Identificación de elementos
Se deben identificar características muy importantes para el desarrollo del
proyecto; una de ellas son el proceso, los flujos de datos entre procesos y
datos de cada flujo de datos.
4. Técnicas de investigación de los atributos de las necesidades de
los clientes
Quien conoce las necesidades del cliente, es el mismo cliente, lo que debemos
hacer es preguntarle al cliente sobre ellas y poderlas solucionar de forma
coherente, lo que se hace es escuchar al cliente y atender sus necesidades.
Para esto se necesitan métodos en el que el cliente comparte sus necesidades,
entre estos métodos están:
 Clientes piloto
Los clientes pilotos son muy importante ya que nos ofrecen herramientas
nuevas para nuestro producto, no es fácil encontrar este tipo de clientes pero
sus beneficios son muy buenos en cuanto a nuestro producto a realizar, es una
ayuda muy beneficiaria ya que puede incrementar el rendimiento y el
funcionamiento de nuestro producto.
 Grupos focales
Los grupos focales son aquellos que eligen a los determinados clientes y
realizan un foro de discusión planteando sus ideas.

10. Con esta herramienta se obtiene mayor información y es más eficaz en el
momento de la aclaración de dudas y una profundización sobre el tema.
 Entrevistas individuales
Estas entrevista individual es más eficaz ya que se entrevista a un cliente en
específico y un entrevistador, este entrevistador debe tener una mayor
capacidad sobre el producto que se va a realizar, saber todo sobre cómo se
realiza una entrevista para darle al cliente una motivación positiva.
 Análisis contextual
En esta herramienta es muy importante el conocimiento del cliente ya que
sus aportes servirán para un nuevo requerimiento. Se le pide al cliente
sobre experiencia y cuál será el uso para nuestro producto y su necesidad
detalladamente, observando sus opiniones acerca del producto.

11. CAPITULO 3
DEFINICION REQUERIMIENTOS
Cuando quieres tener una buena identificación de los requerimientos,
primero hay que saber sobre ellos, información detallada sobre el producto
y también la información involucrada del producto.
Para realizar una identificación adecuada de requerimientos se utilizaran las
siguientes herramientas:
Para hacer una buena definición de los requerimientos es necesario que
sean bien definidos.
 Verificación de requerimientos:
Para la verificación de requisitos se deben añadir criterios de aceptación por cada
requisito, para tener una buena verificación de requerimientos se debe tener en cuenta
las siguientes herramientas:
- El requerimiento sea necesario para el sistema y le de valor al
producto.
- Que en el requerimiento no se encuentren palabras ambiguas que se
refieran a propiedades u objetos
- Se deben confirmar que los involucrados en el negocio y
especificación de requerimiento tiene tienen el mismo entendimiento
acerca de los requisitos específicos.
 Revisión de requisitos vs especificación
Una vez realizada los requisitos anteriores se procede a realizar una
investigación más detallada de ellos con la base de información del
usuario del sistema. En esta revisión participa el equipo de trabajo y los
usuarios específicos.

12. Para su revisión necesitan saber que:
- Que los requisitos estén en su totalidad
- Que los requisitos sean claros y cumplibles por parte de la organización
- Que se tenga documentado todo lo solicitado
- Que estén resueltas sus diferencias entre los requisitos solicitados y los
requisitos definitivos.
 Proceso de verificación de requerimientos
A continuación se presentaran algunos requisitos para la verificación de
requerimientos
 Preparar plan de revisión
Se debe de planear quien asistirá, quien será el vocero del grupo, de que se
va a hablar, etc.
 Documentos de requisitos a revisar
Identificar los documentos de identificación de requerimientos que se va a
revisar.
 Preparar reunión
Se debe confirmar el lugar donde se realizara la reunión y preparar los
materiales necesarios.
 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.
 Identificación de defectos de la especificación
Se revisa el documento, si se encuentra algún defecto o falta alguna
especificación requerida.
 Realización de correcciones a documentos
Cumpliendo con la condición si en el punto anterior se encuentra algún defecto
erróneo, el analista de sistemas tiene que realizar una debida corrección al
documento.

13.  Informar modificaciones a los interesados
Una vez el informe sea corregido se debe informar de las tareas realizadas y
los documentos corregidos a los participantes de 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. CAPITULO 4
TECNICAS PARA DEFINIR REQUERIMIENTOS
Para crear una buena lista es necesario realizar entrevistas talleres en grupo
para crear listas de requisitos. Esto es para que un sistema resuelva las
necesidades del negocio.
Se han solicitado las siguientes herramientas que cumpla con las necesidades
del cliente:
 Definición de diagramas
Cuando iniciamos un desarrollo de sistemas, nos encontramos con el problema
de que no sabemos dar a conocer con mayor especificación el proyecto,
entonces utilizamos esta herramienta como soporte para nuestra explicación.
Usualmente se recomienda usar diagramas UML, de qué manera se puede
utilizar y cómo hacerlo? Se dibujan diagramas solo cuando es necesario.
Se utilizan los diagramas cuando una persona necesita dar a entender un
tema, hay diferentes tipos de diagramas:
- Diagramas de estado: son aquellos que nos muestran los diferentes
opciones de un tema en concreto.
- Diagrama de secuencia: son aquellos en los que se intercambian ideas,
de un mismo tema.

15. - Diagrama de casos de uso: son aquellos que nos describe que es lo que
debe realizar el sistema.
 Definición de caso de uso
Para la definición concreta sobre caso de uso se debe de tener en
cuenta las siguientes características:
- La identificación de actores: identificar características comunes de los
actores que intervienen en el sistema. Hay que tener en cuenta que
algunos factores, ya que pueden llegar a ser un humano un usuario o un
sistema, para eso nos haremos las siguientes preguntas: ¿Quién
proveerá usara o quitara información?, ¿Quién esta o estará interesado
en dicho requerimiento?, ¿Qué otros sistemas necesitaran interactuar
con este sistema?.
- Intereses de los actores: nos hace saber los intereses que tienen los
casos de uso para su desarrollo, nos permite reconocer quien serán los
usuarios con los que vamos a trabajar en el caso de uso.
 Especificación de caso de uso
Los casos de uso tienen que especificar cuál será su función en el
sistema que se va a desarrollar, asi se debe determinar cuando inicia y
cuando termina el caso de uso, que datos se intercambian entre el actor
y el caso de uso, etc.
Se deben tener en cuenta algunos detalles que no se debe realizar en el
caso de uso:
- No dar detalles sobre el usuario, se realiza cuando sea necesario para
entender el desarrollo del sistema.
- Evitar un vocabulario tal como “por ejemplo”, “etc.”, “información”
- No dejar texto que sean ambiguos o preguntas que se debieron resolver
en la información
 Prototipos
Para un prototipo es muy importante elegir un objetivo, ya que puede ser
muy útil para el proyecto que se desea realizar, el objetivo debe ser claro
para la cada etapa del proyecto.
Características de prototipos:
- El prototipo es una herramienta que puede que no funcione ejemplo de
ello es conjunto de dibujos o presentación en escenarios y otros casos si
funcionen, ejemplo de esto es conjunto de pantallas que proporcionan

16. un modelo dinámico, se crean con rapidez, evolucionan a raves de un
proceso interactivo, tienen bajo costo en su desarrollo.
 Definición de los criterios de aceptación
Esta herramienta nos permite asegurar que los requisitos empleados
cumplen con su función, esto hace que obtenga una aceptación tanto
para el cliente como para la empresa que lo va a desarrollar.
Para la definición de los criterios de aceptación se debe tener en cuenta
los siguientes detalles:
- El requisito no debe tener escenarios ambiguos, se debe cumplir con
todos los escenarios, el requisito debe ser medible, asi es fácil de
identificar si cumple o no cumple, el requisito debe de ser aprobado y
aceptado por el proceso, cumplir con los requisitos que algunas veces el
cliente solicita, entregar los requisitos dentro de las fechas establecidas.

17. Capítulo 5 PRUEBA DE REQUERIMIENTO:
La meta de las pruebas de verificación es buscar la calidad, en la ejecución del software;
pariendo de esto, seguimos las actividades para que dichas pruebas ya realizadas a los
productos estén en buen funcionamiento, se tiene en cuenta los siguientes pasos:
PLANEACIÓN:
En la primerafase,se realizaunaspruebasde alcance para observar cuanto limita el producto
antes de la venta, la estrategia de venta para la ejecución de venta, los requerimientos de
prueba(documentación,recursoshumanosyrecursostecnológicos), el tiempo estimado para
la misma y las observaciones para la terminación.
DISEÑODE CASOS DE PRUEBA:

18. Vamosa definirel “checklist”conlascaracterísticas para el requerimiento.El siguiente listado
nos muestra las características evaluados de dichos requerimientos:
EJECUCIÓN DE CASOS DE PRUEBA:
De acuerdo con el “check list” que se a realizo al producto en caso de prueba (conciso,
contraposición, ambigüedad y completitud, etc.), se reportara los errores, sugerencias y se
realizaranreuniones para hablar y decidir lo planteado es solucionado o el requerimiento es
correcto.
CIERRE:
En esta última fase, ya que se hayan realizado las pruebas se hace el cierre de prueba donde
cuyos resultados salen exitosamente correspondiente a lo esperado y además se coloca el
visto bueno a los requerimientos evaluados.
Capítulo 6 GESTION DE CAMBIOS:
La gestión de cambios en un proyecto debe ser una coordinación que planifica ciertas
actividades que llevan a los objetivos o metas propuestas en común a través de una
comunicación concreta y eficiente.
A continuación mostraremos el proceso de gestión de cambios con las actividades que se
deben llevar a cabo:

19. IDENTIFICACIÓN CONTROL DE CAMBIO:
Para una clara y sobretodocorrectaidentificaciónde losrequerimientosde laorganización del
software, se identifican estas siguientes actividades:
 ANALISIS DE SOLICITUD:
La solicitud del cliente ya sea interno o externo, es recibida a través del líder de
implementos para ser analizada. El alcance y el tiempo son los puntos más importantes
para ser analizados,estoconel finde identificar si la solicitud es viable para ser realizada
sobre el mismo requerimiento o por el contrario, ser manejada como un requerimiento
nuevo.

20.  VALORAR EL CAMBIO:
Uno de los puntos importantes es valorar la fácil solicitud realizada por el cliente ya sea
internooexterno.Paraestose deberáirllevandotodounárbol de requisitos, observando
cómo reaccionan al cambio y en esa parte entra lo que es la trazabilidad de requisitos.
 ANALIZAR MODIFICACIÓN:
El líder debe plasmar lo solicitado por el cliente para saber si impactara el cambio o
identifica si modifica las solicitudes que puede afectar al requerimiento y así se podrá
identificar que tanto puede afectar a más de un requerimiento.
 DOCUMENTAR CAMBIO:
Para tenerun mejor control o rendimiento de los cambios realizados es mejor utilizar un
tipo documentación donde pueda diferenciar o si es mejor evitar las ambigüedades en
estos requerimientos realizados. Esto nos ayuda a tener ese control de ciertas
modificaciones que se le hacen al requerimiento y mantener informado al grupo de
trabajoy obviamente al clientede lasactualizacionesque se le hacenenlos documentos y
de que también cual es la razón y por supuesto quien apoyo el proyecto.
APROBACION DE CONTROL DE CAMBIOS:
 APROBAR CAMBIOS:
Una vez habladoyanalizadoel cambio, se tiene que llegar a una conclusión o decisión. Si
estose llegara aprobar, tras ser negociado con el cliente, se sigue con el funcionamiento
de mejorarlo aun más. Si en caso de lo contrario se negociaría con el cliente y seguir las
otras opciones.
 PLANEAR CAMBIO:
Ya una vez hecho una cierta aprobación formal, se realiza una estrategia de tiempo de
espera y ciertos recursos para realizar el cambio apropiado.
 REALIZAR CAMBIO:
Una vez ya habladocony planeado,se realiza esas modificaciones del cambio a todos los
productos para que sean afectados por igual por este dicho cambio.
 ACTUALIZAR LINEA BASE:
Es muy importante y también recomendable realizar un segundo requerimiento como
LINEA DE BASE,y con estoespara trabajarcon la última versión o actualización trabajada.
 INFORMAR:
Una vez realizadolamodificación de lo pedido, se debe informarle a los interesados que
dicho cambio ya esta echo y que este verificado por los mismos clientes.

21. ENTREGABLE CONTROL DE CAMBIOS:
Como ya lo habíamos hablado en los anteriores puntos, es muy importante el control que
apoye a la identificaciónde lasolicitudde uso exclusivo para los clientes internos o externos.
Este documento no tiene que ser ambigua y por supuesto debe ser válida por el cliente y la
empresa.
Capítulo 7 GESTIÓN DE REQUERIMIENTO:
Se debe aplicar para el cliente en pro una necesidad satisfactoria y un control a cerca del
proyecto en general, se debe cumplir los siguientes pasos:
MATRICES DE TRAZABILIDAD
 MATRIZ DE RELACIÓN DE DOCUMENTOS
En esta Matriz nos enseña cuales son las relaciones de documentación que en cada
requisito debemos clasificar si es funcional o no funcional para calificarlas en negocio,
usuario o sistema; ya que en cada uno de sus casos se realizan pruebas asociados, la

22. dependencia con otros requerimientos y las peticiones de cambio en caso que las tenga.
 MATRIZ DE VALORACIÓN Y APROBACIÓN DE LOS REQUISITOS:
Esta matriznos permite identificarsi el requisito cumple o no con todas las etapas que se
llevan a cabo con la metodología y si es una posibilidad de que se cumpla con todo los
criterios se dará por cerrado y aprobado al requisito.
En el modo de desarrollo, se deja a cargo una persona que revise el chequeo que se
cumplacon todoel procesoy documentaciónparaque se pueda dar un dictamen correcto
y se pueda leer de la siguiente manera:
*Cumple=C, esto nos indica que el requisito cumple con el criterio correctamente, se
encuentra en color verde.
*No cumple=N,El colorrojoes para dar una señal de alertainformandoque el requisitono
estácumpliendocorrectamente conel criteriode aceptaciónyque 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.

23. MATRIZ DE CONTROL DE CAMBIO:
Esta matriz de control de cambio nos permite ver qué cambios se han hecho, en esta matriz
podemosregistrarlosnúmerosde control que se le asignaronalosproductos,la referencia de
dicho producto o control, quien aprueba el control, quien realiza el cambio, por quien fue
revisado por si ya se paso por revisado, su porcentaje de control hasta llegar a 100%, los
requisitos afectados y una descripción del control.
Podemos observar el control detalladamente de cambios solicitado y de su estado actual.