Seguimiento de revisiones: detectar cambios y transferir trabajo

Introducción

Pocas situaciones causan tanta inquietud a los responsables de ofertas como el mensaje: „Hay una nueva revisión del pliego de requisitos.“ Quien ya ha invertido semanas en clasificar, asignar expertos y responder a cientos de requisitos se enfrenta a una pregunta crítica: ¿qué ha cambiado y cuánto del trabajo realizado hasta ahora puede reutilizarse?

Según el UNIFE World Rail Market Study 2024 de 63,3 mil millones de euros, con un crecimiento anual del 7,3 % en Europa Occidental. Cada uno de estos proyectos de contratación comienza con un pliego de requisitos, y casi todos los pliegos se revisan al menos una vez durante la fase de oferta. En grandes licitaciones de transporte ferroviario regional de pasajeros, no es raro que haya entre tres y cinco revisiones entre la publicación inicial y la adjudicación del contrato, provocadas por consultas de licitadores, cambios regulatorios, decisiones políticas o modificaciones de la línea.

Barry Boehm zeigte bereits 1981 in Software Engineering Economics, que el coste de un cambio de requisito crece exponencialmente cuanto más tarde se detecta: de un factor 1 en la fase de requisitos a un factor de 10 a 100 en producción. En la industria ferroviaria esto es aún más acusado. Quien pasa por alto un requisito modificado durante la fase de oferta se arriesga a retrabajo y a una brecha de conformidad que, en el peor de los casos, pone en peligro la homologación.

A continuación se explica cómo funciona en la práctica el seguimiento de revisiones, por qué es obligatorio desde el punto de vista regulatorio, dónde se atasca y qué herramientas ayudan.

Por qué se revisan los pliegos de requisitos

En la industria ferroviaria, las revisiones de los pliegos de requisitos son la regla, no la excepción. Las razones son:

• Consultas de los licitadores: Durante la fase de oferta, los proveedores plantean preguntas de aclaración o señalan contradicciones. El contratante responde de forma consolidada y publica un pliego revisado. El Corrigendum (corrección) subsana errores del documento original, mientras que una adenda añade contenidos o condiciones que no figuraban originalmente. Ambos generan una nueva revisión.
• Cambios regulatorios: Entre la elaboración del pliego y la presentación de la oferta se aprueban TSI-Revisionen o nuevas normas EN. El contratante actualiza las referencias normativas. Solo la ERA define 11 ETI diferentes para vehículos ferroviarios, y un cambio en una de ellas puede afectar a decenas de requisitos del pliego.
• Cambios políticos o financieros: Recortes presupuestarios, modificaciones de la línea, nuevos requisitos de accesibilidad (ETI PRM) o cambios en los conceptos operativos provocan cambios de contenido en el catálogo de requisitos. El estudio del Parlamento Europeo (2023) sobre la competitividad de la industria ferroviaria documentó que, en Alemania, normalmente transcurren entre 7 y 8 años desde la convocatoria de competencia hasta la producción en serie. Un periodo en el que las prioridades políticas pueden cambiar varias veces.
• Fragmentación nacional: Las distintas normas nacionales generan margen de interpretación. Como documenta el CONTACT Software Blog , distintos contratantes derivan requisitos diferentes de las mismas normas. Cuando un contratante advierte estas incoherencias, sigue una revisión.
• Correcciones editoriales: Erratas, identificadores de requisitos faltantes o referencias cruzadas incoherentes; incluso las correcciones menores generan un nuevo número de revisión.

El coste de un mal seguimiento de revisiones

¿Qué ocurre si el seguimiento de revisiones no funciona? Los costes aparecen en tres ámbitos:

