PHARMA LAB · PL-04-001

Laboratory Equipment URS: Writing Verifiable Requirements

From intended use to verifiable requirements: boundaries, performance, alarms, data and responsibilities, with an original matrix and a simulated QC refrigerator case.
Laboratory refrigerator containing closed bottles, with an external recorder and a requirements folder on a light-coloured bench.

A useful user requirements specification, or URS, helps you decide whether equipment meets the laboratory’s needs and what evidence will demonstrate this. Start with intended use, establish the supply boundaries and turn needs into understandable, verifiable requirements. The aim is to make performance, operating conditions, data and responsibilities explicit before purchasing, rather than accumulate catalogue features. A statement such as “GMP-suitable refrigerator” does not explain which materials will be stored, which loads are permitted or who will receive an alarm.

This article presents an original GuideGxP approach for general QC laboratory equipment. It is neither an approved URS nor a qualification protocol. The example concerns a laboratory refrigerator, rather than the design of a temperature-controlled warehouse or a chromatography system.

1. Describe intended use before specifying features

Identify the activities, materials, users and decisions that depend on the equipment. For a refrigerator, distinguish samples, reagents and reference materials; for a mixer, specify containers and operations; for a controlled chamber, clarify the purpose of the maintained conditions. Acceptable conditions must come from approved information about materials, methods or processes, not an online convention.

Describe the load as well: container dimensions and arrangement, simultaneous quantity, access, work sequences and foreseeable variation. “Sufficient capacity” does not distinguish nominal volume from usable volume. Two units with the same declared capacity may need different arrangements to permit access, cleaning and operation consistent with demonstrated conditions. Comparing them is a laboratory assessment, not a commercial ranking.

EU GMP Annex 15 places the URS and/or functional specification among the references used to define equipment and support its lifecycle. Document size should be proportionate to risk and complexity; simple equipment does not automatically need the dossier required for a complex installation. [1] Chapters 3 and 6 provide the context for suitable equipment and quality-control resources. [2] [6]

2. Define boundaries, accessories and interfaces

Describe the system boundary in concrete terms. Does it include only the unit, or also probes, recorder, software, workstation, network connection and alarm transmission? Identify which elements are included in the offer and which the site supplies. A function can be essential to the process without being physically built into the equipment.

GuideGxP recommends an interface list identifying the owner, exchanged information or service, required conditions and behaviour when unavailable. An alarm output alone does not demonstrate that an on-call person will receive the notification. The chain includes connection, configuration, recipients, acknowledgement and any escalation. Testing only the output leaves the other steps uncovered.

Record room constraints: installation and servicing space, power supply, permitted ambient conditions, accessibility, cleaning and compatibility with the safety assessment. Where a material presents specific hazards, involve the relevant specialist before selecting equipment. This article is not a safety assessment, and an ordinary unit must not be assumed suitable for every substance. A boundary-and-responsibility approach is also consistent with NHS URS guidance, although that guidance was developed for aseptic services and must be used within that context. [5]

3. Separate need, requirement, specification and test

The need explains the intended outcome; the requirement states what must be satisfied; the specification describes the proposed solution; and the acceptance criterion defines how evidence will be judged. The test is the activity that produces that evidence. Keeping them distinct prevents a declared feature from being mistaken for demonstrated performance.

Give each requirement a stable identifier and, where possible, a single principal demand. State its conditions of application and reference the approved criterion. Avoid expressions such as “easy to clean”, “highly accurate”, “appropriate alarm” or “compliant software” without explaining the behaviour to be verified. A qualitative requirement can still be verifiable: surface accessibility and removal of an accessory can be assessed through a documented demonstration.

Illustrative rewrite: replace “reliable refrigerator” with “the unit must maintain the approved storage conditions for the listed materials, within the usable volume and defined loading and access scenarios; compliance must be verified through the approved protocol for those scenarios”. The second sentence makes dependencies explicit, but it is not ready for approval until the list, conditions and scenarios are defined. Referencing an empty document does not make a requirement measurable.

