Requirements Revision Tracking: Detect Changes and Transfer Work

Introduction

Few situations make proposal managers as uneasy as the message: “There is a new revision of the specification.” Anyone who has already invested weeks in classifying, assigning experts to, and answering hundreds of requirements faces a critical question: what changed, and how much of the work completed so far can be carried forward?

According to the UNIFE World Rail Market Study 2024 the European rolling-stock market is worth EUR 63.3 billion, with annual growth of 7.3% in Western Europe. Every one of these procurement projects starts with a specification, and nearly every specification is revised at least once during the bidding phase. Major regional-rail tenders commonly see three to five revisions between initial publication and contract award, triggered by bidder questions, regulatory changes, political decisions, or route adjustments.

In 1981, Barry Boehm showed in Software Engineering Economics that the cost of a requirement change rises exponentially the later it is discovered: from a factor of 1 during the requirements phase to a factor of 10 to 100 in production. The effect is even sharper in rail. Missing a changed requirement during the bidding phase risks rework and a compliance gap that, in the worst case, jeopardises approval.

Below, we explain how revision tracking works in practice, why it is a regulatory obligation, where it breaks down, and which tools help.

Why specifications are revised

In the rail industry, specification revisions are the rule rather than the exception. The reasons include:

• Bidder questions: During the bid phase, suppliers ask for clarification or point out contradictions. The contracting authority answers these questions collectively and publishes an updated specification. A corrigendum corrects errors in the original document, while an addendum adds content or conditions not contained in the original. Both create a new revision.
• Regulatory changes: Between drafting the specification and submitting the bid, TSI revisions or new EN standards may be adopted. The contracting authority updates the standards references. ERA alone defines 11 different TSIs for railway vehicles, and a change to one of them can affect dozens of specification requirements.
• Political or financial changes: Budget cuts, route changes, new accessibility requirements (TSI PRM), or altered operating concepts lead to substantive changes in the requirements catalogue. A 2023 European Parliament study on rail-industry competitiveness documented that Germany typically takes seven to eight years from competitive call to series production—a period in which political priorities can shift several times.
• National fragmentation: Different national standards leave room for interpretation. As the CONTACT Software Blog documents, different contracting authorities derive different requirements from the same standards. When an authority notices these inconsistencies, a revision follows.
• Editorial corrections: Typos, missing requirement IDs, and inconsistent cross-references; even minor corrections generate a new revision number.

The cost of poor revision tracking

What happens when revision tracking fails? The cost appears in three places:

• Direct rework: Anyone who overlooks changes and works from an outdated requirement produces results that must be recreated completely once the error is discovered. In a specification with 1,000+ requirements and 15–30 participating subsystem teams, a single missed substantive change can cause weeks of rework.
• Compliance risk: EN 50126 requires complete traceability for every requirement change throughout the RAMS lifecycle. Missing change documentation puts both the current bid and the vehicle’s subsequent approval by the Notified Body (NoBo) at risk.
• Contract risk: Compliance commitments in the technical proposal based on an older specification revision can lead to lower scores during evaluation or, in the worst case, exclusion. The UNIFE priorities for 2024–2029 emphasise the MEAT principle (Most Economically Advantageous Tenders), including life-cycle cost; inconsistencies in the compliance matrix are penalised.

Source: CONTACT Software, From slow train to requirements management

An analysis from the Australian rail sector puts the saving potential from early clarification and structured requirements management at up to 30% of project cost. Conversely, tracking revisions poorly and identifying changes late risks significant budget overruns from avoidable rework.

What a revision means for ongoing work

When a proposal manager receives a revised specification, they must make several decisions in a defined order. The INCOSE Systems Engineering Body of Knowledge (SEBoK) defines the process this way: once requirements are “defined, assessed, and approved,” they are frozen as a baseline. Each change must then include the “rationale why the change is necessary” and be assessed across the entire architecture hierarchy, “including suppliers.”

Translated into the daily work of a proposal manager:

Manual comparison: why it does not scale

The most obvious way to identify a delta is manual comparison: open both document versions side by side and review them line by line. That may work for a specification with 20 requirements. For a typical regional-rail specification, it is impractical.

