URS for GMP Facilities, Utilities, and Equipment

User Requirements Specification (URS) defines what a facility, utility, equipment item, or laboratory system must accomplish to support its intended GMP use. It translates process, product, operational, quality, safety, and regulatory needs into approved requirements that can be used for design, procurement, risk assessment, qualification, and final system acceptance.

The URS should describe the required outcome without unnecessarily prescribing the technical solution. It establishes what users need from the system; functional specifications, design specifications, drawings, calculations, and vendor documents describe how those requirements will be achieved.

A URS is effective only when its requirements are clear enough to guide design decisions and specific enough to be verified objectively.

This article addresses facilities, cleanrooms, utilities, manufacturing and packaging equipment, sterilization systems, thermal equipment, and laboratory instruments. Requirements unique to software and electronic records are covered separately in User Requirements Specification for Computerized Systems.

Purpose of the User Requirements Specification

The URS establishes the approved basis for determining whether a proposed system is suitable for its intended use.

It should define:

• What the system will be used for
• Which products, materials, processes, loads, or samples it must support
• Required capacity, operating ranges, and performance
• Product-quality and contamination-control requirements
• Required functions, controls, alarms, and interfaces
• Cleaning, sanitization, sterilization, or decontamination needs
• Facility and utility conditions required for operation
• Documentation, calibration, maintenance, and support expectations
• Applicable GMP, safety, environmental, and data requirements
• Criteria by which the completed system will be accepted

The URS provides a common technical and quality basis for users, engineering, validation, quality assurance, procurement, vendors, and other project participants. It reduces the risk that a system will be designed or purchased based primarily on a vendor’s standard offering without adequately addressing the actual manufacturing or laboratory need.

An approved URS supports:

• Project scope definition
• Vendor bidding and proposal comparison
• Conceptual and detailed design
• Design Qualification
• Quality risk assessment
• Factory and site acceptance testing
• Commissioning
• Installation Qualification
• Operational Qualification
• Performance Qualification
• Requirements traceability
• Change-impact assessment
• Final system release

The URS is not merely a validation document prepared after equipment has been selected. It should be developed early enough to influence system design and procurement.

Intended Use and System Boundaries

Effective requirements begin with a clear definition of intended use. The intended-use statement explains the operational and GMP purpose of the system and establishes the context for every requirement that follows.

The intended use should identify, as applicable:

• Process or operation supported
• Product, formulation, material, component, or sample types
• Required batch, load, flow, or test capacity
• Manufacturing or laboratory environment
• Product-contact status
• Sterile, aseptic, controlled, or nonsterile application
• Direct, indirect, or no product impact
• Required operating modes
• Expected operating schedule and availability
• Users and supporting departments
• GMP records or data generated
• Required integration with facilities, utilities, equipment, or control systems

For example, a vessel should not be described only as a “1,000-liter mixing tank.” Its intended use may require it to receive a specific material, mix within a defined working-volume range, control temperature, prevent contamination, support validated cleaning, and transfer product through a closed pathway.

Defining System Boundaries

The URS should state what is included and excluded from the system. Boundaries may identify:

• Major equipment and subsystems
• Product-contact pathway
• Utility supply and return points
• Piping termination points
• Control panels and field instruments
• Local and remote controls
• Building-management or manufacturing-system interfaces
• Ancillary equipment
• Vendor-supplied and owner-supplied components
• Mobile items, change parts, tools, and accessories
• Supporting software or data systems

Poorly defined boundaries create gaps between project packages, qualification protocols, and departmental responsibilities. Boundary definitions should remain consistent across the URS, design documents, drawings, vendor scope, commissioning plan, and qualification strategy.

Development, Review, and Approval Responsibilities

The system owner should normally lead development of the URS because the owner is responsible for the intended use and operational outcome. The document should be prepared and reviewed by a cross-functional team with knowledge of the process, product, system, and applicable controls.

Participants may include:

• Manufacturing or laboratory users
• Process development
• Engineering
• Validation
• Quality assurance
• Quality control
• Facilities and utilities
• Maintenance and metrology
• Automation or information technology
• Environmental, health, and safety
• Contamination-control or microbiology specialists
• Procurement and project management

Responsibilities should be defined so that:

• Users define operational needs and workflows
• Process and technical personnel establish required operating ranges and performance
• Engineering evaluates feasibility, interfaces, and design implications
• Quality and validation identify GMP, qualification, and traceability needs
• Maintenance and metrology address serviceability, calibration, and lifecycle support
• Automation specialists address control functions and interfaces
• Safety personnel address occupational and environmental requirements

The URS should be approved by authorized representatives before it is issued for design or procurement. Approval indicates agreement with the stated requirements; it does not prove that the proposed design satisfies them. That determination is made through design review and Design Qualification.

Characteristics of Effective User Requirements

Each requirement should be written as a controlled statement that can be understood consistently by designers, vendors, reviewers, and testers.

Effective requirements are:

• Necessary: The requirement supports intended use, quality, compliance, safety, reliability, or an approved business need.
• Clear: The wording has one reasonable interpretation.
• Specific: The required function, condition, range, or outcome is defined.
• Measurable: Compliance can be determined using objective evidence.
• Testable or verifiable: A practical method exists to confirm that the requirement has been satisfied.
• Feasible: The requirement can be achieved with available technology and within known project constraints.
• Traceable: The requirement has a unique identifier and can be linked to design and verification evidence.
• Consistent: It does not conflict with other requirements, process needs, or approved standards.
• Solution-neutral where appropriate: It states the need without unnecessarily dictating the design.
• Risk-based: Its importance and verification approach reflect its potential effect on product quality, patient safety, data integrity, or process control.

Use of “Shall”

Mandatory requirements should normally use shall. Statements using may, should, as appropriate, adequate, suitable, user-friendly, or where possible are difficult to verify unless the document defines what those terms mean.

Each requirement should contain one principal obligation. Combining several unrelated needs in a single requirement makes traceability and testing difficult.

Weak and Improved Requirement Examples

Exact values should be included when they are known and scientifically justified. When development remains incomplete, the URS should not invent unsupported values. The open requirement should be resolved through documented technical evaluation before the value is needed for design or acceptance.

Requirement Identification and Organization

Every requirement should have a unique, stable identifier. Identifiers allow individual requirements to be discussed, revised, traced, tested, and closed without ambiguity.

A structured identifier may distinguish categories, for example:

• URS-GEN-001 — General
• URS-PRC-001 — Process and performance
• URS-MOC-001 — Materials of construction
• URS-CLN-001 — Cleaning and contamination control
• URS-CTL-001 — Controls, alarms, and interlocks
• URS-UTL-001 — Utility requirements
• URS-DOC-001 — Documentation
• URS-MNT-001 — Maintenance and calibration

The selected format is less important than consistency and control. Requirement numbers should not be silently reused after a requirement is deleted. Retaining the identifier and marking the requirement as deleted or superseded preserves historical traceability.

Useful URS fields may include:

A URS should remain readable. Excessive metadata can make the document difficult to develop and maintain. Detailed design traceability and test results may be managed in a separate requirements traceability matrix.

Core Requirement Categories

The content of a URS depends on system type and intended use. Not every category applies to every system.

General and Operational Requirements

These requirements may define:

• Intended use
• System boundaries
• Operating modes
• Required workflows
• Products, materials, loads, or samples
• Batch sizes and production rates
• Normal, maximum, and minimum operating conditions
• Expected operating schedule
• Required availability or redundancy
• Operator access and ergonomics
• Change parts and format ranges
• Location and environmental conditions
• Required interfaces

Capacity and Performance

Performance requirements should define the capability needed for intended operation. Examples include:

• Working volume
• Flow rate
• Pressure range
• Temperature range
• Heating or cooling rate
• Mixing speed
• Filtration area
• Cycle duration
• Load capacity
• Filling rate and accuracy
• Detection limit
• Measurement range
• Environmental recovery time
• Air-change or airflow performance
• Storage capacity
• Required uniformity or distribution

Requirements should state the conditions under which performance must be achieved. A capacity or accuracy requirement without the associated load, material, operating range, or environmental condition may be misleading.

Process and Product Requirements

The URS should identify conditions necessary to protect product quality and process performance, including:

• Critical Process Parameters supported by the system
• Required operating ranges and control accuracy
• Critical Quality Attributes affected by system performance
• Material and product characteristics
• Maximum allowable hold or exposure times
• Shear, heat, pressure, light, oxygen, or moisture sensitivity
• Required closed processing
• Cross-contamination controls
• Segregation and containment needs
• Sampling requirements
• Drainability and recovery requirements

