Análisis y Especificación de Requisitos de Software

1. Introducción al Análisis de Requisitos

El análisis de requisitos es una fase crucial del ciclo de vida del software. Consiste en producir un documento que describa qué debe hacer el sistema, pero no cómo. El analista realiza actividades de análisis y síntesis, trabajando en conjunto con los proveedores y clientes. El análisis de requisitos se define como «el proceso de estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema».

Esta colaboración es esencial porque:

• Los clientes no suelen comprender el proceso de desarrollo de software para redactar una Especificación de Requisitos de Software (ERS).
• Los analistas no siempre entienden completamente el problema del cliente debido a que no dominan su área de trabajo.

Según el estándar IEEE 1074, el análisis de requisitos incluye tres actividades principales:

• Definir los requisitos del software: Es una tarea iterativa para crear una especificación a partir de la información obtenida mediante técnicas como entrevistas, cuestionarios, JAD y prototipado.
• Definir los requisitos de las interfaces: Se trata de definir los flujos de información del software con el usuario y otras aplicaciones, las interacciones usuario-sistema y las características de interrelación con aplicaciones y hardware. La interfaz de usuario es crítica para la usabilidad y el éxito del software.
• Integrar los requisitos en un documento: Consolidar toda la información en un documento ERS completo y coherente.

2. Especificación de los Requisitos del Software

2.1 Introducción a la ERS

Para comprender qué es una ERS, definamos:

• Especificación: Documento que define de forma completa, precisa y verificable los requisitos, el diseño, el comportamiento u otras características de un sistema o sus componentes.
• Software: Conjunto de programas, procedimientos y documentación asociados a la operación de un sistema informático.

La ERS documenta los requisitos esenciales del software (funciones, rendimiento, diseño, restricciones y atributos) y sus interfaces externas. Actúa como los planos de una casa, definiendo su aspecto, pero no su estructura interna. Debe incluir información veraz y fácilmente entendible, coherente con las necesidades del usuario.

Esto implica que:

• Debe describir correctamente todos los requisitos, sin incluir requisitos innecesarios.
• No debe describir detalles del diseño, verificación o dirección del proyecto, salvo restricciones que influyan en los requisitos (ej. limitaciones de hardware).

2.2 Características de una Buena ERS

Una ERS eficaz debe tener las siguientes características (IEEE 1984b):

1. No ambigua: Cada requisito tiene una única interpretación.
2. Completa: Incluye todos los requisitos (funcionalidad, ejecución, diseño, calidad, interfaces), define todas las clases de datos y situaciones (entradas válidas e inválidas), cumple con los estándares de especificación y tiene todos los elementos (figuras, tablas, diagramas) etiquetados y referenciados.
3. Fácil de verificar: Cada requisito se puede verificar mediante un procedimiento finito y efectivo.
4. Consistente: No hay requisitos contradictorios. Los conflictos pueden ser de terminología, características o temporales.
5. Fácil de modificar: Su estructura permite cambios fáciles, completos y consistentes, con tabla de contenidos, índice y referencias cruzadas, sin redundancia.
6. Trazabilidad: Facilidad para identificar el origen y las consecuencias de cada requisito, con referencias hacia atrás (documentos previos) y hacia adelante (documentos generados a partir de la ERS).
7. Fácil de utilizar: Debe ser comprensible para el personal de mantenimiento, que puede ser diferente al equipo de desarrollo.

2.3 Estructura de la ERS

1. Introducción: Objetivo, Ámbito, Definiciones, Siglas y Abreviaturas, Referencias, Visión global.
2. Descripción general: Perspectiva del producto, Funciones del producto, Características del usuario, Limitaciones generales, Supuestos y dependencias.
3. Requisitos específicos:
   1. Requisitos funcionales (cada requisito con: Introducción, Entradas, Procesamiento, Salidas)
   2. Requisitos de interfaz externa (Interfaces de usuario, hardware, software, comunicaciones)
   3. Requisitos de ejecución
   4. Requisitos de diseño (Acatamiento de estándares, Limitaciones de hardware)
   5. Atributos de calidad (Seguridad, Mantenimiento)
   6. Otros requisitos (Base de datos, Operaciones, Adaptación de situación)

2.4 Interfaces

Las interfaces externas son cruciales para la facilidad de uso. Coinciden con las entradas y salidas del sistema, identificables en el diagrama de contexto. Ejemplos:

• Entradas: Teclados, pantallas de introducción de datos, sensores, ficheros.
• Salidas: Pantallas de presentación de información, listados, ficheros.

3. Técnicas de Especificación

Existen diferentes técnicas de especificación, clasificadas según su forma de representación:

• Gráficas: Usan iconos para representar componentes y sus conexiones (ej. DFD).
• Textuales: Especifican con detalle los componentes definidos en los gráficos, usando una gramática más formal (ej. DD, lenguaje estructurado).
• Marcos o plantillas: Especifican la información de un modelo mediante formularios con campos para cada característica.
• Matriciales: Estudian las referencias cruzadas entre los componentes de los modelos.