• Retrabajo directo: Quien pasa por alto cambios y trabaja sobre la base de un requisito desactualizado produce resultados que deben rehacerse por completo una vez detectado el error. En un pliego con más de 1.000 requisitos y entre 15 y 30 equipos de subsistemas implicados, un solo cambio sustancial omitido puede causar semanas de retrabajo.
• Riesgo de conformidad: EN 50126 exige la trazabilidad completa de cada cambio de requisito a lo largo de todo el ciclo de vida RAMS. Si falta la documentación del cambio, se pone en peligro la oferta actual y la posterior homologación del vehículo por el Organismo Notificado (NoBo).
• Riesgo contractual: Los compromisos de conformidad de la especificación técnica que se basan en una revisión anterior del pliego pueden llevar a una puntuación inferior en la evaluación o, en el peor caso, a la exclusión. Las UNIFE-Prioritäten 2024–2029 hacen hincapié en el principio MEAT (ofertas económicamente más ventajosas), con costes de ciclo de vida, y las incoherencias en la matriz de conformidad se penalizan.

Fuente: CONTACT Software, tren lento hacia la gestión de requisitos

Un análisis del sector ferroviario australiano cifra el potencial de ahorro derivado de aclaraciones tempranas y una gestión estructurada de requisitos en hasta el 30 % de los costes del proyecto. A la inversa, quien sigue mal las revisiones y detecta cambios tarde se arriesga a importantes sobrecostes por retrabajo evitable.

Qué implica una revisión para el trabajo en curso

Cuando un responsable de ofertas recibe la revisión de un pliego, debe tomar varias decisiones en un orden definido. El INCOSE Systems Engineering Body of Knowledge (SEBoK) define el proceso de esta manera: una vez que los requisitos están „defined, assessed, and approved“, se congelan como línea base. Cada cambio debe incluir el „rationale why the change is necessary“ y evaluarse a lo largo de toda la jerarquía de arquitectura, „including suppliers“.

Traducido al día a día de un responsable de ofertas:

La comparación manual: por qué no escala

El enfoque más obvio para detectar el delta es la comparación manual: abrir las dos versiones del documento una junto a otra y revisar línea por línea. Con un pliego de 20 requisitos puede funcionar. En un pliego típico de transporte ferroviario regional de pasajeros, este enfoque no es práctico.

El blog de CONTACT Software documentó ya en 2014que la documentación de especificaciones de una sola licitación „había crecido de un CD a un DVD“. Desde entonces el volumen ha seguido aumentando. Comparar manualmente dos versiones de un documento de este tamaño consume tiempo y es propenso a errores. Quien contrasta dos tablas de Excel línea por línea durante horas pasa cosas por alto. No es una debilidad: es humano.

Incluso si un contratante proporciona un registro de revisión (lo que no siempre ocurre), persiste el riesgo de que esté incompleto. Los responsables de ofertas experimentados lo saben: confía en el delta, no en la carta de acompañamiento.

La comparación basada en ID: el fundamento

El método más fiable de detección del delta se basa en identificadores únicos de requisitos. Cada requisito del pliego tiene una ID estable (p. ej.,REQ-LH3-0147) que se conserva entre revisiones. El algoritmo de comparación es entonces sencillo:

• ID presente en Rev. B, no en Rev. A → Requisito nuevo
• ID presente en Rev. A, no en Rev. B → Requisito eliminado
• ID presente en ambas, texto idéntico → Sin cambios (trabajo transferible)
• ID presente en ambas, texto distinto → Modificado (requiere revisión)

Este enfoque presupone que el contratante utiliza ID estables, algo que la VDB-Leitfaden Anforderungsmanagement recomienda expresamente. La guía estandariza el proceso de creación, intercambio y comentario de especificaciones entre contratantes, fabricantes de vehículos y proveedores. Prevé el intercambio electrónico en formato ReqIF-Format y establece explícitamente que, al utilizar el formato de archivo ReqIF, „las entradas nuevas y los cambios pueden reconocerse de inmediato mediante marcado automatizado, evitando pérdidas de tiempo derivadas de comparaciones laboriosas con estados de trabajo anteriores.“

