CONCEPTOS O COMPONENTES

Definición
La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.
El proceso de Ingeniería de Requisitos es un conjunto estructurado de actividades que sirven para derivar, validar y mantener los requisitos de un sistema.

En el dibujo, los cuadros redondeados son tareas. Los cuadrados son productos (inputs u outputs).
Se pueden dar diferentes variaciones en el proceso, ya sea según la naturaleza del proyecto (dirigido a mercado, a medida), o según la naturaleza de la aplicación (riesgo, recursos, incertidumbre, sistemas empotrados).

TAREAS A REALIZAR

Educción
La educción de requisitos se refiere a la captura y descubrimiento de los requisitos. Es una actividad más “humana” que técnica. Se identifica a los interesados y se establecen las primeras relaciones entre ellos y el equipo de desarrollo.

Fuentes de Requisitos
• Metas: Factores críticos de éxito (de la empresa).
• Conocimiento del dominio de la aplicación: Cosas que pueden resultar obvias a los expertos no lo son para los usuarios.
• Los interesados: Los afectados por el sistema.
• El entorno físico que rodea al sistema.
• El entorno organizacional: Los procesos de negocio.

Problemas de la educción
• Los usuarios no pueden/saben describir muchas de sus tareas.
• Mucha información importante no llega a verbalizarse.
• A veces hay que “inventar” los requisitos.
• La educción no debería ser un proceso pasivo, sino cooperativo.

Análisis de Requisitos
Consiste en detectar y resolver conflictos entre requisitos. Se precisan los límites del sistema y la interacción con su entorno. Se trasladan los requisitos de usuario a requisitos del software.
En el análisis de requisitos se realizan tres tareas fundamentales:

• Clasificación:
En funcionales vs. No funcionales (Capacidades vs. Restricciones).
Por prioridades.
Por coste de implementación.
Por niveles (alto nivel, bajo nivel).
Según su volatilidad/estabilidad.
Si son requisitos sobre el proceso o sobre el producto.

• Modelización Conceptual:
Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados, de interacción, de objetos, etc.
La meta es entender mejor el problema, más que iniciar el diseño de la solución (idealmente).
El tipo de modelo elegido depende de la naturaleza del problema.

• Negociación:
En todo proceso de IR intervienen distintos individuos con distintos y, a veces, enfrentados intereses.
Estos conflictos entre requisitos se descubren durante el análisis. El conflicto no es rechazable, pues los conflictos son fuente de nuevos requisitos.
Los conflictos nunca se deben resolver “por decreto”, sino mediante un proceso de Re negociación.

EL DOCUMENTO DE REQUISITOS

Tipos de Documentos
El Documento de Requisitos es el modo habitual de guardar y comunicar requisitos. Es buena práctica
Utilizar, al menos, dos documentos, a distinto nivel de detalle.
Un documento es cualquier medio electrónico de almacenamiento y distribución (procesador de textos, base de datos, herramienta de gestión de requisitos).
• DRU: Documento de Requisitos de Usuario.
El DRU se escribe desde el punto de vista del usuario/cliente/interesado. Normalmente los requisitos de usuario, contenidos en la DRU, no poseen demasiado nivel de detalle. Se incluye la descripción del problema actual (razones por las que el sistema de trabajo actual es insatisfactorio) y las metas que se espera lograr con la construcción del nuevo sistema.
• ERS: Especificación de Requisitos Software.
La ERS desarrolla mucho más los contenidos de la DRU. Los requisitos del software contenidos en la ERS son, por tanto, más detallados. Contiene la respuesta a la pregunta “¿Qué características debe poseer un sistema que nos permita alcanzar los objetivos, y evitar los problemas, expuestos en la DRU?”.

VALIDACIÓN DE REQUISITOS
El objetivo de la validación de requisitos es descubrir problemas en el documento de requisitos antes de comprometer recursos a su implementación. Como resultado de esta validación se produce una línea-base.
El documento debe revisarse para descubrir omisiones, conflictos, ambigüedades, y comprobar la calidad del documento y su grado de adhesión a estándares.

Otros métodos de validación:
Prototipado: Permite descubrir con rapidez si el usuario se encuentra satisfecho, o no, con los requisitos (Uso de escenarios/casos de uso)
Validación de modelos: Cuando los requisitos se expresan por medio de modelos (de objetos, DFDs, etc.)
Validación de su “testabilidad”: El equipo de pruebas debe revisar los requisitos.

GESTIÓN DE REQUISITOS
Consiste, básicamente, en gestionar los cambios a los requisitos. Asegura la consistencia ente los requisitos y el sistema construido (o en construcción). Consume grandes cantidades de tiempo y esfuerzo. Abarca todo el ciclo de vida del producto.
La Gestión de Requisitos es necesaria porque los requisitos son volátiles, el entorno físico y el entorno organizacional cambian, y la propia existencia del sistema va a generar nuevos requisitos por parte de los usuarios.

Qué implica la Gestión de Requisitos
Definir procedimientos de cambios: definen los pasos y los análisis que se realizarán antes de aceptar los cambios propuestos.
Cambiar los atributos de los requisitos afectados.
Mantener la trazabilidad: hacia atrás, hacia delante y entre requisitos.
Control de versiones del documento de requisitos.

Herramientas de Gestión de Requisitos
Facilitan las tareas relacionadas con la escritura, trazabilidad y gestión de cambios.
Organizan los requisitos en bases de datos.
Gestión incremental de líneas-base.
Todas permiten añadir atributos a los requisitos.