Building the FUSE(P) User Requirements in an ICH Q8, Q9 and Q10 World

“The specification for equipment, facilities, utilities or systems 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 any GMP risks mitigated to an acceptable level. The URS should be a point of reference throughout the validation life cycle.” – Annex 15, Section 3.2, Eudralex Volume 4

User Requirement Specifications serve as a cornerstone of quality in pharmaceutical manufacturing. They are not merely bureaucratic documents but vital tools that ensure the safety, efficacy, and quality of pharmaceutical products.

Defining the Essentials

A well-crafted URS outlines the critical requirements for facilities, equipment, utilities, systems and processes in a regulated environment. It captures the fundamental aspects and scope of users’ needs, ensuring that all stakeholders have a clear understanding of what is expected from the final product or system.

Crafting Good User Requirements

Building Quality from the Ground Up

The phrase “essential elements of quality need to be built in at this stage” emphasizes the proactive approach to quality assurance. By incorporating quality considerations from the outset, manufacturers can:

Minimize the risk of errors and defects
Reduce the need for costly corrections later in the process
Ensure compliance with Good Manufacturing Practice (GMP) standards

Mitigating GMP Risks

Risk management is a crucial aspect of pharmaceutical manufacturing. The URS plays a vital role in identifying and addressing potential GMP risks early in the development process. By doing so, manufacturers can:

Implement appropriate control measures
Design systems with built-in safeguards
Ensure that the final product meets regulatory requirements

The URS as a Living Document

One of the key points in the regulations is that the URS should be “a point of reference throughout the validation life cycle.” This underscores the dynamic nature of the URS and its ongoing importance.

Continuous Reference

Throughout the development, implementation, and operation of a system or equipment, the URS serves as:

A benchmark for assessing progress
A guide for making decisions
A tool for resolving disputes or clarifying requirements

Adapting to Change

As projects evolve, the URS may need to be updated to reflect new insights, technological advancements, or changing regulatory requirements. This flexibility ensures that the final product remains aligned with user needs and regulatory expectations.

Practical Implications

Involve multidisciplinary teams in creating the URS, including representatives from quality assurance, engineering, production, and regulatory affairs.
Conduct thorough risk assessments to identify potential GMP risks and incorporate mitigation strategies into the URS.
Ensure clear, objectively stated requirements that are verifiable during testing and commissioning.
Align the URS with company objectives and strategies to ensure long-term relevance and support.
Implement robust version control and change management processes for the URS throughout the validation lifecycle.

Executing the Control Space from the Design Space

The User Requirements Specification (URS) is a mechanism for executing the control space, from the design space as outlined in ICH Q8. To understand that, let’s discuss the path from a Quality Target Product Profile (QTPP) to Critical Quality Attributes (CQAs) to Critical Process Parameters (CPPs) with Proven Acceptable Ranges (PARs), which is a crucial journey in pharmaceutical development using Quality by Design (QbD) principles. This systematic approach ensures that the final product meets the desired quality standards and user needs.

It is important to remember that this is usually a set of user requirements specifications, respecting the system boundaries.

From QTPP to CQAs

The journey begins with defining the Quality Target Product Profile (QTPP). The QTPP is a comprehensive summary of the quality characteristics that a drug product should possess to ensure its safety, efficacy, and overall quality. It serves as the foundation for product development and includes considerations such as:

Dosage strength
Delivery system
Dosage form
Container system
Purity
Stability
Sterility

Once the QTPP is established, the next step is to identify the Critical Quality Attributes (CQAs). CQAs are physical, chemical, biological, or microbiological properties that should be within appropriate limits to ensure the desired product quality. These attributes are derived from the QTPP and are critical to the safety and efficacy of the product.

From CQAs to CPPs

With the CQAs identified, the focus shifts to determining the Critical Process Parameters (CPPs). CPPs are process variables that have a direct impact on the CQAs. These parameters must be monitored and controlled to ensure that the product consistently meets the desired quality standards. Examples of CPPs include:

Temperature
pH
Cooling rate
Rotation speed

The relationship between CQAs and CPPs is established through risk assessment, experimentation, and data analysis. This step often involves Design of Experiments (DoE) to understand how changes in CPPs affect the CQAs. This is Process Characterization.

Establishing PARs

