grado en ingeniería del software curso 2010 – 2011 ......jerarquía multinivel: 1º por usuario,...

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






Actividades

Productos

Modelos del sistema


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






Actividades

Productos

Modelos del sistema


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


Gestió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


� 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


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


� Sólo si ya se desarrolló uno durante la fase de captura� Hay que seguir desarrollando el prototipo y en paralelo


� 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� 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


� Impacto del cambio�Momento del cambio�Productos del desarrollo afectados:

trazabilidad�Tiempo y esfuerzo

� Puntos de función


� 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.

grado en ingeniería del software curso 2010 – 2011 ......jerarquía multinivel: 1º por usuario,...

Documents