Classify mandatory requirements and preferences separately. A convenience feature can have operational value without being critical to quality. Conversely, a data-retention requirement must not lose priority because it is invisible during a demonstration. Criticality should be justified by consequences, rather than assigning every requirement the highest category.

4. Link performance, capacity and environment to use

For each function, ask what must happen, under which conditions and with what evidence. Where temperature matters, distinguish the setpoint, sensor indication, conditions at different locations and behaviour over time. The URS should explain which quantity or condition supports the decision; a single “accuracy” figure cannot replace these questions.

Specify the scenarios the laboratory intends to support: ordinary load, relevant configurations, access and expected ambient conditions. The combinations to be tested will be justified in the qualification strategy. The URS does not need to anticipate every protocol detail, but it must provide the basis needed to design the protocol. Avoid specifying only empty-unit tests when the decision concerns use with materials.

Discuss practical constraints with users: material identification, shelf access, cleaning after a spill, maintenance access and restoration after intervention. These are original GuideGxP design questions. The GMP reference remains equipment suitability for use and the ability to maintain and clean it properly; this guide contains no universal list of dimensions or performance values. [2]

5. Specify alarms, data and continuity requirements

An alarm requirement should describe the event detected, applicable logic, recipient, event evidence and planned organisational response. Thresholds and delays need justification in relation to materials and process. Do not confuse acknowledging an alarm with resolving its cause or authorising use of the affected materials.

Where electronic data support GMP decisions, define the records and metadata to retain, who can create or change them, how they are reviewed and how retrieval will be demonstrated. Distinguish display, export, backup and long-term retention. An exported file does not automatically prove record completeness or effective restoration. The computerised component needs an applicability and risk assessment under Annex 11; documentation requirements connect to Chapter 4. [3] [4]

Consider loss of power, network or communication without assuming a single technical solution. Clarify what must remain available, which gaps will be identifiable and who decides actions for materials. A continuity requirement must connect to actual responsibilities and procedures. Avoid promising “no loss” without defining the events and conditions to be demonstrated.

6. Original matrix: requirement, rationale, criticality, test and evidence

The following matrix is a GuideGxP reasoning aid, not a normative table. Priorities must be assigned within the project; the suggested tests are candidates to be developed into protocols with approved criteria. A reference to a controlled list assumes that the list exists, is versioned and is available to the person performing the verification.

Illustrative requirementRationale and criticality to assessCandidate testExpected evidence
R01: material conditions maintained in approved scenariosMaterial integrity; consequence of loss of controlVerification in defined load configurationsConfiguration, data and judgement against criteria
R02: usable volume identified and accessibleReproducible loads and prevention of unverified usesDemonstration with representative containersShelf layout and documented use limitations
R03: critical event notified to the designated roleDetection and opportunity to interveneControlled simulation of the alarm chainEvent, notification, receipt and responsibility
R04: records retrievable with their contextReconstruction of storage conditionsRetrieval and examination of a representative setData, times, identifiers and relevant metadata
R05: setting changes restricted to authorised rolesPrevention of uncontrolled changesTests with authorised and unauthorised profilesOutcomes, configuration and relevant records
R06: surfaces and accessories compatible with planned cleaningResidues, access and maintenance of conditionsMaterial review and access demonstrationDocumented compatibility and workable procedure
R07: documents and training available before releaseSustainable operation and maintenanceReview of delivery and required competenciesAccepted list, versions, training and closed gaps

Add the owner, requirement source, criterion, verification stage and status to the project register. Commercial priority and GMP criticality may differ: separate fields make the choice transparent. Do not allow a favourable average score across offers to cancel out a critical gap.

7. Define documentation, services and exclusions

Ask the response to the URS to distinguish requirements that are met, met subject to conditions, not met and not included. For each condition, identify the additional component, responsibility, cost and necessary verification. A generic compliance statement does not replace a response for each requirement, supported by evidence already available or still to be produced.

