From Requirements to Solution: the Art of Specification

A project that starts with vague requirements rarely ends well. On the critical systems I work on, in aerospace as much as in railway, this reality is even harsher: a single ambiguity in a specification can translate into a safety defect or a regulatory non-compliance.

The problem with poorly defined requirements

I've seen too many projects start on the wrong foot. A need expressed as "a performant system" without ever defining what performance means; a feature described as "it should work like the old system", with no further detail. The outcome barely varies: the team builds something, the client discovers it's not what they expected, and we start over.

The engineer as translator

My role doesn't start at the keyboard. It starts upstream, in understanding the need: the operational context, the business constraints, the stakes behind the request.

Take a concrete case. On a railway project, I'm asked for "a system that displays the train's speed". The questions come straight away: what precision, what refresh rate, what resilience in case of sensor failure? They are what turn a vague request into a measurable requirement.

Writing an actionable requirement

Every requirement must be specific, measurable, and traced back to an identified need. On critical systems (DO-178C in aerospace, CENELEC EN 50128 in railway), this traceability isn't optional: every line of code must answer an identified requirement.

The steps I follow

1. Clarify the need, through workshops with business experts and the "5 whys" to trace back from the symptom to the actual need.

2. Formalise the requirements: numbered, phrased imperatively ("shall"), each with its own validation criterion.

3. Run a cross-review, validated by business, engineering and the client, to catch inconsistencies early.

4. Maintain traceability, linking each requirement to a need, then to a design, code, and tests.

The concrete impact

Studies commonly cited in engineering estimate that a specification error costs far more to fix in production than upstream. On my projects, investing a day in a rigorous specification consistently saves weeks of rework. That effort also greatly eases certification audits, where every regulatory requirement must be traced down to the code.

In short

Specifying means translating a business need into technical requirements without losing meaning along the way. It's an exercise in listening and rigor that I always place before the first line of code, and it's often what decides whether the project moves forward smoothly or turns into a chaotic slog.