Metodologia de gestion de requerimientos

si los requerimientos se enfocan a describir las necesidades del cliente, entonces para recabarlos haya que obtener la información de primera mano. Esto es mediante la entrevista u obteniendo la documentación del cliente que describa la manera de como el cliente desee que funcione el software.

1. 111111



METODOLOGIA DE
GESTION DE
REQUERIMIENTOS

CENTRO AGROEMPRESARIAL Y DESARROLLO PECUARIO DEL HUILA
TEGNOLOGO EN ANALISIS Y DESARROLLO DE SISTEMAS DE
INFORMACION (ADSI) 866036
MAICKOLL STIVENS
RAMIREZ GUTIERREZ
CRISTIAN DAVID PAREDES
FERNANDEZ

3. Contenido
DEFINICION DE ALCANCE ..........................................................................................4
FUENTES DE INFORMACION ..............................................................................................5
RECOMENDACIONES PARA DEFINIR EL ALCANCE..............................................................7
BENEFICION DE UNA DEFINICION ....................................................................................7
1. Técnicas generales para la identificación de requerimientos............................................9
Entrevista .....................................................................................................................9
Lluvia de ideas ............................................................................................................ 10
Cuestionarios .............................................................................................................. 10
2. Técnicas específicas para la identificación de requerimientos ........................................ 11
OBSERVACIÓN ............................................................................................................ 11
ESCENARIOS ............................................................................................................... 11
3.Técnicas para identificar requisitos funcionales y no funcionales .................................... 12
IDENTIFICACION DE REQUERIMIENTOS FUNCIONALES................................................... 12
IDENTIFICACION DE LOS REQUERIMIENTOS NO FUNCIONALES ...................................... 12
ASPECTOS A TENER EN CUENTA EN LA IDENTIFICACION DE REQUERIMIENTOS
FUNCIONALES Y NO FUNCIONALES............................................................................... 13
IDENTIFICACION DE ELEMENTOS.................................................................................. 13
4.TEGNICAS DE INVESTIGACION DE LOS ATRIBUTOS DE LAS NESESIDADES DE LOS CLIENTES
...................................................................................................................................... 14
GRUPOS FOCALES ........................................................................................................... 14
ENTREVISTA INDIVIDUAL................................................................................................. 14
ANALISIS CONTEXTUAL ................................................................................................... 14
CLIENTE PILOTO ............................................................................................................. 14
DEFINICIÓN DE REQUISITOS ............................................................................................ 15
CLASIFICACIÓN DE REQUERIMIENTOS .............................................................................. 16
REQUERIMIENTOS FUNCIONALES:................................................................................ 16
REQUERIMIENTOS NO FUNCIONALES ........................................................................... 16
PREPARAR PLAN DE REVISIÓN: ........................................................................................ 16
PREPARAR REUNIÓN: ...................................................................................................... 16
REALIZAR REUNIÓN: ....................................................................................................... 16
IDENTIFICAR DE DEFECTOS DE LA ESPECIFICACIÓN: .......................................................... 17
REALIZACIÓN DE CORRECCIONES A LOS DOCUMENTOS: ................................................... 17
INFORMAR MODIFICACIONES A LOS INTERESADOS: ......................................................... 17
CIERRE DE LOS REQUERIMIENTOS:................................................................................... 17

4. DEFINICIÓN DE DIAGRAMAS............................................................................................ 18
Cuando no Utilizar Diagramas ...................................................................................... 18
Cuando Utilizar los Diagramas...................................................................................... 18
De estados:................................................................................................................. 19
De secuencia:.............................................................................................................. 19
De caso de uso: ........................................................................................................... 19
DEFINICIÓN DE CASOS DE USO ........................................................................................ 19
La identificación de actores: ........................................................................................ 19
Intereses de los actores: .............................................................................................. 19
La identificación de eventos y escenarios que este podría llegar a tener: ........................ 20
Especificación de Casos de uso ........................................................................................ 20
Prototipos ...................................................................................................................... 21
Características de un prototipo .................................................................................... 21
Definición de criterios de aceptación ............................................................................... 21
Planeaciones .................................................................................................................. 22
Diseño de casos de prueba .............................................................................................. 23
EJECUCIÓN DE CASOS DE UNA PRUEBA ............................................................................ 23
Cierre............................................................................................................................. 23
Identificación control de cambios. ................................................................................... 25
Valorar el cambio ....................................................................................................... 25
Analizar modificación .................................................................................................. 25
Documentar cambio.................................................................................................... 26
Aprobación control de cambio......................................................................................... 26
Aprobar cambios......................................................................................................... 26
Planear cambio ........................................................................................................... 26
Realizar cambio........................................................................................................... 26
Revisar cambio............................................................................................................ 26
Actualizar line base ..................................................................................................... 26
Informar ..................................................................................................................... 26
Entregable control de cambios ........................................................................................ 26
Matriz de relación de documentos............................................................................... 27
Matriz de valoración y aprobación de los requisitos ................................................... 27
Matriz de Control de cambios ...................................................................................... 28