Define the documentation needed for operation and upkeep: delivered configuration, instructions, maintenance, relevant components, sensor and software information, and pertinent test documents. Agree format, language, versions and delivery timing. Specify training, spare-parts access and management of changes affecting the site. Do not automatically treat every document included in the offer as qualification evidence.

Supplier evidence can contribute to qualification when assessed for relevance and adequacy; responsibilities, gaps and site checks must remain defined. [1] A test performed on a different configuration requires a documented comparison, not acceptance based on a similar commercial name.

8. Simulated case: a refrigerator for a QC laboratory

A laboratory wants to replace a refrigerator used for reagents and samples awaiting testing. The initial request lists only external volume and the presence of an alarm. In this example, the working group includes QC users, the equipment owner, QA and relevant technical and IT expertise; this is not a mandatory team composition for every project.

The first review separates material families and refers to their approved conditions. If those conditions are incompatible, purchasing a single unit is not already justified. The group then documents containers, arrangement, access and out-of-hours responsibilities. Usable volume becomes a verifiable configuration, rather than a catalogue measure considered sufficient on its own.

The second decision concerns the boundary: local control, recorder and personnel notification are handled by different elements. The offer includes the alarm output but not connection to the site system. The URS identifies this interface, its owner and the test from event to receipt; the gap remains open until the solution is defined. It is not cancelled because the unit cools correctly.

Finally, the group translates approved conditions into criteria and verification scenarios, agrees documentation and data restoration, and assigns the missing activities. The case attributes no results to tests that have never been performed: it shows the decisions needed before approving the specification and purchasing. It sets no temperatures, durations, delays or intervals valid for every laboratory.

9. Approval, traceability and discrepancy management

Before approval, review each requirement for an owner, rationale, defined conditions and a verification route. Open information needs an owner and deadline; an undefined essential element may prevent approval or require a formal restriction on the authorised phase. Do not conceal it in a generic note.

Link the requirement identifier to the technical response, risk, test and outcome. After approval, a change must make its reason and impact on selection, configuration, verification and use visible. Annex 15 and Chapter 4 support document and deviation control; the matrix format proposed here is an editorial choice. [1] [4]

Common mistakes include copying a datasheet as a URS, classifying everything as critical, postponing alarm requirements until after purchase and writing criteria only after seeing test results. Also avoid confusing commercial acceptance of delivery with release for GMP use. The two decisions may use different documents and require different issues to be closed.

Operational conclusion

A good URS makes the path from laboratory work to the purchasing decision and subsequent evidence clear. Start with real materials and scenarios, define boundaries and make every important request verifiable. Keep responsibilities, exclusions and open questions visible: the document is useful when it exposes a gap before that gap becomes an operational problem.

This topic belongs to the Laboratory Equipment & Controlled Storage hub. For the records context, see Data Integrity in QC Labs: Essential Principles. Equipment verification and validation of computerised functions should be scaled to actual use.

Sources and applicability boundaries

References checked on 29 September 2026. The EU GMP framework cited here concerns human medicines within its applicable scope. Annex 11 is cited in its published 2011 revision; revision drafts are not presented as effective requirements. NHS guidance concerns aseptic services and does not automatically transfer cleanroom requirements to QC laboratories. The matrix, examples and questions are original GuideGxP recommendations for local adaptation and approval.

  1. European Commission — EU GMP Annex 15 — Qualification and Validation. 2015 revision, effective 1 October 2015.
  2. European Commission — EU GMP Chapter 3 — Premises and Equipment. Chapter 3, revision effective 1 March 2015.
  3. European Commission — EU GMP Annex 11 — Computerised Systems. Revision 1, effective 30 June 2011.
  4. European Commission — EU GMP Chapter 4 — Documentation. January 2011 revision.
  5. NHS Specialist Pharmacy Service — Writing the User Requirement Specification. Guidance published 28 August 2026; aseptic-services context.
  6. European Commission — EU GMP Chapter6 Quality Control. Revision effective 1 October 2014.
Technical content for informed decisions; it does not replace the approved procedure, applicable requirements or the instrument manual.

Continue exploring