How to Write a GMP-Compliant User Requirement Specification (URS)

Typically developed in the early stages of a project, after validation, planning, and business case approval, but before procurement, the URS guides both the selection and qualification of systems and equipment. In GMP terms, it is essential for ensuring that the purchased asset is not only fit for purpose but also aligned with regulatory expectations.

Origins of URS in Pharmaceutical Industry

The concept of URS gained traction during the early phases of computer system validation, particularly with the adoption of the V-model for system development and qualification. In its early form, the V-model required extensive documentation, including Functional Specifications (FS) and Design Specifications (DS), for every system, regardless of complexity. 

This led to burdensome paperwork and the perception that validation was merely a bureaucratic obligation.

To streamline the process, the industry began categorizing URS documents based on the complexity and risk of the system:

• Complex systems require detailed URS documents, often only testable at the Performance Qualification (PQ) stage.
• Moderately complex systems had a general specification segmented into User, Functional, and Design requirements to support testing at various qualification phases (IQ/OQ/PQ).
• Simple systems, especially those with minimal GMP impact, were often implemented without a formal URS—though this approach is no longer acceptable under current regulatory expectations.

SEE ALSO: IQ, OQ, and PQ: Importance in GMP

Current Role of URS in Pharma

Today, the URS has evolved into more than just a checklist for testable requirements. It serves as a central reference point for GMP compliance, vendor accountability, and internal alignment. 

A well-written URS not only defines critical system attributes but also embeds high-level quality expectations that may not always be directly testable, such as data integrity, scalability, or ease of cleaning.

Regulatory and industry standards now emphasize the importance of a URS:

• EU GMP Annex 15 mandates that a URS be available for all new equipment, utilities, and systems.
• ASTM E2500-20 reinforces a science- and risk-based approach to qualification, placing the URS at the core of verification planning.

Despite this, some companies still underutilize URS documents, particularly for smaller installations. However, the trend is shifting: URS is increasingly recognized as the primary GMP specification, influencing procurement decisions, design reviews, FAT/SAT activities, and the entire qualification lifecycle.

Key Principles of a Robust URS Document

Creating an effective User Requirement Specification (URS) is not just about listing what a system should do; it’s about doing so in a way that ensures clarity, traceability, and regulatory compliance. A robust URS serves as the foundation for successful qualification, risk management, and vendor accountability. 

Below are the core principles that make a URS fit for purpose in a GMP-regulated environment:

1. Requirements Must Be Clear and Unambiguous

Each requirement should be stated in simple, direct language. Ambiguity leads to misinterpretation, which can cause project delays, cost overruns, or compliance failures. Avoid vague terms like “sufficient,” “adequate,” or “user-friendly” unless they are clearly defined and understood.

Example:

Don’t write: “The system must be fast.”
Instead, use: “The system must withstand a pressure of up to 1000 bars, to provide quick and reliable results.”

2. Requirements Should Be Testable and Verifiable

Every functional requirement should be written in a way that allows it to be verified during Factory Acceptance Testing (FAT), Site Acceptance Testing (SAT), or Qualification (IQ/OQ/PQ). If a requirement cannot be tested or measured, it must be justified as a general expectation or GMP principle.

3. Link Requirements to GMP and Risk

Each requirement should reflect critical process parameters, product quality attributes, or regulatory obligations. Use a risk-based approach to prioritize and document why specific requirements are critical (e.g., related to product sterility, data integrity, or contamination control).

4. Use a Structured and Consistent Format

Organize the URS into logical sections—such as functionality, environment, data management, alarms, access control, and compliance features. Use a numbering system or a requirement ID system for traceability throughout the design, testing, and qualification phases.

5. Align with Regulatory Guidelines and Industry Best Practices

The URS should be aligned with:

• EU GMP Annex 11 & 15
• GAMP 5 – A Risk-Based Approach to Compliant GxP Computerized Systems
• FDA 21 CFR Part 11, where applicable
• ASTM E2500-20

These references provide frameworks for documentation, lifecycle validation, and system categorization.

6. Distinguish Between Functional and Non-Functional Requirements

Functional requirements describe what the system must do (e.g., record temperature every 10 seconds). Non-functional requirements encompass qualities such as performance, scalability, usability, and security (e.g., the system must store data for 5 years and support 10 simultaneous users).

