cosmoSys » cosmoSys-Req

{{>toc}}

# Gestor de requisitos

Un **gestor de requisitos** es una herramienta para organizar y mantener la información que define **qué debe hacer un sistema, bajo qué condiciones debe hacerlo y cómo se comprobará que cumple lo establecido**.

En proyectos pequeños, los requisitos pueden mantenerse en documentos o incluso en hojas de cálculo. Cuando el sistema crece, también crece la cantidad de información relacionada con cada requisito: su origen, sus relaciones con otros requisitos, las decisiones que lo justifican, los documentos aplicables, quién debe desarrollarlo y cómo se verificará.

Un gestor de requisitos permite mantener esa información estructurada y trazable durante la vida del proyecto.

No convierte por sí solo una frase en un buen requisito ni sustituye la revisión técnica. Su valor está en hacer explícitos la identidad, el contexto, las relaciones, las decisiones y los cambios que de otro modo quedarían repartidos entre documentos, correos y conocimiento personal.

{{thumbnail(requirements-management-overview.png, size=600, title=De la necesidad a la especificación)}}

## Un requisito es algo más que una frase

Un requisito suele comenzar como una necesidad expresada en lenguaje natural:

> El instrumento debe funcionar dentro de determinadas condiciones ambientales.

Para convertir esa necesidad en una especificación de ingeniería, normalmente es necesario identificarla, darle una identidad y añadir información que permita trabajar con ella.

Por ejemplo, un requisito puede tener:

- una **identidad** única;

- un texto que describa lo que debe cumplirse;

- una clasificación;

- una fuente o procedencia;

- relaciones con otros requisitos;

- información sobre quién debe implementarlo;

- un método de verificación;

- un estado dentro del proceso de revisión;

- información sobre su cumplimiento.

También conviene distinguir la **posición** de un requisito dentro de la especificación de sus relaciones de ingeniería. Estar debajo de un capítulo explica dónde se presenta; derivarse de otro requisito o bloquear un diseño explica por qué existe o qué depende de él. Confundir ambas dimensiones produce árboles difíciles de mantener y una trazabilidad poco fiable.

La forma concreta de organizar estos datos depende de la metodología y de las necesidades de cada proyecto.

## De las necesidades a los requisitos

Los requisitos suelen aparecer como consecuencia de necesidades, objetivos, restricciones, normas, decisiones de diseño o requisitos procedentes de otros niveles del sistema.

En un sistema complejo, un requisito puede dar lugar a otros requisitos más concretos.

Por ejemplo:

**necesidad → requisito de sistema → requisitos de subsistema → requisitos de implementación**

Este proceso se conoce habitualmente como **derivación de requisitos**.

Mantener esta relación permite saber de dónde procede un requisito y qué otros requisitos se han establecido para satisfacerlo.

También permite recorrer el camino en sentido contrario: partir de un requisito y comprobar qué elementos dependen de él.

{{thumbnail(requirements-derivation.png, size=600, title=Derivación de requisitos hacia disciplinas)}}

## Trazabilidad

La **trazabilidad** consiste en mantener relaciones que permitan seguir el origen, evolución y destino de la información de ingeniería.

En gestión de requisitos, puede ser necesario relacionar:

**necesidad → requisito → diseño → implementación → verificación**

No todos los proyectos necesitan exactamente las mismas relaciones, pero el principio es el mismo: poder responder a preguntas sobre cómo se conecta una decisión con el resto del sistema.

Por ejemplo:

- ¿De dónde procede este requisito?

- ¿Qué requisitos se derivaron de él?

- ¿Qué parte del sistema lo implementa?

- ¿Cómo se verifica?

- ¿Qué requisitos pueden verse afectados si cambia?

- ¿Qué requisitos quedan sin verificar?

La trazabilidad convierte estas preguntas en relaciones que pueden recorrerse en lugar de depender únicamente del conocimiento personal de los miembros del equipo.

{{thumbnail(requirements-traceability.png, size=600, title=Cadena de trazabilidad)}}

## Verificación y validación de requisitos

Un requisito debería poder comprobarse.

Por eso, además de describir **qué debe cumplirse**, la especificación puede indicar **cómo se verificará**.

Dependiendo del sistema y de la naturaleza del requisito, la verificación puede realizarse mediante métodos como:

- inspección;

- análisis;

- demostración;

- ensayo o prueba.

La relación entre el requisito, su método y la evidencia obtenida permite comprobar posteriormente si el sistema cumple lo especificado.