The URS should not attempt to duplicate the complete process description or control strategy. It should identify the system capabilities required to implement them.

Materials of Construction and Hygienic Design

Materials should be specified according to intended use, product compatibility, cleaning agents, operating conditions, and contamination risk.

Requirements may address:

• Product-contact materials
• Non-product-contact materials in critical areas
• Surface finish
• Corrosion resistance
• Chemical and temperature compatibility
• Elastomers, gaskets, lubricants, and adhesives
• Material certification
• Weld quality and documentation
• Passivation or surface treatment
• Dead-leg and crevice control
• Drainability
• Accessibility for inspection and cleaning
• Prevention of particle, fiber, or lubricant contamination

For drug-product manufacturing equipment, product-contact surfaces must not be reactive, additive, or absorptive in a manner that could alter product safety, identity, strength, quality, or purity. The URS should translate this principle into system-specific requirements based on the product and process.

Hygienic design requirements should be proportionate to the application. A sterile product-contact system may require a defined surface finish, drainable piping, cleanable seals, aseptic connections, and sterilization capability. A non-product-contact support system may require different controls.

Over-specification should be avoided. Requiring an identical material or surface finish for every component without considering function and risk can add cost without improving product protection.

Cleaning, Sanitization, Sterilization, and Decontamination

The URS should define how the system must support the approved contamination-control and cleaning strategy.

Requirements may include:

• Manual, clean-in-place, or automated cleaning
• Cleaning coverage and accessibility
• Required disassembly
• Cleaning-agent compatibility
• Rinse and drain capability
• Prevention of residue retention
• Clean-hold and dirty-hold conditions
• Sanitization method
• Steam-in-place capability
• Autoclave compatibility
• Dry-heat or chemical decontamination
• Required sterilization temperature, exposure, or cycle capability
• Prevention of recontamination
• Separation of clean and dirty pathways
• Cycle parameter control and recording
• Sampling access for cleaning verification

The URS should define the capability the system must provide. Detailed cleaning recipes, validated cycle parameters, and routine procedural steps are normally established in downstream development, qualification, and operating documents.

For equipment requiring automated cleaning or sterilization, the URS should address both the physical design and the required control functions. Critical cycle parameters, alarms, interlocks, and record requirements should be identified early enough to influence equipment and automation design.

Facility and Utility Requirements

Facility and Cleanroom Requirements

A facility URS may address:

• Process and personnel flows
• Material, waste, and equipment movement
• Room functions and adjacencies
• Segregation and containment
• Cleanroom classification
• Pressure relationships
• Temperature and humidity
• Airflow direction and recovery
• Surface materials and finishes
• Cleanability and access
• Personnel and material airlocks
• Utility distribution
• Maintenance access
• Space for operation, cleaning, and component movement
• Environmental monitoring provisions
• Emergency power and business-continuity needs

Requirements should be based on the process and contamination-control strategy rather than copied automatically from another facility.

Utility Requirements

A utility URS may define:

• Required utility quality
• Generation and distribution capacity
• Peak and normal demand
• Pressure, flow, temperature, or quality ranges
• Points of use
• Recirculation and return conditions
• Materials of construction
• Drainability and sanitization
• Sampling locations
• Instrumentation and monitoring
• Alarm conditions
• Redundancy and backup
• Storage capacity
• Expansion allowance
• Required records and trend data

For pharmaceutical water, clean steam, compressed gases, process air, vacuum, and other critical utilities, the URS should distinguish quality requirements at the point of generation from conditions required at the point of use.

Equipment Requirements

An equipment URS may address:

• Product and process function
• Capacity and throughput
• Operating range
• Accuracy, repeatability, or uniformity
• Required recipes or operating modes
• Product-contact pathway
• Loading and unloading
• Changeover
• Cleaning and sterilization
• Controls and instrumentation
• Alarms and interlocks
• Containment and operator protection
• Utility needs
• Space and access
• Maintenance and calibration
• Documentation and training

Laboratory Instrument Requirements

A laboratory instrument URS may define:

• Intended analytical use
• Sample and matrix types
• Measurement range
• Accuracy, precision, sensitivity, and resolution
• Throughput and sample capacity
• Environmental conditions
• Accessories and consumables
• Calibration and performance checks
• Data output and review needs
• Maintenance and vendor support
• Required qualification documentation

