Pptx

1. 2.2 Técnicas de Ingeniería de
Requisitos

2.  El análisis de requisitos siempre comienza con
una comunicación entre dos o mas partes.
 Un cliente tiene un problema al que puede
encontrar una solución basada en computadora.
 El desarrollador responde a la petición del
cliente. La comunicación ha comenzado. Pero, el
camino entre la comunicación y el entendimiento
esta lleno de obstáculos.

3.  Antes de mantener las reuniones con los clientes
y usuarios e identificar los requisitos es
fundamental conocer el dominio del problema.
 Para conocer el domino del problema se puede
obtener información de fuentes externas al
negocio.

4.  Normalmente clientes y analistas se enfrascan en
el proyecto de forma unilateral y no en equipo.
Cada parte define su propio territorio.
 Este enfoque no es muy efectivo, se pierde
información y nunca se establece de trabajo
satisfactoria.

5.  Con los problemas anteriores de han
desarrollado numerosas técnicas para tratar de
superarlos.
 Cada técnica puede aplicarse en una o mas
actividades de la ingeniería de requerimientos;
en la practica, la técnica mas apropiada
dependerá del proyecto que se este
desarrollando.

6. Entrevista
 Las entrevistas son la técnica de licitación más
utilizada, y de hecho son prácticamente
inevitables en cualquier desarrollo.
 En las entrevistas se pueden identificar
claramente tres fases: preparación, realización y
análisis.

7. Preparación de entrevistas: Las entrevistas no
deben improvisarse, por lo que conviene realizar
las siguiente tareas previas:
 Estudiar el dominio del problema.
 Seleccionar a las personas a las que se va a
entrevistar.
 Determinar el objetivo y contenido de las
entrevistas.
 Planificar las entrevistas.

8. Realización de entrevistas: se distinguen tres etapas:
 Apertura.
 Desarrollo.
 Terminación.
Análisis de las entrevistas.
 Reorganizar la información, contrastarla con otras
entrevistas o fuentes de información.
Validar con el entrevistado para confirmar los contenidos.

9. Casos de Uso
 Los casos de uso son una técnica para la
especificación de requerimientos funcionales
propuesta inicialmente en por Jacobson y
actualmente forma parte de la propuesta de UML.
 Una descripción de una secuencia de acciones
que el sistema debe llevar a cabo para obtener
un resultado observable para un actor particular.

10.  Un caso de uso es la descripción de una
secuencia de interacciones entre el sistema y
uno o más actores en la que se considera al
sistema como una caja negra.
 Los actores son personas u otros sistemas que
interactúan con el sistema cuyos requerimientos
se están describiendo. Un actor puede participar
en varios casos de uso y un caso de uso puede
estar relacionado con varios actores.

11.  Sirven de base a las pruebas del sistema y a la
documentación para los usuarios.
 Los más reconocidos especialistas en métodos
Orientados a Objetos coincidieron en considerar
a los casos de uso como una excelente forma de
especificar el comportamiento externo de un
sistema.
 Se escriben, generalmente, en lenguaje natural
No hay descripción interna del sistema, solo la
interacción con el mismo.

12. Ventajas y desventajas.
 Caracterización detallada de todas las posibles
interacciones con el sistema.
 Ayuda en el dibujo de los límites del sistema, y
con el alcance de los requerimientos.
 Los casos de uso no captura en dominio del
conocimiento.
 Un caso de uso no es especificación precisa,
solo es la representación de un problema
puntual.

13.  Ejemplo: