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.