1 Ingeniería de Requisitos

2 2 Temario Definiciones Requisitos Funcionales y No Funcionales Tipos de Requisitos Ingeniería de Requisitos  Proceso de los Requisitos Obtención de Requisitos - Técnicas Modelado del Sistema - Técnicas Especificación de Requisitos - Documentos de Requisitos Validación y Verificación– Técnicas  Administración de los Requisitos Planificación Trazabilidad Administración del cambio Medición Metodologías de Desarrollo Especificación Formal - Z

3 3 Bibliografía Pfleeger: Capítulo 4 Ingeniería de SW - Sommerville (7ma. edición): Capítulos  6 – Requisitos del software  7 – Procesos de la Ing. de Requisitos  10 – Especificación formal IEEE Recommended Practice for Software Requirements Specifications – Std 830-1998. Casos de uso:  Larman: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition)  Artículos en la página: Capítulo 6 del libro de Craig Larman: Applaying UML and Patterns – 2nd Edition Capítulo 19 del libro de Alistair Cockbourn: Writting Effective Use Cases Is the clock an actor? Artículo de la revista Rational Edge UML:  http://www.uml.org/ http://www.uml.org/  Artículos en la página: Introducción a UML - Artículo de la revista Rational Edge Diagramas de Actividad - Artículo de la revista Rational Edge

4 4 Motivación

5 5 Definiciones Requisitos:  Descripción de los servicios que debe brindar un sistema y sus restricciones. Ingeniería de Requisitos  Proceso de descubrir, analizar, documentar y verificar esos servicios y restricciones.

6 6 Definiciones Sistema  Incluye hardware, software, firmware, personas, información, técnicas, servicios, y otros elementos de soporte Requisitos del Sistema  Son los requisitos para el sistema entero Requisitos del Software  Se refieren solo al SW

7 7 Requisitos vs. Diseño Requisitos definen el Qué (el problema) del sistema El Diseño define el Cómo (la solución)

