Ask what would be different if it were true
Do not open by explaining that the requirement is untestable. Open by asking what the
stakeholder would see if it had been achieved, and what they are seeing today that made them
say it. "Intuitive" almost always has a specific irritation underneath: new starters take three
weeks before they can process a case unsupervised, or the team keeps ringing the helpdesk about
the same screen, or an experienced clerk can do eleven cases an hour on the old green-screen and
only six on the replacement. Each of those is measurable, and each points at a different design
problem. The adjective was a compression of one of them.
So the diagnostic question is about consequence, phrased concretely. What does someone get wrong
today? How long does training take, and what part of it do people fail? Which screen generates
support calls? If the answer is "nothing specific, I just do not want another system like the
last one", you have learned something important too: this is not a requirement, it is a fear,
and it needs handling as a design constraint and a review gate rather than as a line in a
specification.
The shape a testable requirement takes
A requirement is testable when it names the actor, the task, the conditions, the measure and the
threshold, and when somebody has agreed how the measurement is taken. Missing any one of those
and you have a sentence that will be argued about at acceptance.
| As stated | As written back |
|---|
| The system must be intuitive | A clerk who has completed the two-hour induction and has never seen the system can process a standard single-line claim end to end, unassisted, with no error, within four minutes. Measured with six clerks during UAT; five of six must pass. |
| The report must be fast | The monthly branch summary returns within eight seconds at the 95th percentile, measured server-side at the reporting endpoint, with 24 months of history loaded and 40 concurrent users. |
| Search must be accurate | For the 50 sample queries in appendix C, the intended record appears in the first ten results. Agreed with the branch network team; the sample is refreshed each quarter. |
| The process must be less manual | Median touches per invoice falls from the measured baseline of four to no more than two, counted from system audit logs over a full month after go-live. |
Two things are doing the work in that right-hand column, and neither is the number. The first is
the measurement method, because a threshold with no stated method is just a different flavour of
argument. The second is the sample and the pass rule, since a usability target that one clerk out of
the six can meet has not been met.
When you honestly cannot put a number on it
Some qualities resist quantification and should not be forced. Consistency of visual language,
tone of error messages, whether a screen feels crowded — you can invent a metric for these, but
it will be a metric nobody measures, and an unmeasured number is worse than the adjective was
because it looks rigorous while being just as unenforceable.
The honest treatment is to change the artefact the requirement lives in. Move it out of the
functional requirements and into a design standard or a checklist, verified by a named reviewer
at a named point — a design review before build, or a usability walkthrough with three real
users before UAT exit. That is still a requirement with a verification method; the method is a
judgement by a nominated person rather than an assertion by a test script. Record who that
person is, because "the business will review it" is how this quietly reverts to being
unverifiable.
Where a comparative baseline is available, prefer it to an invented absolute. "No slower than
the screen it replaces, measured the same way" is defensible, cheap to verify, and much harder
for a stakeholder to dismiss as arbitrary than a number you chose because it sounded reasonable.
Why leaving it vague is a commercial problem, not a tidiness one
An untestable clause in a document somebody signs does not stay dormant. It sits there until
acceptance, and then it becomes the lever by which sign-off is withheld: the software does
everything in the specification, the stakeholder says it is not intuitive, and there is no
agreed way to settle whether they are right. Under a fixed-price contract that argument is
expensive; under an internal programme it is corrosive, because both sides can prove they are
correct. Vagueness in a requirement is not deferred detail, it is a deferred dispute, and the
deferral is what makes it costly.
That is also the case to make to a stakeholder who resents being pinned down. You are not asking
for precision to protect the delivery team from them. You are asking so that the day they say
"this is not what we needed", there is a shared standard that agrees with them.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).