Part 3

3.1 Introduction

The User Requirement Specification (URS) is one of the most important documents in pharmaceutical qualification.

Every qualification activity ultimately traces back to the URS.

A poor URS results in:

• weak qualification
• incomplete testing
• design changes
• project delays
• regulatory observations
• increased lifecycle cost

A well-written URS produces:

• better design
• better supplier proposals
• easier FAT
• easier IQ/OQ/PQ
• improved traceability
• better inspection readiness

The URS should answer one fundamental question:

What must the system do to satisfy the intended GMP use?

It should not prescribe the technical solution unless there is a justified business, process, regulatory, or compatibility need.

3.2 What is a URS?

A User Requirement Specification (URS) is a controlled document that defines the business, process, operational, quality, regulatory, safety, maintenance, and lifecycle requirements for a facility, utility, equipment, or computerized system.

The URS represents the voice of the user, not the vendor.

It specifies what the system must achieve rather than how it will be designed.

3.3 Why is a URS Required?

A URS provides the baseline against which the design and qualification are evaluated.

It supports:

• equipment procurement
• supplier selection
• design qualification (DQ)
• risk assessment
• FAT
• SAT
• IQ
• OQ
• PQ
• traceability
• change control
• lifecycle management

Without an approved URS, it is difficult to demonstrate that the delivered system satisfies the intended use.

3.4 URS in the Qualification Lifecycle

The URS is the starting point of the evidence chain.

Business Need
      ↓
Intended Use
      ↓
User Requirement Specification (URS)
      ↓
Risk Assessment
      ↓
Design Specification
      ↓
Design Qualification
      ↓
Factory Acceptance Test
      ↓
Site Acceptance Test
      ↓
Installation Qualification
      ↓
Operational Qualification
      ↓
Performance Qualification
      ↓
Traceability Matrix
      ↓
Qualification Summary Report
      ↓
Routine GMP Operation

Every major qualification document should be traceable to one or more URS requirements.

3.5 Objectives of a Good URS

A well-prepared URS should:

• define the intended use
• establish measurable requirements
• support procurement
• define GMP expectations
• support risk assessment
• support qualification testing
• minimize design ambiguity
• facilitate lifecycle management

The URS should not become a design specification or operating manual.

3.6 Who Should Prepare the URS?

A URS is best developed by a cross-functional team.

The user organization should own the URS, even when external consultants or vendors assist in drafting it.

3.7 URS Document Structure

A practical URS may include:

1. Document information
2. Purpose
3. Scope
4. Intended use
5. Process description
6. System description
7. Functional requirements
8. GMP requirements
9. Mechanical requirements
10. Utility requirements
11. Instrumentation requirements
12. Automation requirements
13. Data integrity requirements
14. Safety requirements
15. Environmental requirements
16. Maintenance requirements
17. Documentation requirements
18. FAT/SAT expectations
19. Qualification requirements
20. Training requirements
21. Acceptance requirements
22. Appendices
23. Requirement traceability numbering

3.8 Intended Use

The intended use is the foundation of the URS.

It should describe what the system is expected to do in routine GMP operation.

Example – Tablet Compression Machine

Good Intended Use

The tablet compression machine shall manufacture immediate-release tablets within the approved operating ranges defined by the manufacturing process, while maintaining process control, product quality, operator safety, and applicable GMP controls.

Poor Intended Use

Machine to make tablets.

The first statement defines purpose and operational context, while the second is too vague to support design or qualification.

3.9 Process Requirements

The URS should describe the process requirements that the equipment must support.

Examples include:

• product type
• dosage form
• production capacity
• batch size
• operating speed
• minimum and maximum throughput
• product characteristics
• changeover requirements
• cleaning requirements
• process control needs

Example Requirement

URS-PR-001

The compression machine shall support batch sizes from 100,000 to 2,000,000 tablets without requiring hardware modification.

This requirement is specific and testable.

3.10 Capacity Requirements

Capacity should be defined quantitatively.

Poor Requirement

High production capacity.

Improved Requirement

The machine shall achieve a nominal production capacity of up to 350,000 tablets per hour for approved products under defined operating conditions.

3.11 Operating Range Requirements

Operating ranges define the expected performance limits.

Examples:

• turret speed
• feeder speed
• compression force
• fill depth
• tablet thickness
• tablet weight
• environmental conditions

Example

URS-OR-004

The machine shall allow adjustment of turret speed within the validated operating range defined by the approved process.

3.12 Critical Process Parameters (CPPs)

Where appropriate, the URS should identify process parameters that are critical to product quality.

Examples:

• compression force
• pre-compression force
• turret speed
• feeder speed
• drying temperature (FBD)
• blend time
• coating spray rate

The URS identifies the need; subsequent design documents define how these parameters are implemented.

3.13 Critical Quality Considerations

The URS should identify requirements that support critical quality attributes (CQAs), such as:

• tablet weight consistency
• hardness
• thickness
• friability
• content uniformity
• dissolution performance

