User Requirements Specification

---

📊 Chapter 7: How to Specify Requirements (URS & RFP Guidance)

By this point, you know what “good” looks like.

Chapter 7 is about locking it into writing so vendors can’t hand-wave their way through your expectations.

You’re going to produce two core artefacts:

1. A URS (User Requirement Specification) that states exactly what you need and why.
2. A procurement-ready RFP that translates those requirements into a vendor-facing, scoreable document.

Think of this chapter as your “we are not the easy customer” toolkit.

---

7.1 URS Components

7.1.0 Purpose of the URS

Your URS is not a shopping list. It is:

• A formal statement of need owned by Quality / Compliance.

• The bridge between regulatory obligations, business risk, and technical reality.

• The document that lets you say in an audit:

  “Here is what we required, why we required it, and how we ensured the system meets those requirements.”

A strong URS is:

• Risk-based – linked to product / patient / food safety / uptime risk.
• Environment-aware – warehouses ≠ reefers ≠ data halls.
• Vendor-agnostic – describes outcomes, not specific brands.

Below is a structured URS blueprint with commentary and sample wording you can adapt.

---

7.1.1 Measurement Performance – Temperature Range, Accuracy, Resolution

At minimum, define what needs to be measured, how well, and under what conditions.

Recommended URS sections

1. Measurement Parameters

   • Temperature requirements per environment type (e.g.:
     • Refrigerated: +2 to +8 °C
     • Frozen: ≤ −18 °C
     • CRT / ambient: +15 to +25 °C (or your defined ranges)
     • Data rooms: as per internal policy / ASHRAE class).

   Sample URS requirement

   The system shall support continuous temperature measurement across the range −30 °C to +50 °C as a minimum, with suitable sensor options for extended ranges where required.

2. Accuracy & Resolution

   • Define minimum accuracy at relevant ranges (e.g. ±0.5 °C or better for pharma & biologics; ±1.0 °C may be acceptable for some food / logistics applications, if justified).
   • Define resolution (e.g. 0.1 °C).

   Sample URS requirement

   For GxP-relevant environments, system sensors and loggers shall provide a measurement accuracy of ±0.5 °C or better over the range −30 to +30 °C, with a display and storage resolution of 0.1 °C.

3. Sampling Interval & Response Time

   • Define standard and minimum sampling intervals (e.g. 5 minutes routine; 1 minute possible for critical points).

   Sample URS requirement

   The system shall support configurable sampling intervals from 1 to 15 minutes for routine monitoring, and shall ensure that logged values reflect the true sensor reading within an update latency of ≤ 60 seconds.

---

7.1.2 Data Integrity Expectations (Audit Trail, E-Signature, Time Stamps)

This is where you bake ALCOA+ and Part 11 / Annex 11 expectations into your URS.

Core elements

1. Unique User Identification

   The system shall enforce unique user accounts; shared logins shall not be supported for any GxP-/risk-relevant functions.

2. Audit Trails

   The system shall maintain secure, computer-generated audit trails for all GxP-/risk-relevant data and configuration elements, including creation, modification, and deletion events, capturing user ID, date/time, and nature of change.

   Audit trail records shall be tamper-evident and not editable by end users.

3. Time Stamps & Time Synchronisation

   All recorded data, alarms, and audit trail entries shall be stamped with date and time derived from a controlled time source. The system shall support time synchronisation of devices and servers and provide clear handling of time zone and daylight saving changes.

4. Electronic Signatures (where applicable)

   Where electronic signatures are used to indicate review, approval, or verification activities, they shall be uniquely linked to the individual, include meaning (e.g. “reviewed”, “approved”), and be permanently associated with the signed record.

5. ALCOA+ Alignment

   The system design and configuration shall support ALCOA+ principles, ensuring data are attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available throughout the defined retention period.

---

7.1.3 Calibration Protocols & Certificates

The URS must close the loop between sensors, calibration policy, and documentation.

Key URS items

• Traceability

  All temperature and humidity measurement devices used for regulated monitoring and mapping shall be calibrated against reference standards traceable to national or international standards, either via an accredited laboratory (e.g. ISO/IEC 17025) or an internally controlled system with traceable references.

• Calibration Intervals

  The system and service provider shall support risk-based calibration intervals as defined in the organisation’s calibration policy, typically 6–24 months for critical devices, and shall provide tools or processes to track due dates and overdue instruments.

• Certificates & Data

  Calibration certificates shall include “as found” and “as left” results, measurement uncertainty, reference standards used, calibration points, and instrument identification. The solution shall support storing, linking, or referencing calibration certificates to individual devices within the asset register.

• Impact Assessment Support

  The system and procedures shall enable documented impact assessment where “as-found” results are out of tolerance, including identification of impacted data sets and periods.

---

7.1.4 Mapping Scope & Deliverables

Here you formalise where and how mapping must be done, and what you expect on paper.

Scope definition

The URS shall define which environment classes require temperature mapping (e.g. pharma warehouses, cold rooms, freezers, stability chambers, refrigerated vehicles, reefers, passive shippers, retail cabinets, data halls, critical server rooms).

