A user requirements specification (URS) says what your monitoring system must do, in terms you can test. Annex 11 expects one for a GMP computerised system, Annex 15 makes it the starting point of qualification, and it is the document your design qualification and PQ are checked against. It is easy to put off and easy to copy from a brochure. This guide explains what a URS is for, how it drives supplier selection, DQ and PQ, how to write requirements that can be verified, and the mistakes to avoid. There is a free template at the end.
What it is for
The reference point for the whole lifecycle
Annex 11 clause 4.4 (EU GMP; for GDP-only wholesalers, the benchmark behind GDP 3.3.1): "User Requirements Specifications should describe the required functions of the computerised system and be based on documented risk assessment and GMP impact. User requirements should be traceable throughout the life-cycle" (EU GMP Annex 11, 4.4).
Annex 15 puts it first in the qualification sequence. The specification "should be defined in a URS and/or a functional specification", the essential elements of quality "need to be built in at this stage", and "The URS should be a point of reference throughout the validation life cycle" (EU GMP Annex 15, 3.2). Its glossary defines a URS as the requirements "necessary and sufficient to create a feasible design meeting the intended purpose of the system".
For wholesalers, EU GDP 3.3.1 requires a computerised system to be shown, before use, to be "capable of achieving the desired results accurately, consistently and reproducibly". You cannot show that without first writing down what the desired results are.
How it is used
Supplier selection, DQ and PQ all start from it
Selecting the supplier. Send the URS with your enquiry and ask each supplier to say, requirement by requirement, how it is met: as standard, by configuration, by a procedure, or not at all. Annex 11 3.3 expects regulated users to review the documentation supplied with off-the-shelf products "to check that user requirements are fulfilled"; a URS is what you check against.
Design qualification. Annex 15 3.3: "The requirements of the user requirements specification should be verified during the design qualification." For a configurable cloud system, DQ verifies the configuration specification designed from your URS (alarm limits, delays, notification schedules, roles) against each requirement, item by item. Checking that the live system matches that specification is part of IQ.
IQ, OQ and PQ. Each requirement names the stage that verifies it. Installation and operational qualification cover the hardware at your site and the configured system's functions in your configuration, without retesting platform functions you accept on the supplier's evidence (Annex 15 3.8 to 3.12); performance qualification shows the system works in your operation, with your people, phones and procedures (3.13 and 3.14).
Change control and periodic review. When the system or your process changes, the URS is updated first, and the requalification follows from the requirements affected.
Writing requirements
What makes a requirement testable
A good requirement is atomic (one thing per requirement), unambiguous (one reading), measurable (a number, a list or a yes/no), testable (you can say how you would prove it) and traceable (it has a unique ID that never changes). Each one should carry its priority, its basis and how it will be verified.
Compare "The system shall have suitable alarms" with "An alarm not acknowledged within 15 minutes shall be escalated to the duty manager by voice call". The first cannot fail. The second can be tested in under half an hour, and its acceptance criterion writes itself.
| Weak | Testable |
|---|---|
| Accurate sensors | Each temperature sensor shall have a maximum permissible error of ±0.5 °C or better from +2 to +8 °C, shown on its calibration certificate |
| Frequent readings | The system shall store a reading from each sensor at least every 5 minutes |
| Alarms go to the right people | Notification schedules shall cover every hour of every day, including weekends and public holidays |
| Full audit trail | Every change to an alarm limit shall be recorded with user, date, time, old and new value, and a reason |
| Data is kept safe | Records shall be retained and retrievable for at least 5 years from creation |
What to cover
What a monitoring system URS should cover
The 2025 consultation draft of Annex 11 says requirements should include "operational, functional, data integrity, technical, interface, performance, availability, security, and regulatory requirements" (draft 6.2). It is a draft and not in force, but it is a fair list. For temperature monitoring, that means:
- What is monitored: each area or asset, its storage condition and its mapping study, so sensors sit at the mapped extremes (EU GDP 3.2.1).
- Measurement: range, accuracy, resolution, logging interval, and calibration traceable to national or international standards (EU GDP 3.3).
- Alarms: limits, delays, offline detection, who may change them, and local alarms where needed.
- Notification and escalation: channels, recipients, timings, out-of-hours cover and failed-delivery detection.
- Acknowledgement and investigation: who may acknowledge, comments, and the entries an excursion record needs.
- Data integrity: audit trail with who, what, when and why; readings that cannot be changed; ALCOA+ (Annex 11 clause 9; MHRA data integrity guidance 6.13).
- Access and security: personal accounts, roles, password rules and access records (Annex 11 clause 12).
- Records: reports, retention period, complete export in readable formats (Annex 11 8.1 and 17).
- Availability: outage handling, backup and restore testing, and your alternative monitoring (Annex 11 7.2 and 16).
- Supplier and service: validation evidence, release notification, support levels, a quality and technical agreement, and training.
The 2025 draft
What the July 2025 Annex 11 draft changes for a URS
The revised Annex 11 the European Commission and PIC/S consulted on from 7 July to 7 October 2025 is not in force and may change; the 2011 Annex 11 applies until the final version is published and comes into operation. In Great Britain, a revised Annex 11 applies only once the MHRA adopts it. Its section 6, "System Requirements", makes explicit what clause 4.4 implies: a regulated user should approve requirements that describe the functionality it relies on, whether the system is in-house, off the shelf or "provided as-a-service" (6.1); their detail should match risk, complexity and novelty and cover data integrity, availability, security and interfaces as well as functions (6.2); a vendor's specification can be used only once you have reviewed, owned and approved it (6.3); requirements are kept current (6.4) and traced to tests (6.5); and configuration options are described and the chosen configuration documented (6.6).
Elsewhere the draft adds detail a monitoring URS can anticipate now: alarm logs that can be searched, sorted and periodically reviewed (8.6, 8.7), independent audit trail review (12.6), recurrent access reviews (11.11), tested disaster recovery and restore (15.7, 16.6) and supplier oversight through SLAs and KPIs (7.3). Our template groups these as optional requirements, flagged with their draft clause. See the Annex 11 and Annex 22 drafts for the wider picture.
Common mistakes
Where URSs go wrong
These are the problems we see most often:
- Copying the supplier's brochure or specification. It describes the product, not your needs, and it will always pass. The draft Annex 11 accepts that a SaaS vendor may provide a requirements specification, but expects the regulated user to review it, take ownership and approve it for the implemented version (draft 6.3).
- Untestable wording: "user-friendly", "suitable", "real-time", "secure". Replace each with something you could fail.
- Several requirements in one line, so a partial pass cannot be recorded.
- No values. Limits, delays, intervals and escalation times left for the installer to decide.
- No link to the mapping. Sensor positions should trace to the mapped hot and cold spots.
- Forgetting what depends on you: out-of-hours notification, alternative monitoring, access reviews and training.
- Written once and never updated. Annex 11 4.4 wants requirements traceable throughout the lifecycle; the draft (6.4) says they should be kept current as the system changes.
Risk and priority
Base it on risk, and say what matters most
Annex 11 4.4 expects the URS to be based on a documented risk assessment. Use the principles of ICH Q9(R1): the higher the risk to product quality and data integrity, the more precise the requirement and the more rigorous its verification. Mark each requirement must (the system cannot be accepted without it) or should (a documented, risk-assessed gap can be accepted).
ISPE GAMP 5 (second edition, 2022), which many validation teams follow, describes a risk-based lifecycle in which requirements drive specification and verification in proportion to risk. It is a licensed industry guide, not regulation.
Help with yours
We will usually help you write it
We help customers write their URS as part of a monitoring or validation project, usually at no extra cost. We run a short workshop with your quality, operations and IT people, draft the requirements with values taken from your mapping, storage conditions and procedures, and propose which ones the supplier's validation evidence may cover, for you to confirm after your own assessment of the supplier. You review and approve it; it stays your document.
It then feeds straight into the rest of the work: the configuration we design, the design qualification against it and the PQ tests. See validating your monitoring system for how the parts fit, and quality and technical agreements for who is responsible for what.
In summary
The short version
- Annex 11 4.4 expects a URS based on risk and traceable through the lifecycle; Annex 15 3.2 makes it the reference point for qualification.
- Each requirement should be atomic, unambiguous, measurable, testable and traceable, with a priority, a basis and a verification method.
- Use it to choose the supplier, then verify it in DQ (Annex 15 3.3), IQ, OQ and PQ.
- Do not copy the supplier's specification: write what your sites need, with your own values.
- Keep it current under change control. The 2025 Annex 11 draft (section 6) shows where expectations are heading; it is not in force.