Where applicable, the relationship between CPPs and CQAs should be considered during risk assessment and qualification planning.

3.14 Materials of Construction

The URS should define expectations for materials of construction relevant to the intended GMP use.

Typical considerations include:

• product-contact materials
• corrosion resistance
• compatibility with cleaning agents
• durability
• regulatory suitability

Example Requirement

URS-MOC-002

Product-contact components shall be manufactured from materials suitable for the intended pharmaceutical process and compatible with approved cleaning procedures.

The URS should state the requirement; detailed material specifications are normally defined in design documentation.

3.15 Product-Contact Parts

The URS should identify:

• product-contact surfaces
• removable parts
• seals and gaskets
• tooling
• hoppers
• feeders
• compression tooling interfaces

Requirements may address:

• cleanability
• accessibility
• replacement
• identification
• compatibility with product and cleaning agents

3.16 Surface Finish

Where surface finish is important, the URS should define the requirement without unnecessarily specifying manufacturing methods unless justified.

Example

URS-SF-001

Product-contact surfaces shall be finished to support effective cleaning and minimize product retention, consistent with the approved design requirements.

Detailed roughness values, if required, should be supported by engineering or process justification.

3.17 Cleaning Requirements

The URS should identify:

• manual cleaning
• clean-in-place (CIP) where applicable
• dismantling requirements
• accessibility
• drainability
• inspection access
• prevention of product retention
• cleaning validation considerations

Example

URS-CL-003

Product-contact components shall be accessible for routine cleaning using the approved cleaning procedure.

3.18 Drainability

For systems handling liquids, the URS may include requirements for complete drainage where appropriate.

Example systems:

• purified water
• WFI
• clean steam condensate
• process vessels
• CIP systems

Drainability requirements should reflect the intended process and cleaning strategy.

3.19 Cross-Contamination Control

Where relevant, the URS should define measures to minimize cross-contamination.

Examples include:

• enclosed product path
• dust extraction interfaces
• containment
• cleanability
• product segregation
• material flow
• air management

3.20 Containment Requirements

For potent products or dust-generating operations, the URS may define containment expectations.

Examples:

• closed transfer
• extraction points
• glove ports
• dust-tight seals
• pressure differentials
• operator protection

3.21 Safety and Interlocks

Safety requirements should be identified separately from GMP requirements.

Typical examples include:

• emergency stop
• guard interlocks
• overload protection
• access protection
• lockout provisions
• warning alarms

Example Requirement

URS-SAF-005

Opening the designated safety guard shall prevent machine operation until the defined reset conditions are satisfied.

3.22 Environmental Requirements

Where relevant, define:

• operating temperature
• relative humidity
• cleanroom classification
• vibration limits
• utility quality
• environmental monitoring interfaces

3.23 Utility Requirements

The URS should identify required utilities, such as:

• electrical supply
• compressed air
• vacuum
• purified water
• clean steam
• chilled water
• nitrogen

Example:

The system shall operate with the site electrical supply and compressed-air specification defined by the facility utility standards.

3.24 Instrumentation Requirements

Typical URS requirements include:

• sensor type
• measuring range
• display requirements
• calibration capability
• identification
• alarm capability

3.25 Calibration Requirements

The URS may specify that critical instruments:

• are uniquely identified
• can be calibrated
• have accessible calibration points
• support documented calibration records

It should avoid prescribing calibration procedures, which belong in maintenance and calibration documentation.

3.26 Automation Requirements

For automated equipment, the URS should define functional expectations such as:

• PLC control
• HMI operation
• SCADA integration
• alarm management
• sequence control
• recipes
• user roles
• reports
• data storage

3.27 PLC / SCADA / HMI Requirements

Typical examples include:

• operator interface
• alarm display
• parameter entry
• status indication
• diagnostics
• communication
• trend display (where applicable)

3.28 Recipe Management

Where recipe control is used, the URS may define requirements such as:

• controlled recipe creation
• recipe selection
• version control
• approved parameter limits
• change authorization
• auditability where applicable

3.29 User Access

The URS should define the need for appropriate user access controls.

Typical roles:

• Operator
• Supervisor
• Maintenance
• Engineering
• Administrator
• QA (where applicable)

The URS should state the need for role-based access rather than describing software implementation details.

3.30 Audit Trails

For computerized systems where audit trails are applicable, the URS should identify the expectation that significant GMP-relevant actions are recorded and reviewable.

The detailed implementation should be defined during system design.

3.31 Electronic Records

Where electronic records support GMP activities, the URS should define expectations for:

• record creation
• retention
• retrieval
• protection
• availability

Requirements should be aligned with the system’s intended use.

3.32 Electronic Signatures

If electronic signatures are part of the intended use, the URS should identify that requirement.

Not every computerized system requires electronic signatures.

Their applicability depends on the intended GMP process and the organization’s quality system.

3.33 Data Storage

The URS may define:

• storage duration
• retrieval capability
• backup requirements
• storage capacity
• integrity protection

3.34 Backup and Restore