Mapping methodology expectations

• Minimum number/density of loggers (by volume, layout, risk).
• Required conditions: empty / partially loaded / fully loaded, door-opening patterns, seasonal extremes where practical.
• Test duration and acceptance criteria (e.g. percentage of time in range, max allowed excursions, recovery times).

Deliverables

For each mapping campaign, the provider shall deliver:

• Approved mapping protocol,
• Sensor layout diagrams,
• Raw and processed data,
• Statistical analysis and summary tables,
• Identification of hot/cold spots,
• Recommendations on probe placement, alarm limits, and storage practices,
• A final mapping report in a format acceptable to regulators and customers.

---

7.1.5 Alarm Management Logic

Your URS should avoid vague “we want alarms when it’s bad” statements. Be specific.

Core requirements

• Alarm Types

  The system shall support at least four threshold-based alarm states per channel (e.g. low, low-low, high, high-high), plus device- and system-level alarms (e.g. communication failure, low battery, sensor failure).

• Time Delays

  The system shall support configurable time-over-threshold delays to avoid nuisance alarms while still detecting meaningful excursions.

• Notification & Escalation

  The system shall support multi-channel notification (e.g. on-screen, email, SMS, push) and configurable escalation rules if alarms are not acknowledged or resolved within defined timeframes.

• Alarm Acknowledgement & Comments

  Alarm acknowledgement and closure shall require user authentication and allow entry of comments/actions, with full audit trail.

• Testing & Simulation

  The system shall support controlled testing of alarm functions (e.g. alarm simulation mode) without corrupting production data or creating false excursion records.

---

7.1.6 Software Validation Expectations

You’re not just buying features; you’re buying evidence that the system can be trusted.

Sample URS statements

• Risk-Based Validation

  The supplier shall support a risk-based validation approach consistent with industry good practice, providing documentation and guidance to enable the customer to perform or oversee Computer System Validation (CSV) or equivalent activities aligned with applicable GxP expectations.

• Vendor Documentation

  The supplier shall provide, on request, system descriptions, configuration guides, test summaries, and change history relevant to validation and ongoing lifecycle management.

• Change Control & Updates

  The system shall support controlled deployment of updates and configuration changes. The vendor shall provide release notes and impact assessments for new versions to support customer change control and re-validation decisions.

---

7.1.7 Integration Requirements (API, BMS, DCIM, ERP, WMS, QMS)

Integrations are where great ideas die if you don’t specify them early.

Core API expectations

The system shall provide documented, secure APIs (e.g. REST/JSON) for reading measurement data, alarm states, device status, and for integrating with third-party systems including BMS, DCIM, ERP, WMS, LIMS, and QMS.

Integration scenarios to specify

• Push alarms into BMS / DCIM or ticketing systems.
• Link temperature history to batch / lot / shipment records in ERP / WMS.
• Feed excursions into QMS for deviations and CAPAs.

Security & performance

APIs shall support authentication, authorisation, and encryption consistent with organisational IT security policies, and shall be capable of handling expected transaction volumes without performance degradation.

---

7.1.8 Data Backup, Retention, Access Controls & Security

This is the “what happens when something breaks” section.

Sample URS items

• Backup & Restore

  The system shall support regular, automated backups of configuration and data, with documented restore procedures. Backups shall be tested periodically according to the organisation’s policies.

• Retention

  The system shall allow configuration of data retention periods aligned with regulatory and business requirements, ensuring that data remain retrievable, readable, and intact for the full retention period.

• Access Control

  The system shall support role-based access control, allowing segregation of duties between operators, reviewers, administrators, and IT/technical users.

• Security

  The system architecture and implementation shall meet organisational cybersecurity policies, including secure communication (e.g. TLS), hardened endpoints, and appropriate logging of security-relevant events.

---

7.1.9 “Everything Else” You Shouldn’t Forget

Beyond the headings in your outline, your URS should also address:

• Scalability & multi-site support – maximum number of devices/sites; ability to manage global hierarchies.
• Usability & localisation – language support, time zones, units (°C as primary, optionally °F), mobile access.
• Service & support – availability of local support, response times (to be mirrored in SLA), training options.
• Reporting – standard and custom reports, scheduling, export formats.

You can add these as separate URS sections or fold them into the above categories.

---

7.2 Procurement-Ready RFP Template

Once your URS is approved by QA, you can translate it into an RFP that is:

• Tight enough that vendors can’t dance around requirements.
• Structured enough that Procurement can score and compare responses.
• Governance-friendly so Quality can veto non-compliant offers early.

Below is a suggested RFP structure you can adapt.

---

7.2.1 Recommended RFP Structure

1. Introduction & Background
   • Brief description of your organisation, regulatory context, and high-level objectives.
2. Scope of Work
   • Environments covered (warehouses, cold rooms, reefers, retail, data centres, etc.).
   • Geographic scope (single site / multi-country).
   • Hardware, software, services, support.
3. Reference URS
   • Attach the URS as an annex.
   • Instruct vendors to respond item-by-item where required.
