Análisis e Ingeniería de RequisitosAIR... · Análisis e Ingeniería de Requisitos – Tema 5...

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


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


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


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



AIR - 5



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



AIR - 7



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



AIR - 9


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


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


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



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



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



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



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



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



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



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



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



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



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



¿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



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



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



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



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



Ejercicio: Complete la siguiente tabla con las técnicas conocidas.

Dimensión Técnicas Tipo

Información

Función

Tiempo

AIR - 28

Análisis e Ingeniería de RequisitosAIR... · Análisis e Ingeniería de Requisitos – Tema 5...

Documents

Transcript of Análisis e Ingeniería de RequisitosAIR... · Análisis e Ingeniería de Requisitos – Tema 5...