From requirements specification to system specification
From TSI compliance and CENELEC evidence to supplier coordination: the five phases of requirements-specification work, ReqIF in practice, typical bottlenecks and where digitisation makes the greatest difference.
Introduction
Anyone submitting a bid in the European rail industry must translate a requirements specification into a functional specification. That sounds like document work. In practice, dozens of subject-matter experts coordinate thousands of individual requirements with hundreds of standards references, and many companies still do this in Excel and Word.
According to the UNIFE World Rail Market Study 2024 alone, the European rolling-stock market is worth EUR 63.3 billion, with annual growth of 7.3% in Western Europe. According to a European Parliament study (2023) the four largest European manufacturers hold more than 70% market share. To compete in this market, companies must be able to respond to requirements specifications quickly, completely, and in compliance with standards. The process that makes this possible is the subject of this article.
The following explains why the rail industry is particularly demanding, the five phases of the process, where it typically gets stuck, and how digital tools can change it.
What is a requirements specification?
A requirements specification (English: requirements specification or tender specification) describes all requirements that a client places on a system to be delivered. In the rail industry, it is prepared by the purchaser, i.e. a transport company or infrastructure operator, and sent to potential suppliers.
Depending on the scale of the project, a requirements specification contains hundreds to several thousand individual requirements. In the rail industry, its structure often follows the LH categories (LH1 to LH8), which cover various subsystems: vehicle structure, traction technology, braking systems, interior fittings, passenger information, and others.
Each requirement typically contains a unique ID, the requirement text itself, standards references (TSI, DIN EN, ISO), and a level of obligation (must, should, may). The VDB requirements management guide recommends electronic exchange via the ReqIF format (Requirements Interchange Format) in order to avoid manual comparisons between document versions.
The timeline should not be underestimated: according to the European Parliament study in Germany, it typically takes 7 to 8 years from the call for competition to serial production, and at least 6 years from contract signature. The functional-specification phase is at the start of this chain and determines whether a supplier makes the shortlist at all.
Why the rail industry is particularly demanding
Requirements specifications exist in every industry. What distinguishes the rail industry is the combination of regulatory depth, diversity of standards, and breadth of the supply chain.
TSI complexity
A rail vehicle must simultaneously comply with several Technical Specifications for Interoperability (TSIs) issued by the EU. The ERA defines 11 different TSIs. At least three are directly relevant to vehicles: LOC&PAS (locomotives and passenger rolling stock), Noise (noise emissions), and PRM (accessibility). Depending on the vehicle type, CCS (control-command and signalling), SRT (safety in railway tunnels), and others also apply.
Every TSI is an EU regulation and therefore directly applicable law. Where TSIs leave open points, national technical rules (NNTRs) also apply. In cross-border projects, bidders must comply with the TSIs plus the NNTRs of several countries at the same time. Conformity is assessed by a Notified Body (NoBo) and a Designated Body (DeBo).
CENELEC EN 5012x: RAMS, software, safety case
In addition to TSIs, the market requires proof of functional safety under the CENELEC standards. The three key standards are:
- EN 50126 defines the RAMS lifecycle (Reliability, Availability, Maintainability, Safety) in 12 phases. Bidders must provide RAMS targets, risk analyses (FMEA, FTA), and a safety case for their system.
- EN 50716 has combined the previous EN 50128 (signalling technology) and EN 50657 (vehicle software) into a single standard since October 2023. New: explicit provisions for iterative development, AI/ML components, and cybersecurity.
- EN 50129 defines the structure of the safety case and the evidence required for hardware safety. For commissioning in the EU, assessment by an independent safety assessor (ISA) is mandatory.
All this evidence feeds into the functional specification. A bidder with gaps in RAMS documentation is penalised in the evaluation, regardless of how technically good its vehicle is.
The supply chain multiplies complexity
No OEM builds a rail vehicle alone. According to its own supplier page Alstom works with more than 21,000 suppliers in 83 countries. Procurement accounts for 60% of annual revenue. Each of these suppliers receives a partial requirements specification for its share and must respond with its own functional specification. A brake-system manufacturer receives the braking requirements, an HVAC supplier the climate-control requirements, and a seat manufacturer the interior-fittings requirements.
This means the OEM must not only prepare its own functional specification, but also pass requirements consistently to subsystem suppliers and consolidate their responses. If the brake manufacturer rates a requirement as OKB and the OEM reports it to the customer as OK, an inconsistency arises that will be noticed during the assessment.
The EUR 15 billion contract for Berlin's S-Bahn was awarded to a consortium of DB, Siemens, and Stadler. 1,400 new cars, tender ongoing since 2020, award only in 2025. Alstom challenged the process. Consortium structures like these show how many parties can be involved in processing requirements.
The 5 phases of the process
The process can be divided into five phases. In practice, they overlap and vary by company, but the basic pattern is similar for most suppliers.
The requirements specification is imported and broken down into individual requirements. Structure, IDs, and standards references are extracted. In revisions, changes from the previous version must be identified. Ideally, exchange takes place in ReqIF format, which is supported by tools such as IBM DOORS, Siemens Polarion, and Eclipse RMF.
Each requirement is assessed: OK (fully achievable), OKB (achievable subject to conditions), NOK (not achievable), OKM (achievable with modification), or R (question for the purchaser). OKB is often the most difficult case because the condition must be formulated precisely, measurably, and in a way the customer can accept.
Requirements are assigned to the responsible specialist departments: traction technology, braking systems, electrical engineering, RAMS, interior fittings. Depending on the scale of the project, 10 to 30 subsystem teams are involved. Incorrect assignments cost time and create gaps.
Subject-matter experts formulate standards-compliant responses with references to supporting evidence. Conditions, alternative proposals, and questions are documented. Every response must be able to refer to source documents: test reports, approval documents, manufacturer data sheets, and RAMS evidence.
The individual responses are consolidated into the functional specification and exported as a complete document as well as partial requirements specifications per subsystem, in the format required by the customer, with full traceability from requirement to evidence.
ReqIF in practice
The Requirements Interchange Format (ReqIF) is an open OMG standard (currently version 1.2) for the lossless exchange of requirements data between different tools. Originally developed in 2004 by the Manufacturer Initiative Software (HIS) of the German automotive industry, ReqIF has been maintained by the OMG since 2011.
In theory, ReqIF solves the problem of exchanging requirements between purchaser and bidder. In practice, there are documented interoperability problems: when importing Polarion ReqIF into IBM DOORS all objects are marked as locked. Older DOORS versions implemented RIF 1.0, while Polarion used RIF 1.1a, leading to silent import errors . Vendor-specific extensions, missing attribute filtering, and version incompatibilities remain issues.
Penetration was estimated at 30% in 2020. In the rail industry it is lower than in the automotive industry. The CONTACT Software article noted in 2014 that most manufacturers were not yet able to deliver their specifications in the correct format. This has improved since then, but many smaller suppliers still exchange requirements via Excel.
Typical challenges
Processing a requirements specification takes weeks to months on major rail projects. The problems that arise are familiar to every industry with extensive tenders. In the rail industry, they are more pronounced because the volumes of requirements, the number of teams involved, and the regulatory depth are greater.
The number of requirements that need to be commented on when processing requirements specifications has increased at least tenfold over the past ten years.
– Manager at a brake-system manufacturer, CONTACT Software Blog (2014)Source: CONTACT Software, Slow train to requirements management
The same article cites further causes: national standards in different countries conflict with one another, international stakeholders interpret standards differently, and multiple tenders by the same purchaser lead to divergent specifications between lots. In addition, requirements documents grew from a CD to a DVD simply to accommodate the scope of a single tender.
Cross-industry figures confirm the picture. The Loopio 2025 RFP Response Trends Report (1,500+ proposal teams, all industries) shows that 48% of teams report difficulties collaborating with subject-matter experts, and 39% have trouble finding accurate answers to technical questions in time. There is no comparable survey for the rail industry, but given the greater number of subsystem teams involved, the actual rate is likely to be higher.
Specification quality as a bottleneck
The problem often begins with the requirements specification itself. Prover Technology identifies three main problems with specifications in the tender phase: incomplete, inconsistent, and defective. Errors that are not detected at this stage persist throughout the project lifecycle and become more expensive to correct in every subsequent phase.
What a functional specification must contain
The functional specification (Compliance Document or Technical Offer) is the official response to the requirements specification. It documents, for every individual requirement, whether and how the supplier fulfils it. A professional functional specification contains:
- Complete requirement coverage: every requirement in the requirements specification is addressed; none is omitted
- Classification with rationale: OK, OKB, NOK, OKM, or R with a specific explanation (more in the classification deep dive)
- Evidence references: links to source documents such as test reports, approval documents, RAMS evidence, or manufacturer data sheets
- Standards compliance: mapping to relevant standards (TSI, DIN EN, ISO, CENELEC EN 50126/50716/50129)
- Conditions and alternative proposals: clear wording for OKB and OKM
- Partial requirements specifications: breakdown by subsystem for internal processing and onward sharing with suppliers
The EuroSpec standard for requirements management also defines six core areas: requirement characteristics, syntax, attributes, traceability, validation/verification, and data exchange. This structure offers good guidance for quality assurance of functional specifications.
The difference between good and poor functional specifications
The quality of a functional specification often determines award or exclusion. In regulated procurement procedures, such as at the ESA or under public procurement law, discrepancies between compliance statements and the actual offer can lead to significant score reductions or exclusion. The UNIFE Priorities 2024–2029 recommend applying the MEAT principle (Most Economically Advantageous Tenders) with lifecycle costs. In practice, this means: the client evaluates on the basis of the compliance matrix, and gaps or inconsistencies are penalised.
How digitalisation and AI are changing the process
Digitalisation takes place in two steps. First, the shift from Excel and Word to database-based systems. Then, building on that, AI support.
Step 1: Database-based systems
The established tools in the rail sector are IBM DOORS (the de facto standard in regulated industries for decades), Siemens Polarion (with native ReqIF support), and Reqtify by Dassault Systèmes (a traceability overlay with more than 100 interfaces). Many rail companies have already taken this step or are in the process of doing so.
A concrete example: Rail Projects Victoria (Melbourne) selected DOORS Next as a SaaS solution for the Metro Tunnel Project in order to manage requirements centrally across multiple project participants. Deutsche Bahn did not introduce a database-based requirements-management system until around 2012/2013, as the CONTACT Software article documents.
Step 2: AI support
According to the Loopio 2025 RFP Response Trends Report 68% of proposal teams across industries already use generative AI, double the 34% figure in 2023. In the rail industry, this shift is still largely ahead.
How much can be automated depends on the phase:
Requirements capture: Automatic parsing, structuring, and diff detection between revisions. The VDB guide recommends the ReqIF format for this purpose, which enables automatic change marking.
Classification: Matching requirements against internal documents, standards, and previous project responses. This is where the greatest potential lies, but quality depends entirely on the internal knowledge base, and the final decision remains with the subject-matter expert.
Expert routing: Automatic assignment based on topic, LH category, and standards reference. Platforms such as Tendric use rule-based routing to reduce incorrect assignments.
Response: Generating proposed responses based on the knowledge base. According to Bidara the cross-industry content reuse rate is 66%, potential that many companies do not exploit because they lack a searchable knowledge base.
Export: Automated formatting and generation of partial requirements specifications for each subsystem and supplier.
Since October 2023, EN 50716 has replaced the previous EN 50128 and EN 50657. The new standard permits iterative development (Agile/Scrum) for the first time, contains provisions for AI/ML components, and requires cybersecurity integration in accordance with CENELEC TS 50701. For bid managers, this means that the standards references in old functional-specification templates must be updated.
According to Verified Market Reports the market for tender-management software will grow to USD 3.5 billion by 2033 (CAGR 9.8%). Established tools such as IBM DOORS and Siemens Polarion are widespread in the rail sector, but specialised solutions for the entire journey from requirements specification to functional specification, such as Tendric, are still rare.
Conclusion and next steps
The larger the requirements specification, the more a structured process pays off. With hundreds or thousands of requirements, 11 TSIs, CENELEC evidence, and a supply chain with dozens of subsystem suppliers, the difference between document-based and database-supported work becomes the decisive factor.
Maturity can be broadly divided into four levels:
- Excel and Word (document-based, no traceability)
- Database-based system (DOORS, Polarion) with central requirements management
- Integrated platform with ReqIF exchange, expert routing, and partial-requirements-specification export
- AI-supported classification and response generation based on an internal knowledge base
Anyone still at level 1 today should not try to jump straight to level 4. The most obvious first step is a central system in which requirements, classifications, source references, and responses are linked and traceable. Tools such as Tendric provide exactly this structure. Without such structured data, AI support has no foundation.
- Rail-industry specific: multiple TSIs, CENELEC EN 5012x evidence, and national rules (NNTRs) per project
- The process covers 5 phases, from capture to export, which often run in parallel in practice
- OEMs such as Alstom coordinate 21,000+ suppliers, each of which must respond to its own partial requirements specification
- ReqIF solves exchange in theory, but has documented interoperability problems between tools
- Since October 2023, EN 50716 has replaced EN 50128/50657 and introduced AI/ML and cybersecurity provisions
- Maturity progression: Excel → database → integrated platform → AI support
Das tendric-Team entwickelt KI-gestützte Werkzeuge für die Ausschreibungsbearbeitung in der Industrie. Wir schreiben über Best Practices, Branchentrends und die Zukunft des Angebotsmanagements.