Writing a user requirements specification for temperature-controlled equipment

Annex 15 places the URS at the start of the qualification lifecycle: the specification for equipment, facilities, utilities or systems should be defined in a URS and the essential elements of quality built in. A good URS reads like a set of acceptance criteria waiting for tests.

Example requirements for a cold room

• Maintain 2.0–8.0 °C at all product locations during routine use with doors opened up to N times per hour.
• Recover to range within X minutes after a door opening of Y seconds.
• Independent monitoring with calibrated sensors at locations to be defined by mapping; alarm within Z minutes of an excursion.
• Monitoring data retained for at least N years in original form with audit trail.
• Calibration certificates traceable to national standards for all controlling and monitoring sensors.

Each line becomes a test in IQ, OQ or PQ. A requirement that cannot be tested should be rewritten until it can.

Fill in the blanks, because the blanks are the requirement

The example requirements above contain N, X, Y and Z, and those placeholders are where most URS documents quietly fail. A requirement that says recover to range within X minutes is not a requirement; it is a reminder to write one. The numbers have to come from somewhere defensible — the product stability data, the real door traffic in the area, the alarm response time the on-call rota can actually deliver — and if nobody can source a number, that is a decision still to be made, not a detail to be filled in later by whoever executes the test.

Number them, and mean the numbers

Every requirement gets a unique identifier, because the identifier is what makes traceability possible. DQ checks the design against URS-01. An OQ test cites URS-05. The qualification report demonstrates each identifier is met. Without identifiers the traceability matrix has to quote requirements in full, drifts out of step with the URS the first time it is edited, and stops being checkable.

Prioritise as well. Splitting requirements into critical (product quality or data integrity depends on it) and desirable (operational convenience) lets the risk assessment allocate test depth, and stops a nice-to-have shelf light consuming the same protocol space as the alarm chain.

Who writes it

• The user — quality and operations together. Suppliers respond to a URS; they do not write it, and a URS assembled from a supplier's specification sheet is a purchase order wearing a different name.
• Operations contributes the reality: how often the door is really opened, how the room is really packed, who really answers the phone at 03:00.
• Quality contributes the constraints: label conditions, retention periods, Annex 11 expectations, what an inspector will ask.
• Both approve it before it goes out, because after the purchase order a gap is negotiated from a weaker position.

The test of a finished URS: hand it to someone who will later execute the qualification and ask them to write the acceptance criteria from it alone. Every question they have to ask is a requirement that is not yet written.