La guía VDB también recomienda comprobar de antemano la compatibilidad de las implementaciones ReqIF, señal de que los problemas de interoperabilidad son reales. El ProSTEP iViP ReqIF Implementor Forum realizó seis benchmarks en total hasta 2024; el más reciente abarcó 56 combinaciones de sistemas y 2.800 criterios de evaluación. Pese a estos avances, las extensiones específicas de proveedores y las incompatibilidades de versiones siguen siendo un reto.

EuroSpec y EN 15380: atributos para el seguimiento de cambios

La EuroSpec-Initiative (European Specification for Railway Vehicles) ha definido en su especificación de gestión de requisitos (versión 3.0) un modelo de atributos para requisitos. La especificación cubre seis áreas: características de requisitos, sintaxis, atributos, trazabilidad, validación/verificación e intercambio de datos. Para el seguimiento de revisiones son especialmente relevantes estos atributos:

• ID: identificador único y estable del requisito
• Estado: estado actual de tratamiento en el ciclo de vida
• Historial de cambios: historial documentado con marca de tiempo y descripción
• Fuente: origen del requisito (contratante, norma, documento interno)
• Trazabilidad: vínculo con requisitos, evidencias y riesgos relacionados
• Comentarios: comentarios de texto libre sobre la justificación del cambio

EuroSpec estructura los requisitos conforme a EN 15380-5, la norma europea para la System Breakdown Structure (SBS) de vehículos ferroviarios. La serie EN 15380 incluye varias partes: parte 2 (grupos de productos), parte 4 (grupos funcionales) y parte 5 (estructura de sistemas). Esta estructura hace posible seguir cambios no solo a nivel de requisito individual, sino también de subsistema: „En LH3 (tracción) hubo 12 cambios; en LH6 (equipamiento interior), ninguno.“

En la práctica, esto significa que si una revisión contiene 47 requisitos modificados, pero 40 de ellos corresponden a LH5 (sistemas de freno) y solo 7 a otros subsistemas, se puede avisar a los expertos de manera específica. Sin una agregación basada en subsistemas, cada experto debe revisar toda la lista de deltas. Con entre 15 y 30 equipos implicados, esto consume tiempo.

Marco regulatorio: EN 50126, ISO 22163 e INCOSE

El seguimiento de revisiones también es un requisito regulatorio. Varias normas lo exigen simultáneamente, con requisitos parcialmente solapados.

CENELEC EN 50126: ciclo de vida RAMS y gestión de configuración

La CENELEC EN 50126 define el ciclo de vida RAMS (fiabilidad, disponibilidad, mantenibilidad y seguridad) para todas las aplicaciones ferroviarias. La norma exige una gestión de configuración documentada en cada fase del ciclo de vida: todo cambio de un requisito debe documentarse, aprobarse y ser trazable, desde la definición del concepto hasta la retirada de servicio.

Esto empieza ya en la fase de oferta, no solo durante el desarrollo. Los compromisos de conformidad asumidos allí constituyen la primera línea base del proyecto posterior. Si esta línea base se fundamenta en una revisión desfasada del pliego, surgen incoherencias que salen a la luz en la revisión del Organismo Notificado (NoBo) . Como resume resume LDRA, la familia de normas EN 5012x exige trazabilidad entre todos los artefactos de desarrollo. Una cadena que empieza en la línea base de requisitos.

ISO 22163:2023 (IRIS Rev. 04): configuración y control de cambios unidos

La ISO 22163:2023 se publicó en julio de 2023 como norma internacional plena (antes existía como especificación técnica ISO/TS 22163:2017). La principal novedad estructural: los anteriores subapartados 8.1.4 „gestión de configuración“ y 8.1.5 „gestión de cambios“ se reunieron en un único subapartado 8.1.4, „gestión de configuración y control de cambios“.

Esta fusión es más que cosmética. La norma trata ahora el seguimiento de cambios como parte de la configuración, no como un proceso separado. La IRQB Guideline 8 (Configuration & Change Management) proporciona orientación detallada para su implantación. En concreto, la norma exige:

