Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Análisis e Ingeniería de Requisitos Tema 5: Documentación de Requisitos
Curso 2012-2013
AIR - 1
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Bibliografía Básica
Ingeniería del Software: un enfoque práctico. Pressman, McGraw-Hill,
2002 5ª Ed.
Ingeniería del Software. Ian Sommerville,Addison Wesley, 2004ª Ed.
Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión. Piattini et al., RA-MA, 1996.
AIR - 2
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Recordamos: Ingeniería de Requisitos
¿Qué es la Ingeniería de Requisitos?
Es el proceso para descubrir, analizar, documentar y verificar los servicios que debe proporcionar el sistema y sus restricciones.
Define un proceso.
Facilita la comprensión de lo que quiere el cliente. • Analizando sus necesidades
• Confirmando su viabilidad
• Negociando la solución
• Especificando la solución sin ambigüedad
• Validando y Gestionando requisitos para que el sistema pueda ser operativo.
AIR - 3
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Recordamos: Proceso de Desarrollo de Requisitos
Objetivo: Crear y mantener un documento de requisitos del sistema.
Define el conjunto estructurado de actividades de cuya ejecución se obtiene y mantiene la especificación de los requisitos.
El proceso de desarrollo (ingeniería) de requisitos comprende (en general) 4 etapas: 1. Identificación o captura de requisitos
2. Análisis (y negociación) de requisitos
3. Especificación o documentación de requisitos
4. Validación de requisitos
AIR - 4
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Recordamos: Proceso de Desarrollo de Requisitos
AIR - 5
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Recordamos: Proceso de Desarrollo de Requisitos
Identificación o captura de requisitos
En esta etapa los ingenieros de software trabajan con los clientes y los usuarios finales del sistema.
Determinar: el dominio de la aplicación
qué servicios debe proporcionar el sistema
rendimiento requerido del sistema
restricciones de hardware
etc.
AIR - 6
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Recordamos: Proceso de Desarrollo de Requisitos
AIR - 7
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Recordamos: Proceso de Desarrollo de Requisitos
Análisis (y negociación) de requisitos:
Una vez recopilados los requisitos: Se agrupan por categorías y se organizan
Se estudia cada requisito en relación con el resto
Se examina la consistencia, completitud y ambigüedad de los requisitos
Se clasifican en base a las necesidades de los clientes/usuarios (negociación) • Los clientes, usuarios y resto de los implicados deberán clasificar
sus requisitos y discutir posibles conflictos
• Priorizar requisitos
• Compromiso final sobre el conjunto de requisitos a implementar Especificación o documentación de requisitos
AIR - 8
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Recordamos: Proceso de Desarrollo de Requisitos
AIR - 9
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Proceso de Desarrollo de Requisitos
AIR - 10
Captura de Requisitos Análisis y Negociación
de Requisitos
Documentación de Requisitos Validación de Requisitos
Requisitos Informales
Requisitos Negociados
Borrador del documento de requisitos
Documento de requisitos e informe de validación
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Tema 5: Documentación de los Requisitos
1. Definición
2. Aspectos fundamentales de la documentación de los requisitos.
3. Estándares y esquemas de documentación.
4. Características de la documentación.
AIR - 11
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
Documentación de requisitos
El proceso de redacción o registro de los requisitos. Para este proceso puede recurrirse al lenguaje natural, lenguajes formales, modelos, gráficos, etc.
Especificación o Documento de Requisitos:
Es un documento que define, de forma completa, precisa y verificable, los requisitos, el comportamiento u otras características de un sistema o componente de un sistema.
AIR - 12
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
Para ser eficaz, la especificación de requisitos debe tener ciertas características que facilitan su utilización por el equipo del proyecto para el trabajo técnico y para la interacción con el usuario.
Es un elemento clave dentro de la documentación necesaria para el desarrollo de software.
Una especificación de requisitos juega un papel similar al que representan en la arquitectura los planos que definen el aspecto
de una casa (no su estructura de construcción).
AIR - 13
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
Características fundamentales de un especificación de requisitos:
Debe incluir información cierta, es decir, coherente con las necesidades reales del usuario que se desean satisfacer. Ejemplo: no sirve de nada que se describa erróneamente el formato de
los datos.
Debe comunicar dicha información de forma eficaz, es decir, de tal manera que se pueda comprender perfectamente. Vemos una lista de propiedades que debería tener una buena
especificación de requisitos.
AIR - 14
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
Una especificación de requisitos no debe llevar a excedernos a la
hora de definirla y construirla. La especificación debe abordar la descripción de lo que hay que desarrollar, no el cómo, el cuándo se desarrolla el software. Esto implica:
Debe describir correctamente todos los requisitos del software, pero sin incluir requisitos innecesarios.
Ejemplo: aquellas funciones que no ha pedido explícita o implícitamente el usuario.
No debe describir ningún detalle del diseño del software, de su verificación o de la dirección del proyecto, excepto las restricciones impuestas al diseño.
Ejemplo: limitación del hardware disponible que influyen en los requisitos
Esta información se incluirá en otros documentos (plan de proyecto, descripción del diseño, etc.)
AIR - 15
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
Características de una BUENA especificación de requisitos:
1. No ambigua.
2. Completa.
3. Fácil de verificar.
4. Consistente (coherente).
5. Clasificada por importancia o estabilidad.
6. Fácil de modificar.
7. Fácil identificación del origen y de las consecuencias de cada requisito.
8. De fácil utilización durante la fase de explotación y de mantenimiento.
AIR - 16
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
1. No ambigua: Un requisito ambiguo se presta a distintas interpretaciones. Una
especificación de requisitos no es ambiguo si y sólo si cada requisito descrito tiene una única interpretación.
Esto implica que cada característica del producto final sea descrita utilizando un término único.
En los casos en que un término usado en diferentes contextos pueda tener distintos significados, debe incluirse en un glosario.
Se debe poner especial atención con el lenguaje natural. Ejemplo: “Todos los registros de un fichero serán controlados mediante un
bloque de control de registro” a) un bloque controla todos los registros del fichero? b) cada registro tiene su propio bloque? c) se controla cada registro mediante un bloque, pero un bloque puede
controlar más de un registro?
AIR - 17
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
2. Completa: Una especificación de requisitos está completa si:
Incluye todos los requisitos significativos del software Define la respuesta del software a todas las posibles clases de datos de entrada y en todas las posibles situaciones. (Ojo: entradas válidas y no válidas) Está conforme con cualquier estándar de especificación que se deba cumplir. Están etiquetadas y referenciadas en el texto todas las figuras, tablas y diagramas. También deben estar definidos todos los términos y unidades de medida.
Cualquier ERS que utilice la expresión 'por determinar' (TBD: To Be
Determined) no está completa. Si es necesario, se debe acompañar de: Una descripción de las condiciones que han causado el TBD para que la situación pueda ser resuelta (por ejemplo, porque la administración aún no ha determinado el formato exacto de un impreso de pago de impuestos). Una descripción de qué hay que hacer para eliminar el TBD (por ejemplo, esperar a la publicación de un Real Decreto o un reglamento de impuestos).
AIR - 18
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
3. Fácil de verificar: Una especificación de requisitos es fácil de verificar si y sólo si
cualquier requisito al que se haga referencia se puede verificar fácilmente, es decir, existe algún procedimiento finito y efectivo en coste para que una persona o una máquina compruebe que el software satisface dicho requisito.
Ejemplo: “El programa no debe entrar nunca en un bucle infinito”
Si no se encuentra un método para determinar si el producto software satisface un requisito concreto, entonces se debe eliminar dicho requisito.
AIR - 19
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
4. Consistente: Una especificación de requisitos es consistente si y sólo si ningún conjunto de
los requisitos descritos en ella son contradictorios o entran en conflicto. Se pueden presentar tres tipos distintos de conflicto:
Dos o más requisitos pueden describir el mismo objeto real pero utilizan distintos términos para designarlo. Las características especificadas de objetos reales pueden estar en conflicto. Puede haber un conflicto lógico o temporal entre dos acciones determinadas.
5. Clasificada por orden de importancia o estabilidad: Los requisitos deben tener establecido un orden de prioridad basado en su
importancia para la aplicación o, alternativamente, una clasificación en función de su estabilidad, es decir, su resistencia a la volatilidad.
AIR - 20
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
6. Fácil de modificar: Una especificación de requisitos es fácilmente modificable si su estructura y estilo
permiten que cualquier cambio necesario en los requisitos se pueda realizar fácil, completa y consistentemente. Esto implica que la especificación debe:
Tener una organización coherente y manejable, con una tabla de contenidos, un índice y referencias cruzadas. No ser redundante. Así, un cambio supone modificar el documento en un solo sitio. La redundancia en sí no es un error, pero puede fácilmente conducir a problemas.
7. Facilidad para identificar el origen y las consecuencias de cada requisito: Se dice que una especificación de requisitos facilita las referencias con otros
productos del ciclo de vida si establece un origen claro para cada uno de los requisitos y si posibilita la referencia de estos requisitos en desarrollos futuros o en incrementos de la documentación. Se recomiendan dos tipos de referencias:
Referencias hacia atrás: depende de que los requisitos referencien explícitamente sus fuentes en documentos previos. Referencias hacia delante: depende de que cada requisito de la ERS tenga un nombre o número de referencia único que sirva para identificarlo en futuros documentos.
Concepto de Trazabilidad: Se habla de la propiedad de Traceability para denominar la
capacidad de establecer una relación entre dos o más productos del ciclo de vida.
AIR - 21
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
8. Facilidad de utilización en la fase de explotación y mantenimiento: La especificación de requisitos también debe tener en cuenta las necesidades
de mantenimiento, incluyendo la sustitución eventual del software. Esto se debe a las siguientes causas:
1. El personal que no ha estado relacionado con el desarrollo del producto software se encarga del mantenimiento. Es esencial actualizar la documentación del diseño y de los requisitos. Por lo tanto, para este último caso:
La ERS debe ser fácilmente modificable, como vimos con anterioridad. La ERS debería prever un registro de las características especiales de cada componente, tales como: • Su criticidad • Su relación con necesidades temporales • Su origen
2. Gran parte de los conocimientos y de la información necesaria para el mantenimiento se dan por supuestos en la organización del desarrollo, pero suelen estar ausentes en la organización del mantenimiento.
Si no se entiende la razón del origen de una función, es prácticamente imposible desarrollar el mantenimiento.
AIR - 22
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
¿Cómo organizar una ERS? Un conjunto de requisitos se puede agrupar según se refieran a:
1. El mismo estímulo externo 2. La misma característica del sistema 3. La misma respuesta del sistema 4. El mismo objeto del mundo real 5. La misma clase de usuarios 6. La misma clase de función
Jerarquía multinivel: 1º por usuario, luego por objetos del mundo real
AIR - 23
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
Estructura para una especificación de requisitos: Estructura propuesta por el estándar IEEE 830
1. Introducción 1.1. Objetivo 1.2. Ámbito 1.3. Definiciones, Siglas y Abreviaturas 1.4. Referencias 1.5. Visión Global 2. Descripción general 2.1. Perspectiva del producto 2.2. Funciones del producto 2.3. Características del usuario 2.4. Limitaciones generales 2.5. Supuestos y dependencias 3. Requisitos específicos Apéndices Índice
AIR - 24
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
Estructura de la sección 3 de una especificación de requisitos:
3. Requisitos específicos 3.1. Requisitos funcionales 3.1.1. Requisito funcional 1 3.1.1.1. Introducción 3.1.1.2. Entradas 3.1.1.3. Procesamiento 3.1.1.4. Salidas 3.1.2. Requisito funcional 2 .................. 3.1.n. Requisito funcional n 3.2. Requisito de Interfaz externa 3.2.1. Interfaces de usuario 3.2.2. Interfaces hardware 3.2.3. Interfaces software 3.2.4. Interfaces de comunicaciones 3.3. Requisitos de ejecución 3.4. Restricciones de diseño 3.4.1. Acatamiento de estándares 3.4.2. Limitaciones hardware 3.5. Atributos de calidad 3.5.1. Seguridad 3.5.2. Mantenimiento 3.6. Otros requisitos 3.6.1. Base de datos 3.6.2. Operaciones 3.6.3. Adaptación de situación
AIR - 25
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
Clasificación de Técnicas de Especificación:
Según la forma de Representación: Gráficas
Textuales
Marcos (o plantillas (“templates”))
Matriciales
Según el enfoque de modelización: Dimensión de la función: qué hace el sistema
Dimensión de la información: qué información utiliza el sistema
Dimensión del tiempo: cuándo sucede algo en el sistema
AIR - 26
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
INFORMACION
FUNCION TIEMPO
INFORMACION
FUNCION TIEMPO
INFORMACION
FUNCION TIEMPO
Sistema de Tiempo Real
Sistema de Gestión de orientado a datos
Sistema de Gestión orientado a funciones
AIR - 27
Análisis e Ingeniería de Requisitos – Tema 5 www.kybele.urjc.es
Documentación de los Requisitos
Ejercicio: Complete la siguiente tabla con las técnicas conocidas.
Dimensión Técnicas Tipo
Información
Función
Tiempo
AIR - 28