For each CPP, a Proven Acceptable Range (PAR) is determined. The PAR represents the operating range within which the CPP can vary while still ensuring that the CQAs meet the required specifications. PARs are established through rigorous testing and validation processes, often utilizing statistical tools and models.

Build the Requirements for the CPPs

The CPPs with PARs are process parameters that can affect critical quality attributes of the product and must be controlled within predetermined ranges. These are translated into user requirements. Many will specifically label these as Product User Requirements (PUR) to denote they are linked to the overall product capability. This helps to guide risk assessments and develop an overall verification approach.

Most of Us End Up on the Less than Happy Path

This approach is the happy path that aligns nicely with the FDA’s Process Validation Model.

This can quickly break down in the real world. Most of us go into CDMOs with already qualified equipment. We have platforms on which we’ve qualified our equipment, too. We don’t know the CPPs until just before PPQ.

This makes the user requirements even more important as living documents. Yes, we’ve qualified our equipment for these large ranges. Now that we have the CPPs, we update the user requirements for the Product User Requirements, perform an overall assessment of the gaps, and, with a risk-based approach, do additional verification activations either before or as part of Process Performance Qualification (PPQ).

System Boundary

A system boundary for equipment or utility refers to the demarcation points that define the extent of a system’s components and the scope of its operations. This boundary is crucial for managing, validating, maintaining, and securing the system.

For utilities, the last valve before the system being supplied can be used as the boundary, which can also serve as a Lock Out Tag Out (LOTO) point.
Physical connections like tri-clamp connections or flanges can define the boundary for packaged systems or skids.
For critical and non-critical systems, such as air or HVAC systems, filters can be the boundary between systems.

Defining system boundaries is crucial during the design of equipment and systems. It helps identify where the equipment starts and stops and where the breakpoints are situated. This ensures a smooth transition and handover during the commissioning process.

Early Definition: Define system boundaries as early as possible in the system’s development life cycle to reduce costs and ensure effective security controls are implemented from the start.
Stakeholder Involvement: Relevant stakeholders, such as system engineers, utility providers, and maintenance teams, should be involved in defining system boundaries to ensure alignment and a clear understanding of responsibilities.
Documentation and Traceability: To ensure consistency and traceability, document and maintain system boundaries in relevant diagrams (e.g., P&IDs, system architecture diagrams) and commissioning/qualification protocols.
Periodic Review: Regularly review and update system boundaries as the system evolves or the environment changes, using change management and configuration management processes to ensure consistency and completeness.
Enterprise-level Coordination: At an enterprise level, coordinate and align system boundaries across all major systems to identify gaps, overlaps, and seamless coverage of security responsibilities.

Applying Systems Thinking

Systems thinking and modeling techniques are essential for managing and improving complex systems. These approaches help understand the interconnected nature of systems, identify key variables, and make informed decisions to enhance performance, reliability, and sustainability. Here’s how these methodologies can be applied:

Holistic Approach

Systems thinking involves viewing the system as an integrated whole rather than isolated components. This approach acknowledges that the system has qualities that the sum of individual parts cannot explain.
When developing frameworks, models, and best practices for systems, consider the interactions between people, processes, technology, and the environment.

Key Elements:

Interconnectedness: Recognize that all parts of the utility system are interconnected. Changes in one part can affect other parts, sometimes in unexpected ways.
Feedback Loops: Identify feedback loops where outputs from one part of the system influence other parts. These can be reinforcing or balancing loops that affect system behavior over time.
Time Consideration: Understand that effects rarely ripple through a complex system instantaneously. Consider how changes will affect the system over time.

Crafting Good User Requirements

The User Requirements are a foundational document identifying the system’s product and process requirements. These product quality-related user requirements are based on product knowledge (CQAs), process knowledge (CPPs), regulatory requirements, and organization/site quality requirements. Writing a good user requirement for quality requirements involves several critical steps to ensure clarity, specificity, and effectiveness.

Understand the User Needs

Start by thoroughly understanding the user’s needs. This involves engaging with the end users or stakeholders to gather insights about their expectations, pain points, and the context in which the system will be used. This foundational step ensures that the requirements you develop are aligned with actual user needs and business goals.

Be Specific and Use Clear Language

Requirements should be specific and clearly stated to avoid ambiguity. Use simple, direct language and avoid technical jargon unless it is widely understood by all stakeholders. Define all terms and ensure that each requirement is phrased in a way that leaves no room for misinterpretation.

