1
Paloma Cá[email protected]
Grado en Ingeniería del SoftwareCurso 2010 – 2011
Análisis e Ingeniería de RequisitosTema 5, 6, 7: Documentación, Validación y Gestión de Requisitos
2
Recordando el proceso de IR (tema 2.II)….
Estudio de viabilidad
Obtención y análisis de requisitos
Especificación de requisitos
Validación de requisitos
Informe de viabilidad
Actividades
Productos
Modelos del sistema
Requisitos de usuario
DocumentoERS
3
Recordando…Actividades del proceso de IR: Obtención y análisis de
requisitos
Descubrimiento de requisitos
(I)
Clasificación y organizaciónde requisitos
(II)
Ordenaciónde requisitos
(III)Documentación
de requisitos(IV)
Proceso general de obtención y análisis de requisitos
Digido por Casos de Uso
4
Recordando….Actividades del proceso de IR: Obtención y análisis de requisitos
Proceso general de obtención y análisis de requisitos:
1. Descubrimiento de requisitos. Interacción con los stakeholders para recopilar requisitos. Lectura de la documentación existente y de las especificaciones de sistemas similares.
2. Clasificación y organización de requisitos. Se toman los requisitos recopilados no estructurados y los grupos relacionados de requisitos y los organiza en grupos coherentes.
3. Ordenación por prioridades y negociación de requisitos. Al existir muchos stakeholders, muchos requisitos entrarán en conflicto. En esta actividad se organizan los requisitos según las prioridades, y se resuelven los conflictos a través de negociaciones.
4. Documentación de requisitos. Se documentan los requisitos generando documentos formales o informales. Se puede volver a realizar otra iteración.
5
Recordando…El proceso de IR
Estudio de viabilidad
Obtención y análisis de requisitos
Especificación de requisitos
Validación de requisitos
Informe de viabilidad
Actividades
Productos
Modelos del sistema
Requisitos de usuario
DocumentoERS
El documento de requisitos
� Es el modo habitual de guardar y comunicar requisitos.� Es buena práctica utilizar, al menos, dos documentos, a
distinto nivel de detalle� DRU = Documento de Requisitos de Usuario (en
inglés, URD)� ERS = Especificación de Requisitos Software (en
inglés, SRS)� OJO: Con “Documento” nos referimos a cualquier medio
electrónico de almacenamiento y distribución:� Procesador de textos� Base de Datos� Herramienta de Gestión de Requisitos
El documento de requisitos ¿Cómo organizar una ERS?
� Un conjunto de requisitos se puede agrupar según se refieran a:
1. El mismo estímulo externo2. La misma característica del sistema3. La misma respuesta del sistema4. El mismo objeto del mundo real5. La misma clase de usuarios6. La misma clase de función
� Jerarquía multinivel: 1º por usuario, luego por objetos del mundo real
El documento de requisitos ¿Cómo organizar una ERS? Estándares
� IEEE Std. 830� PSS-05 de la Agencia Espacial Europea
(ESA)� Las herramientas de gestión de requisitos
permiten generar documentación en los anteriores formatos, a partir de una base de datos de requisitos.
El documento de requisitos IEEE Std. 830.
1. INTRODUCCIÓN 1.1. Propósito1.2. Ámbito1.3. Definiciones, acrónimos y abreviaturas1.4. Referencias1.5. Visión general del resto del documento
2. DESCRIPCIÓN GENERAL2.1. Perspectiva del producto2.2. Funciones del sistema2.3. Características de los usuarios2.4. Restricciones generales2.5. Suposiciones y dependencias
APÉNDICESÍNDICE
3. REQUISITOS ESPECÍFICOS3.1. Requisitos de interfaces
externos3.1.1. Interfaces de usuario3.1.2. Interfaces hardware3.1.3. Interfaces software3.1.4. Interfaces de comunicaciones
3.2. Requisitos funcionales3.2.1. Usuario 1
3.2.1.1. Requisito funcional 1.1.…3.2.1.n. Requisito funcional 1.n.
…3.2.2. Usuario 2
3.2.1.1. Requisito funcional 2.1.…3.2.1.n. Requisito funcional 2.n.
3.3. Requisitos de rendimiento3.4. Requisitos de diseño3.5. Atributos del sistema3.6. Otros requisitos
3. REQUISITOS ESPECÍFICOS
Por ACTORES
Número y nombre
Descripción
Entradas
Validación de las entradas
Proceso
Fórmulas de conversión de entradas en salidas
Mensajes de error y control de excepciones
Efecto de los parámetros
Salidas
Secuencia de las salidas
Importancia *
Estabilidad *
10
El proceso de IR
Estudio de viabilidad
Obtención y análisis de requisitos
Especificación de requisitos
Validación de requisitos
Informe de viabilidad
Actividades
Productos
Modelos del sistema
Requisitos de usuario
DocumentoERS
requisitos informales
borrador documento de requisitos
requisitosnegociados
documento derequisitos e informe devalidación
análisis y negociaciónde requisitos
captura derequisitos
documentaciónde requisitos
validación derequisitos
punto de decisión
Validación de requisitos
Gestión de requisitos
Validación de requisitos
� ¿En qué consiste?� Comprobar que los requisitos son consistentes,
completos, precisos, realistas, verificables, definen lo que el usuario quiere….
� ¿Por qué validar los requisitos?� Coste de errores muy alto después de implementar.
� ¿Cómo validar los requisitos?1. evaluación estática o revisión de requisitos2. prototipos
3. generación de casos de prueba (test de requisitos)
13
Los errores en el documento de especificación de requisitos puede conducir a importantes costes si esto implica repetir un desarrollo ya realizado.
Técnicas de validación de requisitos:o Revisiones de requisitos: Los requisitos se analizan sistemáticamente por un
equipo de revisores experto.o Construcción de prototipos: Realizar un modelo ejecutable del sistema para
que clientes y usuarios finales puedan experimentar con él y determinar si cumple sus necesidades.
o Generación de casos de prueba: Los requisitos deben poder probarse. Si se incluye la generación de casos de prueba se incluye como parte del proceso de IR, a menudo se revelarán problemas en los requisitos.
Recordando…Actividades del proceso de IR: Validación de
requisitos
Validación de requisitos
� Acciones a tomar frente a problemas detectados:� requisitos mal expresados: clarificarlos� falta información en el requisito: identificarla y
añadirla� conflictos entre requisitos: negociación� requisitos no realistas: eliminación o modificación
Validación de requisitos
Documento derequisitos
Estándares
Conocimiento de laorganización
Lista de problemas
Lista de acciones
Validación de requisitos. 1. Evaluación estática o revisiones. Técnicas
� Se conocen como REVISIONES.
� Detectar manualmente los defectos.� Tipos:
�Revisiones informales�Revisiones formales o INSPECCIONES
�Walkthrough�Auditorías
Validación de requisitos. 1. Evaluación estática. Inspecciones
� Las Inspecciones son un proceso bien definido y disciplinado donde un equipo de personas cualificadas analizan un producto software usando una técnica de lectura con el propósito de detectar defectos. El objetivo principal de una inspección es detectar faltas antes de que la fase de prueba comience. Cualquier desviación de una propiedad de calidad predefinida es considerada un defecto
Visión general(Opcional)
Validación de requisitos. 1. Evaluación estática. El proceso de inspección
Seguimiento
Informe deinspecciónResumen de
defectos
Productoaceptado
Agenda
Lista de comprobación
Reunión
Lista dedefectos
Corrección
PlanificaciónProductoa revisar
Formularios
Documentos de soporte(estándares, guías, procedimientos)
Notificacióninspección Preparación
Validación de requisitos. 1. Evaluación estática. Inspecciones. Técnicas de lectura
� Guías para detectar defectos.� Ayuda al conocimiento del producto que se inspecciona.� Tipos:
� Ad-hoc.
� Basada en listas de comprobación.
� Lectura por abstracción� Revisión activa de diseño� Lectura basada en escenarios.
� Basada en defectos.� Basada en perspectivas.
Validación de requisitos. 1. Evaluación estática. Inspecciones Técnicas de lectura. Lectura sin y con listas de comprobación
� Lectura Ad-hoc
� No hay apoyo para los inspectores.� Lectura basada en listas de comprobación
� Preguntas que los inspectores deben responder.� Ayudan a saber qué tipo de faltas buscar.� Pero:
� Las preguntas suelen ser generales (independientes del contexto y del problema)
� Limitadas a un tipo de defectos (normalmente de corrección)
� ¿Existen contradicciones en la especificación de los requisitos?� ¿Resulta comprensible la especificación?� ¿Está especificado el rendimiento?� ¿Puede ser eliminado algún requisito? ¿Pueden juntarse dos
requisitos?� ¿Son redundantes o contradictorios?� ¿Se han especificado todos los recursos hardware necesarios?� ¿Se han especificado las interfaces externas necesarias?� ¿Se han definido los criterios de aceptación para cada una de las
funciones especificadas?� ¿Cada requisito tienen un identificador único?� ¿Están definidos en el glosario los términos técnicos?� ¿El requisito se comprende sin tener que recurrir a otros requisitos?� ¿Requisitos diferentes utilizan el mismo término de maneras
distintas?
Validación de requisitos. 1. Evaluación estática. Inspecciones Técnicas de lectura. Listas de comprobación para requisitos
� Conectores persuasivos (ciertamente, claramente, obviamente,...)
� Evitar términos imprecisos (algunos, a veces, normalmente, en la mayoría de los....)
� Términos de certidumbre (siempre, todos, nunca, ...)� Rangos: (10..100) ¿enteros, reales?� Ejemplos para los cálculos� Nº de página, pie, etc.
Validación de requisitos. 1. Evaluación estática. Inspecciones Técnicas de lectura. Listas de comprobación para requisitos
Validación de requisitos. 1. Evaluación estática. Inspecciones Técnicas de lectura. Lectura basada en escenarios
� Proporciona guías sobre cómo examinar el producto software.� Un escenario limita la atención del inspector al tipo de defectos
definidos en la guía.� Cada inspector puede trabajar con escenarios distintos.
� Lectura Basada en Defectos
� Focaliza cada inspector en una clase distinta de defectos (p.e.que los requisitos sean claros).
� Lectura Basada en Perspectiva
� Un producto software se inspecciona bajo las perspectivas de distintos participantes.
� Las perspectivas dependen del papel de los participantes. � Para cada perspectiva se definen uno o varios escenarios
consistentes en actividades repetibles que un inspector debe realizar y preguntas que el inspector debe responder.
Validación de requisitos2. Prototipos
� Tipos de prototipos:�Mock-up: pantallas dibujadas a mano en
papel. Para aclarar la IU en casos concretos.�Storyboard: además de la IU se muestra una
secuencia de acciones o escenarios.�Maquetas: versión simplificada del sistema.
Se representan además las conexiones entre pantallas mediante elementos activos.
�Prototipo funcional.
selecciona quiénprobará elprototipo
desarrollaescenariosde pruebas
ejecutaescenarios
documentaproblemas
amplia el prototipoUsuarios finales con trabajos distintos
En amplitud Observación de losingenieros de requisitos
Validación de requisitos2. Prototipos
� Sólo si ya se desarrolló uno durante la fase de captura� Hay que seguir desarrollando el prototipo y en paralelo
Validación de requisitos2. Prototipos
� El prototipo debe:� ser fiable: si “casca” sin que avise el ingeniero, el usuario estará
descontento� si falta funcionalidad: avisar al usuario� documentación sobre qué hacer si algo va mal
� Otra forma de validar requisitos es escribir un manual de usuario del prototipo desarrollado:� descripción de la funcionalidad implementada y su acceso a
través de la interfaz de usuario� indicar claramente qué partes del sistema no están
implementadas� descripción de procedimientos de recuperación frente a fallos.� instrucciones de instalación
Validación de requisitos3. Test de requisitos
� Es deseable diseñar pruebas sobre cada requisito individual.
� Si hay dificultades en derivar casos de test para un requisito, esto puede implicar que la descripción del requisito es ambigua, que falta o información,....
requisitos informales
borrador documento de requisitos
requisitosnegociados
documento derequisitos e informe devalidación
análisis y negociaciónde requisitos
captura derequisitos
documentaciónde requisitos
Validación derequisitos
punto de decisión
Gestión de requisitos
Gestión de requisitos
Gestión de requisitos� Cambios en los requisitos
� Surgen nuevos requisitos al cambiar las necesidadesdel negocio y entender mejor el sistema
� Diferentes puntos de vista tienen diferentesrequisitos, a menudo contradictorios
� Cambia la prioridad en los requisitos� Cambios tecnológicos� Cambios en leyes y/o regulaciones
� Gestionar los cambios� Seleccionar los requisitos para una entrega
�Triage
Gestión de requisitos
� Impacto del cambio�Momento del cambio�Productos del desarrollo afectados:
trazabilidad�Tiempo y esfuerzo
� Puntos de función
Gestión de requisitos
� Los requisitos deben ser “rastreables”:� Quién lo propuso y por qué existe (trazada, hacia atrás)� Con qué requisitos está relacionado (ref’s cruzadas, interna)� Cómo se relaciona el requisito con elementos de diseño y/o
implementación (trazable, hacia adelante)
� Herramientas para la gestión de requisitos:� Base de datos para almacenarlos� Facilidades de generación y análisis de documentos: para crear
documentos de requisitos y la misma base de datos.� Facilidades de gestión de cambios: para evaluar los cambios� Facilidades de “rastreo”: para descubrir dependencias
� Procedimientos, procesos y estándares utilizados para gestionar los cambios de requisitos de un sistema.
� Actividades durante el proceso de gestión de cambios:
Gestión de requisitos. Proceso de gestión de cambios
identificación delcambio
análisis del cambioy evaluación de costes
desde análisis de requisitos, nuevas necesidades del cliente, problemas operacionales
cuántos requisitos se verán afectados y cuántocostará (tiempo, dinero)
documentar el cambio realizado
(Específico del tipo de cambio)
(Específico del tipo de cambio)
(General)
implementacióndel cambio
rechazodel cambio
� Seleccionar los requisitos para maximizar los beneficios del proyecto (no sólo coste, sino satisfacción, cumplimiento de los objetivos principales, etc)
� Factores:� Influencia de los requisitos en el producto
� Estabilidad� Importancia� Referencias cruzadas
� Evaluación del beneficio� Aspectos técnico-sociales
Gestión de requisitosSelección de requisitos o triage
Gestión de requisitosTriage. Actividades
Anotar por estabilidad e importancia
Estimar los ingresos
Definir referencias cruzadas
Estimar coste de cada requisito
Toma de decisiones y planificación de releases
Bibliografía1.- Ingeniería del software: un enfoque práctico. A. R. S. Pressman. Editorial McGraw-Hill. Madrid 1996. ISBN: 84-481-1186-9
3.- Software Engineering. A. I. Sommerville. Editorial Addison-Wesley. Harlow 1996. ISBN: 0201427656
7. Requirements Engineering: Processes and Techniques. Gerald Kotonya e Ian Sommerville. Wiley
8. Requirements Engineering: A good practice guide. Ian Sommerville y Pete Sawyer. Wiley
¿Dónde encuentro información adicional?
� Revista Requirements Engineering (Springer)�http://rej.co.umist.ac.uk/
� IEEE Software: columna de interés dedicada a este tema (Robertson, 2001).
� IEEE Joint International RequirementsEngineering Conference.