• Procedimientos documentados para identificar y controlar cambios
• Evaluar el impacto de cada cambio antes de implantarlo (Change Impact Analysis)
• Trazabilidad: ¿quién cambió qué, cuándo y por qué?
• Gestión de líneas base: estados de configuración definidos y congelados como referencia

La certificación IRIS conforme a las nuevas reglas IRIS Rev. 04 es obligatoria para todas las auditorías desde el 1 de enero de 2024. El propietario de las reglas de certificación es UNIFE (Union des Industries Ferroviaires Européennes).

Fuente: DQS Global, IRIS Revision 04

INCOSE y SEBoK: buenas prácticas de ingeniería de sistemas

Más allá de las normas específicas del ferrocarril está el INCOSE Systems Engineering Body of Knowledge (SEBoK), que formula principios generales para la gestión de requisitos. Cuatro se aplican directamente al seguimiento de revisiones:

• Líneas base: Los requisitos aprobados se congelan como línea base. Los cambios exigen una justificación formal y un análisis de impacto.
• Trazabilidad bidireccional: Cada requisito debe poder trazarse a escenarios operativos, riesgos, requisitos relacionados y artefactos de verificación.
• Control de cambios:INCOSE recomienda establecer el proceso de control de cambios „early in the effort“, no cuando llegue la primera revisión.
• Integración de proveedores:Los cambios deben evaluarse a través de „multiple levels in the architecture hierarchy (including suppliers)“. Un aspecto especialmente relevante para OEM con más de 10.000 proveedores.

Herramientas para el seguimiento de revisiones

Las herramientas van desde enfoques manuales hasta sistemas ALM integrados. La elección determina cuánto trabajo se transfiere automáticamente en una revisión y cuánto debe completarse manualmente.

Word/PDF: comparación con marcas de revisión

Microsoft Word ofrece una función integrada de comparación de documentos („Comparar documentos“) que marca los cambios como redline. Para documentos de texto libre es una primera pista, pero en listas estructuradas de requisitos el enfoque alcanza sus límites: Word compara texto, no requisitos. Un requisito desplazado aparece como eliminación más nueva creación, no como desplazamiento. No permite transferir automáticamente a la nueva versión la clasificación o el comentario del experto existentes.

Excel: fórmulas y BUSCARV

En flujos de trabajo basados en Excel, la comparación basada en ID puede hacerse con fórmulas BUSCARV (VLOOKUP): se contrastan las ID de la revisión anterior con la nueva y se detectan diferencias de texto con fórmulas EXACT. El enfoque funciona, pero es frágil (desplazamiento de columnas, cambios de formato) y no genera un historial de cambios duradero. En la siguiente revisión hay que volver a configurar la lógica de fórmulas. El CONTACT Software Blog ya observó en 2014 que muchos proveedores pequeños de la industria ferroviaria todavía intercambian requisitos mediante Excel. Desde entonces, esto ha cambiado solo lentamente.

IBM DOORS: líneas base e impacto de cambios

IBM DOORS (Dynamic Object Oriented Requirements System) es el estándar de facto en sectores regulados desde los años noventa. El sistema ofrece soporte nativo para Baselines , es decir, instantáneas congeladas de un estado de requisitos que sirven de referencia para comparaciones posteriores. La función de comparación de líneas base muestra para cada requisito la diferencia exacta entre dos estados, incluidos los cambios de atributos.

En DOORS Classic, las líneas base se crean a nivel de módulo, un modelo que ha demostrado su eficacia durante más de dos décadas . IBM DOORS Next (DNG) sigue otro enfoque: las líneas base se crean a nivel de componente o proyecto, lo que ofrece ventajas en grandes proyectos con varios subsistemas. Un ejemplo concreto de la práctica: Rail Projects Victoria (Melbourne) eligió DOORS Next como solución SaaS para el Metro Tunnel Project, para gestionar centralmente los requisitos entre varios participantes del proyecto.

