ENSAYOMETODOLOGIA DE GESTION DE REQUERIMIENTOS

03/03/2015ZULY JULIETH CESPEDES BARRAGANKATHERINE ARENAS MARIN

Tabla de contenido

OBJETIVOS:.....................................................................................................................................2

CAPÍTULO 1 IDENTIFICACIÓN DE NECESIDADES CON EL CLIENTE......................................................3

CAPÍTULO 2 TÉCNICAS PARA IDENTIFICAR REQUERIMIENTOS.......................................................4

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

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

Técnicas para Identificar Requisitos Funcionales y No Funcionales...............................................5

Técnicas de investigación de los atributos de las necesidades de los clientes...............................6

CAPÍTULO 3 DEFINICIÓN REQUERIMIENTOS..................................................................................6

Definición de Requisitos.................................................................................................................7

Verificación de Requisitos:.............................................................................................................8

CAPÍTULO 4 TÉCNICAS PARA DEFINIR REQUISITOS........................................................................9

Definición de diagramas:................................................................................................................9

Definición de Casos de uso...........................................................................................................10

Especificación de Casos de uso....................................................................................................11

Prototipos.....................................................................................................................................11

Definición de criterios de aceptación...........................................................................................12

CAPÍTULO 5 PRUEBAS DE REQUERIMIENTOS...............................................................................12

CAPÍTULO 6 GESTIÓN DE CAMBIOS..............................................................................................13

Aprobación Control de Cambios.....................................................................................13

CAPÍTULO 7 GESTIÓN DE REQUERIMIENTO.................................................................................14

Matrices de Trazabilidad.............................................................................................................14

OBJETIVOS: Adquirir conocimientos sobre la metodología de gestión de requerimientos. Dar a conocer nuestras ideas y lo que aprendimos sobre el tema. Promover lectura.

Aprender a identificar paso por paso.

GESTIÓN DE REQUERIMIENTOS

CAPÍTULO 1 IDENTIFICACIÓN DE NECESIDADES CON EL CLIENTE

Se refiere a la información obtenida por medio de la descripción de los requerimientos (necesidades) del cliente. Estos, a medida que transcurre el tiempo van evolucionando y cada cambio tiene un costo. Por tal motivo, es necesario que se haga una copia del documento y se realicen las actualizaciones correspondientes; llevando así un registro de cada cambio que se vaya a realizar.

Para esta identificación es necesario:

1. Obtener y analizar la información.2. Definir el alcance: es decir, el límite hasta donde pueden llegar las necesidades.

El manual debe llevar la descripción completa del desarrollo del proyecto y el cual debe ser entregado al cliente.

Los tipos de datos y bases de datos que hacen parte del proyecto y los que están fuera del alcance.

El espacio límite de alcance. Se debe tener en cuenta las condiciones que están fuera del alcance, es

decir, son las acciones que no pueden ser ejecutadas y que traen tanto ventajas como desventajas para el proceso de creación del proyecto.

Para definir el alcance es necesario conocer:

El documento, el cual explica con detalles precisos las características que han sido solicitadas y mantiene estable la información (todo lo que está en el entregable es lo que hace parte del proyecto)

Si el proyecto cumple con las expectativas del cliente, es lógico que sea aceptado, y por consiguiente será dado a conocer.

Los Beneficios que trae la exactitud y claridad de lo solicitado por el cliente es:

1. No habrá pérdida de tiempo ni de recursos y será menos costoso.2. Definir las responsabilidades de cada uno de los integrantes del proyecto.3. Que el líder del proyecto y el usuario tengan una comunicación entendible para

que el trabajo sea un éxito.

Su objetivo, es describir los requerimientos del cliente para darle la respectiva solución.

CAPÍTULO 2 TÉCNICAS PARA IDENTIFICAR REQUERIMIENTOS

Técnicas generales para la identificación de requerimientosSon abiertas y necesitan de una orientación para encontrar la información exacta.

Entrevista: está muy bien estructurada y es fundamental para establecer confianza con el usuario, para que pueda dar a conocer su punto de vista de una manera más detallada.

Es importante tener en cuenta los siguientes Tips:

1. Tener en cuenta el tipo de persona a la cual se va a entrevistar.

2. Buscar un entorno cómodo a la hora de realizar la entrevista, para obtener la información deseada.

3. La forma de cómo se expresan cada una de ellas.

4. Comprobar si las necesidades dadas a conocer se pueden tomar como requerimientos. .

5. Examinar como es la relación entre el usuario y el líder de la organización para que sea mejor el trabajo. Y siempre el cliente debe dejar determinado que es lo que desea.

Lluvia de ideas: se utiliza para dar a conocer nuevas necesidades o servicios que el cliente no dio a conocer con anterioridad.

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. Saber cómo iniciar una reunión enfocada en la confianza.

3. Tomar nota de las ideas que las personas expresan en los equipos de trabajo.

