The Relationship Between URS (User Requirements Specification) and PQ (Performance Qualification)

Introduction

In validation practices, understanding the proper relationship between the URS (User Requirements Specification) and PQ (Performance Qualification) is critically important for achieving effective system verification and regulatory compliance. This article provides a detailed explanation of how these two essential documents work together and the roles they play throughout the validation process.

The Essence of URS: Expressing User Requirements

When creating a URS, it is recommended to express the genuine needs and expectations of users—their “heartfelt desires”—without being overly constrained by the rigid conventions of CSV (Computerized System Validation). This represents a fundamental principle for clarifying the value that a system should ultimately deliver.

The role of system personnel is to technically interpret these user requirements and implement them as reliable systems. In this process, they bear the important responsibility of bridging user business requirements with technical system specifications.

Definition and Purpose of Validation

The concept of validation is defined by internationally harmonized regulatory guidance. According to definitions from organizations such as ICH (International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use), validation is “establishing documented evidence which provides a high degree of assurance that a specific process (or system) will consistently produce a product (or result) meeting its predetermined specifications and quality attributes, including integrity, accuracy, reliability, and intended performance.”

As evident from this definition, one of the fundamental goals of validation is to demonstrate that the system meets user requirements—that is, the requirements documented in the URS.

In recent years, the industry has been transitioning from the traditional CSV approach to a more agile and efficient CSA (Computer System Assurance) approach. This streamlines overly conservative and time-consuming verification processes, adopting a risk-based approach with minimal burden. However, the essential principle remains unchanged: “the system must meet user requirements.”

The Purpose of PQ: Verifying Business Performance Capability

A critical aspect here is the correct interpretation of the term “Performance.” In the context of validation, “Performance” does not simply refer to computer processing speed or hardware technical capabilities. Rather, it signifies the system’s ability to appropriately execute the business functions required by users in an actual operational environment.

The purpose of PQ (Performance Qualification) is precisely to verify this point. Specifically, it demonstrates through concrete test scenarios whether the system can deliver the business performance capabilities (Performance) required by users in an actual operational environment. PQ is the stage where we confirm that the system, integrated into actual business processes, can consistently produce expected outcomes.

The Relationship Between URS and PQ: The Importance of Traceability

The URS serves as the foundational document for PQ. To properly manage this relationship, each user requirement documented in the URS must be clearly described in a bulleted format, with each requirement assigned a unique identification number (ID).

This requirements management methodology serves the following important purposes:

First, by making each requirement individually trackable, it ensures traceability from URS through to PQ. A traceability matrix (requirements traceability matrix) is a document that clearly indicates which PQ tests verify each URS requirement. Without this document, it is impossible to objectively prove that all requirements have been appropriately tested.

Second, requirement numbering enables precise identification of impact scope when specification changes or functional additions occur throughout the system lifecycle, facilitating appropriate re-verification.

Third, it establishes an evidence system that can clearly explain to regulatory authorities during inspections and audits that the system meets user requirements.

Position in GAMP 5 and the V-Model

The GAMP 5 (Good Automated Manufacturing Practice, Second Edition: 2022) guidance, widely adopted in the pharmaceutical industry, illustrates the verification process from URS to PQ in what is known as the V-Model. In this model, requirement specifications are detailed on the left side of the V (URS → Functional Specification → Design Specification), the system is built at the bottom, and verification is performed in stages on the right side (IQ: Installation Qualification → OQ: Operational Qualification → PQ: Performance Qualification).

Within this framework, the URS is positioned at the apex of the V-Model and serves as the starting point for all subsequent activities. PQ is positioned at the upper right of the V-Model and plays the role of finally confirming that the requirements defined in the URS are met in the actual operational environment.

Latest Regulatory Trends and Industry Standards

Introduction of ICH E6 (R3)

ICH E6 (R3), published on January 6, 2025, establishes a new chapter on computerized systems in clinical trials, focusing on system validation, data integrity, and risk-based system management. This guidance is scheduled for adoption by the EMA (European Medicines Agency) from July 23, 2025.

