The Five Tests Every Requirement Must Pass Before It Enters a Baseline
A requirement that has not been tested against necessity, clarity, verifiability, consistency, and achievability is not a requirement yet, it is a draft. Baselining it anyway simply moves the cost of testing it further downstream.
A requirement entering a baseline without having cleared a real standard first is not actually a requirement. It is a draft that has been treated as finished. The cost of that gap does not disappear when the requirement is baselined. It moves downstream, to a point in the programme where finding and fixing it is far more expensive than catching it now would have been.
Necessary
The first test asks whether this requirement actually needs to exist. A surprising number of requirements are inherited, carried forward from a previous project’s template, a standard boilerplate clause, or an assumption nobody actually checked against the specific need in front of them this time. A requirement that cannot justify its own presence, tied clearly to something this particular design genuinely needs to achieve, should not survive into the baseline simply because it has always been there.
Unambiguous
The second test asks whether two competent engineers, reading the same requirement independently, could reasonably design to different interpretations of it. If the answer is yes, the requirement is not ready. Ambiguity discovered during a review is a conversation. Ambiguity discovered after two teams have already built to different readings of the same words is a genuine problem, and an expensive one to unwind.
Verifiable
The third test asks whether the requirement states a measurable acceptance criterion and an actual method by which it will be checked. Plenty of requirements sound testable without actually being testable, stating an intention without ever specifying what evidence would prove it has been met. A requirement that cannot be verified is not a requirement. It is an aspiration.
Consistent
The fourth test asks whether this requirement conflicts with any other requirement already sitting in the set. Conflicts caught before baseline are a design conversation, worked through while the cost of resolving them is still low. Conflicts caught after baseline, once design work has proceeded on both requirements independently, are a design crisis, forcing a choice between two things that were both supposedly already agreed.
Achievable
The fifth test asks whether the requirement is realistic given known constraints, or whether it quietly assumes a capability, a budget, or a schedule that does not actually exist. A requirement that cannot honestly be achieved within the real constraints of the programme should be challenged now, not discovered as unachievable partway through detailed design.
Why passing all five still is not enough
A requirement can clear every one of these five tests cleanly and still not be defensible. The five tests check whether a requirement is well formed. They do not check whether it represents the minimum genuinely needed to reach the outcome, or whether it has quietly been decorated with detail that was never actually required. Every piece of unnecessary specificity layered into a requirement becomes a constraint the design has to carry for the rest of its life, even though nothing about that extra precision was ever genuinely needed to define the outcome in the first place.
Bringing downstream thinking into the requirement itself
A requirement written with some genuine foresight for how the outcome will actually be manufactured, assembled, and tested carries real advantages over one written in isolation from those concerns. This is not about specifying the design, which remains the wrong place for a requirement to go. It is about writing the requirement with enough awareness of what implementation and verification will actually demand that the requirement does not unknowingly work against them.
The deeper danger even a passing requirement carries
There is a more honest caution worth ending on. A requirement can pass all five tests, necessary, unambiguous, verifiable, consistent, achievable, and still be wrong in a deeper sense. Defining a requirement with too much precision and rigidity, too early, before any real design exploration has happened, can quietly foreclose a better, cheaper, or higher performing approach before anyone ever had the chance to consider it. The five tests confirm a requirement is well formed. They say nothing about whether it was formed at the right moment, with enough openness still left for the design to actually respond to it. A checklist that catches every flaw in how a requirement is written can still miss the flaw in when, and how tightly, it was written at all.