Tener una preparación sobre el tema que se va a desarrollar en la lluvia de ideas.

Cuestionarios: Se busca obtener respuestas concretas y confiables, aunque se ven involucradas una gran cantidad de personas con sus diferentes opiniones. Por tal motivo, se debe tener mucho cuidado a la hora de escoger a los encuestados.

Técnicas específicas para la identificación de requerimientos Se utilizan para complementar las técnicas generales, para conseguir más detalles y eliminar las dudas en la información.

Observación: solo se utiliza si es necesaria para el proyecto, es la forma directa para evitar inconsistencias (no hay coherencia) con las actividades del proceso que se va a realizar.

Escenarios: es el lugar en el cual, se van a presentar los diferentes eventos determinados por el comportamiento de dicho producto.

Técnicas para Identificar Requisitos Funcionales y No Funcionales Identificación de Requerimientos funcionales

Son aquellos que actúan directamente por medio de un sistema, es decir que se ve afectado por los cambios a los que se enfrenta. Teniendo como base el comportamiento del sistema.

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.

Identificación de Requerimientos no funcionales

Dependen de los requerimientos funcionales. No se pueden realizar cambios, debido a que se encarga solamente de las propiedades del sistema como el almacenamiento de información y la restricción de capacidad de entrada y salida.

Técnicas de investigación de los atributos de las necesidades de los clientesEs primordial conocer las necesidades del usuario, organizarlas y buscar la solución para cada una de ellas; innovando y permitiendo al cliente compartir sus conocimientos.

Para realizar las respectivas investigaciones son necesarios los siguientes métodos:

Grupos focales: es conformado por un grupo de clientes, los cuales son dirigidos por una persona encargada del orden para llevar a cabo un debate, en el cual se hablará de aspectos y cuestiones concretas donde se logra una mayor profundidad en la discusión, ya que todo gira en torno a una situación específica que es planteada y se enfocan en un análisis. Se busca la total comprensión del tema. El dirigente debe dar a conocer el motivo de la reunión y depende de su habilidad para obtener una buena cantidad y calidad en la información.

Entrevista individual: el entrevistador debe tener mucho dominio sobre el tema, estar seguro de lo que va a preguntar y sobre todo establecer un vínculo con el usuario para generar en él una motivación positiva. Tiene mayor privacidad.

Análisis contextual: en esta técnica de análisis, la colaboración del cliente pasa de contar y relatar su experiencia y opinión, desde luego en sus expresiones y en sus propios términos, a dejar ver al fabricante cómo realmente se construye esa opinión y se acumula esa experiencia.

Clientes piloto: son personas de gran autoridad y liderazgo ya que poseen gran conocimiento y experiencia; tienen la máxima capacidad para exigir, sugerir cambios, corregir defectos y completar características; es decir se involucra en el desarrollo. Los beneficios para utilizar esta técnica son elevados.

CAPÍTULO 3 DEFINICIÓN REQUERIMIENTOSSe debe realizar una buena identificación de los requerimientos, haciendo un análisis más detallado de los aportes de los usuarios.

Definición de Requisitos

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.

Requerimientos Funcionales:

1. se relaciona con el usuario: identificación de la relación del usuario con el sistema.

2. se relaciona con el sistema, dando respuesta al usuario (Ejecución del sistema).

Los requerimientos siempre deben ser específicos y claros, porque de lo contrario se pueden presentar algunos inconvenientes cuando se va a definir los datos y entregar los resultados, ya que existen muchas dudas acerca del proyecto.

Verificación de Requisitos:Se debe tener en cuenta la calidad de los requisitos, que cumplan con lo asignado por el cliente; para que pueda ser aprobado.

Revisión de Requisitos Vs Especificación: después de realizar la identificación, documentación y verificación, se hace la revisión con base a la información recogida con los clientes del sistema.

Proceso para la verificación de los requerimientos:

Preparar plan de revisión: quienes deben asistir, que tema se analizará y cuánto tiempo va a durar.

Documentos de requisitos a revisar

 Preparar reunión: Se debe fijar el lugar apropiado y los materiales necesarios para la reunión.

Realizar reunión: Se revisa y valida si cumple con las necesidades que el usuario ha solicitado.

Identificar los defectos de la especificación: Se revisa detalladamente si hace falta información o hay algún error.

Realización de correcciones a los documentos: Si hay algún error el analista del sistema deberá realizar la respectiva corrección al documento.

 Informar modificaciones a los interesados: Se debe enviar los documentos específicos y los 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 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.

CAPÍTULO 4 TÉCNICAS PARA DEFINIR REQUISITOS.

Definición de diagramas: Son necesarios para dar inicio al desarrollo de sistemas con gran dificultad en la especificación y descripción de su funcionalidad.

En general, se recomienda el uso de los diagramas UML, pero ¿cuándo utilizar diagramas UML? Y ¿cuándo no hacerlo?