5. Capí tulo 1 “IDENTIFICACION DE
NESESIDADES CON EL CLIENTE
si los requerimientos se enfocan a describir las necesidades del cliente,
entonces para recabarlos haya que obtener la información de primera mano.
Esto es mediante la entrevista u obteniendo la documentación del cliente que
describa la manera de como el cliente desee que funcione el software.







DEFINICION DE 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.
Es importante para la definición del alcance la identificación de los siguientes
aspectos:

6. Los entregables que hacen parte del alcance.
se recomienda describir y listar los entregables finales principalmente los que
deben ser aprobados por el cliente.
Los tipos de datos que están en el alcance y fuera de él. Los “tipo de
datos” se refieren a la categoría del negocio de los entregables tales como
datos financieros, datos de ventas, datos de los empleados, etc.

Las fuentes de datos (bases de datos) que están en el alcance y
fuera de él. Esto es similar a los tipos de datos, excepto que ahora se está
refiriendo a los datos agregados tales como base de datos de clientes,
Contabilidad general, sistema de facturación y cobranza, etc.

Áreas involucradas en el alcance y fuera de él. En algunos casos, las
áreas involucradas en el proyecto ayudan a delimitar el alcance.

Condiciones fuera del alcance. Se recomienda como punto de claridad y
contraste al describir entregables que no serán creados, qué organizaciones no
serán impactadas, qué facilidades y funciones no serán incluidas, entre otros
aspectos.


FUENTES DE INFORMACION
Cualquier información creada debe ser usada como base para definir el
alcance de manera más detallada. Si no se cuenta con suficiente información
para la definición del alcance, se debe buscar apoyo con el patrocinador para
reunir información adicional.

8. RECOMENDACIONES PARA DEFINIR EL ALCANCE
Algunas recomendaciones son:
 Desarrollar un escrito o un documento frontal
 Detallar claramente que actividades y procesos que son parte del
proyecto
 Definir los criterios que se utilizarán para determinar si el proyecto ha
finalizado exitosamente, es decir, los criterios de aceptación.
 Al definir el alcance, tener en mente que lo que no esté en el alcance
está fuera del proyecto.
 Al definir el alcance, tener en mente que lo que no esté en el alcance
está fuera del proyecto. Al definir el alcance, tener en mente que lo que
no esté en el alcance está fuera del proyecto.
 Formalizar la aceptación del alcance con el cliente.


BENEFICION DE UNA DEFINICION
El alcance marca la pauta para la toma de decisiones futuras y realización de
actividades a nivel Operativo y nos ayuda a:
 Mejorar la precisión en las estimaciones de tiempo, costo y recursos.
 Facilitar la asignación clara de recursos y responsabilidades.
 Definir la línea base para la medición del desempeño y control
 Identificar, tanto el equipo de proyecto como el cliente, el objetivo final
del proyecto y sus entregables.
 Desarrollar y confirmar un entendimiento común del proyecto entre
ambas partes, cliente y equipo de proyecto.
 Asegurar que el proyecto incluye todo el trabajo requerido y solamente el
trabajo requerido para terminar exitosamente. "Asegurar que el proyecto
incluye todo el trabajo requerido para terminar exitosamente."

9. CAPITULO 2 TEGNICAS PARA
IDENTIFICAR REQUERIMIENTOS

En la actualidad las organizaciones enfocadas al desarrollo de aplicaciones de
software utilizan diferentes herramientas que permiten facilitar la fase de
identificación de requerimientos, puesto que se presta mayor atención a las
necesidades que se identifican en todas las fases del ciclo de vida del sistema;
para así obtener un mejor aprovechamiento, entendimiento, y rendimiento al
momento que entre en ejecución el sistema que se esté desarrollando.

