The User Requirements Specification (URS) is the foundational document in any computerised system validation project. It defines what the system must do - from the user's perspective - before any system is selected, designed, or implemented. A well-written URS makes everything downstream easier: supplier selection, risk assessment, functional testing, and inspection defence all become more straightforward when requirements are clearly stated upfront.
Despite its importance, the URS is one of the most frequently poorly executed documents in pharmaceutical CSV. This guide explains what a URS must contain, how to distinguish GxP from non-GxP requirements, and the most common mistakes to avoid.
What Is a URS in Pharmaceutical CSV?
A URS is a formal document that describes what a system must do - the user-defined requirements that the system must meet. Critically, the URS describes what the system must do, not how it does it. The "how" belongs in the Functional Requirements Specification (FRS) or design documentation, which is the supplier's or developer's responsibility.
The URS forms the basis for:
- Supplier evaluation and selection
- Risk assessment (identifying which requirements are GxP-critical)
- Test case development in IQ, OQ, and PQ
- Validation scope definition
- Change control (changes to the system are assessed against URS requirements)
GAMP 5 and EU GMP Annex 11 both require that user requirements be formally documented and that the validation programme traces test results back to specific requirements. Without a URS, this traceability cannot be established.
URS Structure and Content
A pharmaceutical URS typically contains the following sections:
- Introduction and scope - what system this URS covers, the system's intended purpose, and the facilities or processes where it will be used
- Regulatory context - which GMP regulations apply (FDA 21 CFR Part 11, EU GMP Annex 11, etc.) and the system's GxP impact classification
- Functional requirements - what the system must do (data entry, calculation, reporting, alarm management, workflow control)
- Data management requirements - data storage, retrieval, backup, retention, and archiving
- Data integrity and security requirements - audit trail, access control, electronic signatures, and user authentication
- System administration requirements - user management, system configuration control, privileged access management
- Interface requirements - integration with other systems (LIMS, ERP, instruments)
- Performance and availability requirements - uptime, response time, concurrent users
- Infrastructure requirements - hardware, operating system, database, network, and hosting environment
- Vendor and support requirements - vendor qualification, support SLAs, documentation availability, software development lifecycle evidence
- Compliance requirements - specific regulatory requirements the system must demonstrate compliance with
GxP vs Non-GxP Requirements
One of the most important tasks in URS development is classifying each requirement as GxP-critical or non-GxP. GxP-critical requirements are those where a failure could directly impact product quality, patient safety, or the integrity of GxP records. Non-GxP requirements might be important for business function, but their failure would not create a regulatory compliance issue.
Examples of GxP-critical requirements:
- The system shall create an audit trail of all entries, modifications, and deletions of GxP data, including the identity of the user, date/time, and reason for change
- The system shall prevent unauthorised access to GxP data through user authentication and role-based access controls
- The system shall electronically sign all batch release records in compliance with 21 CFR Part 11
- The system shall generate Certificate of Analysis reports that include all required data fields per the product specification
Examples of non-GxP requirements (business requirements):
- The system shall support English and Arabic language interfaces
- The system shall allow users to export data to PDF format for internal reporting
- The system shall load the dashboard within 3 seconds of login
The validation programme focuses testing effort on GxP-critical requirements. Non-GxP requirements may be tested for acceptance but do not require the same level of documented evidence and traceability.
How to Write Individual Requirements
Each requirement in a URS should be:
- Testable - you must be able to objectively verify that the requirement is met. Vague requirements like "the system shall be user-friendly" cannot be tested. "The system shall complete a data entry workflow in fewer than 5 user interactions" is testable.
- Uniquely identified - each requirement gets a unique reference number (e.g. URS-001, URS-002) so it can be traced through the validation lifecycle
- Single-subject - one requirement per statement. Compound requirements ("the system shall do X and Y") create ambiguity in testing
- Unambiguous - the requirement should have one clear interpretation. Avoid "the system shall quickly process data" - define "quickly"
- Risk-classified - each requirement is tagged as GxP-critical or non-GxP to drive test scope
Free URS Template for Computerised Systems
Download our GxP-compliant URS template with pre-populated sections, example requirements, and GxP classification guidance for pharmaceutical CSV projects.
Download Free Checklist →