CAPÍTULO 3

CAPÍTULO 3

EL ANÁLISIS DE REQUISITOS

Es la segunda fase del proceso de duración del proyecto software. En esta fase se origina la documentación técnica en la que se especifican los requisitos técnicos que debe cumplir el software a un alto nivel de abstracción y de forma concisa, consistente y sin ambigüedades.

La Especificación de Requisitos se basa en definir QUÉ es el producto, en QUÉ consiste el producto que se desea construir, en lugar de definir CÓMO será ese producto.

Un documento ER deberá contemplar los siguientes aspectos del producto software:

1. Un resumen del producto y objetivo del mismo, así como los ambientes de desarrollo, operación y mantenimiento.

2. Información sobre las interfaces externas y el flujo de la información, así como de los requisitos funcionales y de operación.

3. Información sobre el manejo de las aplicaciones.

4. Descripción de la arquitectura del sistema.

5. Información sobre los recursos necesarios.

6. Requisitos para la validación del sistema.

7. Información de ayuda para el proceso de diseño

3.1. PRINCIPIOS DEL ANÁLISIS DE REQUISITOS

Existen propuestos muchos métodos para llevar a cabo el AR, cada uno con notación, reglas. . . distintos, pero con las siguientes características en común:

§ Dominio de la información:

Dominio de los datos y de de las funciones. El dominio de la información contiene tres visiones diferentes de los datos que son procesados por las funciones:

1. Flujo de la información: Cómo se mueve la información. Representa como cambian los datos cuando pasan por el sistema.

2. Contenido de la información: Qué información se mueve y qué significa. Representa elementos de datos individuales que componen a otros elementos de mayor entidad.

3. Estructura de la información: Forma de la información dentro de la estructura del sistema. Organización lógica de los distintos elementos de datos individuales y relaciones entre ellos.

§ Partición o descomposición del problema:

Generalmente un problema es demasiado complejo como para ser entendido como un “todo”. Se recurre a la división jerárquica del problema en la que se identifiquen distintas partes, fáciles de entender, y que en conjunto realicen la función global del sistema. Conceptualmente se establece una representación jerárquica de la información y luego se divide el elemento superior en base a las siguientes técnicas:

1. Incrementado de detalles: Nos movemos verticalmente en la jerarquía.

2. Descomponiendo funcionalmente el problema: Nos movemos horizontalmente en la a jerarquía.

§ Representación lógica y física:

1. Visión lógica: Funciones a realizar e información que deben procesar con independencia de detalles de implementación.

2. Visión Física: Representa una manifestación del mundo de las funciones de procesamiento y las estructuras de información.

3.2. ESPECIFICACIÓN DE LOS REQUISITOS

3.2.1. Actividades de la ERS

Consiste en tres actividades:

§ Definición de requisitos del software:

Tarea iterativa para crear una definición o especificación preliminar de los requisitos que debe cumplir el software.

§ Definición de los requisitos de las interfaces del software con el resto del sistema y con el exterior:

Definición de las propiedades del software para que logre una interacción eficaz con otros elementos u otras aplicaciones software.

§ Integrar los requisitos en un documento de especificación y asignarles prioridades:

Una vez descritos los requisitos deben ser revisados por el usuario vara su verificación y validación, por ello es necesario asignarles prioridades. Una vez realizada dicha revisión se genera un documento llamado Especificación de los Requisitos del software.

Raghavan propone otra forma de describir las actividades que se realizan durante la AR:

§ Extracción de requisitos.

§ Análisis de requisitos.

§ Especificación de requisitos.

§ Validación de requisitos.

La realización de las mismas suele apoyarse en distintas técnicas. Así para la extracción de los requisitos se emplean técnicas de recogida de información como la observación, entrevistas, grupos de trabajo… Para el análisis y especificación existen técnicas gráficas como los Diagramas de flujo de datos.

Para la validación suele recurrirse listas de comprobación junto con listas de revisión.

3.2.2. TÉCNICAS DE RECOGIDA DE LA INFORMACIÓN

Conjunto de técnicas cuyo objetivo es mejorar la comunicación usuario/cliente e ingeniero durante la definición del problema y especificación de la solución.

El proceso de recogida de información suele seguir los siguientes pasos:

1. Identificar las fuentes de información.

2. Realizar preguntas adecuadas.

3. Analizar la información recogida para ver qué aspectos quedan poco claros.

4. Confirmar con los usuarios que se han comprendido los requisitos.

5. Sintetizar los requisitos en un documento apropiado.

Las técnicas principales utilizadas en esta actividad son: entrevistas, desarrollo conjunto de aplicaciones, prototipado, observación, estudio de documentación, cuestionarios, tormenta de ideas (BrainStorming), ETHICS…

3.2.3. ESPECIFICACIÓN DE LOS REQUISITOS SOFTWARE

La ERS se define como:

La documentación de los requisitos esenciales (funciones, rendimiento, diseño, restricciones y atributos) del software y de sus interfaces externas.

La ERS debe por un lado incluir información veraz, coherente con las necesidades reales del usuario y comunicarla de forma eficaz, pero además deberá cumplir las siguientes características:

