tema3 extraccion 2012 2013

Tema 3. Extraccin de requisitos ELICITACIN

IR y M. Tema 3. Extraccin de Requisitos

Tema 3. Extraccin de requisitos

ndice Objetivos del tema Dificultades y soluciones Toma de requisitos

Objetivos de un proyecto Localizacin de Stakeholders Conocimiento del dominio Gestin de tangibles Realizacin de entrevistas Otras tcnicas

Establecimiento de prioridades Gestin de cambios Extraccin de requisitos gil: Historias de usuario



Objetivos del tema

mbito



Dificultades

El software es de naturaleza lgica

Realizado por programadores y no por Ingenieros del Software

Basada en la comunicacin entre personas

Comunicacin: El informtico desconoce el dominio y el usuario (la sociedad) carece cultura informtica. (GLOSARIO) Produce: Ausencia de informacin e informacin errnea

Soluciones: mtodos lenguaje natural estructurado, Lenguaje de descripcin de diseo, diagramas, notacin matemtica y otras especificaciones formales.



Dificultades (y 2) Personas: Capacidad de la memoria cercana es 7 ( 2)

(George Miller)

Soluciones: Abstraccin y descomposicin en categoras complementarias que podamos estudiar por separado. Uso de Formularios gua.

Mitos del Software

Desarrolladores

Clientes

Gestin



Formulario ejemplo: Formulario de captura de Requisitos de RENDIMIENTO

Informacin Esttica Transacciones Histrico

1. Cuantos usuarios accedern al sistema?

Media

Mximo

2. Cuntas operaciones realizar el usuario por sesin?

Media

Mximo

3. Cul es el tiempo de respuesta deseado?

Media

Mximo

4. Qu ancho de banda ser el ms comn?

Servidor

Cliente

5. Cul ser el volumen de datos?

6. Cul debe ser el tiempo de almacenamiento de esos datos? IR y M. Tema 3. Extraccin de Requisitos


Resultado, contenido de un requisito

Identificador

Autor

Tipo de requisito

Descripcin

Prioridad (alta / media / baja)

Estado (propuesto / aprobado / incorporado)

Fechas de creacin / revisin.



Resultado (y 2) Orden de requisitos

Por el modo

Por modo ampliado

Por Clase de Usuario

Por Objeto

Por rasgo

Por estmulo

Por jerarqua funcional

Organizaciones mltiples

IEEE-STD-830-1998



Conocimiento del dominio Acerca del contexto del proyecto

Acerca del dominio de la aplicacin objetivos, requisitos y propiedades del dominio del sistema

actual y posibles sistemas futuros modelos de objetivos

fenmenos de inters, terminologa modelos conceptual

escenarios, operatorias, funcionalidades escenarios y casos de uso

responsabilidades e interfaces diagramas de contexto

potenciales conflictos y riesgos modelos de conflictos y obstculos

Pueden representar requisitos y restricciones



Objetivos de un proyecto

Requiere conocimiento previo del negocio del cliente y del origen de sus ingresos y gastos

No siempre tiene una motivacin econmica. Legales, de imagen

Consistirn en tres o cuatro objetivos que responden a la pregunta Por qu va a pagar el cliente en este proyecto?

Deben numerarse, describirse y priorizarse.

Licitaciones: parecen claros pero ya ha pasado tiempo desde que se concibi la licitacin



objetivos, requisitos y restricciones objetivos:

principios de alto nivel que se utilizan para guiar el proyecto definen los atributos realmente importantes del sistema

(seguridad, fiabilidad,...) a veces hay conflicto entre objetivos (por ejemplo, seguridad y

bajo coste) que aumentan la complejidad del proyecto

requisitos caractersticas que debe tener el sistema requisito funcional: rea de funcionalidad que debe soportar el

sistema (por ejemplo, proporcionar billetes de tren) requisito no funcional: restriccin que se establece sobre el

funcionamiento del sistema (por ejemplo, proporcionar billetes de tren en menos de un segundo)

otras restricciones: por ejemplo, utilizacin de un determinado lenguaje, de una determinada plataforma o de un sistema antiguo que el cliente no quiere retirar



Localizacin de Stakeholders El compromiso ( opinin) de los stakeholders es

imprescindible para el xito del proyecto Se deben descubrir los opositores al proyecto y

futuros boicoteadores La visin de los jefes sobre las actividades que de l

dependen estn idealizadas Si el proceso ya existe solicitar registro de incidencias

y reclamaciones Para cada Stakeholder numerarlo, incluir su nombre y

apellidos, precauciones a tener con el y forma de comprometerlo



Localizacin de Stakeholders (y 2) Quin lo pide? Quin lo define? Quin lo paga? Quin lo usar? Quin resuelve los casos especiales? Quin lo aprueba? Quin lo valida? Con quin tenemos que intercambiar datos o se

entremezclan procesos? Alguien regula la actividad?



Gestin de tangibles Formulario = coleccin estructurada de variables que

est formateada para soportar ingreso de datos y su recuperacin

Es una fuente importante porque: es un modelo formal

es un modelo de datos

a menudo contienen informacin sobre la organizacin

sus instrucciones de uso encierran conocimiento sobre el dominio

su anlisis puede automatizarse



Preparacin de entrevistas Conocer el vocabulario del dominio del problema.

Imprescindible para poder entender al entrevistado.

Seleccionar las personas a entrevistar Se debe minimizar el nmero de entrevistas. Los directivos suelen proporcionar una visin general, mientras

que los futuros usuarios una ms detallada.

Determinar objetivos y contenidos de las entrevistas Se debe minimizar el tiempo de la entrevista. Los entrevistados deben conocer con antelacin el objetivo de la