Where computerized systems are involved, the URS should define the expectation that data can be backed up and restored appropriately.

Qualification should later verify the agreed functionality.

3.35 Cybersecurity

For networked systems, the URS may include expectations for:

• authenticated access
• password management
• secure communication
• protection against unauthorized changes
• controlled remote access where applicable

The URS should focus on business and GMP needs rather than detailed cybersecurity architecture.

3.36 Data Integrity

Data integrity requirements should support principles such as:

• attributable
• legible
• contemporaneous
• original
• accurate
• complete
• consistent
• enduring
• available

Where applicable, the URS should identify the need for controls that support these principles.

3.37 Alarm Management

The URS may require:

• critical alarms
• operator notification
• alarm acknowledgement
• alarm history
• alarm prioritization

3.38 Reporting Requirements

Examples include:

• batch reports
• production summaries
• alarm reports
• event logs
• maintenance reports

The URS should define what reports are required rather than their final layout.

3.39 Maintenance Requirements

Typical expectations:

• accessible components
• preventive maintenance
• spare parts
• lubrication points
• diagnostics
• maintenance manuals

3.40 Documentation Requirements

The URS should identify expected documentation such as:

• manuals
• drawings
• certificates
• calibration records
• software documentation
• spare-parts lists
• qualification support documents

3.41 FAT / SAT Requirements

The URS may identify that the supplier should support:

• FAT
• SAT
• documentation review
• qualification activities
• operator training

Detailed FAT and SAT protocols are developed separately.

3.42 Qualification Requirements

The URS may state that the supplier should support the agreed qualification strategy by providing necessary technical documentation and participation where defined.

The qualification protocols themselves are separate controlled documents.

3.43 Training Requirements

The URS may specify that training should be provided for:

• operators
• maintenance personnel
• engineering
• automation
• quality

Training content is generally documented outside the URS.

3.44 Characteristics of a Good Requirement

A good URS requirement should be:

• Specific
• Measurable
• Achievable
• Relevant
• Testable
• Traceable
• Unambiguous
• Uniquely numbered

3.45 Poor vs. Good URS Requirements

3.46 Testable vs. Non-Testable Requirements

Testable

The system shall generate an alarm when the designated hopper level falls below the defined operating limit.

Non-Testable

The system shall perform optimally.

The second statement lacks measurable acceptance criteria.

3.47 GMP-Critical Requirement Example

URS-GMP-021

The system shall prevent unauthorized modification of approved recipe parameters through role-based access controls appropriate to its intended use.

This requirement can later be traced to:

• risk assessment
• design specification
• FAT
• OQ
• traceability matrix

3.48 Data Integrity Requirement Example

URS-DI-004

Where applicable to the intended use, the system shall retain audit records for GMP-relevant actions in a manner that supports review and traceability.

3.49 Requirement Numbering

Each requirement should have a unique identifier, for example:

• URS-001
• URS-002
• URS-003
• URS-004

Grouping by category (e.g., URS-SAF-001, URS-AUT-010) is also acceptable if defined consistently.

Unique numbering simplifies traceability and change control.

3.50 Common URS Deficiencies

3.51 Inspector Perspective

Typical inspector questions include:

• Why was this requirement included?
• How were GMP-critical requirements identified?
• How is each requirement verified?
• Show the traceability from URS to OQ.
• Which requirements were not tested and why?
• How are changes to the URS controlled?

A strong URS allows these questions to be answered with clear, documented evidence.

3.52 URS Preparation Checklist

Before Approval

• □ Intended use defined
• □ Scope defined
• □ Cross-functional review completed
• □ Requirements uniquely numbered
• □ Requirements are specific and testable
• □ GMP requirements identified
• □ Automation requirements identified
• □ Data integrity needs identified
• □ Qualification expectations defined
• □ Approval completed

Before Qualification

• □ Traceability matrix initiated
• □ Risk assessment linked
• □ Design review completed
• □ Supplier understands requirements
• □ FAT protocol references URS
• □ IQ/OQ protocols reference URS

Part 3 — Key Takeaway

The User Requirement Specification (URS) is the cornerstone of the pharmaceutical qualification lifecycle. It defines what a system must achieve to support its intended GMP use and provides the basis for risk assessment, design, supplier testing, qualification protocols, traceability, and lifecycle management.

A well-constructed URS is clear, testable, traceable, risk-informed, and focused on user and GMP needs rather than technical implementation details. It establishes the first link in the evidence chain that ultimately demonstrates a facility, utility, equipment item, or computerized system is fit for its intended GMP use.

About the Author

Ramesh Palav is a pharmaceutical professional with 20+ years of industry experience in manufacturing, GMP, quality systems, validation, compliance, and operational excellence. Through Pharma Manufacturing Hub, he shares practical insights on pharmaceutical careers, manufacturing, quality, validation, Pharma 4.0, AI, and professional development.

His goal is to help students, freshers, experienced professionals, and career-break professionals build the knowledge and skills needed to succeed in the pharmaceutical industry.