4. Response Instructions
   • Submission format (Word/Excel/PDF).
   • Timelines, contact points, Q&A process.
   • Clarification call rules, site visit options.
5. Evaluation Process
   • High-level criteria and weightings (to manage vendor expectations).
   • Stages: pre-qualification, detailed evaluation, demos, site visits, pilots.
6. Commercial Terms
   • Pricing structure expectations (licence vs subscription, calibration fees, mapping services, support).
   • Contract length, renewal, exit conditions.
7. Compliance & Legal
   • Data protection, information security, confidentiality, IP, jurisdiction.
8. Annexes
   • URS matrix.
   • Site list.
   • Example mapping & monitoring scenarios.
   • Response templates (tables) for easy scoring.

---

7.2.2 Pre-Qualification Questionnaire (PQQ)

The PQQ is your first filter. Vendors who fail here shouldn’t proceed.

Suggested PQQ sections (Yes/No + short evidence)

1. Company & Experience
   • Have you implemented temperature mapping and/or monitoring systems for at least X organisations in [pharma / food / logistics / data centres] in the past Y years?
   • Do you have references available in similar regulatory environments?
2. Regulatory & Standards Familiarity
   • Do your solutions currently support compliance with:
     • Good Distribution Practice (e.g., EU GDP-equivalent)?
     • HACCP-based food safety schemes?
     • Data integrity expectations based on ALCOA/ALCOA+?
     • Data centre thermal management aligned with relevant guidelines (e.g., ASHRAE classes), where applicable?
3. Calibration & Metrology
   • Are your calibration services performed by, or traceable to, accredited labs (e.g., ISO/IEC 17025) for temperature and humidity?
   • Can you provide sample calibration certificates on request?
4. Platform & Architecture
   • Is your monitoring platform currently in active use with at least X concurrent customers?
   • Do you support both on-prem and hosted/cloud deployment models (if required)?
   • Do you provide documented APIs for integration (e.g. REST/JSON)?
5. Security & Data Hosting
   • If offering a hosted/cloud solution, do you host in recognised, audited data centres (e.g., ISO 27001-certified)?
   • Can you support data residency requirements if applicable?
6. Support & Services
   • Do you offer temperature mapping services and/or work with preferred partners?
   • Do you provide implementation and validation support and documentation?

You can set mandatory thresholds (e.g., any “No” to designated questions = disqualification).

---

7.2.3 Evaluation Scoring Table

After pre-qualification, you need a structured way to compare compliant vendors.

Example evaluation matrix (high level)

Scoring

• Each criterion scored 1–5 or 1–10.
• Weighted totals calculated for an overall score per vendor.
• Quality/Compliance should explicitly sign off the Regulatory & Data Integrity Fit category; no vendor should be selected with a poor score there even if they are “cheap”.

---

7.2.4 SLA Clauses

SLA clauses make the vendor’s promises contractual, not aspirational.

Key SLA dimensions to consider

1. Platform Availability

   • Uptime commitment (e.g., ≥ 99.5 % or 99.9 % per month, excluding planned maintenance).
   • Maintenance windows and notice periods.

2. Support Response & Resolution Times

   • Severity levels (Critical / High / Medium / Low).
   • Response time and target resolution times by severity and region.

3. Alarm Delivery & Data Loss

   • Expectations around alarm delivery (e.g., “alarms shall be enqueued and delivered via at least one channel in case of partial outages”).
   • Maximum acceptable data loss in case of severe incidents (ideally zero for monitoring; emphasis on buffered storage).

4. Change & Release Management

   • Advance notice for changes that may affect validated status or integrations.
   • Options to defer certain updates in validated environments (with agreed timelines).

5. Calibration & Service Turnaround (if vendor provides this)

   • Turnaround time for off-site calibrations.
   • Commitment for on-site service response (e.g., within X days for critical equipment).

6. Data Ownership & Exit

   Data collected via the system remains the exclusive property of the customer. The supplier shall provide mechanisms and support to export historical data and configurations in a usable format (e.g., CSV/JSON/PDF for reports) in the event of contract termination or system migration.

---

7.2.5 Compliance Checkboxes

This is where you make vendors visibly commit to specific obligations.

You can include a table like:

Regulatory & Standards Alignment

Please indicate compliance status and provide supporting documentation where available.

You can add environment-specific rows depending on where you operate (blood banks, vaccine cold rooms, data centres, etc.).

---

7.2.6 Bringing URS & RFP Together

In practice:

• URS = your internal “truth”. Owned by Quality, aligned to risk and regulation.
• RFP = the vendor-facing version that:
  • Presents context and scope.
  • Asks vendors to respond against your URS, not their brochure.
  • Builds in scoring and compliance visibility for Procurement and QA.

If you get Chapter 7 right, you’ll never again have to say:

“We bought a great-looking system… and now we’re reverse-engineering requirements to justify it to auditors.”

Instead, you’ll be able to say:

“We know exactly what we asked for, why we asked for it, and how this system meets those requirements across all our environments.”

From here, the natural next step is to turn these structures into ready-to-use URS matrices, vendor scorecards, and checklists that your teams can plug straight into their next project.

---