The business insists on a requirement that nobody can test — "the system must be intuitive". What do you write instead?

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.