Bitter Lessons in Requirements: SNCF & Renfe Trains

What happens when a value in your requirements doesn’t match the real-world conditions your hardware must fit into?

Two European railway operators faced this exact problem when they ordered new trains. The platform and tunnel measurements in their specifications didn’t match the actual platforms and tunnels, and the mismatch became apparent only after they placed the orders. Fixing it meant modifying about 1,300 platforms in France and delaying the trains in Spain.

In this article, you will learn how those mismatches stayed hidden or took too long to resolve, and which three best practices you can use to reduce the risk of similar problems in your own hardware projects.

Key Takeaways

• Know where each critical requirement value came from and what it covers before it drives a design decision.
• Validate critical requirement values against real-world operating conditions before the design relies on them.
• Ensure every raised concern has an owner who can act, and track its status until it’s closed.

What Happened with Two European Train Orders

In 2014, it became public that new regional trains ordered by SNCF, France’s national railway, were too wide for many platforms. The order relied on platform data that mostly covered platforms built in recent decades, even though much of the network was older. About 1,300 platforms had to be modified, at an estimated cost of €50 million.

Spain ran into a similar problem a few years later. In 2020, Renfe, Spain’s rail operator, signed a €258 million contract for new trains. In 2021, the manufacturer found that the tunnel measurements in the tender didn’t match the actual tunnels. The trains hadn’t been built yet, but the problem took a long time to resolve and became public only in 2023. Delivery of the trains was later pushed back.

In both cases, the teams worked from numbers that didn’t match reality:

• In France, platform data that didn’t cover the whole network
• In Spain, wrong tunnel measurements and a problem that took a long time to resolve

The illustration shows that the most important numbers in a design deserve one simple check against the real constraint early in the project.

What Hardware Teams Can Learn from These Cases

You design to requirements and intent that come from other people. That’s normal, but it carries two risks: a value in a requirement can be wrong, or a concern can be raised that never reaches someone who can act. Three best practices help you catch both early.

Know Where Each Value Came from and What It Covers

Every value used in a requirement comes from somewhere. For example, the French platform data didn’t cover the older part of the network. Before a value drives a design decision, know where it came from and what it represents.

Validate Critical Values Before They Drive the Design

In both cases, the trains were designed to the spec, but the specification didn’t match reality. For critical requirements, spend extra time validating the values before the design relies on them. Check each value against the real constraint, for example by measuring the actual part or performing a fit check, and ask someone who didn’t write the requirement to review it.

Give Every Raised Concern a Path and an Owner

In Spain, the team identified the problem early, but it took a long time to resolve. Assign every raised concern an owner’s name and a visible status. That keeps it from getting lost among the groups working on the same project.

How a Connected Requirements Workflow Helps

A connected requirements workflow keeps each requirement linked to its rationale, the design work it affects, and the verification and validation activities that check it.

That matters most when someone questions a value or raises a concern. A value may look correct, but it may be unclear what it covers. A concern may be real, but it may sit with someone who can’t act on it.

Altium Requirements Portal supports this workflow by keeping requirements, rationale, verification and validation activities, comments, and tasks in one shared workspace. Its purpose-built AI can also help you check your requirements for gaps and contradictions, and nothing changes until you approve it. This helps teams catch a wrong value or a lost concern earlier, because the context stays next to the requirement and the AI works from the same project data.

Can You Trace Every Value in Your Spec?

Pick one active requirement in your current project and try to answer three questions about it.

• Where did this value come from, and what does that source cover?
• Has it been checked against the real constraint, or only against the document that states it?
• If someone raises a concern, is someone responsible for closing it?

If you can’t answer these questions quickly, you may be missing context. Without it, a wrong value or a lost concern can go unnoticed until late in development.

Keep every requirement’s context in one place with a requirements management tool your whole team can use.

Try Requirements Portal free for 30 days

More Bitter Lessons in Requirements

If you want more lessons from real hardware cases, these articles cover other requirements management failures and what you can learn from them:

• Ariane 5 Flight 501 explains why requirements, software, and tests reused from an earlier project need a second look before you rely on them.
• S-80 Submarine Program shows how a design change can break a constraint that no one was reviewing, and how linking constraints to design decisions shows what a change affects.
• Unit Conversion Failures covers how a number with an unclear unit or source can mislead a team, and why every value needs its unit, its source, and an owner for each handoff.

Frequently Asked Questions

How Do You Decide Which Values Are Critical?

Start with the values the design depends on most. For each one, ask what would change if the value were off (for example, if a tolerance doubled) and what the worst outcome would be. A value is likely critical if an incorrect value would force a redesign, affect safety or compliance, or can’t be changed once the hardware exists.

What Should You Do When You Can’t Confirm a Value Yet?

Enter your best estimate and mark it TBD (to be determined) rather than leaving it blank. Record why you chose it, what needs to happen to confirm it, who is responsible, and by when. Confirm the assumptions behind the estimate before the design depends on it.

Who Should Agree on a Requirement That Sits Between Two Teams?

Both sides should agree on it. Write it as an interface requirement and have each side’s owners approve it. That way, neither side designs based on its own guess. Any later change goes through the same agreement.