Emphasis on Data Integrity

Recent regulatory trends emphasize ensuring data integrity based on ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available). In URS documentation as well, there is a requirement to clearly define system requirements that satisfy these elements.

Adoption of Risk-Based Approaches

Regulations such as those from the FDA (U.S. Food and Drug Administration) and EU GMP Annex 11 recommend determining the depth and scope of verification based on risk assessment, rather than providing equivalent verification for all system functions. The mainstream approach now assigns risk levels to each URS requirement and implements more rigorous PQ verification for high-risk requirements.

Practical Recommendations

To effectively create a URS and ensure appropriate traceability to PQ, we present the following practical recommendations:

Method of Describing Requirements

Each requirement must be described in a clear and verifiable format. For example, rather than an ambiguous requirement such as “The system must be user-friendly,” write specific and measurable requirements such as “The system must log every user login attempt with timestamp and username.”

Categorization of Requirements

It is useful to categorize requirements into functional requirements, performance requirements, regulatory requirements, security requirements, and other categories. This enables systematic planning and execution of PQ testing.

Maintenance of the Traceability Matrix

The traceability matrix is a “living document” maintained throughout the system’s lifecycle. When system upgrades or change management occur, this document must be updated to identify affected PQ tests and re-execute them as necessary.

Stakeholder Involvement

Creating a URS requires the participation of diverse stakeholders, including end users, quality assurance departments, system personnel, and regulatory personnel. This enables comprehensive requirements definition that considers both technical feasibility and regulatory compliance.

Conclusion

The relationship between URS and PQ forms the foundation of the validation process. The URS expresses genuine user needs, and PQ verifies that those needs are met in the actual business environment. To properly link these two elements, clear identification of requirements, assignment of unique IDs, and systematic management through a traceability matrix are essential.

While considering latest regulatory trends such as risk-based approaches, emphasis on data integrity, and the transition to CSA, adhering to these fundamental principles enables efficient and highly compliant validation. This represents a fundamental responsibility in the pharmaceutical industry for ensuring patient safety, product quality, and data reliability.

Table: Comparison of Traditional CSV and Modern CSA Approaches

Aspect	Traditional CSV	Modern CSA (Computer System Assurance)
Documentation Burden	Extensive documentation for all systems	Streamlined, risk-proportionate documentation
Testing Approach	Comprehensive testing of all functions	Risk-based testing focused on critical functions
Vendor Documentation	Often duplicated by user	Leveraged when appropriate with verification
Timeline	Lengthy validation cycles	Accelerated, agile approach
Resource Requirements	High resource investment	Optimized resource allocation
Regulatory Alignment	Traditional interpretation	Aligned with FDA’s “least burdensome approach”
Focus	Process compliance	Patient safety and data integrity outcomes

Key Elements for Effective URS-to-PQ Traceability

The following elements should be incorporated into an effective traceability system:

Unique Requirement Identification: Each requirement in the URS should have a unique identifier (e.g., URS-001, URS-002) that can be traced throughout the validation lifecycle.

Requirement Categorization: Requirements should be categorized by type (functional, performance, regulatory, security) and risk level (critical, major, minor) to guide appropriate testing strategies.

Traceability Matrix Structure: The matrix should link each URS requirement to corresponding specifications (Functional Specification, Design Specification), test protocols (IQ, OQ, PQ), and test results, creating a complete chain of evidence.

Version Control: All documents in the traceability chain must be version-controlled to maintain consistency and enable effective change management throughout the system lifecycle.

Risk Assessment Integration: Each requirement should have an associated risk assessment that guides the depth and rigor of verification activities, particularly during PQ.

Cross-Functional Review: The traceability matrix should be reviewed and approved by all relevant stakeholders—including users, quality assurance, IT, and regulatory affairs—to ensure completeness and accuracy.

By implementing these elements, organizations can demonstrate clear, auditable evidence that all user requirements have been properly implemented and verified, fulfilling both the spirit and letter of validation regulations while optimizing resource utilization through risk-based approaches.