Make Requirements Measurable and Testable

Each requirement should be measurable and testable. This means stating requirements so one can verify whether they have been met. For example, instead of saying, “The system should load fast,” specify, “The system should load within 3 seconds when the number of simultaneous users is less than 10,000”.

Avoid Using Ambiguous Terms

Avoid terms open to interpretation, such as “user-friendly” or “fast.” If such terms are necessary, clearly define what they specifically mean in the context of your project. For instance, “user-friendly” is “the user can complete the desired task with no more than three clicks”.

Use the SMART Criteria

Employ the SMART criteria to ensure that each requirement is Specific, Measurable, Achievable, Relevant, and Time-bound. This approach helps set clear expectations and facilitates easier validation and verification of the requirements.

Make Requirements Concise but Comprehensive

While keeping each requirement concise and to the point is important, ensure all necessary details are included. Each requirement should be complete and provide enough detail for designers and developers to implement without making assumptions.

Prioritize Requirements

Not all requirements are equally important. Prioritize them based on their impact on the users and the business objectives. This helps manage the project scope and focuses on delivering maximum value.

It is good to categorize the user requirements here, such as:

Quality
Business
Health, Safety, and Environmental (HSE)

Review and Validate with Stakeholders

Review the requirements regularly with all stakeholders, including end-users, project managers, developers, and testers. This collaborative approach helps identify gaps or misunderstandings early in the project lifecycle.

Maintain a Living Document

Requirements might evolve as new information emerges or business needs change. Maintain your requirements document as a living document, regularly update it, and communicate changes to all stakeholders.

Use Models and Examples

Where applicable, use diagrams, mock-ups, or prototypes to complement the written requirements. Visual aids can help stakeholders better understand the requirements and provide feedback.

When writing user requirements for quality requirements, it’s crucial to avoid common pitfalls that can lead to misunderstandings, scope creep, and, ultimately, a product that does not meet the needs of the users or stakeholders. Here are some of the most common mistakes to avoid:

Ambiguity and Lack of Clarity

One of the most frequent errors in writing requirements is ambiguity. Requirements should be clear and concise, with no room for interpretation. Using vague terms like “user-friendly” or “fast” without specific definitions can lead to unmet expectations because different people may interpret these terms differently.

Incomplete Requirements

Another common issue is incomplete requirements that do not capture all necessary details or scenarios. This can result in features that do not fully address the users’ needs or require costly revisions later in development.

Overlooking Non-Functional Requirements

Focusing solely on what the system should do (functional requirements) without considering how it should perform (non-functional requirements), such as performance, security, and usability, can jeopardize the system’s effectiveness and user satisfaction.

Failure to Involve Stakeholders

Not involving all relevant stakeholders in the requirements gathering and validation process can lead to missing critical insights or requirements important to different user groups. This often results in a product that does not fully meet the needs of all its users.

Scope Creep

Without a clear definition of scope, projects can suffer from scope creep, where additional features and requirements are added without proper review, leading to delays and budget overruns. It’s important to have a well-defined project scope and a change management process in place.

Not Prioritizing Requirements

Not all requirements are equally important. Failing to prioritize requirements can misallocate resources and efforts on less critical features. Using prioritization techniques like MoSCoW (Must have, Should have, Could have, Won’t have this time) can help manage and focus efforts on what truly matters.

Lack of Validation and Verification

Skipping the validation (ensuring the product meets the intended use and needs of the stakeholders) and verification (ensuring the product meets the specified requirements) processes can lead to a final product not aligned with user needs and expectations.

Poor Documentation and Traceability

Inadequate documentation and lack of traceability can lead to confusion and errors during development. Maintaining detailed documentation and traceability from requirements through to implementation is crucial to ensure consistency and completeness.

Ignoring the Importance of Clear Communication

Effective communication is essential throughout the requirements process. Miscommunication can lead to incorrect or misunderstood requirements being developed. Regular, clear communication and documentation updates are necessary to keep all stakeholders aligned.

Not Considering the Testing of Requirements

Considering how requirements will be tested during the definition phase is important. This consideration helps ensure that requirements are testable and that the final product will meet them. Planning for testing early can also highlight any potential issues with clarity or feasibility of requirements.