Written and maintained by CASRAI Editorial Board
Last updated
A user requirements specification (URS) is the first document produced in a GxP computer system validation (CSV) lifecycle, and the one everything else in that lifecycle ultimately gets checked against. It states, before a system is bought, configured, or built, what it must do — in language specific enough that a tester can later confirm, with objective evidence, whether the finished system actually does it. A URS that can’t be tested against isn’t a specification; it’s an intention.
This page covers what a URS needs to contain to survive that test, and how a single requirement written on day one turns into a specific, executed test script at Operational Qualification (OQ) and Performance Qualification (PQ). For the full IQ/OQ/PQ sequence and GAMP 5 software categorization the URS feeds into, see Computer System Validation (CSV): GAMP 5, IQ/OQ/PQ, and 21 CFR Part 11. For where the URS sits inside a lab’s broader validation programme, see Validation Master Plan (VMP) for a Regulated Laboratory. This page deliberately doesn’t repeat either — it’s about the one document, in depth.
Why the URS Is the Document Everything Else Is Tested Against
GxP validation runs on a simple discipline borrowed from the V-model: every requirement defined during planning must be traceable forward to a specific test that proves it was met, and every executed test must trace backward to a specific requirement that justified running it. The URS is where that chain starts. If a requirement isn’t in the URS, there’s no basis for writing a test for it — and inspectors reading a validation package specifically look for gaps in that chain, not just for passing test results.
This is what separates a URS from a marketing feature list or a vendor’s product datasheet. A vendor spec sheet describes what a system can do; a URS states what a system must do for this specific use, in this specific regulated context, written before anyone commits to how it will be met. Writing the URS from the vendor’s own datasheet — a common shortcut — inverts the logic: it validates that the system does what the vendor already claims, not that it does what the process actually needs.
What a URS Must Contain
A complete URS organizes its requirements into three categories. Mixing them into one undifferentiated list is one of the most common reasons a URS is hard to test against later — a reviewer (or an inspector) can’t quickly tell which requirements are operationally important and which are non-negotiable regulatory obligations.
| Category | What it covers | Example |
|---|---|---|
| Functional requirements | What the system must do — the specific operations, calculations, workflows, and outputs it must perform | “The system shall calculate % relative humidity from raw sensor voltage using the calibration curve stored in Table 3.2” |
| Non-functional requirements | How the system must perform — availability, response time, capacity, data retention, interoperability, usability constraints that aren’t a specific function but still have to be met | “The system shall retain raw and processed data for a minimum of 10 years in a format readable without the original application” |
| Regulatory requirements | Obligations that exist because of the applicable GxP framework itself, not because of the process being automated — tagged separately so they’re never accidentally dropped or treated as optional during descoping | “The system shall generate a secure, computer-generated, time-stamped audit trail (21 CFR 11.10(e)) that records the original value, the changed value, the user identity, and the reason for change for any GxP-relevant data” |
Tagging regulatory requirements as their own labeled category (rather than folding them into functional requirements) matters for a concrete reason: when a project descopes requirements under schedule or budget pressure, a clearly-tagged regulatory requirement is much harder to quietly drop than one buried in a general list. It also gives QA a fast way to confirm, at review, that every applicable regulatory obligation is actually represented before the URS is approved.
Writing a Requirement That Can Actually Be Tested
Every individual requirement in a URS should follow the same discipline: one requirement per statement, a unique identifier, and acceptance criteria specific enough that two different testers, executing the same test script, would reach the same pass/fail conclusion.
| Element | Purpose |
|---|---|
| Unique requirement ID (e.g. URS-014) | The anchor the traceability matrix references — without it, “traceability” is just a narrative, not a checkable table |
| One requirement per statement | A compound requirement (“the system shall X and Y”) can pass on X and silently fail on Y with no way to record that in a single traceability row |
| Verifiable acceptance criteria | A measurable, observable condition — not a description of intent. “Shall be user-friendly” cannot be tested; “shall complete a batch record review in no more than 3 operator actions” can |
| Source or rationale | Why the requirement exists — a specific process step, a regulatory citation, or a risk-assessment finding — so a later reviewer can tell whether it’s still needed if the process changes |
| Category tag | Functional, non-functional, or regulatory, per the table above |
Vague, common phrasings to avoid because they can’t be objectively tested: “should be able to,” “user-friendly,” “reasonably fast,” “as needed,” “where appropriate.” Each of these either hides an unstated assumption about what “fast enough” or “as needed” actually means, or defers a decision that the URS is supposed to have already made. If a requirement can’t be rewritten with a number, a specific condition, or a specific outcome, it isn’t finished yet.
The Traceability Chain: From URS to Executed Test Script
A single requirement moves through several documents on its way to being proven met. The chain, and what each stage adds:
| Stage | Document | What happens to the requirement |
|---|---|---|
| 1. Planning | User Requirements Specification (URS) | The requirement is stated, given a unique ID, and tagged functional / non-functional / regulatory |
| 2. Design | Functional or Configuration Specification | The requirement is translated into how the system will actually meet it — a specific configuration setting, workflow, or build feature |
| 3. Design | Traceability matrix | The requirement ID is mapped to the design element that addresses it and the test script that will verify it — built as the URS and design docs are written, not reverse-engineered afterward |
| 4. Execution — OQ | OQ test script | Functional and non-functional requirements are tested individually, including at boundary and error conditions, under controlled (not necessarily production) conditions |
| 5. Execution — PQ | PQ test script | The requirement is confirmed under actual operating conditions, with real (or representative) users and workflows — this is the step that closes the loop back to the original URS statement |
| 6. Closure | Traceability matrix (completed) | Every URS requirement shows at least one passing test reference; any requirement with no linked test, or a failed test with no resolved deviation, is a validation gap that blocks release |
The traceability matrix is what makes this chain auditable rather than assumed. Its two failure directions both matter: a requirement with no test reference means something was never actually verified, and a test with no requirement reference means effort was spent testing something nobody asked for — neither is a formality; both are common inspection findings.
URS Depth Scales With GAMP Software Category
Not every system needs the same weight of URS. GAMP 5’s risk-based, software-category framework (Category 3: non-configured or default-configured commercial off-the-shelf software; Category 4: configurable software; Category 5: custom-developed or custom-coded software) is what determines how much URS detail is proportionate. A Category 3 system — a balance or pH meter’s built-in firmware, used exactly as the vendor ships it — needs a URS scoped mainly to confirming the built-in function meets the process need and that the required regulatory controls (e.g. audit trail, access control) are present out of the box. A Category 5 custom-built LIMS workflow needs a full URS covering every custom function, because there’s no vendor-verified baseline to lean on. Writing a Category-5-depth URS for a Category-3 instrument is wasted validation effort; writing a Category-3-depth URS for custom code leaves genuine gaps untested.
Who Writes and Approves the URS
The URS is not a QA or IT document written in isolation — it’s owned by the people who will actually use the system, because they’re the ones who know what the process genuinely requires. In practice that usually means:
- Process owner / end users draft the functional and non-functional requirements — what the system needs to do for the actual work.
- Quality Assurance reviews and confirms the regulatory requirements are complete for the applicable GxP framework, and approves the final document before design work begins.
- IT / validation lead coordinates the document, confirms every requirement is stated in testable form before sign-off, and owns the traceability matrix as the project moves into design and execution.
A URS approved before design work starts, then formally change-controlled (not silently edited) if requirements shift during the project, is what keeps the traceability chain intact. A URS rewritten after the system is already built to match what was actually delivered isn’t a specification anymore — it’s documentation of a fait accompli, and it won’t hold up under inspection scrutiny of the original design-review record.
Common URS Mistakes That Cause Validation Rework
- Copying a vendor’s feature list instead of stating the actual process need. This produces a URS that trivially “passes” because it was written to describe the system, not the requirement — and it usually misses non-functional and regulatory requirements the vendor’s marketing material never mentions.
- Vague acceptance criteria. “System shall be reliable” cannot be tested; “system shall achieve 99.5% uptime measured over a rolling 30-day window” can.
- No regulatory-requirements category. When 21 CFR Part 11 or Annex 11 obligations are scattered through functional requirements instead of tagged separately, they’re the first thing lost when scope gets trimmed under schedule pressure.
- Building the traceability matrix after testing, not during requirements-writing. A matrix assembled retroactively from whatever got tested tends to match the testing that happened, not the requirements that were actually needed — the opposite of what traceability is for.
- No version control on the URS itself. If the URS changes mid-project without a documented change history, there’s no way to confirm which version of a requirement a given OQ/PQ test script was actually written against.
Frequently Asked Questions
What’s the difference between a URS and a Functional Specification?
The URS states what the system must do, from the user’s and the regulatory framework’s point of view, before anyone has decided how. The Functional (or Configuration) Specification, written next, states how the system will meet each URS requirement — the specific configuration, workflow, or build. The URS shouldn’t describe implementation details; the Functional Specification shouldn’t introduce requirements that weren’t in the URS.
Does every GxP system need a full URS?
Every GxP-relevant system needs a URS, but its depth should scale with GAMP software category and documented risk/GxP-impact assessment — a Category 3 off-the-shelf instrument needs a much lighter URS than a Category 5 custom-built system. See the GAMP category section above.
What happens if a system fails to meet a URS requirement during PQ?
It’s recorded as a deviation, investigated, and either resolved (with a re-test that closes the traceability chain) or the requirement itself is formally reassessed and the URS change-controlled — a PQ failure is never simply dropped from the record. See the Validation Summary Report, which closes a validation project by disposing of exactly this kind of open item.
Can the URS be written after the system is already selected?
It can be, and often is for commercial off-the-shelf systems where a vendor is chosen based on market research — but the URS should still be written and approved before configuration or build work starts, and should state requirements independent of that vendor’s specific feature set, so the document remains a genuine test of fitness rather than a retrospective description of what was bought.
Who signs off on the URS?
Typically the process owner or end-user representative (confirming it reflects actual operational need), and Quality Assurance (confirming regulatory completeness) — both before design or configuration work begins. See “Who Writes and Approves the URS” above.
