D
Dieter Goetz
Guest
False precision enters requirements surprisingly easily. A measured value, an estimate, and an acceptable tolerance are not the same thing.
A number in a requirement looks reassuring.
“The process shall complete within five minutes.”
Five minutes sounds precise. It can be tested. It can be put into a specification. It can be passed to engineering, procurement, software development or verification without anybody having to interpret words such as “quickly” or “within a reasonable time.”
But there is a question that should come before all of that:
Where did the five minutes come from?
Imagine that someone observed an existing process several times. It normally took about five minutes. During requirements work, that observation was recorded as “5 minutes.” Later, someone converted it into a formal requirement:
The process shall be completed within 5 minutes.
Something subtle has happened. The source information has not become more accurate, but the requirement has.
Observation is not tolerance.
“About five minutes” may describe an observation. It does not tell us whether 4:50 is good, whether 5:10 is unacceptable, or whether six minutes would make any practical difference at all.
Nor does it tell us whether the original process varied between four and seven minutes, whether five minutes was an average, whether somebody timed it once, or whether the person supplying the information simply remembered it as taking roughly five minutes.
Yet, once the value appears in a requirement as 5 minutes, its history tends to disappear.
Downstream, an engineer sees a limit. A tester sees a pass/fail boundary. A supplier may design against it. A project manager may regard exceeding it as non-compliance.
The notation has acquired more certainty than the evidence that produced it.
Precision can be added accidentally.
This problem is not restricted to time.
It appears whenever approximate knowledge is converted into apparently exact requirements:
- a user normally performs a task three times per shift;
- a component is usually replaced after two years;
- operators typically stand about one metre from a display;
- a report generally contains 200 records;
- a response normally arrives in two seconds.
Each may be useful evidence.
None automatically establishes a hard boundary.
Before turning the number into a requirement, we need to know what the number represents.
Is it an observation? An average? A design target? A maximum? A minimum? A contractual threshold? A safety boundary? Or simply the best estimate somebody could provide during an interview?
Those distinctions matter because the system will eventually be judged against what we write down—not against the forgotten conversation that produced it.
Keep the distinction visible
A useful requirements practice is therefore to preserve the chain between source evidence, interpretation, and requirement.
If the evidence says “approximately five minutes,” record that honestly. Then establish the acceptable tolerance separately.
Perhaps the real requirement is:
95% of transactions shall complete within six minutes.
Or perhaps anything below ten minutes is operationally irrelevant, and the five-minute figure should never have become a requirement at all.
The important point is not which number we finally choose. It is that we do not manufacture precision merely by changing the grammatical form of the statement.
A Quick Test
Whenever a requirement contains a conspicuously precise number, ask:
What evidence justifies this precision?
Then try moving the value slightly.’
If “5 minutes” became 5 minutes 10 seconds, would anybody care?
What about 5 minutes 30 seconds?
At what point does a stakeholder, user, process, or physical constraint actually notice the difference?
That boundary is often much closer to the real requirement than the original number.
A requirement can be perfectly measurable and still misrepresent what we know.
Precision in the specification should never exceed precision in the evidence without a reason.
This article develops one case from the RequiScribe Requirements Failure Field Guide, Season 01. The compact field specimen, #20 — “A measured value becomes a hard requirement”, preserves the diagnostic, response, and quick test in field-reference form.