How to write a URS that survives an audit

Most URS documents are written to be approved. The good ones are written to be tested against — and, two years later, to be defended in front of someone who has never seen the system, holding a printout of your OQ and asking why test 14 exists.

That second reading is the one that matters. An auditor does not read a URS to learn what the system does. They read it to check that your qualification proved something you had actually asked for. If a requirement cannot be tested, the test that "covers" it proves nothing. If a test has no requirement behind it, nobody can say why it was run or what passing it means.

This guide is about writing the document for that reader.

What the guideline asks for — and what it leaves to you

EU GMP Annex 11 §4.4 is short: user requirements should describe the required functions of the system, be based on a documented risk assessment and GMP impact, and be traceable throughout the life cycle. GAMP 5 (2nd edition) builds the whole specification-and-verification model on the URS as the top of the V. ASTM E2500 and the ISPE Baseline Guide on C&Q say the same thing in engineering language: user requirements define the critical aspects that verification must demonstrate.

None of them tell you how to phrase a requirement, how many you need, or what to leave out. That is the part that gets people into trouble.

The seven ways a URS fails an audit

Every one of these has been a finding somewhere. Most URS documents carry at least three.

1. Requirements that cannot be tested. "The system shall be user-friendly." "The interface shall be intuitive." "Data shall be secure." There is no test whose outcome would be fail here, so any test claiming to cover them is decoration. Rewrite as something observable: "A trained operator shall be able to start a batch from the home screen in no more than three actions."

2. Compound requirements. "The system shall record the operator, timestamp and reason for every change and prevent deletion of records." That is three requirements — audit trail content, audit trail coverage, and record retention — sharing one ID. When one of them fails in OQ, the whole line fails, and when you trace it you cannot say which part was verified by which test. One requirement, one ID, one thing.

3. No identifiers, or identifiers that move. A requirement without a stable ID cannot be traced, so it does not exist for verification purposes. Numbering by position in the document ("see requirement 4.2.3") breaks the moment someone inserts a section. Use IDs that never change once assigned, and never reuse a retired one.

4. The vendor's specification, retyped. When a URS is written by pasting the supplier's functional specification and changing "the product" to "the system", it becomes a description of what you bought instead of what you need. Two consequences: you will "require" features nobody will ever use — and then have to test them — and the requirement that actually protects the patient ("the temperature record shall be complete for the whole hold time") is missing, because the brochure never mentioned it.

5. No GMP impact, no risk basis. Annex 11 §4.4 ties the URS to a documented risk assessment. In practice that means every requirement should carry an impact classification (direct / indirect / none, or your site's equivalent) and a criticality. Without it, every requirement is tested to the same depth — which either bankrupts the schedule or, more often, means the critical ones are tested as lightly as the trivial ones.

6. Approved by the wrong people, or not at all. A URS signed only by the engineer who wrote it has not been reviewed. The minimum that holds up: the process owner (the person who will use the system and is accountable for the process), Quality, and the engineering or IT function responsible for delivery. Dated signatures, on a controlled version.

7. Frozen at approval and never touched again. Systems change during a project. If the URS approved in March does not reflect the scope agreed in June, either the qualification tests something that no longer exists or the change happened without control. Both are findings. Requirements are living records under change control, not a milestone document.

The anatomy of a requirement that holds up

A requirement that survives has a fixed set of parts. Whether you keep them in columns of a table or fields of a system, all of them should be there.

Part	What it is	Example
ID	Unique, permanent, never reused	URS-014
Statement	One testable shall sentence	The system shall lock a batch record against edits once it has been electronically signed by QA.
Acceptance criterion	How a tester decides pass or fail	After QA signature, all edit controls are disabled and any attempted edit via the interface is rejected with a message; the audit trail shows the attempt.
Type	Functional, performance, interface, data, security, regulatory…	Regulatory (21 CFR Part 11)
GMP impact	The risk basis Annex 11 asks for	Direct
Priority	Must / should / could — decides what is negotiable	Must
Source / rationale	Why it exists: a regulation, a process step, a risk	21 CFR 11.10(e); risk assessment RA-07
Status	Draft, approved, superseded, retired — with history	Approved v2.0

Two of these carry most of the weight and are most often missing.

The acceptance criterion is what turns a sentence into a test. Write it as the tester will read it: what they do, what they should see. If you cannot write it, the requirement is not ready.

The source is what defends the requirement when someone asks "why is this here?" — and, more importantly, what tells you it can be retired when the process changes.

How much is enough

A URS with 600 requirements is not a thorough URS; it is a document nobody reads and a qualification nobody finishes. Depth should follow risk:

• Critical aspects — the functions that protect product quality, patient safety or data integrity — get precise requirements with explicit acceptance criteria, and they get tested directly.
• Standard functions of a configured product (GAMP category 4) that carry no GMP impact can be covered by a small number of requirements and verified through supplier documentation and configuration checks. You do not need to re-prove that a commercial database can store a row.
• Anything you will not test, do not write. A requirement without a planned verification is a promise you are documenting your failure to keep.

A practical test: read each requirement and ask what happens to the product or the patient if this is wrong? If the honest answer is "nothing", it is a design preference, not a requirement. Keep it somewhere else.

Traceability starts on day one, not at the end

The traceability matrix is often produced at the end of a project, by someone matching test scripts to requirements after the fact. Those matrices are where the compound requirements, the untestable ones and the orphaned tests come to light — too late to fix cheaply.

Build the links as you go. Each requirement should point forward to the functional or design specification element that implements it, and each of those to the test that verifies it. When a link is missing while the FS is being written, it costs a sentence to fix. When it is missing in the RTM the night before the audit, it costs an audit finding.

The matrix is then not a deliverable you assemble; it is a view of links that already exist.

The review that counts

Before it goes for approval, walk the document with these questions:

1. Can every requirement fail a test? If a requirement can only pass, rewrite it.
2. Does every requirement say exactly one thing?
3. Does every requirement have an ID that will not change and a criticality that was actually assessed, not defaulted?
4. Is there a requirement for every critical aspect the risk assessment identified — and no requirement the risk assessment cannot justify?
5. Do the process owner and Quality recognise their process in it, in their words, not the supplier's?
6. Is there a change-control route for after approval, and does everyone know it?

If the answer to all six is yes, the qualification that follows will be shorter, and the audit that follows that will be quiet.

A short checklist

• One requirement, one ID, one shall.
• An acceptance criterion a tester can apply without asking you.
• GMP impact and priority on every line, from a risk assessment you can show.
• Source or rationale recorded, so requirements can be defended and retired.
• Written in the user's language, not copied from the supplier's.
• Approved by process owner, Quality and delivery — dated, versioned.
• Under change control from the day after approval.
• Linked forward to specification and test as you go, not reconstructed at the end.