Ingeniería de Requisitos de Software: Casos de Uso, Prototipos, Elicitación y Validación
Ingeniería de Requisitos de Software
Casos de uso
Los casos de uso se basan en escenarios para obtener los requisitos funcionales del software. Un caso de uso es un escenario que representa la interacción entre los actores y el sistema. Un actor caracteriza las interacciones que los usuarios pueden tener con el sistema y puede participar en uno o más casos de uso, al igual que un caso de uso puede estar relacionado con uno o varios actores.
Prototipos
Un prototipo es un desarrollo representativo, a pequeña escala, de las necesidades del usuario, simulando el software a desarrollar. Sus fases son:
- Captura de requisitos;
- Definición de objetivos del software e identificación de requisitos por parte de desarrolladores y clientes;
- Diseño rápido del software, centrado en los elementos que interactuarán con el usuario (entradas y salidas);
- Construcción del prototipo.
Ingeniería inversa
La ingeniería inversa es la técnica que se utiliza para obtener información de un software ya existente con la finalidad de entender cómo funciona y, así, poder modificarlo, mejorarlo, evolucionarlo y rediseñarlo.
Validación de requisitos
La validación de requisitos es la actividad en la que se verifica que todos los requisitos obtenidos, descritos y documentados en los pasos anteriores son válidos. Durante esta validación debemos controlar que estos requisitos sean: válidos, consistentes, completos, reales, verificables, comprensibles, trazables y adaptables.
Entrevistas
Las entrevistas pueden ser cerradas o abiertas y sirven para comprender las necesidades del software. Sus fases son: preparación, realización y análisis.
Requisitos
Los requisitos deben ser: comprensibles, necesarios, no ambiguos, completos, consistentes, verificables, realizables, modificables, rastreables y priorizables.
- Requisitos funcionales (RF): describen con detalle los servicios y funciones que un sistema debe aceptar. Cómo debe reaccionar ante una entrada particular y cómo debe comportarse ante situaciones particulares y excepcionales.
- Requisitos no funcionales (RNF): describen las restricciones que afectan a los servicios o funcionalidades del sistema. Son restricciones sobre los RF y pueden ser de tipo:
- De producto: especifican o restringen el comportamiento del producto obtenido, por ejemplo: memoria requerida o velocidad de ejecución (usabilidad, fiabilidad, eficiencia [rendimiento, espacio], portabilidad).
- Organizacionales: pueden ser procesos estándar utilizados, fechas de entrega o documentación a entregar (entrega, implementación, estándares).
- Externos: describen factores externos al sistema, por ejemplo: LOPD (interoperabilidad, ético, legislativos [privacidad, seguridad]).
- Requisitos del dominio (RDOM): provienen del dominio de aplicación del sistema, reflejando las características y restricciones de dicho dominio. Pueden ser RF o RNF. Por ejemplo: debido a las restricciones de la licencia CC, algunos documentos solo podrán visualizarse online.
Validación de software
- Prueba de componentes;
- Prueba del sistema;
- Prueba de aceptación.
Elicitación de requisitos
Hasta las últimas décadas, la elicitación de requisitos no era considerada parte de un proyecto de desarrollo de software, ya que se asumía que los clientes debían proporcionar los requisitos; por ello, estas tareas de elicitación y validación no se consideraban necesarias. A partir de la “crisis del software” comenzaron a considerarse importantes estas tareas.
Esta actividad es donde se capturan y obtienen los requisitos. Los participantes o stakeholders son aquellas personas que se verán afectadas por el software que se va a desarrollar. La elicitación y análisis de requisitos puede estructurarse en cuatro puntos:
- Descubrimiento de requisitos;
- Clasificación y organización de requisitos;
- Ordenación por prioridades y negociación de requisitos;
- Documentación de requisitos.
Técnicas de elicitación
- Entrevistas individuales/grupales;
- Cuestionarios;
- Escenarios;
- Casos de uso;
- Brainstorming;
- Reutilización de requisitos;
- Prototipos;
- Revisión de documentación técnica;
- Ingeniería inversa;
- Talleres de discusión.
Brainstorming
Participan personas con experiencia en distintas disciplinas para aportar ideas creativas. No se juzgan las ideas y no se descarta ninguna. Sus fases son: preparación, generación, consolidación y documentación.
JAD (Joint Application Development)
Es una técnica de trabajo grupal con todos los stakeholders para realizar un diseño preliminar del software a desarrollar. Tipos de participantes: facilitador del JAD, analista, patrocinador ejecutivo, representantes de los usuarios, representantes de los sistemas y especialistas.
Modelos de desarrollo
- Cascada: definir requisitos, diseño del sistema, implementación, integración y pruebas, funcionamiento y mantenimiento.
- Desarrollo evolutivo: se basa en la implementación de un sistema inicial, exponerlo a los comentarios de los usuarios y depurarlo, en un bucle (especificación, desarrollo, validación) hasta obtener el sistema deseado.
- Modelo de entrega incremental: modelo intermedio, mezcla de cascada y evolutivo.
Etapas principales de especificación de software
- Estudio de viabilidad;
- Obtención y análisis de requisitos;
- Especificación de requisitos;
- Validación de requisitos.
Crisis del software
La crisis del software surgió por la dificultad de desarrollar programas que, además de funcionar correctamente, fueran comprensibles, verificables, adaptables y no costosos. Los principales problemas eran:
- No terminaban en la fecha establecida;
- Superaban de manera sustancial el presupuesto inicial;
- No se cumplían las especificaciones establecidas;
- Se desarrollaba código de baja calidad.
SRS (Software Requirements Specification)
El SRS debe incluir todo lo que los desarrolladores del software deben implementar, es decir, una descripción general de las funcionalidades, necesidades y restricciones del software a desarrollar. Debe incluir tanto los requisitos de usuario como los del sistema.