Las organizaciones actuales utilizan múltiples herramientas para el apoyo de la
identificación de los requerimientos.

A continuación se especifican cada una de las técnicas utilizadas:
o Técnicas generales para la identificación de requerimientos
o Técnicas específicas para la identificación de requerimientos
o Técnicas para Identificar Requisitos Funcionales y No Funcionales
o Técnicas de investigación de los atributos de las necesidades de los
clientes
o
A continuación se presenta documento de uso opcional como apoyo para
identificación y definición de requerimiento:
Formato Objetivo
MR_002_Entrevista (Ver formato) Sugerir las preguntas que permitan detallar el
requerimiento.

10. 1. Técnicas generales para la identificación de requerimientos

Las técnicas generales son las que permiten investigar aspectos generales
para posteriormente ser especificado con mayor detalle con el apoyo de
técnicas más específicas. Estas técnicas son más abiertas y requieren ser
adecuadamente orientadas para cubrir a información que se quiere capturar.


Entrevista
 Esta técnica es muy utilizada para recolección de opiniones, criterios o
descripciones.
 Se lleva a cabo mediante conversaciones estructuradas
 Es fundamental que la relación con el cliente este basada en confianza
para dar a conocer la información más detallada

Antes de iniciar una entrevista es importante tener en cuenta los siguientes
Tips.

1. estudiar al tipo de persona a las cuales se les realizara la entrevista.
2. Estudiar cómo será el entorno donde se llevara a cabo la entrevista
para identificar que tan confortables estarán las personas y así obtener la
información de la manera más eficiente.

11. 3. Estudiar como es la manera de hablar de las personas individualmente
o en un equipo de trabajo.
4. Verificar que las personas tengan la disponibilidad para dar a conocer
las necesidades que posterior a esto se puedan convertir en requerimientos.
5. Revisar como es la relación del cliente con la organización que realizará
la identificación de los requerimientos, esto con el fin de facilitar el trabajo y
la disposición de ambas partes.
6. Entender que es importante obtener la mayor información para la
definición de los requerimientos, teniendo en cuenta que nada es obvio para
las organizaciones de desarrollo de software.


Lluvia de ideas

 Esta técnica es abierta y se utiliza para explorar necesidades iniciales
con la ayuda de la identificación de ideas de todas las personas que
hacen parte del equipo de apoyo para la identificación de los
requerimientos.
 Es utilizada para investigar nuevos servicios o necesidades que no son
claramente identificadas.
Algunos Tips para tener en cuenta cuando se realice una lluvia de ideas:
1. Escoger un sitio tranquilo que permita que las personas
involucradas se sientan cómodas y dispuestas para dar a conocer
sus ideas.
2. Tomar la iniciativa para iniciar una reunión enfocada en la
confianza.
3. Tomar nota de las ideas que las personas expresan en los equipos
de trabajo.
Cuestionarios
Esta técnica puede ir dirigida a un público específico o general, lo que
permite obtener una información mayor, ya que se tiene la posibilidad de
involucrar más personas para el desarrollo de los cuestionarios y que estos
tengan diferentes puntos de vista. Lo importante es tener en cuenta que se
debe tener un mayor cuidado en la selección de los encuestados y de la
forma en que se pregunta para obtener respuestas concretas y confiables

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

Las técnicas como las especificas permiten complementar las técnicas
generales para tener mayor detalle.


OBSERVACIÓN
Esta técnica permite obtener información directa sobre la manera en que se
realizan las actividades. Esta técnica sirve para revisar que no existen
emisiones o interpretaciones erróneas sobre el proceso realizado.
ESCENARIOS
Esta técnica permite conocer el comportamiento del producto ante
determinados eventos considerando los datos, acciones y acepciones que se
pueden presentar.

13. 3.Técnicas para identificar requisitos funcionales y no funcionales


Ya que los requerimientos del sistema de software se clasifican en funcionales
y no funcionales deben tener en cuenta las siguientes técnicas para para la
identificación correcta.


IDENTIFICACION DE REQUERIMIENTOS FUNCIONALES