The URS should state performance needed for the intended analytical application rather than simply naming a preferred model.

Instrumentation, Controls, Alarms, and Interlocks

Control requirements should define the functions necessary to operate and monitor the system safely and consistently.

The URS may address:

• Parameters to be measured, displayed, controlled, or recorded
• Required ranges, accuracy, resolution, and response
• Local and remote operation
• Manual and automatic modes
• Sequence controls
• Recipe or setpoint management
• Alarm conditions and priorities
• Interlocks and permissives
• Fail-safe states
• Emergency-stop functions
• Power-failure and restart behavior
• Status indication
• Sensor redundancy
• Calibration requirements
• Communication with other systems
• Required reports and records

An alarm requirement should identify the condition requiring detection and the expected system or operator response. It should not merely state that “all necessary alarms” will be provided.

Interlocks should be associated with a defined risk or operational need. Requirements should distinguish:

• Alarm: Notifies the operator of an abnormal or defined condition.
• Interlock: Prevents or changes operation when a specified condition exists.
• Permissive: Establishes conditions that must be satisfied before an action can begin.

Setpoints, limits, delay times, and response actions may be finalized during detailed design or process development, but the need for the function should be established in the URS.

Automation and Data Requirements

Modern facilities, utilities, equipment, and laboratory instruments frequently contain embedded software or connect to external computerized systems. The general URS should identify automation and data functions that are part of the equipment’s intended use, including:

• Required automatic operating sequences
• Parameter entry and setpoint control
• Recipe selection
• Alarm generation
• Data display and recording
• Required interfaces
• Report generation
• Time synchronization
• User roles where operational access affects equipment control
• Retention or export of critical process data
• Recovery behavior following interruption

The depth of computerized-system requirements should reflect system function and data risk.

Computerized systems require additional requirements addressing data integrity, security, user access, audit trails, electronic records, electronic signatures, interfaces, backup, recovery, and record retention. These specialized requirements are addressed in User Requirements Specification for Computerized Systems.

For automated manufacturing equipment, the general URS should remain the primary document for the complete physical system. A separate automation or software URS may be used when the control system is complex, separately supplied, or managed under a distinct computerized-system lifecycle. The relationship and boundaries between the documents must be defined.

Maintenance, Calibration, Reliability, and Lifecycle Support

The URS should include requirements necessary to keep the system usable and in a qualified state throughout its operational life.

Requirements may address:

• Access for inspection, maintenance, and calibration
• Calibration ranges and accuracy
• Identification of instruments
• Preventive-maintenance capability
• Diagnostic functions
• Replaceable and wear components
• Recommended spare parts
• Special tools
• Lubrication controls
• Required service clearances
• Component availability
• Vendor service response
• Remote support controls
• Warranty
• Training
• Technical manuals
• Obsolescence and upgrade support
• Backup or redundant components
• Expected system life

Maintenance access should be considered during design. A component that cannot be reached, removed, calibrated, or replaced without unacceptable contamination or operational risk may prevent the system from remaining suitable for use.

Reliability requirements should be measurable when reliability is important. Statements such as “high reliability” should be replaced by defined availability, duty cycle, redundancy, recovery, or performance expectations where appropriate.

Documentation and Deliverables

The URS should identify documents and records required from the designer, constructor, integrator, or equipment vendor.

Required deliverables may include:

• Approved design and functional specifications
• General arrangement and layout drawings
• Process flow diagrams
• Piping and instrumentation diagrams
• Electrical drawings and schematics
• Instrument and component lists
• Material certificates
• Weld documentation
• Surface-finish and passivation records
• Calibration certificates
• Software and firmware inventories
• Configuration records
• Manuals
• Recommended maintenance plans
• Spare-parts lists
• Factory Acceptance Test protocols and reports
• Site Acceptance Test protocols and reports
• Commissioning records
• Vendor IQ or OQ protocols
• Training materials and training records
• Certificates of conformity
• Safety and environmental documentation

The URS should define required format, language, approval, delivery timing, and as-built status where these affect project acceptance.

Vendor documents should be evaluated for suitability rather than accepted solely because they are standard deliverables. Use of vendor testing within formal qualification is addressed in Vendor Protocols in Equipment Qualification.

