ACTIVIDADES DE LA INGENIERA DE REQUISITOS

ACTIVIDADES DE LA IR

Actividades de la Ingeniera de Requisitos

Los procesos utilizados en Ingeniera de Requisitos varan dependiendo del dominio de aplicacin, de la gente implicada y de la organizacin que desarrolla los requisitos. Sin embargo, hay un nmero de actividades genricas comunes a todos los procesos. Estudio de viabilidad Elicitacin (extraccin o captura) de Requisitos Anlisis de Requisitos Validacin de Requisitos Gestin de Requisitos

Estudio de viabilidad
El estudio de viabilidad permite decidir si el sistema propuesto es conveniente. Es un estudio rpido y orientado a conocer: si el sistema contribuye a los objetivos de la organizacin. si el sistema se puede realizar con la tecnologa actual y con el tiempo y el coste previsto. si el sistema puede integrarse con otros existentes.

Elicitacin y anlisis de requisitos

Elicitacin (o extraccin o captura o determinacin) de requisitos: El proceso mediante el cual los usuarios descubren, evelan, organizan y comprenden los requisitos que desean. Tcnicas: Observacin, entrevistas, herramientas CASE y UML). Anlisis de requisitos: El proceso de razonamiento sobre los requisitos obtenidos en la etapa anterior, detectando y resolviendo posibles inconsistencias o conflictos, coordinando los requisitos relacionados entre s. Tcnicas: Diferentes representaciones grficas (UML) y tcnicas de revisin.
5

Validacin y gestin de requisitos

Validacin de los requisitos: El proceso de confirmacin, por parte de los usuarios, de que los requisitos especificados son vlidos, consistentes, completos, etc. Tcnicas: Listas de comprobacin y tcnicas de revisin. Gestin de Requisitos: es el proceso de manejar los requisitos que cambian durante el desarrollo del sistema. Tcnicas: Herramientas CASE (REM).
6

El documento de requisitos
El documento de requisitos es la declaracin oficial de lo que se necesita construir. Se denomina Documento de Especificacin de Requisitos del Software (ERS). Incluye tanto los requisitos del usuario como especificacin detallada de los requisitos del sistema. NO es un documento de diseo: Debe indicar QU es lo que el sistema debe hacer. No debe indicar CMO va a hacerlo. la

Caractersticas de una ERS

No ambigua. Completa. Fcil de verificar. Consistente. Fcil de modificar. Facilidad para identificar el origen y las consecuencias de cada requisito. Facilidad de utilizacin durante la fase de explotacin y mantenimiento.
Estndar IEEE-830 para la ERS (trabajo) 8

OBTENCIN DE REQUERIMIENTOS

ELICITACIN
En esta etapa, se trata de descubrir los requisitos. El personal tcnico trabaja con los clientes y usuarios para descubrir el dominio de la aplicacin los servicios que se deben proporcionar y las restricciones. Puede implicar a usuarios finales, encargados, ingenieros implicados en el mantenimiento, expertos del dominio, etc. Son los llamados participantes o interesados (stakeholders).

10

Problemas
Los participantes no conocen realmente lo que quieren. Los participantes expresan los requisitos con sus propios trminos. Diferentes participantes pueden tener requisitos conflictivos. Factores polticos y organizativos pueden tener influencia en los requisitos. Los requisitos cambian durante el anlisis. Pueden aparecer nuevos participantes y cambiar el entorno del negocio.
11

Etapas en la elicitacin de requisitos

1. Obtener informacin sobre el dominio del problema y el sistema actual. 2. Preparar y realizar las reuniones de elicitacin/negociacin. 3. Identificar/revisar los objetivos del sistema. 4. Identificar/revisar los requisitos de informacin. 5. Identificar/revisar los requisitos funcionales. 6. Identificar/revisar los requisitos no funcionales. 7. Priorizar objetivos y requisitos.

12

Etapas en la elicitacin de requisitos

13

TCNICAS DE OBTENCIN DE REQUISITOS

Investigar antecedentes Entrevistas individuales/grupales Encuestas/Cuestionarios Tormenta de ideas Workshop Casos de Uso Observacin/Participacin Prototipado

14

Investigar antecedentes
Estudio, muestreo, visitas. Interna: Estructura de la organizacin, polticas y procedimientos, formularios e informes, documentacin de sistemas. Externa: Publicaciones de la industria y comercio, encuentros profesionales, visitas, literatura y presentaciones de vendedores.

15

Entrevista Individual / Grupal

Los objetivos de la etapa de elicitacin son dos: Conocer a fondo el departamento donde la empresa necesita mejorar. Realizar un censo exhaustivo de las necesidades del sistema que se quiere informatizar. Cada persona del departamento tiene su propia visin del sistema.
La direccin, global pero difusa; los trabajadores, parcial pero concreta.

Las tcnicas de recogida inicial de informacin son: Observacin directa Estudio de los documentos Revisin de los ficheros que se manejan actualmente, 16 sobre todo, las entrevistas.

Entrevistas a la direccin
Objetivos: primer conocimiento censo de objetivos deseados organigrama de puestos de trabajo interfaces con otros proyectos concretar en lo posible el campo de estudio Entrevistados: Jefe de rea, de servicio, de negociado. Tcnica: informal, periodstica. Resultados: Visin del proyecto. objetivos principales lista de puestos de trabajo campo de estudio 17 restricciones: medios, calendario, etc.

Entrevistas a puestos de trabajo

Objetivos: operaciones efectuadas (Lista de Tareas) eventos peridicos datos y documentos/informaciones manipuladas qu puestos intervienen, tambin mensajes electrnicos, telefnicos, fax. reglas del negocio lenguaje de la empresa Entrevistados: Contable, administrativo, agente de ventas, etc. Tcnica: Se debe intentar estructurar la informacin recibida, mediante fichas, representacin grfica.

18

Fichas de entrevista
El contenido de una ficha de entrevista a un puesto de trabajo ser: Identificacin Persona Departamento Empleo Operaciones que realiza y descripcin. Documentos enviados y recibidos desde el puesto (incluidos los documentos orales) y descripcin. Nombre origen y destino Periodicidad 19 Volumen conservacin/destruccin

Herramientas auxiliares
Matriz de flujos: En ella, se representan tanto los actores externos como los internos y cmo fluye la informacin entre ellos. Diagrama de flujos de trabajo (diagrama de actividades de UML). Se asignan actividades a los actores externos e internos. Los resultados de las actividades (la informacin que fluye) se representan como objetos. Permite la reorganizacin de los flujos de trabajo

20

Ejemplo Restaurante: pedidos a proveedores.

1. El encargado del restaurante, cada martes y jueves confecciona los pedidos a los proveedores con todo aquello que est bajo mnimos y en funcin de los mens de la prxima semana. 2. Dispone de una ficha por cada producto y una vez hecho el pedido (fax o telfono), guarda una copia en la carpeta de pendientes. 3. Cuando un pedido llega al almacn, el almacenista comprueba el albarn de entrada y si es correcto se lo pasa al encargado. 4. Al final de cada da, el encargado actualiza las fichas de producto y la carpeta de pendientes con los albaranes revisados. 21

Documentacin de actividades

22

Matriz de Flujos

23

Entrevista Individual / Grupal

Usar para: Entender el problema de negocio Entender el ambiente de operacin Evitar omisin de requisitos Mejorar las relaciones con el cliente Ventajas Orientado a las personas Interactivo/flexible Rico Desventajas Costoso Depende de las habilidades interpersonales.

24

Entrevista Individual / Grupal

Pasos para las Entrevistas Seleccionar participantes Preparar la entrevista Utilizar un patrn de estructura Conducirla Apertura, desarrollo, conclusin Enviar un memo con resultado Seguimiento

25

Entrevista Patrn para conducirla

Datos de las Personas: Usuarios, interesados. Qu trabajo realizan? Para quin? Qu interfiere con su trabajo? Qu cosas hacen su trabajo mas fcil o mas difcil? Datos: Entradas y salidas clave, datos ya existentes Listar las entradas y salidas Cul es el problema? Cmo se resuelve ahora? Como le gustara que se resolviera?

26

Entrevista Patrn para conducirla

