Take any requirements document from a real aerospace programme, pick twenty requirements at random, and ask of each one: what is the test, and what result would fail it. On most programmes a third of them have no answer. They still passed review.
What an untestable requirement looks like
They are rarely absurd. They read perfectly well:
The system shall be robust to sensor degradation. Which sensor, degraded how far, and what does the system do at the point where robustness ends? The aircraft shall have adequate control authority in gusts. Adequate for what manoeuvre, at which mass and centre of gravity, in what gust model? The ground station shall be easy to operate. Measured by whom.
Each one names something real. None of them can be closed. An engineer asked to verify the first will invent a definition, test against the definition they invented, and record a pass. The requirement has now been satisfied by a criterion nobody agreed to, and the record does not say so.
Why they survive review
Requirements reviews mostly check whether a requirement is sensible, not whether it is falsifiable. Sensible is easy to agree with, so the review moves on. There is also a social cost to challenging a requirement that everyone understands the intent of: the objection sounds pedantic, and the person raising it looks like they are slowing the programme down.
The cost of not raising it arrives later, and lands on someone else. Verification planning is where the bill comes due, typically nine to eighteen months after the document was baselined, when a test engineer discovers that a quarter of the set cannot be planned against and the schedule already assumed it could.
The one question
Every requirement should carry, in the same breath, the method by which it will be verified and the threshold that separates pass from fail. Not the full test procedure. Just enough that two engineers reading it would design the same test.
Applied honestly this is uncomfortable, because it forces decisions early that programmes prefer to defer. "Robust to sensor degradation" becomes a table: which sensors, what degradation modes, what the required behaviour is in each. That table is an argument. Somebody has to own it. That is precisely why writing it down at requirements time is worth more than discovering the disagreement during flight test.
Verification method is a design input
The second effect is more useful than the first. Deciding how something will be verified frequently changes what gets built.
A requirement that can only be closed by flight test is expensive, late, and carries programme risk that cannot be retired early. The same intent, restated so it can be closed by analysis backed with a bench test, retires the risk eighteen months sooner. A requirement written so it can be closed in simulation against a scenario library can be re-verified on every software change for free.
Teams that decide verification method at requirements time end up with different architectures to teams that decide it at verification time. Usually better ones, because observability had to be designed in rather than added afterwards.
Traceability is not the same thing
Programmes often answer this concern by pointing at a traceability matrix. Every requirement traces to a verification activity, and the matrix is complete and green.
A matrix records that a link exists. It does not record whether the activity on the far end is capable of failing. "Verified by analysis" against an analysis whose acceptance criterion was written after the results came in is a green cell in a matrix and a hole in the programme. The matrix is necessary. It is not the check.
What to do with the ones already written
Programmes mid-flight cannot rewrite a baselined set, and should not try. What works is triage. Sort the set by consequence of being wrong, take the top ten per cent, and apply the question only to those. Most of them will be fine. The two or three that are not will be the ones carrying real risk, because vague requirements cluster around the parts of the system nobody fully understood at the time.
That clustering is the useful signal. A requirement nobody could make testable is usually pointing at a design decision nobody had made yet.