URS Versus Other Project Documents

The URS is part of a hierarchy of requirements and design documents. Its purpose should not be confused with the purpose of vendor or engineering specifications.

A vendor proposal should not replace the URS. The proposal describes what the vendor is offering; the URS defines what the user needs. Proposal review should identify:

• Requirements fully satisfied
• Requirements partially satisfied
• Proposed alternatives
• Requirements not addressed
• Vendor exceptions and assumptions
• Additional owner responsibilities

Vendor documents may be incorporated by reference when their status, scope, and relationship to the approved URS are controlled.

Risk-Based Classification of Requirements

Requirements may be classified to support design review, risk assessment, and qualification planning. Possible classifications include:

• Direct product-quality impact
• Indirect product-quality impact
• Data-integrity impact
• Regulatory or GMP requirement
• Process-performance requirement
• Safety or environmental requirement
• Business or operational requirement

Classification should not be used to remove necessary requirements from control. Its purpose is to determine the appropriate degree of design assurance and verification.

Higher-risk requirements may require:

• More detailed design review
• Formal risk assessment
• Stronger supplier evidence
• Direct verification during qualification
• Challenge testing under worst-case or boundary conditions
• Greater traceability
• Quality-unit approval
• Continued monitoring or periodic review

Lower-risk requirements may be verified through document review, inspection, commissioning, or another justified method.

The level of effort, formality, and documentation should be proportionate to risk. Risk classification should be based on scientific knowledge and intended use, not simply on the department that originated the requirement.

Requirements Traceability

Traceability demonstrates that approved requirements have been addressed by the design and verified before system release.

A requirements traceability matrix may link each URS requirement to:

• Functional or design specification
• Drawing or calculation
• Design Qualification evidence
• Risk assessment
• FAT or SAT test
• Commissioning record
• IQ, OQ, or PQ test
• Procedure or training record
• Deviation or change record
• Final acceptance status

The Validation V-Model illustrates how user requirements and design activities connect with corresponding verification and qualification activities.

Traceability does not mean that every requirement must be repeated and tested in every protocol. Each requirement should be verified at the stage that provides the most reliable and relevant evidence.

Some requirements are verified through inspection or document review. Others require dynamic testing. The traceability matrix should identify the selected verification method and the final evidence demonstrating closure.

Requirements that are not applicable, replaced, or not fully satisfied should receive a documented disposition. Open traceability items should not be hidden by marking a protocol complete.

URS Review, Approval, and Baseline Control

Before approval, the URS should be reviewed to confirm:

• Intended use and boundaries are clear
• Requirements are complete and internally consistent
• Process and product needs are represented
• Critical ranges and acceptance thresholds are justified
• GMP and regulatory needs are addressed
• Cleaning and contamination controls are adequate
• Utility and interface requirements are defined
• Maintenance and calibration needs are considered
• Automation and data requirements are appropriately addressed
• Requirements are measurable and verifiable
• Vendor deliverables are defined
• Assumptions, exclusions, and unresolved items are visible
• Each requirement has an appropriate owner or technical basis

Approval establishes the URS baseline. The approved version should be placed under document control and referenced consistently by design, procurement, risk-management, commissioning, and qualification documents.

Issuing an incomplete URS with numerous undefined requirements transfers unresolved decisions into later project stages. If an item cannot be finalized before approval, it should be clearly identified, assigned, risk-assessed, and resolved before it affects design or verification.

Managing Requirement Changes

Requirements may change as process knowledge, design information, vendor input, or operating experience develops. Changes should be controlled according to project phase and system status.

Before design approval or system release, a URS change should be evaluated for its effect on:

• Project scope and cost
• Vendor commitments
• Design documents and drawings
• Risk assessments
• Fabrication or construction
• FAT, SAT, and commissioning
• Qualification protocols and completed tests
• Procedures and training
• Regulatory commitments
• Schedule and system acceptance

After qualification or release, changes to the URS should be managed through formal change control. The assessment should determine whether the change affects intended use, system boundaries, validated functions, operating ranges, product quality, data integrity, qualification status, or regulatory compliance.

An URS should not be revised after testing merely to make an unmet requirement match the delivered system. If the original requirement is no longer valid, the technical and quality basis for changing it must be documented and the effect on design and qualification must be assessed.

Superseded requirements should remain historically traceable.

