Metodología Gestión de Requerimientos

1. TRABAJO DE ALGORITMO
PRESENTADO POR: Cristian David Paredes Fernández
PRESENTADO A: HUGO FERNANDO POLANIA DUSSAN
CENTRO AGROEMPRESARIAL Y DESARROLLO PECUARIO DEL HUILA
SENA-GARZON
TECNOLOGO EN ANALISIS Y DESARROLLO EN SISTEMAS DE
INFORMACION
866036

2. Metodología Gestión de Requerimientos
Capitulo 1° "IDENTIFICACIÓN DE NECESIDADES CON ELCLIENTE"
Para identificar las necesidades del cliente se debe realizar una entrevista en la
cual se debe determinar la manera como el cliente desea adquirir un software,
es esta entrevista se determinara el costo y el tiempo de desarrollo de software.
Luego se le facilitara unas técnicas al usuario el cual decidirá para la ejecución
del proyecto
Definición del alcance
La definición del alcance tiene como propósito describir y delimitar claramente
las necesidades del cliente, las cuales pretenden ser cumplidas con el
proyecto.
Fuentes de información claves
Se debe tener información clave para definir el alcance final de una manera
detallada
Se recomienda tener en cuente esta información para cumplir cada uno de los
objetivos
Beneficios de una buena definición
Se ahorran tiempo y recursos del proyecto
Se asigna con responsabilidad los recursos establecidos
Definir el empeño y control del proyecto

3. Capítulo 2 TÉCNICAS PARAIDENTIFICAR REQUERIMIENTOS
En la actualidad para la elaboración de un software que usa distintas
herramientas se deben primero identificar distintas técnicas de requerimiento
las cuales son:
Técnicas generales para la identificación de requerimientos:
Están conformados por tres:
Entrevista: es muy utilizada para la recolección de opiniones e criterios
que sirven para desarrollar distintas actividades.
Cuestionario: esta dirigida a un público en específico, para obtener
mayor información.
Lluvia de ideas: esta es utilizada por un equipo de trabajo el cual
expones ideas para un beneficio.
Técnicas específicas para la identificación de requerimientos
Este consiste en agrupar dos técnicas generales que se complementas
en este caso la observación y el escenario .
Observación: esta permite dar a conocer las actividades realizadas.
Escenario: esta permite conocer el comportamiento de evento
conformado.
Técnicas para Identificar Requisitos Funcionales y No Funcionales
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.

4. Identificación de Requerimientos no funcionales
Son las propiedades emergentes de éste como la fiabilidad, la respuesta
en el tiempo y la capacidad de almacenamiento. De forma alternativa,
definen las restricciones del sistema como la capacidad de los
dispositivos de entrada/salida y la representación de datos que se utiliza
en la interface del sistema.
Técnicas de investigación de los atributos de las necesidades de
los clientes
Esta se encarga de reunir información en los distintos grupos para luego
analizarlas.
Grupos focales:
Está conformado reuniendo a un grupo seleccionado de clientes,
conjuntamente con un moderador que va a conducir un debate de grupo
sobre una serie de aspectos y cuestiones concretas en las que se
focaliza la discusión.
Análisis contextual:
Con esta técnica cliente que cuente su experiencia de uso y responda a
las sagaces y hábiles preguntas de los métodos anteriores, sino que se
le solicita, además, ver cómo utiliza el producto para comprender el
porqué de su necesidad y discutir sobre el terreno cada uno de los
detalles y particularidades de uso.
Clientes piloto:
Es un Clientes de alto prestigio y conocimiento que pueden ofrecer un
formidable campo de pruebas para el nuevo producto. Claro está que no
es fácil encontrar este tipo de clientes piloto, pero también es claro que
los beneficios de esta técnica son elevados.

5. Capítulo 3 DEFINICIÓN REQUERIMIENTOS
Para realizar una correcta definición de los requerimientos del proyecto y
que éstos satisfactorios para el cliente, se deben tener en cuenta las
siguientes actividades:
Requerimientos Funcionales:
Estos determina el software, definiendo las relaciones de su operación y
su implementación, también en lo que el sistema no debe hacer y que
validaciones se deben realizar, teniendo en cuenta cual será el
comportamiento del sistema.
Requerimientos no funcionales:
Estos 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.