Siemens Polarion: LiveDoc y comparación de revisiones

Siemens Polarion adopta con la LiveDoc-Funktionalität un enfoque centrado en el documento: los documentos de requisitos se gestionan como documentos vivos en los que cada párrafo es identificable y trazable de forma única. Cada cambio genera automáticamente un Version History Record, y las líneas base de documentos pueden crearse en puntos definidos (por ejemplo, tras una aprobación). Para cada línea base, Polarion genera automáticamente un enlace a LiveDocs Compare View, que muestra la diferencia con la línea base anterior.

Desde 2025, Polarion también admite KI-gestützte Anforderungsextraktion, que también puede aplicarse a documentos de revisión no estructurados (PDF, Word).

PTC Codebeamer: streams y fusión de deltas

PTC Codebeamer ofrece con Streams, líneas base y Delta Merge un enfoque adaptado a Product Line Engineering (PLE): las líneas base de stream capturan instantáneas de todos los proyectos de un stream, y Delta Merge permite integrar cambios de forma controlada entre plataformas y variantes. Es especialmente relevante para licitaciones multiproducto en las que el mismo pliego debe responderse para distintas variantes de vehículo.

ReqIF: comparación estructurada de revisiones

El formato ReqIF (Requirements Interchange Format) es adecuado para el seguimiento de revisiones porque transporta requisitos como objetos de datos estructurados con ID estables y atributos tipados. Dos archivos ReqIF (Rev. A y Rev. B) pueden compararse automáticamente: requisito por requisito, atributo por atributo.

La norma fue desarrollada en 2004 por la iniciativa de fabricantes de software (HIS) de la industria automovilística alemana (Daimler, VW, Porsche, Audi, BMW Group) y desde 2011 la mantiene la OMG (actualmente versión 1.2 de 2016, desarrollada por 14 empresas). El ReqIF Implementor Forum (operado por ProSTEP iViP) trabaja desde 2018 en benchmarks periódicos de interoperabilidad. El sechste Benchmark (2024) abarcó 56 combinaciones de sistemas y 2.800 criterios de evaluación.

Una limitación importante: ReqIF no contempla un concepto para intercambiar un historial de cambios ni comentarios de cambios. Por ello, la comparación debe realizarse a nivel de herramienta: se comparan dos archivos ReqIF, pero el historial no viaja en el propio formato. Para flujos de trabajo que requieren un historial de cambios acumulado entre varias revisiones, esto es una laguna que debe cubrir la herramienta receptora.

Otras herramientas

Visure Requirements proporciona plantillas para conformidad con EN 50126 y vincula requisitos, pruebas, riesgos y artefactos de extremo a extremo. Para el análisis de riesgo de cambios de requisitos integra PHA y FMEA. Jama Connect se basa en „Live Traceability“: cuando cambia un requisito upstream, todos los elementos downstream se marcan automáticamente como „suspect“. Esto acelera notablemente el Change Impact Analysis.

Transferir trabajo: la cuestión central de las revisiones

La detección del delta es solo el primer paso. La verdadera pregunta es: ¿cuánto del trabajo anterior puede transferirse?

Transferibilidad típica del trabajo anterior por tipo de cambio (valoración cualitativa; varía según la revisión).

En la práctica, entre el 60 y el 80 % de los requisitos permanecen sin cambios entre dos revisiones, por lo que el trabajo anterior puede transferirse directamente en la mayoría de los casos. El Bidara Research cifra la tasa de reutilización de contenido en licitaciones, en todos los sectores, en un 66 %. En la industria ferroviaria este valor debería ser aún mayor entre revisiones, ya que los cambios sustanciales normalmente afectan solo a una parte de los requisitos.