Common URS Deficiencies

Common weaknesses include:

• Preparing the URS after the system has already been selected
• Copying a vendor specification or prior project without evaluating intended use
• Using vague terms without measurable criteria
• Omitting minimum and maximum operating conditions
• Defining functions without the required performance
• Combining multiple requirements under one identifier
• Prescribing a design without a justified user need
• Failing to define system boundaries and interfaces
• Omitting cleaning, maintenance, calibration, or lifecycle requirements
• Omitting automation and data functions embedded in equipment
• Including software requirements that do not address electronic-record risks
• Using a vendor proposal as the only requirements document
• Failing to resolve vendor exceptions
• Treating every requirement as equally critical
• Failing to trace requirements to design and verification evidence
• Changing requirements informally during construction or testing
• Closing qualification while requirements remain unresolved

A very long URS is not necessarily a strong URS. Repetition, generic statements, and copied regulatory language can obscure the requirements that actually determine system suitability.

The document should be detailed enough to control design and acceptance but focused enough to remain usable.

Practical System Examples

Pharmaceutical Water System

Relevant requirements may define:

• Feed-water conditions
• Required water quality
• Generation and distribution capacity
• Peak demand
• Storage volume
• Distribution temperature or sanitization method
• Recirculation flow and return conditions
• Materials and fabrication
• Points of use
• Sampling locations
• Online instruments
• Alarm and trend requirements
• Expansion capacity

Autoclave

Relevant requirements may define:

• Load types and maximum load configuration
• Chamber dimensions and usable volume
• Required cycle types
• Temperature and pressure range
• Air-removal capability
• Sterilization and drying performance
• Load probes and chamber sensors
• Door configuration and interlocks
• Clean-steam and utility requirements
• Cycle records
• Alarm handling
• Loading accessories

Walk-In Freezer

Relevant requirements may define:

• Storage temperature range
• Qualified storage volume
• Maximum and routine load
• Pull-down and recovery expectations
• Temperature monitoring
• Alarm limits and notification
• Door-open conditions
• Backup refrigeration or emergency response
• Power-failure behavior
• Racking and airflow clearance
• Defrost control
• Access and personnel safety

Mixing Vessel

Relevant requirements may define:

• Working-volume range
• Product and material characteristics
• Mixing-speed range
• Temperature-control range
• Addition and transfer functions
• Product-contact materials
• Surface finish and drainability
• Sampling
• Cleaning and sterilization
• Load cells or level measurement
• Pressure or vacuum capability
• Alarms, interlocks, and records

These examples illustrate requirement categories, not universal acceptance criteria. Actual values and controls must be based on the intended process, product, risk, and operating environment.

Key Principles

• The URS defines what the user needs from the system and establishes its intended GMP use.
• The URS should be approved early enough to guide design and procurement.
• Requirements should be necessary, clear, measurable, verifiable, and traceable.
• The URS should define required outcomes without unnecessarily prescribing the technical solution.
• Intended use, system boundaries, operating ranges, and interfaces must be explicit.
• Product-contact, cleaning, contamination-control, maintenance, calibration, and documentation needs should be addressed where applicable.
• Requirements should be classified and verified according to risk.
• Vendor proposals and standard specifications do not replace an approved URS.
• Each requirement should be traced to appropriate design and verification evidence.
• Requirement changes must remain controlled throughout design, qualification, operation, and retirement.
• Computerized-system requirements require additional attention to data integrity, electronic records, security, audit trails, backup, and retention.

Summary

The User Requirements Specification is the approved foundation for the design, procurement, qualification, and acceptance of GMP facilities, utilities, equipment, and laboratory systems.

An effective URS defines intended use, system boundaries, required functions, operating ranges, performance, materials, cleaning, controls, interfaces, documentation, and lifecycle-support needs. Its requirements are written so that they can be evaluated during design and verified through appropriate inspection, testing, review, commissioning, or qualification.

The URS remains distinct from functional and design specifications. It defines the required outcome; downstream documents define the technical solution. Maintaining this distinction preserves clear accountability and allows the completed system to be evaluated against the needs that justified the project.

Requirements traceability and controlled change management keep the URS relevant throughout the system lifecycle. When properly developed and maintained, it provides objective criteria for determining whether a facility, utility, equipment item, or laboratory system is suitable for its intended GMP use.