Los requerimientos funcionales son declaraciones de los servicios que
proveerá el sistema, de manera en que este reaccionara a entradas
particulares.

 Muchos de los problemas de la ingeniería de software viene de la
impresión de la especificación de requerimientos.
 Para un desarrollador es natural dar interpretaciones de un
requerimiento ambiguo.

En la práctica para sistemas grandes y complejos, es imposible cumplir los
requerimientos de consistencia y compleción. Esto se debe a la complejidad
inherente del sistema y parcialmente a que los diferentes puntos de vista tienen
necesidades inconsistentes.


IDENTIFICACION DE LOS REQUERIMIENTOS NO FUNCIONALES

1. No se refiere directamente a las funcionales específicas que entrega el
sistema, sino las propiedades emergentes de este.
2. Define la restricciones del sistema como la capacidad de los dispositivo
de entrada y salida.
3. Surgen de la necesidades del usuario como:
 Las restricciones en el presupuesto
 Las políticas de la organización
 La necesidad de lainteroperabilidad

Estos diferentes requerimientos se clasifican en:

1) Requerimientos de producto. Especifican el comportamiento del producto.
2) Requerimientos organizacionales. Se derivan de las políticas y
procedimientos existen en la organización del cliente y en la del
desarrollador.
3) Requerimientos externos. Se derivan de los factores externos al sistema y
de su proceso de desarrollo.

14. ASPECTOS A TENER EN CUENTA EN LA IDENTIFICACION DE
REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Requerimiento básico: se estructura su identificación al buscar respuestas a
preguntas como:

 ¿Cuál es el proceso básico de la empresa?
 Que datos utiliza o produce este proceso?
 Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
 Que controles de desempeño utiliza?


Las siguientes preguntas sin de utilidad para recibir la comprensión necesaria:

 ¿Cuál es la finalidad de la actividad dentro de la empresa?
 Que pasoso se siguen para realizarla?
 ¿Dónde se realizan estos pasos?
 ¿Quiénes los realizan?
 Cuanto tiempo tardan en efectuarlos?
 Con cuanta frecuencia lo hacen?
 Quienes emplean la información resulrante?


IDENTIFICACION DE ELEMENTOS

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

 Proceso
 Flujo de datos entre procesos
 Datos de cada flujo de datos
 Bases de datos
 Datos de base de datos

15. 4.TEGNICAS DE INVESTIGACION DE LOS ATRIBUTOS DE LAS
NESESIDADES DE LOS CLIENTES

Lo que se hace es preguntarle al cliente sobre cada una de sus necesidades,
con el objetivo de clasificar y ponderar su importancia.

Este proceso de investigación debe ser suficientemente inteligente para
conseguir respuestas que permitan elevar realmente el nivel de competitividad
de la solución buscada.


GRUPOS FOCALES
 se conforman 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 la que se focaliza
la discusión.
 En el debate se establece una relación de afinidad por lo que todas las
respuestas giran en torno a la situación a analizar.


ENTREVISTA INDIVIDUAL

Esta técnica en más eficaz que la anterior, es entre un experto del cliente y el
entrevistador cualificado del equipo de análisis. Tiene unas ventajas sobre el
grupo focal y es que se puede matizar en un espacio de mayor privacidad.

Si el moderado, en el caso de los grupos focales, el entrevistador juega el
papel de crítico, no solo tiene que dominar las técnicas de la entrevista, sino
que además debe reunir la experiencia y dominio suficiente sobre el tema
discutir para generar al cliente una motivación positiva.


ANALISIS CONTEXTUAL
Con esta técnica lo que se hace no solo es pedir al cliente que cuente su
experiencia de uso y responda las preguntas de los metodosanteriores, sino
que le solisite además ver como utiliza el producto para comprender el por que
de su necesidad y discutir sobre el terreno cada uno de los detalles y
particularidades de uso.

CLIENTE PILOTO
Un método de investigación mas sofisticado es utilizar clientes piloto. clientes
con alto prestigio y conocimiento que pueden ofrecer un formidable campo de
pruebas para el nuevo producto.

16. Capí tulo 3 DEFINICIO N
REQUERIMIENTOS
Para tener una buena definición de requerimientos es necesario realizar una
buena identificación de los mismos, posterior a esto es importante definirlos de
manera detallada, donde se involucre la información aportada por los usuarios
Para realizar una correcta definición de los requerimientos del proyecto y que
éstos satisfagan las necesidades verdaderas del cliente, se deben tener en
cuenta las siguientes actividades:




DEFINICIÓN DE REQUISITOS

Para realizar con éxito la definición de los requerimientos es importante
conseguir que los requerimientos sean claramente definidos para minimizar la
ambigüedad de los requerimientos, para esto es importante tener en cuenta lo
siguiente:

 Definir los requerimientos teniendo en cuenta la información identificada
con la perspectiva del usuario

 Reutilizar requerimientos, revisando proyectos ya finalizados para ver si
contienen material potencialmente reutilizable. La ventaja de esta
reusabilidad es que, una vez que un requisito ha sido especificado
satisfactoriamente para un producto y que el producto ha tenido éxito, el
requerimiento no tendrá que volverse a inventar, podrá ser utilizado las
veces que se desee teniendo en cuenta los derechos de autor.

 Se debe documentar los requerimientos de una forma clara y correcta.
En la mayoría de los proyectos se observa que la documentación de los
requerimientos puede parecer una tarea tediosa, pero es la única
manera de asegurar que la esencia de los requisitos ha sido capturada
correctamente, y que esto pueda ser probado.

17. CLASIFICACIÓN DE REQUERIMIENTOS
REQUERIMIENTOS FUNCIONALES:

Estos requerimientos se utilizan para determinar que hara el software
definirndo la relación de su operación y su implementación.
a) Los requerimientos se dividen en dos puntos de vista: el primero tiene
relación con el usuario y el segundo tiene relación con el sistema dando
respuesta al usuario.
REQUERIMIENTOS NO FUNCIONALE S
a) Estos requerimientos se basan en las restricciones de los servicios o
funciones ofrecidos por el sistema.
b) 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.
c) 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.

PREPARAR PLAN DE REVISIÓN:
En la preparación del plan de reunión se deben planear quienes deben asistir,
que se va a hablar y cuánto tiempo se va a demorar.
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.

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

19. Capí tulo 4 TE CNICAS PARA DEFINIR
REQUISITOS
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.

DEFINICIÓN DE DIAGRAMAS
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
o No dibujar diagramas porque el proceso te lo dice
o 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.
o Dibujar diagramas para que otra persona codifique

Cuando Utilizar los Diagramas
o 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
o 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
o 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
o 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:

20. 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
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:
o Quién o qué inicia eventos con el sistema?
o Quién proveerá, usará o quitará información?
o Quién usará esta funcionalidad?
o Quién está interesado en cierto requerimiento?
o En que parte de la organización será usado el sistema?
o Quién dará soporte y mantendrá el sistema?
o Cuales son los recursos externos del sistema?
o Qué otros sistemas necesitarán interactuar con este sistema?

Intereses de los actores:

21. La identificación de estos intereses nos permite 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 necesaria para poder determinar
cuál 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:
o No describir detalles de la interfaz del usuario, a menos que sea
necesario para entender el comportamiento del sistema.
o Evitar terminología vaga tal como “por ejemplo” “etc” “información”.
o 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

o El conjunto de todos los casos de uso, debe cubrir los requerimientos del
sistema en su totalidad.
o Se pueden definir casos de uso en diferentes niveles.
o A nivel de sistema de Negocio
o A nivel de sistema de Software
o Las descripciones de los casos de uso son cruciales para la
comprensión del sistema.

22. o 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.


Características de un prototipo

o 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).
o Los prototipos se crean con rapidez
o Los prototipos evolucionan a través de un proceso iterativo.
o 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:
o Se debe encontrar el documento de requisito terminado, revisado y
aprobado por las diferentes partes, implicadas.
o El requisito no debe tener escenarios ambiguos

23. o El requisito debe hacer que dice el documento de especificación ni mas,
ni menos y cumplir con todos los escenarios.
o El requisito debe ser medible, es fácil identificar si cumple o no cumple.
o No existe contraindicaciones con otros requisitos
o El requisito debe haber sido probado y aceptado por este proceso.
o Se debe entregar el requisito dentro de las fechas establecidas.
o El requisito aparte de cumplir con los anteriores pasos, puede haber
otros criterios que el cliente solicite.

Capí tulo 5 PRUEBAS DE
REQUERIMIENTOS