La cuestión es si la herramienta admite esta transferencia o si el responsable de ofertas debe copiar manualmente las clasificaciones y comentarios a la nueva versión. En sistemas ALM como DOORS o Polarion, así como en plataformas especializadas como Tendric la migración del trabajo puede automatizarse en gran medida. En flujos de Excel significa copiar y pegar cientos de filas, con el riesgo de que las asignaciones se desplacen.

El enfoque diff: lo que enseña el desarrollo de software

En el desarrollo de software, el seguimiento de versiones es un problema resuelto. Herramientas como Git gestionan millones de cambios de texto en miles de archivos, detectan conflictos automáticamente y permiten el trabajo paralelo de cientos de desarrolladores. Los conceptos fundamentales (commits, diffs, branches y merges) pueden transferirse directamente a la gestión de requisitos:

La diferencia esencial es que, en el desarrollo de software, el control de versiones es estándar desde los años noventa. En la gestión de requisitos de la industria ferroviaria, muchas empresas aún están en la fase previa a CVS y Subversion: con copias de archivos numeradas manualmente y la esperanza de que nadie sobrescriba por error la versión equivocada. El blog de CONTACT Software dokumentierteque incluso Deutsche Bahn no introdujo un sistema de gestión de requisitos basado en bases de datos hasta alrededor de 2012/2013.

IA y detección del delta

Según el Loopio 2025 RFP Response Trends Report el 68 % de los equipos de propuestas ya utiliza IA generativa en todos los sectores, el doble que el 34 % de 2023. En la industria ferroviaria esta transformación está aún en gran medida por llegar. Para el seguimiento de revisiones hay tres puntos de partida:

• Documentos no estructurados: Si el contratante entrega la revisión como PDF o documento Word (sin ID estables ni ReqIF), la IA puede analizar el texto libre e intentar vincular semánticamente requisitos entre versiones, incluso si han cambiado las formulaciones o se han desplazado los requisitos. Siemens Polarion ofrece desde 2025 precisamente esta funcionalidad. También PTC anunció en 2026 nuevas funciones de IA para Codebeamer.
• Evaluación de cambios (triaje): La IA puede proponer si un cambio de texto es sustancial (requisito técnico modificado, nueva referencia normativa) o editorial (reformulación sin efecto de contenido). En vez de que un experto deba revisar individualmente 83 requisitos modificados, la IA puede priorizar los 15 cambios sustanciales.
• Análisis en cascada:La IA puede analizar referencias cruzadas entre requisitos e identificar automáticamente qué requisitos sin cambios podrían estar afectados indirectamente por un requisito modificado. Es similar al mecanismo „suspect“ de Jama Connect, pero en el plano semántico en lugar del de vínculos explícitos.

Flujo de trabajo práctico: revisión en 5 pasos

Un tratamiento estructurado de las revisiones puede resumirse en cinco pasos. Este flujo de trabajo se basa en los principios del INCOSE SEBoK y es compatible con los requisitos de EN 50126 e ISO 22163:2023:

Conclusión

El seguimiento de revisiones muestra qué tan bien funciona realmente el proceso de gestión de requisitos de una empresa. Quien gestiona requisitos con ID estables, formatos estructurados y líneas base limpias procesa una nueva revisión en horas. Quien depende de comparaciones manuales de documentos pierde días y se arriesga a pasar por alto cambios sustanciales.

Desde el punto de vista regulatorio no hay margen: EN 50126 exige trazabilidad completa, ISO 22163:2023 reúne gestión de configuración y control de cambios en el apartado 8.1.4, e IRIS Rev. 04 es obligatorio desde 2024.

La herramienta y el proceso para manejar revisiones deben estar preparados antes de clasificar el primer requisito. La guía VDB y EuroSpec aportan las normas, ReqIF el formato de intercambio, y DOORS, Polarion, Codebeamer y plataformas especializadas como Tendric proporcionan la infraestructura técnica. La IA ayuda donde faltan datos estructurados, pero no reemplaza la base: ID estables, líneas base limpias e historial de cambios documentado.