Writing URS that hold up in an audit

At the start of every facility, every system and every qualification stands a document that is often underestimated: the User Requirements Specification, or URS for short. It describes what the system must be able to do. That sounds simple, yet it decides the success of the entire project. Because it is the URS that is later tested against, and whatever is missing or left vague here comes back to bite in every subsequent phase.

Why the URS carries everything

In the qualification model of EU GMP Annex 15, the Design Qualification checks whether the planned design meets the URS. The Performance Qualification finally demonstrates that the system, in operation, complies with exactly those requirements. The URS is thus both the starting point and the yardstick. A qualification can never be better than the requirement it tests against.

A good URS is half the qualification; a poor one is its most common source of error.

Characteristics of a robust requirement

A URS that holds up in an audit follows a few simple but unforgiving principles:

• Testable: every requirement must be verifiable objectively. What cannot be measured is not a requirement but a wish.
• Unambiguous: wordings such as adequate, fast or user-friendly have no place in a URS.
• Atomic: one requirement per statement, so that it can be tested and traced individually.
• Traceable: every requirement is given a unique identifier.

What belongs in a URS

A complete URS covers more than function alone. This includes functional requirements, requirements for data and data integrity, interfaces to other systems, operational and environmental conditions, performance and capacity requirements as well as regulatory requirements. Just as important is what does not belong in it: a URS describes the what, not the how. Anyone who already prescribes the solution unnecessarily constrains suppliers and takes on responsibility that would be better left with the specialist supplier.

Making GMP relevance visible

Not every requirement is equally critical. A good URS marks which requirements are relevant to GMP and to data integrity. This prioritisation later governs the depth of testing: it makes it possible to direct qualification effort, on a risk basis, to where it matters, instead of unnecessarily inflating non-critical items. GAMP 5 makes this link between requirement, risk and test the core of the approach.

Traceability closes the loop

The tool that makes the URS truly sound in an audit is the traceability matrix (Requirements Traceability Matrix). It links each requirement to its specification, its risk assessment and the test case that demonstrates it. An auditor who picks out a requirement can thus follow, without gaps, how it was implemented and verified. Gaps in this matrix are one of the fastest routes to a finding.

Who writes the URS

A robust URS emerges where operations, quality and engineering jointly formulate what is needed. It is expressly not a supplier document: if the vendor writes the requirements for its own product, the independent perspective is missing, and the later Design Qualification tests against a yardstick that the supplier itself has set.

What counts in the end

Time that goes into a clean URS is the best-invested time of a qualification project. It prevents misunderstandings with suppliers, shortens the test phases and makes the result audit-proof. Vispact supports the creation and sharpening of requirement specifications that are designed for the later qualification from the very first sentence.