7. Include Data Integrity and Cybersecurity Expectations

In today’s GMP environment, it is essential to include requirements related to audit trails, role-based access control, electronic signatures, and backup/restore functions. These are often overlooked or underspecified, leading to regulatory findings.

8. Define What is In and Out of Scope

Clearly state any limitations, exclusions, or features not required. This helps avoid scope creep and enables vendors to align their deliverables.

9. Plan for Lifecycle and Change Management

Indicate if the system should be modular, scalable, or ready for future upgrades. Requirements that anticipate future needs show maturity in planning and reduce future revalidation costs.

Structure of an Effective URS Document

An effective URS is not just about what you write; it’s also about how you organize it. A well-structured URS enhances readability, supports qualification activities, and serves as a reference document throughout the system’s lifecycle. 

The following structure is widely accepted in GMP-compliant environments and aligns with the expectations of GAMP 5 and Annex 15.

1. Title Page and Document Control

• Title: Clear and specific to the system or equipment (e.g., “URS for LIMS System – QC Laboratory”)
• Document Number and Version
• Date of Issue
• Prepared By / Reviewed By / Approved By
• Change History: Table summarizing revisions and their rationale

2. Purpose and Scope

• Define the intent of the URS
• Describe the system or equipment being specified
• Specify what is included and excluded from this URS
• Indicate the intended GMP use (e.g., sterile manufacturing, QC testing)

3. System Overview and Intended Use

• Brief description of the system functionality
• High-level user needs and GMP justification
• Description of how the system supports compliance or product quality
• For computerized systems: mention if it handles GMP-critical data or electronic records

4. User Roles and Responsibilities

• Define user groups and their interactions with the system (e.g., operator, supervisor, QA reviewer)
• Helps establish access control and role-based permissions later in validation

5. Functional Requirements

Each requirement should:

• Be numbered or uniquely identified (e.g., FR-01, FR-02)
• Use clear, testable language (e.g., “The system must log every user login attempt with timestamp and username.”)
• Be categorized if needed (e.g., input handling, alarms, data storage, system response time)

For each requirement, optionally include:

• Risk level (High/Medium/Low)
• Justification
• Verification method (FAT, SAT, IQ, OQ, PQ)

6. Non-Functional Requirements

• Performance (e.g., system must process 1,000 samples/hour)
• Availability/Uptime (e.g., minimum 99% uptime excluding planned maintenance)
• Scalability (e.g., ability to expand from 2 to 10 workstations)
• Security (e.g., audit trail, password policy)
• Data storage and backup
• Environmental conditions (e.g., temperature, humidity tolerance for equipment)

7. GMP and Regulatory Requirements

• Annex 11 or 21 CFR Part 11 compliance (for electronic systems)
• Requirements for audit trails, electronic signatures, validation
• Reference to applicable GMP guidelines (Annex 15, GAMP 5, etc.)

8. Risk and Criticality Assessment

• Optional section to categorize each requirement by GMP criticality
• Can reference FMEA or risk assessment documents
• Helps in determining the verification scope during qualification

9. Acceptance Criteria

• Define how compliance will be verified (e.g., specific tests during FAT, SAT, IQ, OQ, or PQ)
• Can be summarized in a matrix linking the requirement ID to the verification activity

10. Reference Documents

• Validation Master Plan (VMP)
• Applicable SOPs
• GxP Guidelines (Annex 11, GAMP 5, ASTM E2500)
• Risk assessments or prior deviation reports

11. Appendices (If Needed)

• Glossary of terms and abbreviations
• Workflow diagrams or system schematics
• User interface mockups
• Traceability matrix (if not maintained separately)

SEE ALSO: Good Documentation Practices in Pharma Industry

Common Mistakes in URS Writing (and How to Avoid Them)

Even experienced teams can fall into common traps when drafting a User Requirement Specification (URS). These mistakes can lead to misinterpretation, qualification delays, non-compliance, or costly redesigns. Identifying and addressing these issues early is essential for maintaining project integrity and regulatory confidence.

Vague or Ambiguous Language

Mistake:
Using subjective terms like “user-friendly,” “fast,” or “sufficient.”

