How to Defend a Requirement Once It's Set, A Working Metric for the Six Tests
Passing the six tests in principle and being able to defend that a requirement passed them are different things. The difference is whether each test has actual evidence behind it, not just a reasonable-sounding claim.
Asserting that a requirement is necessary, unambiguous, verifiable, consistent, achievable, and formed at the right time is not the same as being able to defend that it actually is, under real challenge, during a review that matters. Each test needs genuine evidence attached to it, demonstrating real clarity and technical basis, not a confident claim that the requirement was considered against the standard.
Necessary
The evidence here is a needs analysis, genuinely weighted against the odds, that distinguishes a real need from a want dressed up as one. It is not enough to point at something the requirement connects to. The connection has to survive the harder question, would this still be necessary if it were tested honestly against the possibility that it is simply convenient, or familiar, or assumed, rather than actually required.
Unambiguous
The evidence here is root cause analysis, performed before the requirement’s clauses were even drafted, not applied afterward to check whether the wording happens to hold up. A requirement built on a precise understanding of the underlying cause it is meant to address carries a technical basis that makes ambiguity structurally unlikely from the outset. A requirement written first and checked for clarity second is starting from the wrong end of the problem.
Verifiable
The evidence here is explicit alignment against the governing standard, code, or regulation that actually applies, checked specifically for consistency with any overlay specifications sitting alongside it. A generic acceptance criterion, invented independently of the standards framework the design actually has to satisfy, is not real verifiability. It only looks like it until someone checks it against what actually governs the work.
Consistent
The evidence here has to demonstrate the requirement is genuinely aligned with the real outcome, not quietly shaped to justify a design that has already been decided, and not shaped, deliberately or otherwise, to undermine a design outcome or a product release for reasons that have nothing to do with the requirement itself. Consistency checked only against other requirements in the set catches contradiction. It does not catch dishonesty. A requirement can be perfectly non-contradictory and still be disingenuous.
Achievable
The evidence here begins with defined criteria and a set of actual checks and tests, but it is not fully closed until the finished product’s validation confirms whether the requirement’s real intent, not just its literal wording, was genuinely achieved. A requirement can be technically satisfied on paper and still fail the thing it was actually meant to protect. Achievability is only proven at the point validation confirms it, not at the point the requirement was written.
Formed at the right time
The evidence here is a specific record of the assumptions that were made, and the constraints that were deliberately allowed to unfold during design work, kept honest enough that none of it quietly biased or distorted the requirement’s original intent. This is not a general note that exploration happened. It is a traceable account of what was assumed, what was allowed to remain open, and why neither compromised what the requirement was actually there to protect.
Why this evidence base matters beyond the moment it was built for
This is not only a defence for the review where the requirement is first challenged. Validation and evaluation, carried out properly and recorded honestly, become the thing that protects the requirement’s original intent much later, when a future issue arises and someone has to determine whether the requirement was right from the start, or whether it quietly drifted from what it was actually meant to achieve. A requirement defended once, in the moment, is useful. A requirement whose evidence survives long enough to answer that question years later is what this metric is actually for.