Cuando no Utilizar Diagramas UML

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 UML

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 muestran los diferentes estados de un objeto durante su vida.  

   De secuencia: 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 usoLa 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.Al definir los actores que intervienen en un caso de uso se debe considerar que una persona puede ejecutar distintos roles en el sistema. Hay actores principales, que son los que usan el sistema directamente; para quienes desarrollamos el sistema. Y hay actores secundarios, que son aquellos de los que el sistema necesita ayuda para poder cumplir con el objetivo del caso de uso      Intereses de los actores:       La identificación de estos intereses nos 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:

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

o A nivel de sistema de Negocioo A nivel de sistema de Software 

Las descripciones de los casos de uso son cruciales para la comprensión del sistema.

Prototipos

Son modelos con la perfecta reproducción de lo escrito en la realidad, 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. Pero que dan un aporte fundamental durante las etapas del ciclo de creación.

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 repetitivo. Los prototipos tiene un costo bajo desarrollo.

Definición de criterios de aceptación

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 más, ni menos

y cumplir con todos los escenarios. El requisito debe ser medible, es fácil identificar si cumple o no cumple. No existe 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 REQUERIMIENTOSSe aplica para comprobar si existen diferencias entre los requerimientos y el sistema.

Los métodos que se deben desarrollar, tiene cuatro fases (objetivos):

Planeación

(Formato) es el límite que tiene la prueba, el tiempo de duración, la información necesaria para poder hacerla, es decir los datos escritos, los recursos tanto humano como tecnológico y por último las normas para dar fin a la prueba.

 Diseño de casos de prueba

(Checklist) es el listado de las características del requerimiento que se deben evaluar.

Que esté completo, preciso, correcto, que tenga todos los registros, sin contradicciones ni dudas; y por supuesto, que al querer realizar un cambio no afecte los demás elementos que forman parte de los datos.

 Ejecución de casos de prueba

Después del diseño de casos de prueba, es conveniente que se haga la evaluación, dando a conocer los errores, sugerencias y la posibilidad de considerar si es correcto como esta o si es obligatorio cambiar las soluciones dadas.

 Cierre

Luego de haber completado la información y realizado los ajustes necesarios, se entrega el informe final de la prueba.

CAPÍTULO 6 GESTIÓN DE CAMBIOS

Es obligatorio para la gestión de cambios en el proyecto, la buena organización libre de errores o defectos; que sea fácil de comprender para poder lograr los propósitos deseados y tener de manera adecuada el control del proceso. Es decir que aquí se describe la situación de cambio realizada por el cliente.

         Análisis de la Solicitud:

Para saber si se puede modificar el requerimiento o hay que hacer uno nuevo. Se tiene en cuenta el alcance y el tiempo que se necesita, además de identificar los elementos afectados por la solicitud.

          Valorar el cambio

 Se determina los requisitos límites y la forma como los afecta.

          Analizar Modificación

Se realiza la respectiva observación identificando los diferentes cambios que tendrá los

requerimientos.

          Documentar Cambio

Se debe realizar la correspondiente actualización de las modificaciones en el documento, para que sea fácil de entender y no haya dudas. Teniendo en cuenta el motivo por el cual se desea realizar el cambio.

Aprobación Control de Cambios

         Aprobar Cambios

 Se toma la decisión, si se acepta el cambio se continúa con la actividad, de lo contrario se debe hablar con el usuario para dar solución a lo que se ha realizado.

          Planear Cambio

 Si es aprobado, se revisa cuanto tiempo y recursos se necesitan para llevar a cabo la terminación de los cambios en el proyecto.

          Realizar Cambio

 Se realizan las modificaciones necesarias a todos a los datos que se ven afectados por el cambio.

         Revisar Cambio

 Es necesario comprobar que los cambios solicitados se hayan realizado y estén aprobados.

          Actualizar Línea Base

 Se trabaja con respecto a la última novedad realizada.

          Informar

 Después de todo el proceso terminado se informa al cliente los cambios realizados para que lo verifique.

CAPÍTULO 7 GESTIÓN DE REQUERIMIENTO Se debe tener en cuenta:

Matrices  de Trazabilidad

Matriz de relación de documentos

Nos da a conocer cuáles son las relaciones de  documentación de cada requisito su clasificación si es de negocio, usuario o sistema y si es funcional o no funcional, su respectivo caso de uso, sus casos de prueba asociados, la dependencia con otros requerimientos y las peticiones de cambio en caso que las tenga.

Matriz de valoración y aprobación de los requisitos

Si todo está en orden se dará por cerrado y aprobado los requisitos.

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 muestra en amarillo informando que no hay problema.

Matriz de Control de cambios

Es para realizar un control más detallado acerca de los cambios solicitados por el usuario y su respectiva actualización.

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, quien lo llevo a cabo o quien lo está realizando, por quien fue revisado en caso que ya se encuentre revisado, su porcentaje de ejecución hasta llegar al 100%, el o los requisitos afectados y  una descripción breve del control de cambios.