Why it’s a problem:
These terms are open to interpretation and cannot be tested or verified.

How to avoid it:
Use specific, measurable criteria (e.g., “System must generate reports within 2 minutes of user request”).

Including Design Solutions Instead of Requirements

Mistake:
Describing how the system should be built instead of what it needs to do.

Why it’s a problem:
It restricts vendor creativity and can lead to over-engineered or non-compliant solutions.

How to avoid it:
Focus on the outcome or capability. Leave implementation details for design specifications or vendor input.

Writing Requirements That Cannot Be Verified

Mistake:
Stating general expectations (e.g., “System must be robust”) without any means to test or confirm it.

Why it’s a problem:
It makes validation planning difficult and undermines traceability.

How to avoid it:
Ensure each requirement has an associated verification method: FAT, SAT, IQ, OQ, or PQ.

Neglecting Data Integrity and Security Requirements

Mistake:
Overlooking audit trail functionality, user access levels, backup policies, or compliance with 21 CFR Part 11/Annex 11.

Why it’s a problem:
Leads to findings during inspections and risks compromising GMP data.

How to avoid it:
Include dedicated sections in the URS for data integrity, electronic records, and security expectations.

Not Aligning the URS with Risk Management

Mistake:
Treating all requirements as equal, without identifying GMP-critical ones.

Why it’s a problem:
Wastes validation resources on low-risk features and underemphasizes high-impact ones.

How to avoid it:
Apply risk-based thinking—categorize requirements based on GMP impact and criticality.

Failing to Involve Key Stakeholders

Mistake:
Developing the URS in isolation (e.g., by QA or engineering only).

Why it’s a problem:
Misses operational needs, introduces gaps, or creates user resistance during implementation.

How to avoid it:
Involve end users, QA, engineering, IT, validation, and procurement during URS drafting and review.

Missing Change Control and Versioning

Mistake:
Not tracking changes to the URS or issuing updated versions without formal approval.

Why it’s a problem:
Creates confusion, misalignment, and audit gaps.

How to avoid it:
Apply document control practices: version numbers, approval signatures, and change logs.

Copy-Paste from Past Projects Without Customization

Mistake:
Reusing old URS templates or content without adapting them to the specific system or context.

Why it’s a problem:
Leads to irrelevant or contradictory requirements and a lack of clarity for vendors.

How to avoid it:
Tailor each URS to the project scope, intended use, and risk profile.

How URS Supports the V-Model

The V-model is a well-established validation framework used in the pharmaceutical industry to manage the lifecycle of systems and equipment. At its core, the V-model emphasizes the relationship between system requirements and verification. 

In this model, the User Requirement Specification (URS) forms the foundation on the left-hand side of the “V” and is directly linked to testing and qualification activities on the right-hand side.

V-Model Structure

The V-model is divided into two main sides:

• Left side: Specification and design stages
• Right side: Verification and testing stages

The bottom of the “V” represents the implementation or build stage. Each phase on the left is matched with a corresponding testing phase on the right.

URS and Its Link to PQ

The URS drives the Performance Qualification (PQ) phase, where the system is evaluated under real-world operating conditions. Requirements defined in the URS, especially those related to performance, usability, and GMP functionality, must be verifiable during PQ.

Example:
URS Requirement: “The system must store audit trails for at least 5 years.”
→ Verified during PQ by demonstrating data retention and retrieval in the production environment.

Importance of Traceability

To comply with GMP, traceability between the URS and qualification documents is essential. This ensures:

• All user needs are met
• No critical requirement is overlooked
• Audit readiness is maintained

Best practice: Use a traceability matrix to map each URS requirement to the corresponding test in FAT, SAT, IQ, OQ, or PQ.

Simplified V-Model for Low-Risk Systems

Not all systems require complex multi-document structures. For low-risk or non-critical systems, the URS can be combined with functional/design requirements, and verification may be simplified.

However, even in such cases:

• A documented URS is still required under Annex 15
• GMP expectations (data integrity, qualification, documentation) must still be met

URS as a Living Part of the V-Model

The V-model isn’t a one-time exercise. Changes to the system (e.g., upgrades, patches, procedural changes) may necessitate URS updates. Therefore, it should be:

• Maintained under change control
• Reviewed periodically
• Updated when business, technical, or regulatory needs evolve