The CONTACT Software Blog documented as early as 2014 that the specification documents for a single tender had “grown from a CD to a DVD.” The volume has increased since then. Manually comparing two versions of a document this size is time-consuming and error-prone. Anyone comparing two Excel sheets line by line for hours will miss things. That is not a weakness; it is human.

Even where a contracting authority provides a revision log (which is not always the case), the risk remains that the log is incomplete. Experienced proposal managers know: trust the delta, not the cover letter.

ID-based comparison: the foundation

The most reliable method of delta identification uses unique requirement IDs. Every requirement in the specification has a stable ID (for example, REQ-LH3-0147) that remains unchanged across revisions. The comparison algorithm is then simple:

• ID exists in Rev. B, not Rev. A → New requirement
• ID exists in Rev. A, not Rev. B → Deleted requirement
• ID exists in both, text is identical → Unchanged (work can be carried over)
• ID exists in both, text differs → Changed (review required)

This approach assumes that the contracting authority uses stable IDs, which the VDB requirements-management guide explicitly recommends. The guide standardises the creation, exchange, and commenting process for specifications between contracting authorities, vehicle manufacturers, and suppliers. It provides for electronic exchange in ReqIF format and expressly states that when ReqIF is used, “new entries and changes can be identified immediately through automated marking, avoiding time losses caused by complex comparisons with earlier work states.”

The VDB guide also recommends checking the compatibility of ReqIF implementations in advance, an indication that interoperability problems are real. The ProSTEP iViP ReqIF Implementor Forum completed six benchmarks up to 2024; the latest included 56 system combinations and 2,800 evaluation criteria. Despite this progress, vendor-specific extensions and version incompatibilities remain challenging.

EuroSpec and EN 15380: attributes for change tracking

The EuroSpec initiative (European Specification for Railway Vehicles) defines an attribute model for requirements in its Requirements Management Specification (Version 3.0). It covers six areas: requirement characteristics, syntax, attributes, traceability, validation/verification, and data exchange. These attributes matter most for revision tracking:

• ID: unique, stable identifier for the requirement
• Status: current processing status in the lifecycle
• Change History: documented change history with timestamp and description
• Source: origin of the requirement (contracting authority, standard, internal document)
• Traceability: link to related requirements, evidence, and risks
• Comments: free-text comments explaining the reason for a change

EuroSpec structures requirements in accordance with EN 15380-5, the European standard for the System Breakdown Structure (SBS) for railway vehicles. The EN 15380 series includes several parts: Part 2 (product groups), Part 4 (function groups), and Part 5 (system structure). This structure makes it possible to track changes not only at individual-requirement level but also at subsystem level: “There were 12 changes in LH3 (traction), and none in LH6 (interior fittings).”

In practice, that means that if a revision contains 47 changed requirements but 40 of them relate to LH5 (braking systems) and only 7 to other subsystems, the relevant experts can be notified directly. Without subsystem-based aggregation, every expert must review the entire delta list. Across 15 to 30 participating teams, that consumes time.

Regulatory framework: EN 50126, ISO 22163, and INCOSE

Revision tracking is also a regulatory requirement. Several standards require it simultaneously, with partially overlapping requirements.

CENELEC EN 50126: RAMS lifecycle and configuration management

CENELEC EN 50126 defines the RAMS lifecycle (Reliability, Availability, Maintainability, Safety) for all railway applications. In every lifecycle phase, it requires documented configuration management: every requirement change must be documented, approved, and traceable, from concept definition through decommissioning.

That starts in the bidding phase, not only in development. The compliance commitments made there form the first baseline for the later project. If that baseline relies on an outdated specification revision, inconsistencies emerge during review by the Notified Body (NoBo). As LDRA summarises, the EN 5012x family requires traceability between all development artefacts—a chain that begins with the requirements baseline.

ISO 22163:2023 (IRIS Rev. 04): configuration and change control combined

ISO 22163:2023 was published as a full international standard in July 2023 (previously ISO/TS 22163:2017). Its central structural change is that former subsections 8.1.4, “configuration management,” and 8.1.5, “change management,” were combined into subsection 8.1.4, “configuration management and change control.”

This combination is more than cosmetic. The standard now treats change tracking as part of configuration rather than as a separate process. IRQB Guideline 8 (Configuration & Change Management) offers detailed implementation guidance. The standard specifically requires:

• Documented procedures for identifying and controlling changes
• Assessment of every change’s impact before implementation (Change Impact Analysis)
• Traceability: who changed what, when, and for what reason?
• Baseline management: defined, frozen configuration states as reference points

IRIS certification under the new IRIS Rev. 04 rules has been mandatory for all audits since 1 January 2024. The owner of the certification rules is UNIFE (Union des Industries Ferroviaires Européennes).

Source: DQS Global, IRIS Revision 04

INCOSE and SEBoK: systems-engineering best practices

Beyond rail-specific standards, the INCOSE Systems Engineering Body of Knowledge (SEBoK) sets out general requirements-management principles. Four apply directly to revision tracking:

• Baselining: Approved requirements are frozen as a baseline. Changes require a formal rationale and impact analysis.
• Bidirectional traceability: Every requirement must be traceable to operational scenarios, risks, related requirements, and verification artefacts.
• Change control: INCOSE recommends establishing the change-control process “early in the effort,” not only when the first revision arrives.
• Supplier integration: Changes must be assessed across “multiple levels in the architecture hierarchy (including suppliers).” This is particularly relevant for OEMs with 10,000+ suppliers.

Tools for revision tracking

Tools range from manual approaches to integrated ALM systems. The choice determines how much work is carried forward automatically when a revision arrives, and how much must be updated manually.

Word/PDF: redline comparison

Microsoft Word has a built-in document-comparison function (“Compare Documents”) that marks changes as redlines. It is a starting point for free-text documents, but reaches its limit with structured requirement lists: Word compares text, not requirements. A moved requirement is displayed as deletion plus insertion, not as a move. There is no way to transfer the existing classification or expert comment to the new version automatically.

Excel: formulas and VLOOKUP

In Excel-based workflows, ID-based comparison can be implemented with VLOOKUP formulas: IDs from the old revision are checked against the new one, and text differences are detected with EXACT formulas. The approach works, but is fragile (column shifts and formatting changes) and does not create a persistent change history. Formula logic must be rebuilt for the next revision. The CONTACT Software Blog noted in 2014 that many smaller rail-industry suppliers still exchange requirements through Excel. Change has been slow since then.

IBM DOORS: baselines and change impact

IBM DOORS (Dynamic Object Oriented Requirements System) has been the de facto standard in regulated industries since the 1990s. It natively supports baselines—frozen snapshots of a requirements state that serve as references for later comparisons. Its baseline comparison feature shows the precise difference between two states for each requirement, including attribute changes.

In DOORS Classic, baselines are created at module level, a model that has proven itself for more than two decades. IBM DOORS Next (DNG) takes a different approach: baselines are created at component or project level, which benefits large projects with several subsystems. One practical example: Rail Projects Victoria (Melbourne) selected DOORS Next as a SaaS solution for the Metro Tunnel Project to manage requirements centrally across multiple stakeholders.

Siemens Polarion: LiveDoc and revision comparison

Siemens Polarion uses its LiveDoc functionality for a document-centred approach: requirement documents are managed as living documents in which each paragraph is uniquely identifiable and traceable. Every change automatically creates a Version History Record, and Document Baselines can be created at defined points (for example, after approval). For every baseline, Polarion automatically generates a link to LiveDocs Compare View showing the difference from the previous baseline.

Since 2025, Polarion has additionally supported AI-supported requirements extraction, which can also be applied to unstructured revision documents (PDF and Word).

PTC Codebeamer: streams and Delta Merge

PTC Codebeamer provides streams, baselines, and Delta Merge, an approach designed for Product Line Engineering (PLE): Stream Baselines capture snapshots of all projects within a stream, while Delta Merge allows controlled consolidation of changes across platforms and variants. This is particularly relevant for multi-product tenders where the same specification must be answered for different vehicle variants.

ReqIF: structured revision comparison

The ReqIF format (Requirements Interchange Format) is well suited to revision tracking because it carries requirements as structured data objects with stable IDs and typed attributes. Two ReqIF files (Rev. A and Rev. B) can be compared automatically: requirement by requirement, attribute by attribute.