6. Capítulo 4 TÉCNICAS PARADEFINIR REQUISITOS:
Para obtener los requisito Técnicas más modernas incluyen los
prototipos del cliente se emplear distintas técnica, tales como las
entrevistas, 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
Definición de diagramas:
Cuando se inicia con el desarrollo de un sistema por lo general nos
encontramos con la dificultad de no saber como 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.
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.
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

7. Cuando dos o mas 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.
Capítulo 5 PRUEBAS DE REQUERIMIENTOS:
El objetivo de las pruebas de verificación es buscar discrepancias entre
los requerimientos y la ejecución del software.
Planeación: tiempo y recursos del proyecto.
Diseños y casos de pruebas: para la verificación del requerimiento
Ejecución: evaluación del requisitos, reportes (errores y sugerencias)
Cierre: visto buena para la aprobación.
Capítulo 6 GESTIÓN DE CAMBIOS
La gestión de cambio en los proyectos debe ser una coordinación
planificada de las actividades que conlleve el logro de los objetivos o
propósitos comunes a través de una comunicación clara y eficiente.
Identificación Control de cambios:
Análisis de la Solicitud:
La solicitud es recibida por parte del cliente interno o externo, esta debe
ser recibida por parte del líder de implementación para ser analizada.
Uno de los puntos importantes para analizar son el Alcance y el Tiempo,
esto con el fin de identificar si la solicitud es viable realizarla sobre el
mismo requerimiento.

8. 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á ir
recorriendo todo el árbol de requisitos viendo como les afecta el cambio,
y aquí es donde entra la trazabilidad de los requisitos.
Analizar Modificación
El líder de implementación debe realizar el análisis de la solicitud para
saber que tanto impacta la modificación e identificar puntualmente las
modificaciones solicitadas que afectan el requerimiento completo y así
identificar si el cambio afecta más de un requerimiento.
Documentar Cambio
Para tener un mejor control sobre los cambios solicitados es
recomendable realizar una documentación clara para evitar
ambigüedades en las modificaciones que se van a realizar a los
requerimientos.
Aprobación Control de Cambios
Aprobar Cambios
Una vez se ha analizado el impacto del cambio, se debe tomar una
decisión. Si se acepta el cambio, tras negociarlo con el cliente, se
continuará con la actividad de implementar el cambio. En caso contrario,
se deberá negociar con el cliente el siguiente paso a realizar.
Planear Cambio

9. Después de tener una aprobación formal del cambio aceptado se planea
el tiempo necesario y los recursos necesarios para llevar a cabo el
cambio aprobado.
Realizar Cambio
Una vez se planea el cambio aprobado se debe realizar las
modificaciones necesarias a todos los productos que resulten afectados
por dicho cambio.
Revisar Cambio
Una vez se realice el cambio es recomendable hacer una verificación
por parte del líder para identificar que el requerimiento incluye todos los
cambios solicitados y que fueron aprobados.
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
Una vez se realice la modificación de la solicitud se debe informar a los
interesados que el cambio ya está realizado para que sea verificado por
el cliente.

10. Capítulo 7 GESTIÓN DE REQUERIMIENTO:
Matriz de relación de documentos:
Matriz de valoración y aprobación de los requisitos
La siguiente matriz de trazabilidad es la que nos permite valorar si el
requisito cumple con todas las etapas llevadas a cabo en la
metodología, en caso que todos los criterios se cumplan se dará por
cerrado y aprobado el requisito.
Cumple=C, esto nos indica que el requisito cumple con el criterio
correctamente, se encuentra en color verde.
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.

11. Matriz de Control de cambios
La matriz de control de cambios nos permite registrar los controles de
cambios que se van presentando, en esta matriz podremos registrar el
número de control de cambio que se tiene asignado, la referencia a la
documentación de dicho control, quien aprobó el control, su porcentaje
de ejecución hasta llegar al 100%, el o los requisitos afectados y una
descripción breve del control de cambios.