URS and Risk Management

The development of a User Requirement Specification (URS) is not just a documentation exercise, it is a key opportunity to apply risk management principles early in the lifecycle of the equipment or system. 

By integrating a risk-based approach into the URS, pharmaceutical companies can proactively address potential compliance, quality, and operational issues before they arise.

Risk Assessment and Mitigation in URS

During the drafting of the URS, it is essential to identify and evaluate risks associated with the equipment or system, particularly those that may affect:

• Product quality (e.g., contamination, mix-ups)
• Patient safety (e.g., incorrect data processing)
• Data integrity (e.g., unauthorized access, missing audit trails)
• Regulatory compliance (e.g., failure to meet Annex 11/Part 11)
• Operational continuity (e.g., system downtime, maintenance complexity)

The URS should reflect mitigation strategies for these risks, either through specific design requirements (e.g., redundant power supply, automatic backup) or procedural controls (e.g., user access restrictions, system alarms).

Example:
Risk: Data loss due to power failure
URS Requirement: “The system shall include an uninterruptible power supply (UPS) with automatic data save functionality in the event of power interruption.”

Integration of Risk-Based Approach in URS Development

Modern GMP guidelines, including ICH Q9 and Annex 15, promote a risk-based approach to system design and validation. This approach should be embedded into the URS development process by:

• Assessing the criticality of each requirement based on its impact on product quality and patient safety
• Prioritizing requirements that address high-risk areas (e.g., data integrity, contamination control, cross-contamination prevention)
• Documenting the risk rationale where appropriate (e.g., “This requirement is critical due to potential impact on sterility assurance.”)

This not only helps focus validation and testing efforts on what matters most, but it also provides traceability and justification during inspections or audits.

Linking Risk to Verification Strategy

The risk assessment performed during URS drafting should directly influence the qualification strategy:

• High-risk requirements → Tested during PQ under worst-case conditions
• Medium-risk requirements → Verified during OQ or SAT
• Low-risk or informational items → May be verified by design review or vendor documentation

Tip: Maintain a risk classification column within your URS or traceability matrix to support transparent verification planning.

Regulatory and Guideline References

A well-prepared User Requirement Specification (URS) must do more than define system expectations, it must reflect the regulatory landscape governing pharmaceutical manufacturing. Several international guidelines and standards provide the foundation for URS development, particularly in areas such as validation, data integrity, and quality risk management.

Below is an overview of the most relevant regulatory references:

EU GMP Annex 15 – Qualification and Validation

• Requires a documented URS for all new equipment, facilities, utilities, and systems used in GMP manufacturing.
• Stipulates that the URS should be the starting point for qualification activities, especially Design Qualification (DQ).
• Emphasizes that the URS must define GMP-critical elements and link to risk assessments and verification strategies.

EU GMP Annex 11 – Computerised Systems

• For computerized systems, Annex 11 demands clear documentation of user requirements, including data integrity, security, and audit trails.
• The URS must define compliance with electronic records and electronic signature requirements, and these must be tested during qualification.

FDA 21 CFR Part 11

• Applies to systems that manage electronic records or signatures in FDA-regulated environments.
• While it doesn’t use the term “URS,” the requirements for validation, secure user access, audit trails, and system functionality are typically captured in the URS.
• For vendors supplying to the U.S. market, alignment with Part 11 is essential.

GAMP 5 Guide

• A widely accepted industry guideline that complements GMP regulations.
• Defines system categories and recommends URS content based on system complexity.
• Promotes the V-model lifecycle approach, in which the URS forms the top-level requirement linked to performance qualification.
• Strong emphasis on traceability, risk-based validation, and supplier involvement.

ASTM E2500-20 – Standard Guide for Specification, Design, and Verification

• Provides a science- and risk-based approach to qualification and system lifecycle.
• Promotes the concept of “Verification” over traditional IQ/OQ/PQ and supports lean documentation.
• Recommends that requirements be defined, justified, and traceable, starting from the URS.

ICH Q9 – Quality Risk Management

• Offers the overarching risk management framework for all GxP activities, including URS development.
• Encourages companies to assess and document the impact of each requirement based on patient safety and product quality.
• Supports alignment between URS content and downstream qualification/testing.

FAQ