The standard was developed in 2004 by Herstellerinitiative Software (HIS) of the German automotive industry (Daimler, VW, Porsche, Audi, BMW Group) and has been maintained by the OMG since 2011 (currently Version 1.2 from 2016, developed by 14 companies). The ReqIF Implementor Forum (run by ProSTEP iViP) has been conducting regular interoperability benchmarks since 2018. The sixth benchmark (2024) covered 56 system combinations and 2,800 evaluation criteria.

One important limitation: ReqIF itself has no concept for exchanging a change history or change comments. Comparison must therefore happen at the tool level: two ReqIF files are compared, but the history is not carried in the format itself. For workflows requiring a cumulative change history across multiple revisions, this is a gap the receiving tool must fill.

Other tools

Visure Requirements supplies templates for EN 50126 compliance and links requirements, tests, risks, and artefacts end to end. PHA and FMEA are integrated for risk analysis of requirement changes. Jama Connect relies on “Live Traceability”: when an upstream requirement changes, every downstream element is automatically marked “suspect.” This noticeably accelerates Change Impact Analysis.

Carrying work forward: the core question in revisions

Delta identification is only the first step. The real question is: how much of the work completed so far can be retained?

Typical transferability of existing work by change type (qualitative assessment; varies by revision).

In practice, 60–80% of requirements remain unchanged between two revisions, so previous work can be carried over directly for the majority. Bidara Research puts the cross-industry content-reuse rate in tenders at 66%. In rail, it is likely even higher between revisions because substantive changes usually affect only a portion of requirements.

The question is whether the tool supports this transfer or whether the proposal manager has to copy classifications and comments manually to the new version. In ALM systems such as DOORS or Polarion and specialised platforms such as Tendric, work migration can be largely automated. In Excel workflows, it means copy-paste across hundreds of rows, with the risk that assignments shift.

The diff approach: what software development teaches

In software development, version tracking is a solved problem. Tools such as Git manage millions of text changes across thousands of files, automatically detect conflicts, and enable parallel work by hundreds of developers. Its core concepts—commits, diffs, branches, and merges—transfer directly to requirements management:

The key difference is that version control has been standard in software development since the 1990s. In rail-industry requirements management, many companies are still where software developers were before CVS and Subversion: manually numbered file copies and the hope that nobody accidentally overwrites the wrong version. The CONTACT Software Blog documented that even Deutsche Bahn did not introduce a database-based requirements-management system until around 2012/2013.

AI and delta identification

According to the Loopio 2025 RFP Response Trends Report, 68% of proposal teams across industries already use generative AI, double the 34% in 2023. In rail, this change is still largely ahead. Revision tracking offers three applications:

• Unstructured documents: When the authority delivers a revision as a PDF or Word document (without stable IDs or ReqIF), AI can analyse free text and try to match requirements semantically between versions, even where wording changed or requirements moved. Siemens Polarion has offered precisely this functionality since 2025. PTC also announced new AI functionality in 2026 for Codebeamer.
• Change assessment (triage): AI can suggest whether a text change is substantive (an altered technical requirement or new standards reference) or editorial (rewording with no substantive effect). Rather than having an expert review 83 changed requirements individually, AI can prioritise the 15 substantive ones.
• Cascade analysis: AI can analyse cross-references between requirements and automatically identify unchanged requirements that may be indirectly affected by a changed one. This is similar to the “suspect” mechanism in Jama Connect, but at semantic rather than explicit-link level.

Practical workflow: revision in five steps

A structured approach to revisions can be summarised in five steps. This workflow is based on the principles of the INCOSE SEBoK and is compatible with EN 50126 and ISO 22163:2023:

Conclusion

Revision tracking shows how well a company’s requirements-management process actually works. Those who manage requirements with stable IDs, structured formats, and clean baselines process a new revision in hours. Those dependent on manual document comparison lose days and risk overlooking substantive changes.

There is no regulatory latitude: EN 50126 requires complete traceability; ISO 22163:2023 combines configuration management and change control in section 8.1.4; and IRIS Rev. 04 has been mandatory since 2024.

The tools and process for handling revisions must be in place before the first requirement is classified. The VDB guide and EuroSpec supply the standards; ReqIF supplies the exchange format; DOORS, Polarion, Codebeamer, and specialised platforms such as Tendric supply the technical infrastructure. AI helps where structured data is absent, but it does not replace the foundation: stable IDs, clean baselines, and documented change history.