entrevista y las preguntas que se le van a hacer.

Planificar las entrevistas Establecer fecha, hora, lugar y duracin de cada entrevista de

acuerdo con el entrevistado


Tema 3. Extraccin de requisitos Realizacin de entrevistas

Apertura (5-15 min.) Presentarse al entrevistado y recordarle el objetivo de la entrevista,

como se usar la informacin, etc. Explicar notaciones que el entrevistado no conozca. Causar buena impresin.

Desarrollo ( 2 horas, 20%/80%) Evitar monlogos y mantener el control, contemplando a posibilidad

de una tercera persona tomando notas o la grabacin de la entrevista. Comenzar con preguntas abiertas (no pueden responderse con un s o

un no) y terminar con preguntas ms concretas. No anticipar respuestas a las preguntas. Usar el vocabulario del dominio del problema

Terminacin (5-10 min.) Recapitular para evitar confusiones. Agradecer la colaboracin. Citar para otra entrevista si fuera necesario y dejar abierta la

posibilidad de futuros contactos. IR y M. Tema 3. Extraccin de Requisitos

Tema 3. Extraccin de requisitos Realizacin de entrevistas (y 2)

Anlisis de entrevistas Redactar el acta de la entrevista pasando a limpio las notas

tomadas y reorganizando la informacin. Contrastar los resultados con los de otras entrevistas. Enviar el acta al entrevistado para su confirmacin

Ventajas reuniones vs entrevistas Ahorran tiempo al contactar con varias personas a la vez. Permiten contrastar las opiniones de los participantes

directamente en lugar de hacerlo por separado. Suelen generar una mayor implicacin de clientes y usuarios.

Inconvenientes reuniones vs entrevistas Un grupo de personas es mucho ms difcil de controlar que una

sola persona. El detalle de la informacin obtenida suele ser menor que en las

entrevistas. La planificacin es ms compleja, al implicar a varias personas.



Joint Application Development (JAD) Conjunto de reuniones durante 2 a 4 das Cuatro principios: dinmica de grupo, uso de tcnicas

audiovisuales, organizacin y documentacin WYSIWYG Se adapta mal a los horarios de clientes y usuarios y es

compleja de organizar

Brainstorming (tormenta de ideas) Objetivo: generar ideas en un ambiente libre de crticas o

juicios. Grupos de 4 a 10 personas, una de ellas es el jefe de la sesin. Requiere poca organizacin y es fcil de aprender. Puede generar diferentes vistas del problema, aunque no con

una gran calidad de detalles.



Escenarios Escenario = historia que ilustra cmo un sistema puede

satisfacer necesidades del usuario

Descripcin idealizada pero detallada de una instancia especfica de interaccin hombre-mquina

Medios diversos (texto, dibujos, diagramas)

Estructurados en dilogos o narrativas

Similitud con los prototipos

Ventajas Los usuarios encuentran ms fcil transmitir su experticia a travs

de contar una historia

Es una solucin prometedora al problema de la comunicacin



Observacin in situ Observacin pasiva en el lugar de trabajo del usuario

Puntualmente se pueden hacer preguntas, pero sin interrumpir el trabajo del usuario

Se debe evitar que el usuario se sienta observado

Inmersin/aprendizaje Observacin activa en el lugar de trabajo del usuario

Se trabaja con el usuario como si se fuera un nuevo empleado

Es muy costoso en tiempo



Establecimiento de prioridades

Diferenciar lo imprescindible de lo deseable

Cuantificar prioridad de requisitos y sus criterios:

Cuntas operaciones diarias se realizan?

Cunto se gana con cada operacin?

Cunto se pierde si no se tiene?

Cunto cuesta hacerlo?

Debe contestar la oficina de negocios



Gestin de cambios

Presentes desde el inicio de cualquier proyecto

Deben formar parte del proyecto y tenidos en cuenta antes de aparecer

Deben ser todos anotados

Deben ser aprobados por la comisin de cambios



Categoras iniciales (Larman): Funcionalidad Usabilidad Fiabilidad (Reliability) Rendimiento (Performance) Soporte Otros requisitos como:

Implementacin Interfaz Operacin Empaquetamiento Legales


Tema 3. Extraccin de requisitos Algunas recomendaciones: Prestar atencin a las conjunciones aseverativas (ej., ciertamente, por lo tanto, obviamente,

se puede ver que). En estos casos, preguntar porqu se usan. Prestar atencin a los trminos de significado vago (ej., algunos, algunas veces, a menudo,

usualmente, frecuentemente). Pedir aclaraciones. Cuando se dan listas, pero no completas, asegurarse de que todos los puntos se han

comprendido. Ejemplos a tener en cuenta: "etc.", "y en adelante", "y as sucesivamente". Asegurarse de que los rangos no contienen asunciones no establecidas (ej., Rangos de cdigo

valido desde 10 a 100. Enteros? Binarios? Hexadecimales?). Atencin a los verbos de significado vago como "Mantenido, descartado, procesado,

eliminado". Existen muchas formas en las que pueden ser interpretados. Atencin a los pronombres ambiguos (Ej., el mdulo de entrada/salida se comunica con el

mdulo de validacin de datos y su flag de control se activa. El flag de qu mdulo?) Buscar palabras que impliquen certeza (Ej,. siempre, cada vez, todos, ningn, nunca),

entonces pedir que se pruebe dicha certeza. Cuando se define un trmino en un lugar de forma explcita, probar a sustituir dicha

definicin por el trmino en otros lugares en los que aparezca. Cuando una estructura est descrita con palabras, realizar un diagrama que ayude a su

comprensin. Cuando se especifique algn clculo, deben de aparecer al menos dos ejemplos.


tema3 extraccion 2012 2013

Documents