1What a URS is.
EU GMP Annex 15 defines the URS as “the set of owner, user and engineering requirements necessary and sufficient to create a feasible design meeting the intended purpose of the system”. The specification for equipment, facilities, utilities or systems is defined in a URS, a functional specification or both. “The essential elements of quality need to be built in at this stage”, with GMP risks mitigated to an acceptable level, and the URS “should be a point of reference throughout the validation life cycle”.¹
For computerised systems, Annex 11 section 4.4 says user requirements specifications “should describe the required functions of the computerised system and be based on documented risk assessment and GMP impact”, and that user requirements “should be traceable throughout the life-cycle”. Section 3.3 asks regulated users to review documentation supplied with off-the-shelf products “to check that user requirements are fulfilled”.² WHO describes the URS for a computerised system as a formal document that defines the requirements for using it in its intended production environment, and allows user, functional and performance requirements to sit in one document.³
2Where the URS sits in qualification.
PIC/S PI 006-4, in force since 1 October 2026, starts its qualification principles here: requirements are established in the URS, and IQ, OQ and PQ “should be linked to the URS and Design Qualification (DQ)” to verify that the facility, equipment or system meets them. The URS is the first prequalification stage. Design qualification then verifies that the chosen design meets the URS, and factory and site acceptance tests check it before and after delivery.⁴ Annex 15 asks for URS requirements to be verified during DQ and, where applicable, for equipment to be confirmed against the URS at the vendor before installation.¹
For a computerised system, WHO links the functional specification to the URS: it describes the functions, performance and interfaces needed to satisfy the user requirements. Performance qualification and user acceptance testing then verify the intended system use defined in the URS.³ What are IQ, OQ and PQ? covers the stages and What is a requirements traceability matrix? covers the links.
3Who writes it and who owns it.
PIC/S says the URS should be developed with input from production, engineering, quality, technical services and others where appropriate. It also suggests recording which elements of the specification are essential and which are flexible. GMP risks found while writing it should be assessed, and the URS should be a controlled document, updated through document change control as understanding of the system grows.⁴
The regulated company owns the URS even when a supplier’s product sets much of the content. PIC/S PI 011-3 says the URS, although independent of the supplier, should be understood and agreed by both. For a configurable package, users and suppliers should determine the “degree of fit” between the requirements and the package, and then control any configuration, coding and testing that follows.⁵
4What a URS for a GxP system should cover.
WHO lists what a URS for a computerised system may include; Annex 11 sets the matching expectations.³²
| Area | What to specify | Annex 11 |
|---|---|---|
| Intended use | The intended uses, the critical data and the controls over its lifecycle | 4.4 |
| Data and data flow | Data entered, processed, reported, stored and retrieved, including master data, with data flows and process maps | 5, 6 |
| Interfaces | Interfaces with other systems, networks and the overall security | 5 |
| Access and attribution | Access only for authorised people, and data attributable to unique individuals, with no shared log-ins | 12 |
| Audit trail and time | The what, who, when and why of each step that creates, modifies or deletes GMP data, with synchronised, secure time stamps | 9 |
| Signatures | Electronic signatures | 14 |
| Records over time | Backup and restore, and archive and retrieval that keep all the metadata needed to reconstruct the activity | 7, 17 |
| Operation | Alarms and flags, capacity and volume, performance monitoring, orderly shutdown and recovery, business continuity | 16 |
5How to write requirements that can be tested.
PIC/S PI 011-3 says a properly documented URS should be “complete, realistic, definitive and testable”. Each requirement document should be reviewed, authorised and uniquely catalogued, and no requirement should conflict with another. Each requirement, especially those that meet GxP expectations, should be written so that compliance “is capable of being verified objectively by an authorised method, e.g. inspection, analysis or test”. The URS should distinguish mandatory regulatory requirements from optional features, and cover non-functional requirements such as maintainability and usability as well as function.⁵
WHO adds that the extent and detail should be commensurate with the operational risk and complexity of the system, and that user requirements “should be specific and phrased in a way that supports their testing or verification”.³ ISPE’s GAMP 5, Second Edition, has a section on establishing verifiable and objective user requirements and an appendix, D1, on specifying requirements.⁶
For example, “the system shall be secure” cannot be verified. “Only users with the QA reviewer role can approve a batch record, and the system refuses approval by any other role” can be tested directly.
6Keeping the URS current.
A URS is not finished at go-live. Annex 11 asks for user requirements to be traceable throughout the lifecycle,² and PIC/S PI 011-3 says the URS should be updated as systems are modified, enhanced or integrated.⁵ The 2025 draft revision of Annex 11 would require requirements to be kept up to date through the lifecycle and to remain the basis for qualification and validation. It would also let a vendor supply the requirements specification for a purchased or SaaS system, provided the regulated user reviews, approves and takes ownership of it.⁷
7How it runs in Seal.
In Seal, the URS, functional, design and configuration specifications can be kept as controlled records linked to the configuration, its risks and its tests, with the depth of specification following the complexity and risk of the intended use, as the validation and AI assurance guide explains.
The commissioning and qualification blueprint keeps user requirements atomic, each with its rationale, criticality, acceptance intent, source and owner, and derived functional and design requirements keep their parents, so any requirement can be traced forward to verification and any result back to the approved need. The validation management blueprint maps a controlled URS, linked to its tests, onto the Annex 15 stages.
References
- 1EudraLex Volume 4, Annex 15: Qualification and Validation, European Commission, in operation from 1 October 2015, sections 3.2, 3.3 and 3.5 and glossary. https:/
/ health. ec. europa. eu/ system/ files/ 2016- 11/ 2015- 10_ annex15_ 0. pdf (read 6 November 2026) - 2EudraLex Volume 4, Annex 11: Computerised Systems, European Commission, revision 1, in operation from 30 June 2011, sections 3.3 and 4.4. https:/
/ health. ec. europa. eu/ system/ files/ 2016- 11/ annex11_ 01- 2011_ en_ 0. pdf (read 6 November 2026) - 3WHO Technical Report Series No. 1019, Annex 3, Good manufacturing practices: guidelines on validation, Appendix 5, Validation of computerized systems, sections 2, 5 and 12, WHO, 2019. https:/
/ www. who. int/ docs/ default- source/ medicines/ norms- and- standards/ guidelines/ production/ trs1019- annex3- gmp- validation. pdf (read 6 November 2026) - 4PI 006-4, Recommendations on Qualification and Validation, PIC/S, 1 October 2026, sections 4.1.4 and 4.2. https:/
/ picscheme. org/ docview/ 11277 (read 6 November 2026) - 5PI 011-3, Good Practices for Computerised Systems in Regulated GxP Environments, PIC/S, 25 September 2007, section 9. https:/
/ picscheme. org/ docview/ 3444 (read 6 November 2026) - 6ISPE GAMP 5 Guide, Second Edition, table of contents, ISPE, 2022. https:/
/ ispe. org/ sites/ default/ files/ publications/ guidance- documents/ 2022- TOC/ ISPE- GAMP5- Ed2_ TOC. pdf (read 6 November 2026) - 7Annex 11: Computerised Systems, draft for consultation, European Commission and PIC/S, July 2025, section 6. https:/
/ picscheme. org/ docview/ 9714 (read 6 November 2026)
AQuestions and answers
What is the difference between a URS and a functional specification?
The URS says what the user needs the system to do. The functional specification describes the functions, performance and interfaces that meet those needs, and is linked back to them. WHO allows the two to be combined in one document, and Annex 15 lets the specification sit in a URS, a functional specification or both.
Do you need a URS for an off-the-shelf or SaaS system?
Yes. Annex 11 asks regulated users to check supplier documentation for commercial products against their user requirements, which needs requirements to check against. The draft revision of Annex 11 says the principle applies whether a system is built in house, bought off the shelf or provided as a service, and that a vendor’s specification can be used once the regulated user has reviewed, approved and taken ownership of it.
How detailed should a URS be?
Detailed enough to design, buy, configure and test against, and in proportion to the risk. WHO says the extent and detail should be commensurate with the operational risk and complexity of the system. Requirements behind GMP decisions and data integrity need to be explicit and testable.
Is there a standard URS template?
Annex 15 and PIC/S describe what a URS must do rather than prescribing a format. WHO’s list of topics, from data and data flows to access, audit trails, signatures, backup, archiving and continuity, makes a workable outline, with each requirement numbered, authorised and testable.
Who approves the URS?
The people the quality system names, including the quality unit. PIC/S expects all relevant personnel and the quality unit to approve the specifications and acceptance criteria used in qualification, and Annex 15 asks that qualification documents be approved and authorised by appropriate personnel.
Does the URS change after go-live?
Yes. It stays a controlled document, updated through change control when the system or its use changes, so later testing and periodic review check the system as it is. PIC/S and the draft revision of Annex 11 both expect requirements to be kept current through the lifecycle.