There is a simple test for any requirement in a user requirement specification: describe the observation that would make it fail. If you cannot, the requirement is not a requirement. It is an aspiration, and it will be signed off, traced into a protocol, and passed by an engineer who had no criterion to apply.
The words that cause this are always the same handful.
The offenders
| Written | Why it cannot be tested | Testable form |
|---|---|---|
| "Adequate lighting shall be provided" | Adequate to whom, for what task | "Illuminance at the working plane of the fill zone shall be not less than 500 lux, measured at five defined positions" |
| "Suitable materials of construction" | Every material is suitable for something | "Product contact surfaces shall be 316L stainless steel with Ra ≤ 0.8 µm, with material certificates to EN 10204 3.1" |
| "The HMI shall be user-friendly" | No observation can falsify it | "A trained operator shall complete a format changeover from the HMI without reference to the manual, in not more than 15 minutes, demonstrated at FAT" |
| "Cleaning shall be easy" | Preference, not property | "The product path shall be cleanable in place, with all surfaces drainable at the installed orientation and no dead legs exceeding 3 pipe diameters" |
| "Adequate alarms shall be provided" | No list, no behaviour | "Each critical process parameter in Table 4 shall raise a time-stamped alarm on excursion, requiring acknowledgement by an authorised user before the batch may continue" |
| "The system shall be reliable" | No metric, no period | "The system shall achieve availability of not less than 95% over a continuous 30-day production period, excluding planned maintenance" |
| "Sufficient capacity for future expansion" | Unbounded | "The buffer vessel shall accommodate a batch size of up to 1,200 L without modification to the vessel or its services" |
The four-part shape
A testable requirement carries four elements. Miss one and the protocol writer has to invent it.
REQ-ENV-012 The isolator [subject] shall maintain [action] a positive pressure of
not less than 20 Pa relative to the surrounding room [criterion]
throughout the filling operation including all planned interventions
[condition].
Verification: IQ/OQ pressure decay and continuous monitoring record.
Rules that survive review
- One requirement, one sentence, one criterion. A requirement joined by "and" becomes two lines in the traceability matrix and two arguments at qualification.
- "Shall" is a requirement. "Should" is not. If a should-statement matters, promote it. If it does not, delete it — a document with fifty shoulds trains reviewers to skim.
- Numbers carry units, a tolerance and a measurement method. "20 Pa" is better than "positive pressure"; "20 Pa measured at the transfer port, ±2 Pa" is better still.
- Name the verification stage. Design review, FAT, SAT, IQ, OQ or PQ. If no stage can verify it, the requirement cannot be met — that is a finding at URS review, not at PQ.
- Do not specify the solution. "The vessel shall be agitated by a magnetic bottom-mounted impeller" removes the supplier's ability to offer something better. Specify the mixing outcome and the constraints on it.
- Avoid negative requirements. "Shall not leak" cannot be demonstrated exhaustively; "shall hold 2 bar for 30 minutes with pressure drop ≤ 0.05 bar" can.
Why it pays
Vague requirements do not stay vague. They are resolved eventually — by the supplier at design stage, by an engineer during OQ, or by an auditor two years later, each with a different interpretation and none of them recorded. Deciding the criterion while the document is still a draft costs an hour. Deciding it during qualification costs a deviation, and deciding it during an inspection costs a commitment.
Take any URS you have to hand, search it for adequate, suitable, appropriate, as required, user-friendly and sufficient, and count the hits. Each one is a decision that has not been made yet.