En este capítulo quiere decir que su objetivo de las pruebas es verificar y
buscar los requerimientos y el desarrollo de un software.

Planeaciones
Esta se basa en en los alcances y limitaciones que hay de la prueba, estrategia para
luego utilizarla en la ejecución de la prueba.

Los siguientes pasos para realizar la prueba es:

-Documentación.
-Recurso humano.
-Recurso tecnológico.

24. Diseño de casos de prueba
en este diseño se define el checkilts con las características a evaluar de los
requerimientos.

EJECUCIÓN DE CASOS DE UNA PRUEBA
En esta fase se evalúa cada uno de los de requerimientos de acuerdo con el
checklist definidos como casos de prueba:

-Conciso
-Contraposición
-Ambigüedad
-Completitud, etc…

En estas se reportaran las condiciones sugerencias

Para hacer aclaraciones y definir si las consideraciones planteadas van a ser
solucionadas o si el requerimiento es correcto.
Cierre
Aquí en el cierre donde ya se haya completado la ejecución con los resultados
satisfactorios y los ajustes correspondientes se realiza el cierre de la prueba
donde se dará el visto bueno sobre los requisitos que serán evaluados.

Formato Objetivo
MR_005.1_Planeación Prueba de
requerimiento
Presentar la estrategia, alcance,
estimación de tiempos, de la prueba de
requerimiento.
MR_005.2_Diseño de Casos de Prueba Identificar los posibles casos de prueba
del requerimiento
MR_005.3_Ejecucion de Casos de Prueba Presentar resultado de ejecución de los
casos
MR_005.4_Informe final prueba Presentar informe de cierre con los

25. aspectos más relevantes de la ejecución

26. Capí tulo 6 GESTIO N DE CAMBIOS
en este capitulo quiere decir que la planificación coordinada debe ser un
proyecto de las actividades que conlleve el logro los objetivos o propósitos
claras y eficientes.


Identificación control de cambios.
Las organizaciones de desarrollo de software, se identifican las siguientes actividades.
Análisis de la solicitud: 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.
Valorar el cambio
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

27. La solicitud para saber que tanto impacta la modificación e identificar puntualmente las
modificaciones solicitadas que afectan el requerimiento.

Documentar cambio
Este punto apoya también a tener un control de las modificaciones que se realizan
sobre un documento de requerimiento esto con el fin de mantener informado al grupo
de trabajo y al cliente que actualizaciones se han realizado sobre los documentos.
Aprobación control de cambio
Aprobar cambios
Se debe tomar una decisión. Si se acepta el cambio, tras negociarlo con el cliente se
continuará con la actividad de implementar cambio sino se deberá negociar con el
cliente el siguiente paso a realizar.
Planear cambio
Una aprobación formal del cambio aceptado planea al tiempo necesario.
Realizar cambio
El cambio aceptado se debe realizar las modificaciones necesarias a todos los
productos que resulten afectados.
Revisar cambio
Hacer una verificación por parte del líder para identificar que el requerimiento incluye
todos los cambios solicitados.
Actualizar line base
El nuevo requerimiento como línea base, esto con el fin de trabajar siempre sobre la
última versión.
Informar
La modificación de la solicitud se debe a los interesados que el cambio y se está
realizando para que el cliente lo verifique.
Entregable control de cambios

28. Los puntos anteriores es importante utilizar el documento que apoye a la identificación
de la solicitud realizada por los clientes internos o externos.

Formato Objetivo
MR_006_Control de cambios
Describir la situación de cambio solicitada por
el cliente.


Capí tulo 7 GESTIO N DE
REQUERIMIENTO

Para que la gestión de los requerimientos sea realmente aplicable al cliente en
pro de la satisfacción de las necesidades y control del proyecto general, se
debe cumplir con las siguientes acciones.

Matriz de relación de documentos
La siguiente matriz nos muestra cuales son las relaciones de documentación
de cada requisito.


Matriz de valoración y aprobación de los requisitos
la siguiente matriz es a que nos permite valorar si el requisito cumple con todas
las etapas llevadas a cabo en la metodología.

29. Matriz de Control de cambios

La matriz de control de cambios nos permite registrar los controles de cambio
que se van presentando, en esta matriz podemos registrar el número de control
de cambio que se tiene asignado.