§ No debe ser ambigua, por lo que cada requisito deberá tener una única interpretación. Para lograr este objetivo se puede hacer uso de lenguajes formales de especificación de requisitos como por ejemplo el Lenguaje Z.

§ Debe ser completa.

§ Debe ser fácil de verificar.

§ Debe ser consistente: los requisitos no deben ser contradictorios o entrar en conflicto entre sí. Son fuentes de conflictos las siguientes situaciones:

1. Dos o más requisitos describen un mismo objetivo.

2. Las características especificadas de objetos reales pueden estar en conflicto.

3. Puede haber un conflicto lógico o temporal entre dos acciones determinadas.

§ Debe ser fácil de modificar.

§ Debe ser fácil de identificar origen y consecuencias de cada requisito.

§ Debe ser fácil de utilizar durante las fases de diseño, explotación y mantenimiento del software.

Para lograr que una ERS tenga estas características, Balzer y Goldman proponen ocho principios que deben satisfacer una buena especificación:

1. Una especificación debe separa funcionalidad de implementación.

2. Se debe utilizar un lenguaje de especificación formal orientado al proceso.

3. Una especificación debe abarcar al sistema en el cual el software se implantará.

4. Una especificación debe tener en cuenta el entorno del sistema software.

5. Una especificación debe ser un modelo cognitivo, en lugar de un modelo de diseño o implementación.

6. Una especificación debe ser operativa.

7. Una especificación debe ser tolerante a la incompleción y ampliable.

Generalmente la ERS se va cambiando a medida que se avanza en el proceso de desarrollo del software puesto que en principio hay detalles que es imposible especificar. A pesar de esto debemos tener en cuenta que un requisito debe ser especificado de la forma más completa posible y que si se producen cambios en el mismo, identificarlos, controlarlos, informarlos e incluirlos en la ERS.

3.2.4. ESPECIFICACIÓN DE REQUISITOS DE LAS INTERFACES

Las interfaces externas del software juegan un papel crucial en el propio software puesto que es lo que el usuario percibe más fácilmente y donde más influyen sus preferencias.

Las interfaces coinciden con las tradicionalmente llamadas Entradas/Salidas del sistema, haciendo referencia por un lado a pantallas de introducción de datos, sensores, ficheros... como entradas y por otro a diálogos de información, listados o salidas en papel, ficheros... como salidas de datos.

El objetivo de la definición de las interfaces de E/S es la estabilidad del modo en que el sistema va a interactuar con el exterior del mismo, siendo fundamental no sólo contar con la opinión de los usuarios, sino con criterio que le ayuden a decidir qué es mejor para su trabajo.

3.3. VISIÓN GENERAL DE LAS TÉCNICAS DE ESPECIFICACIÓN DE REQUISITOS

Atendiendo a distintos enfoques se pueden realizar distintos tipos de clasificación de las técnicas de especificación de requisitos.

1. Según la forma de representación:

§ Técnicas gráficas: Por sí solas no sirven de mucho. Su verdadera utilidad se encuentra al combinarla con otras técnicas. Cada técnica utiliza una serie de iconos que representan una serie de componentes de un aspecto particular del modelo.

§ Técnicas textuales: Se utilizan para especificar con más detalle componentes. Se suelen utilizar como complemento de las técnicas gráficas.

§ Marcos o plantillas: Se acogen a un formato preestablecido y se usan para especificar información sobre componentes definidos por técnicas gráficas o para especificar información sobre otros marcos de nivel superior. Ejemplo: Diccionario de datos.

§ Técnicas matriciales: Por sí solas no constituyen una técnica. Se apoyan en otras técnicas de definición haciendo uso de la información obtenida por ellas y la comparan para comprobar en qué medida se han cumplido los requisitos específicados.

2. Según el enfoque de modelación bajo el que se crean modelos del sistema en base a su función, información y tiempo. Bajo esta perspectiva el sistema es analizado bajo los siguientes tres aspectos:

§ Dimensión de la función:

- Diagrama de flujo de datos.

- Lenguaje estructurado.

- Árboles de decisión.

- Tablas de decisión.

- Diagrama de acción.

- Diagramas de descomposición funcional.

- Diccionario de datos.

§ Dimensión en base a la información:

- Diagrama Entidad-Interrelación.

- Diagramas de estructura de datos (para representar la visión lógica de EERR).

- Matriz entidad/entidad (cuando el número de entidades e interrelaciones es elevado).

§ Dimensión en base al tiempo:

- Listas de eventos.

- Diagramas de transición de estados.

- Redes Petri.

- Diagramas de la historia de vida de la Entidad.

- Matriz Evento/Entidad.

3.4. COMPROBACIÓN DE LA ERS

Una vez realizada la especificación de requisitos formada, al menos, por los DFD, DD y específicaciones de procesos es necesario revisarla en base a:

§ Compleción: Comprobando que los modelos son completos.

§ Integridad: Comprobando que no haya contradicciones ni inconsistencias.

§ Exactitud: Comprobando que los modelos cumplen los requerimientos.

§ Calidad: Comprobando el estilo, la legibilidad y la facilidad de mantenimiento de los modelos producidos.