Procesos: Propsito, objetivos y metas. Quin necesita la aplicacin? Cuntos usuarios la van a usar y de qu tipo? Ubicaciones: Lugares involucrados, contexto de los usuarios. Entorno de los usuarios, computadoras, plataformas Aplicaciones relevantes existentes. Experiencia de los usuarios con este tipo de aplicacin, expectativas de tiempo de entrenamiento.

27

Entrevista Patrn para conducirla (2)

Evaluar confiabilidad, desempeo y soporte necesario: Cules son las expectativas respecto a la confiabilidad? Y respecto a la performance? Qu tipo de mantenimiento se espera? Qu nivel de control y seguridad? Qu requisitos de instalacin existen?, cmo se distribuye el software? , debe ser empaquetado? Otros Existen requisitos legales, regulatorios u otros estndares que deban ser tenidos en cuenta? Factores crticos de xito: 28 Qu se considera una buena solucin?

Encuesta / Cuestionario
No substituye la entrevista Determinar la informacin que se precisa Determinar el enfoque ms adecuado Desarrollar cuestionario Probarlo con perfil tpico Analizar resultado de las pruebas
Su principal uso es para validar asunciones y obtener datos estadsticos sobre preferencias.

Ventajas, desventajas
29

Observacin / Participacin
Poco utilizado Antes de usarlo Determinar informacin necesaria Comunicar a los involucrados Considerar perodos normales y distintos. Planificar las anotaciones Ventajas Confiable Muy rico Desarrolla empata Desventajas Efecto Hawthorne Cuidado con generalizar demasiado (sesgo particular/local)

30

Tormenta de Ideas (Brainstorming)

Objetivo: Lograr consenso sobre los requisitos. Ayuda a la participacin de todos los involucrados. Permite pensar en otras ideas. Un secretario saca notas de todo lo discutido. Reglas No se permite criticar ni debatir Dejar volar la imaginacin Generar tantas ideas como sea posible Cambiar y combinar ideas
31

Sesiones de Trabajo (Workshop)

Busca un acuerdo general sobre el alcance, riesgos, y las caractersticas importantes del sistema de software. Son dirigidos por un facilitador. Duracin: tres a cinco das Artefactos creados: declaracin de problema objeto de negocio diagrama de Casos de uso lista de riesgos Ventajas Resultados muy pronto
32

Casos de Uso
Los casos de uso son una tcnica de escenarios incorporada en UML que describe la interaccin entre los actores y el sistema. Un conjunto de casos de uso describe todas las posibles interacciones con el sistema. Los casos de uso son requisitos, describen requisitos funcionales. Describen como el sistema debe comportarse desde el punto de vista del usuario. Casos de Uso como caja negra: Especifican qu es lo que el sistema debe hacer, sin especificar cmo debe hacerlo. Se describen mediante documentos de texto.

33

Casos de Uso
Formato simple y estructurado donde los usuarios y desarrolladores pueden trabajar juntos. No son de gran ayuda para identificar aspectos no funcionales. Mientras se definen los casos de uso, puede ser un buen momento para definir pantallas u otros objetos con los que el usuario interacta. Pueden ser usados en el diseo y en el testing del sistema. Usarlo Cuando el sistema est orientado a la funcionalidad, con varios tipos de usuarios. Cuando la implementacin se va a hacer OO y con UML. No son la mejor eleccin: Sistemas sin usuarios y con pocas interfaces. Sistemas dominados primariamente por requisitos no 34 funcionales y restricciones de diseo.

Requisitos de Informacin
Se trata, aqu, de recopilar todos los datos con los que trabaja la organizacin y que soportan informacin. Hay que distinguir muy claramente lo que es documento (es soporte de informacin) de lo que es dato (es la informacin).

35

Prototipado
Implementacin parcial, permite a los desarrolladores y usuarios: entender mejor los requisitos cules son necesarios, deseables acotar riesgos Prototipo desechable: El propsito es solo establecer que algo se puede hacer, luego se parte de cero en la construccin, quedando el conocimiento aprendido. Prototipo evolutivo: Es implementado sobre la arquitectura del producto final, el sistema final se obtiene de evolucionar el prototipo.
36