URSUser Requirements Specification

A User Requirements Specification (URS) is the document that captures, in business and regulatory language, what a computerised system must do. It is the starting artefact of the GAMP 5 V-model: every subsequent specification (Functional Spec, Design Spec, Configuration Spec) describes how the system meets it, and every test script (IQ, OQ, PQ, PPQ) proves that it does. Without a URS there is nothing to validate against, because there is no definition of "correct."

The URS is owned by the customer, not the supplier. The supplier may help draft it — especially for configured Category 4 products like V5 Ultimate where the supplier knows the system's capabilities best — but final sign-off must come from the business owners and from Quality. If Quality has not signed the URS, the validation project is built on sand: there is no agreed definition of what "works" means, and the eventual PQ has nothing fixed to test.

A URS is not a wish list, a feature inventory, or a technical design. It is a contract between the business that needs the system and the people who will build, configure, validate and use it. Every word in it should survive being read out by an FDA or MHRA inspector five years from now.

GAMP 5 organises specification and verification activities as a V — specifications descend on the left, the system gets built at the bottom, verification activities ascend on the right, and each verification activity tests against its matching specification:

The URS sits at the very top of the V. It is satisfied by the PQ, which proves that the system, in the customer's environment, with the customer's data and users and processes, does what the URS said it must do. PQ failures almost always trace back to URS gaps.

1. Scope — what the system is for, what is in scope, what is out of scope, what assumptions are made.
2. Business process requirements — workflows the system must support (formula approval, work-order release, kiosk dispense, batch close, QC, deviation, CAPA, complaint handling, supplier control).
3. Data requirements — what is captured, by whom, when, retention period, archive format, restore expectation.
4. Regulatory requirements — Part 11, Annex 11, data integrity (ALCOA+), industry-specific (FSMA 204, MoCRA, DSCSA, 21 CFR 820.30, 21 CFR 212, etc.).
5. Security requirements — RBAC matrix, e-signature manifestation, audit-trail content, password policy, session management, MFA, idle-lockout.
6. Interface requirements — what the system must integrate with (ERP, LIMS, scales, label printers, IoT sensors, MES) and the direction / latency expectations.
7. Performance and capacity — concurrent users, transactions per hour, storage growth, RPO / RTO, time-to-restore-from-backup.
8. Constraints — environments (on-prem, cloud, hybrid), browser / device support, languages, accessibility, network bandwidth, time-zone handling.
9. Validation lifecycle requirements — change-control expectations, periodic review, decommissioning.

Each requirement gets stated as a single declarative "shall" statement with one verifiable outcome. "The system shall record the user ID, date and time on every e-signature" is a requirement. "The system shall be user-friendly" is not — it's untestable and therefore useless.

Every URS line should pass five tests:

1. Single — one requirement per line. Compound "shall do A and B" sentences cause coverage problems in the traceability matrix.
2. Testable — a tester can write an objective pass/fail script. "User-friendly," "fast," "intuitive" do not qualify.
3. Unambiguous — two readers reach the same interpretation. "Promptly," "appropriate," "reasonable" are red flags.
4. Necessary — if you remove it, something the business actually needs breaks. Nice-to-have requirements bloat the validation cost.
5. Implementation-free — describes what, not how. "Shall use Postgres" or "shall implement a REST API" belong in the DS, not the URS.

Every line in the URS must have a unique, immutable identifier — typically URS-001, URS-002, URS-003 and so on, sometimes prefixed by domain (URS-SEC-001 for security, URS-DI-014 for data integrity). This identifier is what the FS references, what the test script references, what the traceability matrix lists, and what the auditor follows when they ask "show me where you tested this requirement."

Alongside the identifier, each requirement carries a risk classification — typically Critical / High / Medium / Low — which drives test depth. Critical requirements get scripted, witnessed, and re-tested on every change. Low requirements may get demonstrated once at OQ and skipped at PQ. Classification has to be agreed before testing starts, not assigned retroactively to explain why a failing test "doesn't matter."

The URS should reference each regulation by clause and translate it into a system requirement. "Shall be Part 11 compliant" is not a requirement — it's an aspiration. "The system shall require a two-component e-signature at the start of each session (21 CFR 11.200(a)(1)(i)) and a single-component re-authentication for each subsequent signature in the same session" is.

Every modern regulator (FDA, MHRA, EMA, PIC/S, Health Canada) treats data integrity as a top-three inspection focus. A defensible URS has an explicit Data Integrity section that addresses each ALCOA+ attribute as a requirement, not buried in functional clauses:

• Attributable — every GxP record carries the user ID of the creator and of any modifier. No shared logins.
• Legible — records remain human-readable for the full retention period, including after format / version migration.
• Contemporaneous — records are captured at the time of the event, with server time, not backfilled.
• Original — the first capture ("raw data") is preserved; printed PDFs are derived, not primary.
• Accurate — input validation, scale / instrument tare and stable-read enforcement, two-person verification where required.
• Complete — audit trail captures the full "who/what/when/why" including any failed attempts or repeats.
• Consistent — date/time format, timezone handling, units of measure all standardised.
• Enduring — backup, restore-tested, off-site copy, retention through the legal period.
• Available — retrievable on demand by Quality and by regulators within the agreed SLA.

A URS without the right signatures is just a draft. Minimum sign-off panel for a GxP system:

• Process Owner — the business head whose process the system supports (Head of Manufacturing, Head of QC, Head of Supply Chain).
• Quality / QA — must sign, no exceptions. Quality owns regulatory acceptance.
• IT / System Owner — confirms feasibility and lifecycle responsibility.
• Validation Lead — confirms requirements are testable and the validation plan can execute against them.
• Supplier / vendor representative — optional, but useful to confirm the supplier accepts the requirements as in-scope.

The URS lives. Business processes evolve, regulations update, and the system adds capabilities. Every change after sign-off must go through formal change control: a written change request, an impact assessment against every downstream artefact (FS, DS, test scripts, training, traceability matrix), two-person Quality approval, version bump (URS v2.0 → v2.1), and re-execution of any test scripts affected by the changed clause.

What you must not do: silently edit the URS, append requirements without a version bump, or let the FS drift ahead of the URS. The traceability matrix is the audit trail of the requirements lifecycle — if it doesn't tie every test back to a current, approved URS clause, you have a finding.

• Requirements stated as vague verbs ("the system shall support…") with no acceptance criterion.
• Mixing requirements with design ("the system shall use Postgres") — design belongs in the DS, not the URS.
• No risk classification — every requirement treated as equally critical, blowing out test cost.
• Regulatory clauses copied without being made testable ("shall be Part 11 compliant").
• Renumbered partway through, invalidating every downstream document.
• Drafted by IT alone, never signed by Quality or the business process owners.
• No data-integrity section — ALCOA+ left implicit instead of being made explicit requirements.
• Out-of-scope items never explicitly stated, so scope-creep arguments later have no anchor.
• Version bumped silently with no change-control record, leaving Quality unable to reconstruct who agreed to what.

V5 ships a pre-written URS template covering the Part 11 / Annex 11 / ALCOA+ baseline plus per-industry extensions — pharma (BMR, MMR, 211.186/211.188), medical device (eDHR, DHF, 820.30), food (FSMA 204, HACCP, allergen, GFSI scheme overlay), supplements (111.255, 111.260), cosmetics (PIF, MoCRA), radiopharma (212, RG 1.86, decay handling).

Each requirement is pre-numbered (URS-CORE-001 through URS-CORE-180, plus URS-{INDUSTRY}-001+ extensions), pre-classified by risk, and pre-mapped to the V5 FS, DS and test scripts in the validation pack. The traceability matrix ships pre-populated — every URS line already linked to its FS section and its OQ / PQ script ID.

ISPE's GAMP 5 (Second Edition, 2022) classifies computerised systems into four categories that determine the depth of the URS, the rigour of the verification effort, and the supplier-audit posture. Picking the wrong category is the single most common cause of over- or under-validation budgets.

V5 Ultimate is GAMP 5 Category 4 (configured) — the platform code itself is supplier-validated and ships with a release-validation pack, but every tenant's configuration (industry profile, workflows, e-signature gates, training matrices) lives in their URS. A common trap is to treat the supplier's validation as covering the configuration; it does not, and an inspector will ask for the customer-side validation evidence within the first hour of any cGMP audit.

The URS is the first deliverable of the Computer System Validation (CSV) or, increasingly, the Computer Software Assurance (CSA) lifecycle. Where CSV historically expected the same test depth for every requirement, CSA — FDA's September 2022 draft guidance for medical-device software — formalises the risk-based approach GAMP 5 has urged for a decade. The shape of the lifecycle is unchanged; what changes is the test-rigour gradient.

• URS — what the business needs.
• Functional Specification (FS) — how the supplier intends to meet each URS item, including any configuration choices.
• Design Specification (DS) — for Category 5 only, the bespoke design at the component/code level.
• Configuration Specification (CS) — for Category 4 systems, the tenant-specific configuration captured as a versioned artefact (in V5, this is the workspace configuration export).
• Installation Qualification (IQ) — evidence that the system is installed per spec, on the correct infrastructure, with the correct dependencies.
• Operational Qualification (OQ) — evidence that the system operates per FS/DS/CS across the intended use range.
• Performance Qualification (PQ) — evidence that, in the customer's actual operational environment, the system performs reproducibly to URS expectations.
• Validation Summary Report (VSR) — release-to-production summary, two-person signed, traceable to every URS requirement via the RTM.

The Requirements Traceability Matrix (RTM) is the spine that ties URS → FS/CS → test → test result → release. Every URS requirement must trace forward to at least one verification artefact, and every verification artefact must trace back to a URS requirement. Orphan tests waste budget; orphan requirements are inspection findings.

FDA's CSA draft guidance and the parallel EU AI Act add a new requirement to URS authorship for any system that includes machine-learned components — even features as benign as predictive maintenance or anomaly detection at the line. The URS must explicitly state the intended use of the model, the failure modes it is allowed to have, the human-in-the-loop oversight, and the change-control regime for model retraining.

• Intended use statement: the URS must name the decision the model informs, who acts on the output, and what the consequence of a wrong output would be.
• Drift monitoring: the URS must specify the drift metrics (PSI, KS-test, performance degradation thresholds) the system must monitor and the alerting thresholds.
• Explainability: the URS must specify the minimum explainability the user-facing output must carry (e.g., 'feature contribution chart on every prediction').
• Retraining change control: any model retraining is a configuration change subject to the system change-control SOP. The URS must specify which retraining events constitute a regulatory change vs a minor configuration tweak.
• Bias and fairness: for any model that ingests demographic or patient-level data, the URS must specify the protected-attribute review the validation lifecycle performs.