8 8 Reporte CHAOS de Standish Group `94 350 orgs., 8000 proyectos (Standish Gr.1994) Causas % Respuestas Requisitos incompletos13.10% Falta de involucramiento de usuarios12.40% Falta de Recursos10.60% Expectativas no realistas9.90% Falta de Soporte de Ejecutivos9.30% Requisitos y Especificaciones cambiantes8.70% Falta de planificación8.10% Sistema no se precisaba más7.50% Causas % Respuestas Requisitos incompletos13.10% Falta de involucramiento de usuarios12.40% Falta de Recursos10.60% Expectativas no realistas9.90% Falta de Soporte de Ejecutivos9.30% Requisitos y Especificaciones cambiantes8.70% Falta de planificación8.10% Sistema no se precisaba más7.50% 39.2 %

9 9 Costos de Errores en los Requisitos Costo de corregir un error en los requisitos (Boehm-Papaccio,1988)

10 10 Requisitos Funcionales y No Funcionales Funcionales:  Servicios o funciones que proveerá el sistema  Describen la interacción entre el sistema y su entorno  Ejemplos: Se deben ingresar cédula, nombre y teléfono de cada cliente Se quiere un listado de los clientes por zona No-funcional:  Restricciones a los servicios o funciones ofrecidos por el sistema  Describen restricciones que limitan las elecciones para construir una solución  Ejemplos: Las consultas deben resolverse en menos de 3 segundos El lenguaje de programación debe ser Java

11 11 Requisitos No Funcionales Del Producto: Especifican restricciones al comportamiento del producto  Ejemplos: desempeño, confiabilidad, portabilidad, usabilidad De la Organización: Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador  Ejemplos: estándares, lenguajes de programación, método de diseño Externos: Se derivan de factores externos, como:  Interoperabilidad: con otros sistemas  Legislativos: privacidad, seguridad  Éticos: dependen del contexto, las personas, etc

12 12 Requisitos - Tipos (1) Al describir requisitos se deben tener en cuenta los siguientes aspectos: Ubicación y Entorno Físicos  dónde, uno o varios, restricciones ambientales Interfaces  Entrada de 1 o + sistemas, Salida a 1 o + sistemas, restricciones de formato, soporte Usuarios y Factores Humanos  capacidad de cada tipo de usuario, tipo de entrenamiento, facilidad de uso, posibilidad de mal uso Funcionalidad y Restricciones asociadas  qué debe hacer, cuándo, modos de operación, cómo y cuándo se puede modificar el sistema, restricciones de velocidad, tiempo de respuesta, capacidad de proceso

13 13 Requisitos - Tipos (2) Documentación  cuánta, formato, para quién Datos  formatos E/S, frecuencia, fuentes, destinos, calidad requerida, precisión en cálculos, flujo en el sistema Recursos  materiales, personal y otros para construir, usar y mantener el sistema, habilidades de los desarrolladores, necesidades de espacio y ambientales, calendario prescrito, limitaciones en presupuesto

14 14 Requisitos - Tipos (3) Seguridad  control de acceso a las funciones/datos, aislamiento de los programas, respaldos-frecuencia, disponibilidad-, seguridad física Aseguramiento de la Calidad  Confiabilidad – tiempo medio entre fallas, robustez, tolerancia a fallas  Disponibilidad - tiempo para estar operativo luego de falla- mantenimiento estando activo- tiempo máximo de no disponibilidad  Mantenibilidad  Seguridad  Portabilidad

15 Ingeniería de Requisitos

16 16 SCM Ingeniería de Requisitos Proceso de los Requisitos Obtención Análisis Verificación Administración de los Requisitos Línea Base deRequisitos Línea base actual Línea base corregida Planificación Administración del Cambio Administración del Cambio Cambios en requisitos Cambios en el proyecto Validación Trazabilidad Especificación Medición y Evaluación Medición y Evaluación

17 17 Proceso de Requisitos Artefactos Análisis Especificación Verificación Actividades Especificación de Requisitos Documento de Requisitos Modelo del Sistema Planificación Obtención Validación Documento de Visión

18 18 Participantes en el Proceso de Requisitos Cliente y Usuarios  Requisitos adecuados a sus necesidades Diseñadores  Comprenderlos para lograr diseño que los satisfaga Supervisores del Contrato, sugieren:  Hitos de Control, cronogramas Gerentes del Negocio, entienden:  Impacto en la Organización Verificadores  Comprenderlos para poder verificar si el sistema los satisface

19 Obtención de Requisitos

20 20 Proceso de Requisitos Artefactos Análisis Especificación Verificación Actividades Especificación de Requisitos Documento de Requisitos Modelo del Sistema Planificación Obtención Validación Documento de Visión

21 21 Requisitos - Fuentes Necesidades del cliente, usuario, otros interesados Modelos del dominio Revisar la situación actual Organización actual y sistemas Versión actual del sistema Desarrolladores de versión anterior Documentos existentes (antecedentes) Sistemas análogos ya existentes (antecedentes)

22 22 Obtención & Análisis de Requisitos Se trabaja en conjunto con los usuarios y clientes Problemas comunes:  No saben lo que quieren del sistema, sólo en términos generales, no conocen el costo de sus peticiones  Los requisitos están en sus términos y con conocimiento implícito de su propio trabajo  Distintos usuarios tienen distintos requisitos, se deben encontrar todas las fuentes  Influyen factores políticos  La prioridad que se da a los requisitos varía con el tiempo  Aparecen nuevos requisitos

23 23 Brecha en la Comunicación (Scharer ’90) Según desarrolladores, los usuarios... Según usuarios, los desarrolladores... no saben lo que quierenno captan las necesidades operativas no pueden articular lo que quierenponen excesivo énfasis en aspectos meramente técnicos muchas necesidades por motivos políticospretenden indicarnos cómo hacer nuestro trabajo quieren todo yano son capaces de traducir necesidades claramente establecidas en un sistema son incapaces de definir prioridades entre sus necesidades siempre dicen que no rehúsan asumir responsabilidades por el sistema siempre están pasados del presupuesto incapaces de dar un enunciado utilizable de sus necesidades siempre están atrasados no están comprometidos con los proyectos de desarrollo nos exigen tiempo y esfuerzo aún a costa de las obligaciones esenciales no aceptan soluciones de compromisoestablecen estándares no realistas para la definición de requisitos no pueden mantener el cronogramason incapaces de responder rápidamente a cambios en las necesidades

24 24 Obtención & Análisis de Requisitos (Modelo Genérico) Clasificación y Organización de Requisitos Priorización y negociación de requisitos Relevamiento de Requisitos Documentación de Requisitos

25 25 Qué relevar Requerimientos del negocio:  Objetivos del negocio de alto nivel. Responden a la pregunta: ¿cómo será el mundo mejor para una determinada comunidad?  Categorías: beneficios financieros mejora de las operaciones de negocio posicionamiento estratégico / competitivo adoptar una nueva ley nivelado / desarrollo tecnológico.  product vision statement  beneficios para los stakeholders  descripción de la funcionalidades en alto nivel  prioridades del proyecto  limitaciones del producto Documento de visión. Sirve para establecer una visión común con el cliente y para difusión del proyecto.

26 26 Qué relevar Reglas de negocio. - Existen independientemente del software. Aplican aunque se haga manualmente.  políticas de la organización  estándares  algoritmos  leyes y regulaciones Requisitos funcionales Requisitos no funcionales:  atributos de Q  interfaces externas  restricciones Criterios de éxito. Pe.:  que puedan desarrollar bien tareas significativas  manejo de errores  que satisfaga expectativas de calidad

27 27 Obtención de Requisitos – Técnicas Investigar antecedentes Entrevistas individuales/grupales Encuestas/Cuestionarios Tormenta de ideas Workshop Casos de Uso Observación/Participación Prototipado

28 28 Investigar antecedentes Estudio, muestreo, visitas,… Buena forma de comenzar un proyecto Interna: estructura de la organización, políticas y procedimientos, formularios e informes, documentación de sistemas Externa: publicaciones de la industria y comercio, Encuentros profesionales, visitas, literatura y presentaciones de vendedores  Ventajas  Ahorra tiempo de otros  Prepara para otros enfoques  Puede llevarse a cabo fuera de la organización  Desventajas  Perspectiva limitada  Desactualizado  Demasiado genérico

29 29 Entrevista Individual / Grupal Usar para:  Entender el problema de negocio  Entender el ambiente de operación  Evitar omisión de requisitos  Mejorar las relaciones con el cliente Ventajas  Orientado a las personas  Interactivo/flexible  Rico Desventajas  Costoso  Depende de las habilidades interpersonales Pasos para las Entrevistas  Seleccionar participantes Aprender tanto como sea posible de antemano  Preparar la entrevista Utilizar un patrón de estructura  Conducirla Apertura, desarrollo, conclusión  Enviar un memo con resultado  Seguimiento

30 30 Entrevista – Patrón para conducirla Datos de las Personas: usuarios, interesados, disparador del proyecto  ¿Qué trabajo realizan? ¿Para quién?  ¿Qué interfiere con su trabajo?  ¿Qué cosas hacen su trabajo mas fácil o mas difícil? Datos: entradas y salidas clave, datos ya existentes  Listar las entradas y salidas  ¿Cuál es el problema? ¿Cómo se resuelve ahora? ¿Como le gustaría que se resolviera? Procesos: propósito, objetivos y metas  ¿Quién necesita la aplicación?  ¿Cuántos 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 aplicación, expectativas de tiempo de entrenamiento

31 31 Entrevista – Patrón para conducirla (2) Evaluar confiabilidad, desempeño y soporte necesario:  ¿Cuáles 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 instalación existen?, ¿cómo se distribuye el software?, ¿debe ser empaquetado? Otros  ¿Existen requisitos legales, regulatorios u otros estándares que deban ser tenidos en cuenta? Factores críticos de éxito:  ¿Qué se considera una buena solución? Tener en cuenta:  Si el entrevistado comienza a hablar sobre los problemas existentes, no cortarlo con una próxima pregunta  Luego de la entrevista y mientras los datos aún están en mente, resumir los principales req. (aprox. 3) de este entrevistado

32 32 Encuesta / Cuestionario No substituye la entrevista Antes de usar el enfoque:  Determinar la información que se precisa  Determinar el enfoque más adecuado: Abierto, cerrado, combinado Múltiple opción, valor en escala, orden relativo  Desarrollar cuestionario  Probarlo con perfil típico  Analizar resultado de las pruebas Su principal uso es para validar asunciones y obtener datos estadísticos sobre preferencias  Ventajas  Economía de escala  Conveniente para quien contesta  Respuestas anónimas  Desventajas  Menos rico  Problemas por no-respuesta  Esfuerzo de desarrollo

33 33 Observación / Participación Poco utilizado… Antes de usarlo  Determinar información necesaria  Comunicar a los involucrados  Considerar períodos normales y atípicos  Planificar las anotaciones  Ventajas  Confiable  Muy rico  Desarrolla empatía  Desventajas  Efecto Hawthorne  Cuidado con generalizar demasiado (sesgo particular/local)

34 34 Tormenta de Ideas (Brainstorming) Objetivo: Lograr consenso sobre los requisitos Ayuda a la participación 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 imaginación  Generar tantas ideas como sea posible  Mutar y combinar ideas

35 35 Tormenta de Ideas – Fase de Generación Los principales stakeholders se juntan en un cuarto. Se explican las reglas. Se establece el objetivo:  ¿Qué características esperan en el producto?  ¿Qué servicios esperan que provea? Los objetivos permiten decidir cuando terminar. Se pide que cada participante escriba sus ideas, luego las ideas son leídas para que otros piensen en ideas relacionadas y de esa forma las ideas mutan y se combinan.

36 36 Tormenta de Ideas – Fase de Reducción El secretario lee cada idea y pregunta si es válida  Si hay cualquier desacuerdo, la idea se queda Agrupamiento de ideas  Nombrar los grupos Definición  Se escribe una breve descripción de lo que la idea significa para la persona que la escribió  Ayuda a tener un entendimiento común del requerimiento  Lleva unos minutos por idea Priorización (opcional)  Test de los $100: Cada persona tiene dinero para comprar ideas, se ordena según ideas más compradas Solo se puede hacer una vez Se debe limitar la cantidad a gastar en 1 sola idea

37 37 Sesiones de Trabajo (Workshop) Ámbito para las tormentas de ideas Preparación  Venderlo a los posibles miembros de la reunión  Asegurarse que asisten los stakeholders correctos  Estructurar la invitación, el lugar, etc.  Enviar material previo a la reunión Doc de requisitos Entrevistas, defectos de los sistemas existentes, etc. Asegurarse de enviar lo necesario, sin exagerar  Organizar la Agenda Introducción Tormenta de ideas – generación Tormenta de ideas – reducción Priorización Resumen

38 38 Casos de Uso Técnica para entender y describir requisitos Los casos de uso son requisitos, describen requisitos funcionales Pone el acento en el uso del producto 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 cómo debe hacerlo Se describen mediante documentos de texto Introducido por Ivar Jacobson (1992)

39 39 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 interactúa Pueden ser usados en el diseño y en el testing del sistema  Usarlo  Cuando el sistema está orientado a la funcionalidad, con varios tipos de usuarios  Cuando la implementación se va a hacer OO y con UML  No son la mejor elección:  Sistemas sin usuarios y con pocas interfaces  Sistemas dominados primariamente por requisitos no funcionales y restricciones de diseño

40 40 Prototipado Implementación parcial, permite a los desarrolladores y usuarios:  entender mejor los requisitos  cuáles son necesarios, deseables  acotar riesgos Prototipo desechable: El propósito es solo establecer que algo se puede hacer, luego se parte de cero en la construcción, quedando el conocimiento aprendido Prototipo evolutivo: Es implementado sobre la arquitectura del producto final, el sistema final se obtiene de evolucionar el prototipo Aspectos para los que es frecuente construir prototipos:  Apariencia y percepción de la interfaz de usuario  Arquitectura (riesgos tecnológicos, tiempos de respuesta)  Otros aspectos riesgosos

41 41 Mismos datos, pero… Ingrese año:____ mes:____ día:____ Julio 1998 1998 2025 1 31 Ene Dic Martes 16 Oct. 2002

42 Análisis de Requisitos

43 43 Proceso de Requisitos Artefactos Análisis Especificación Verificación Actividades Especificación de Requisitos Documento de Requisitos Modelo del Sistema Planificación Obtención Validación Documento de Visión

44 44 Análisis de Requisitos Analizar stakeholders / clientes / usuarios Crear vistas Detallar Negociar prioridades Buscar reqs que faltan Evaluar factibilidad técnica - Prototipos Evaluar riesgos de requerimientos – En el Plan

45 45 Stakeholders / Clientes / Usuarios Clientes:  Definir responsable de: resolución de conflictos validación  Planificar reuniones de revisión de avance con el responsable.  Definir proceso de resolución de conflictos pe. en alcance. Usuarios:  dividirlos en clases  definir representantes  definir prototipos  acordar responsabilidades y estrategias de colaboración con representantes Stakeholders Clientes Usuarios

46 46 Proceso de Requisitos Artefactos Análisis Especificación Verificación Actividades Especificación de Requisitos Documento de Requisitos Modelo del Sistema Planificación Obtención Validación Documento de Visión

47 47 Modelos o Vistas del Sistema Glosario Modelos gráficos:  Modelo conceptual  Diagramas de estado – para entidades complejas que pasen por distintos estados. Prototipos de interfaz gráfica. – Definir docs del prototipo (reqs, diseño, CP) Casos de Prueba Tablas de Decisión Redes de Petri Casos de Uso

48 48 Diagramas UML UML  Diagramas de Casos de Uso  Diagramas de Actividad  Diagramas de Máquinas de Estado  Diagrama de Clases Modelo Conceptual

49 Tablas de Decisión

50 50 Tablas de Decisión Descripción dinámica Conjunto de condiciones posibles en un cierto instante Estados donde se verifica una combinación determinada de las condiciones Acciones a tomar Nro estados = 2^nro condiciones => tablas extensas Condiciones Acciones 12345 Importe > 1000FFVVV Buenos AntecedentesVFVVF Ya operó antes--VF- Autorizar CréditoXX Analizar antecedentesXXX Estados