Ingeniería y documentación
Ingeniería y trazabilidad de requisitos
Antes de aprobar un cambio, el equipo puede ver qué requisitos, pruebas y documentos afecta y qué verificaciones siguen pendientes.
Un requisito sin enlaces es solo una frase en una hoja de cálculo. Cuando el proyecto crece, la pregunta difícil deja de ser «qué dice el requisito» y pasa a ser «qué prueba lo verifica, qué componente lo implementa y qué se rompe si lo cambiamos». Una herramienta de trazabilidad puede responder a eso manteniendo relaciones en ambos sentidos entre requisitos, elementos de diseño, casos de prueba, resultados y peticiones de cambio. Podemos diseñarla como aplicación propia o como capa que conecte las herramientas que ya usa tu equipo de ingeniería. La herramienta ordena la información y ayuda a preparar evidencias; la aceptación del producto la deciden el cliente, la autoridad o el proceso de calificación que corresponda.
- Entrada de datos
- Requisitos de cliente y derivados
- Resultados de bancos de prueba
- Peticiones de cambio
- Validación
- Identificadores estables y únicos
- Relaciones permitidas por el modelo
- Procesamiento
- Recorrido de trazas de impacto
- Detección de huecos de cobertura
- Control humano
- Comité de control de cambios
- Aprobación de líneas base
- Trazas
- Líneas base congeladas
- Justificación de cada cambio
- Sistemas de salida
- Matriz de trazabilidad viva
- Paquete de evidencias exportable
Antes y después
Qué cambiaría en la operación
Ejemplo hipotético: un subsistema embarcado cuyos requisitos, casos de prueba y peticiones de cambio se mantienen en hojas de cálculo separadas.
01 · Antes
Cada equipo actualiza su propia hoja, los enlaces entre requisito y prueba se revisan a mano antes de cada revisión y algunos quedan rotos sin que nadie lo note.
02 · Sistema propuesto
Una herramienta importa las hojas con un informe de incidencias, asigna identificadores estables y enlaza cada requisito con su prueba y con los resultados del banco.
03 · Después
El responsable puede filtrar los requisitos sin verificación asignada, comparar dos líneas base y generar de forma reproducible el paquete de evidencias para la revisión.
Alcance
Qué resuelve y qué no
Qué puede resolver
- Mantener una matriz de trazabilidad viva que relacione cada requisito con su origen, su implementación y su verificación.
- Congelar líneas base (baselines) y comparar qué ha cambiado entre dos versiones del conjunto de requisitos.
- Analizar el impacto de una petición de cambio antes de aprobarla: requisitos derivados, pruebas afectadas y documentos que habría que revisar.
- Detectar huecos: requisitos sin verificación asignada, pruebas que no cubren ningún requisito o resultados pendientes.
- Reunir en un informe las evidencias de verificación que el equipo necesita presentar en una revisión de proyecto.
Qué no resuelve
- No otorga ninguna certificación ni calificación aeronáutica, espacial o de defensa: esos procesos los conduce el cliente con los organismos competentes.
- No redacta buenos requisitos por sí misma: puede señalar ambigüedades o duplicados, pero la calidad del requisito sigue dependiendo del equipo de ingeniería.
- No sustituye a las herramientas de modelado, simulación o ejecución de pruebas: recoge sus resultados y los enlaza.
- No implica que la herramienta esté calificada para un estándar concreto; si el proyecto lo exige, la calificación se plantea como trabajo específico con el cliente.
Escenarios operativos
Cómo funcionaría en la práctica
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Matriz de requisitos de un sistema
- Entrada
- Requisitos de cliente, requisitos derivados por subsistema y la estructura de producto acordada para el proyecto.
- Procesamiento
- Cada requisito recibe identificador estable, atributos (prioridad, método de verificación, responsable) y enlaces a su requisito padre y a los elementos de diseño que lo implementan.
- Salida
- Matriz consultable y filtrable por subsistema o estado, con indicadores de requisitos sin enlace o sin método de verificación.
02
Control de cambios sobre una línea base
- Entrada
- Petición de cambio que propone modificar o eliminar requisitos de una línea base ya aprobada.
- Procesamiento
- El sistema recorre las trazas para listar requisitos derivados, pruebas, documentos y elementos de diseño afectados, y somete la petición al comité definido.
- Salida
- Informe de impacto adjunto a la decisión, nueva línea base si se aprueba y registro de quién aprobó y con qué justificación.
03
Seguimiento de verificaciones
- Entrada
- Resultados de pruebas, inspecciones, análisis o demostraciones procedentes de las herramientas del equipo o de registros manuales.
- Procesamiento
- Asociación de cada resultado al caso de verificación y al requisito correspondiente, con la versión del producto o del software sobre la que se obtuvo.
- Salida
- Estado de verificación por requisito (pendiente, superado, fallido, no aplicable) y lista de evidencias que lo respaldan.
04
Preparación de una revisión de proyecto
- Entrada
- Línea base vigente, estado de verificaciones y peticiones de cambio abiertas en la fecha de corte.
- Procesamiento
- Generación de un paquete con la matriz, los huecos detectados y las evidencias enlazadas, en el formato que el equipo acuerde con su cliente.
- Salida
- Documento exportable y reproducible: si se genera de nuevo con la misma línea base, ofrece el mismo resultado.
Integración
Cómo se conecta con lo que ya existe
La trazabilidad atraviesa herramientas distintas: gestión de requisitos, repositorios de código, seguimiento de incidencias, bancos de prueba y gestión documental. Se estudia qué herramienta es la fuente de verdad de cada artefacto y se enlazan por identificadores estables, evitando copiar datos que luego divergen. Si ya existe una herramienta comercial de requisitos, se valora integrarla en lugar de sustituirla.
- Importación y exportación en formatos de intercambio de requisitos como ReqIF cuando la herramienta de origen lo admita
- Repositorios de código y gestores de incidencias para enlazar implementación y defectos
- Herramientas o bancos de prueba que publiquen resultados de forma automatizable
- Gestión documental para especificaciones, planes e informes de verificación
- Autenticación corporativa y permisos por proyecto, subsistema o empresa participante
Modalidades de despliegue que suelen plantearse
Se elige en cada proyecto tras evaluar requisitos y sistemas existentes.
Antes de desarrollar
Datos, validaciones y permisos
- Modelo de información acordado: qué tipos de artefacto existen, qué atributos tiene cada uno y qué relaciones son válidas entre ellos.
- Reglas de identificación estables, para que un requisito conserve su identidad aunque cambie su texto.
- Proceso de control de cambios definido por la organización: quién propone, quién evalúa y quién aprueba.
- Requisitos de confidencialidad y clasificación de la información, especialmente si participan varias empresas.
- Criterios sobre conservación del historial y de las líneas base durante la vida del producto.
Supervisión
Riesgos, límites y mantenimiento
- Una matriz que se rellena al final del proyecto solo para la revisión aporta poco: las trazas deben mantenerse durante el trabajo diario.
- Un modelo de datos demasiado detallado desanima al equipo; es preferible empezar con pocos tipos de relación y ampliar con el uso.
- Las integraciones con herramientas de terceros dependen de sus API y versiones; hay que prever mantenimiento cuando cambien.
- En proyectos con información sensible, el alojamiento, el control de acceso y la exportación de datos deben definirse con el responsable de seguridad del cliente.
Sectores, servicios y lecturas relacionadas
Sectores donde se aplicaría
Cómo se contrata
Preguntas frecuentes
¿Merece la pena una herramienta a medida si ya existen productos comerciales de requisitos?
No siempre. Si un producto comercial encaja con vuestro proceso, solemos recomendar integrarlo con el resto de herramientas. El desarrollo propio tiene sentido cuando el modelo de información es muy particular, cuando hay que unir datos dispersos o cuando el coste de licencias y adaptación no compensa.
¿Podéis importar nuestra matriz actual en hojas de cálculo?
Sí, pero antes revisamos su calidad: identificadores duplicados, enlaces rotos o columnas usadas con significados distintos. La importación incluye un informe de incidencias para que vuestro equipo decida cómo resolverlas.
¿La herramienta sirve como evidencia ante una autoridad o un cliente?
Puede ayudar a organizar y presentar evidencias, pero su aceptación depende del proceso de cada proyecto. Si el uso de la herramienta debe calificarse o justificarse formalmente, se planifica como un trabajo específico junto con vuestro equipo de calidad.
Cuéntanos cómo gestionáis hoy requisitos y verificaciones
Cuéntanos qué datos y sistemas intervienen en tu proceso. Estudiaremos qué puede automatizarse, cómo se integraría y qué convendría validar antes de desarrollar. Ver todas las capacidades.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.