La terminología varía entre organizaciones, pero suele ser útil distinguir:

- **verificación**: comprobar que la solución satisface los requisitos especificados;

- **validación**: comprobar que el resultado satisface la necesidad o el uso previsto.

Un gestor puede registrar métodos, descripciones, resultados y enlaces a evidencias, pero no ejecuta automáticamente toda esa ingeniería ni convierte la existencia de un campo rellenado en prueba de cumplimiento.

## Revisión y evolución

Los requisitos no permanecen necesariamente iguales durante todo el proyecto.

Pueden aparecer nuevas necesidades, cambiar las restricciones, detectarse errores o tomarse decisiones que obliguen a modificar requisitos existentes.

Por eso la gestión de requisitos no consiste simplemente en escribir una especificación una vez.

Consiste en **mantener la información y sus relaciones mientras el proyecto evoluciona**.

Cuando un requisito cambia, interesa poder identificar qué otras partes del proyecto pueden verse afectadas y qué información debe revisarse como consecuencia del cambio.

Aquí aparecen dos necesidades distintas. El **control de madurez** ayuda a evitar que un elemento derivado figure como aprobado cuando su fuente todavía está en elaboración. La **gestión de cambios sobre una línea base** permite saber si el contenido que hoy se presenta sigue siendo el mismo que se revisó, incluso cuando el cambio procede de un parámetro compartido o de un requisito antecedente.

Una herramienta útil debe hacer visible esa deriva sin fingir que puede resolverla por el equipo: aceptar el cambio continúa siendo una decisión explícita de ingeniería.

## La especificación como documento

La especificación de requisitos suele necesitar finalmente una representación documental.

El documento puede servir para:

- revisar la especificación;

- comunicarla a otras personas u organizaciones;

- establecer una referencia para una determinada fase del proyecto;

- formar parte de una entrega contractual;

- conservar una determinada versión de la información.

Sin embargo, el documento no tiene por qué ser la única representación de los requisitos.

En un proceso de gestión de requisitos, la información estructurada puede mantenerse en una herramienta y utilizarse para generar diferentes representaciones documentales cuando sean necesarias.

## Cuando el proyecto crece

En un sistema sencillo, una lista de requisitos puede ser suficiente.

En un sistema complejo aparecen muchas más dimensiones:

- diferentes niveles de requisitos;

- múltiples subsistemas;

- numerosas fuentes;

- documentos normativos;

- relaciones entre requisitos;

- responsables diferentes;

- métodos de verificación;

- revisiones y cambios;

- grandes cantidades de información.

La dificultad deja entonces de estar únicamente en **escribir los requisitos**.

Está en **mantener comprensible y trazable la red de información que se construye alrededor de ellos**.

Es aquí donde un gestor de requisitos resulta especialmente útil.

## Qué aporta un gestor de requisitos

Un gestor de requisitos proporciona un espacio estructurado para mantener esta información durante el proyecto.

Entre sus capacidades habituales están:

- crear e identificar requisitos;

- clasificarlos y organizarlos;

- establecer relaciones entre ellos;

- derivar requisitos;

- registrar fuentes y referencias;

- definir métodos de verificación;

- realizar revisiones;

- distinguir madurez, cierre satisfactorio y retirada;

- detectar cambios que afecten a contenido previamente aprobado;

- mantener estados y otra información de proceso;

- consultar la trazabilidad;

- generar especificaciones y otros documentos.

Las herramientas pueden diferenciarse mucho en la forma en que proporcionan estas capacidades, en el nivel de integración con el resto de la ingeniería y en la calidad de las representaciones que generan.

### Y aquí entra cosmoSys-Req

[[cosmoSys-Req]] es un gestor de requisitos que proporciona estas capacidades dentro de un entorno de ingeniería más amplio.

Además de la gestión de requisitos, **cosmoSys añade capacidades para representar visualmente las relaciones del proyecto, generar diagramas directamente desde el modelo, producir documentación de calidad y mantener contexto sobre las referencias documentales**.

También es una herramienta **libre, abierta y gratuita**, diseñada para que la información permanezca bajo el control de la organización.

Para conocer qué aporta concretamente cosmoSys-Req frente a las capacidades generales descritas aquí, continúa en [[cosmoSys-Req]].

{{thumbnail(cosmosys-req-context.png, size=600, title=cosmoSys-Req dentro del modelo general del proyecto)}}