cosmoSys » cosmoSys-Req

# 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.

## 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.

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.

## 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.

## Verificació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 y su método de verificación permite comprobar posteriormente si el sistema cumple lo especificado.

## 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.

## 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;

* 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.

## Gestores de requisitos y otras herramientas

Un gestor de requisitos no tiene por qué sustituir todas las demás herramientas utilizadas en un proyecto.

Puede formar parte de un entorno más amplio en el que existan herramientas para:

* diseño;

* simulación;

* desarrollo de software;

* control de versiones;

* gestión de tareas;

* documentación;

* pruebas;

* configuración.

Lo importante es que la información pueda relacionarse de forma coherente con el resto del proceso de ingeniería.

### 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]].