2.2 Técnicas de Ingeniería de 
Requisitos
 El análisis de requisitos siempre comienza con 
una comunicación entre dos o mas partes. 
 Un cliente tiene un problema...
 Antes de mantener las reuniones con los clientes 
y usuarios e identificar los requisitos es 
fundamental conocer el dom...
 Normalmente clientes y analistas se enfrascan en 
el proyecto de forma unilateral y no en equipo. 
Cada parte define su ...
 Con los problemas anteriores de han 
desarrollado numerosas técnicas para tratar de 
superarlos. 
 Cada técnica puede a...
Entrevista 
 Las entrevistas son la técnica de licitación más 
utilizada, y de hecho son prácticamente 
inevitables en cu...
Preparación de entrevistas: Las entrevistas no 
deben improvisarse, por lo que conviene realizar 
las siguiente tareas pre...
Realización de entrevistas: se distinguen tres etapas: 
 Apertura. 
 Desarrollo. 
 Terminación. 
Análisis de las entrev...
Casos de Uso 
 Los casos de uso son una técnica para la 
especificación de requerimientos funcionales 
propuesta inicialm...
 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 c...
 Sirven de base a las pruebas del sistema y a la 
documentación para los usuarios. 
 Los más reconocidos especialistas e...
Ventajas y desventajas. 
 Caracterización detallada de todas las posibles 
interacciones con el sistema. 
 Ayuda en el d...
 Ejemplo:
Próxima SlideShare
Cargando en…5
×

2.2 tecnicas de ingenieria de requisitos

215 visualizaciones

Publicado el

Pptx

Publicado en: Empresariales
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
215
En SlideShare
0
De insertados
0
Número de insertados
31
Acciones
Compartido
0
Descargas
6
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

2.2 tecnicas de ingenieria de requisitos

  1. 1. 2.2 Técnicas de Ingeniería de Requisitos
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13.  Ejemplo:

×