Computer System Validation

How to Write a User Requirements Specification (URS)

Updated 2026-11-07

The User Requirements Specification (URS) is the foundation of a validation. Everything downstream — the design, the risk assessment, the tests, the traceability matrix — hangs off it. Get the URS right and the rest of the package is far easier. Get it vague and you will feel the pain in every test script that follows.

This guide shows how to write a URS that holds up, using an invented example system throughout: a fictional sample storage freezer monitoring system in a QC laboratory. (For the basics of validation first, see what Computer System Validation is.)

What a URS is for

A URS states, in the user’s language, what the system must do to support the process — before anyone talks about how it will be built. It answers “what do we need?”, not “how does the software work?”. It is written by or with the people who will actually use the system, and it becomes the thing PQ ultimately tests against.

How to structure it

A workable structure for most systems:

  1. Introduction and scope — the system, its intended use, what is in and out of scope.
  2. Process description — briefly, how the system fits the workflow.
  3. Functional requirements — what the system must do.
  4. Data requirements — what data it holds, and data integrity expectations.
  5. Security and access — users, roles, authentication, segregation of duties.
  6. Interfaces — other systems or instruments it connects to.
  7. Environment and non-functional — performance, availability, backup, retention.
  8. Regulatory requirements — audit trail, electronic signatures, Part 11 / Annex 11 expectations.

The headings matter less than the discipline: every genuine need is captured, once, somewhere obvious.

What makes a good requirement

A requirement is good when it is:

  • Uniquely identified — a reference like URS-FR-012, so it can be traced to a test.
  • Testable — you can design a test that objectively passes or fails it.
  • Unambiguous — one reading, not three.
  • Atomic — one requirement per statement, so one failing part does not sink four requirements at once.
  • Necessary — tied to a real need, not a wish-list item nobody will test.
  • Risk-aware — flagged where it touches product quality, patient safety or data integrity, so testing effort can follow risk.

Good versus bad: worked examples

Bad: “The system should monitor temperature and alert the user appropriately.”

Why it fails: “should” (is it required or not?), “appropriately” (untestable), and it bundles monitoring, thresholds and alerting into one untraceable lump.

Better, split into atomic, testable requirements:

  • URS-FR-010 — The system shall record the temperature of each monitored freezer at intervals not greater than 5 minutes.
  • URS-FR-011 — The system shall generate an alarm when a freezer temperature is outside the range -25 °C to -15 °C.
  • URS-FR-012 — The system shall notify the on-call user by email within 2 minutes of an alarm condition.
  • URS-DI-020 — The system shall retain temperature records for a minimum of 5 years in a form that cannot be altered without an audit trail entry.

Each one is uniquely numbered, states “shall”, gives a concrete, measurable criterion, and can be matched one-to-one with a test.

A note on “shall”, “should” and “may”

Use shall for mandatory requirements — these get tested. Keep should and may out of the requirements themselves, or you create ambiguity about what must be verified. If it matters enough to validate, it is a “shall”. If it does not, it probably does not belong in the URS.

Common mistakes

  • Writing the solution, not the need. “The system shall use a SQL Server database” is a design choice, not a user requirement. State the need (“records shall be retained for 5 years”); let design decide the how.
  • Untestable adjectives. “User-friendly”, “robust”, “fast” — replace with a measurable criterion or drop them.
  • Requirements nobody will test. If no test will ever reference it, ask why it is there.
  • Missing the regulatory requirements. Audit trail, access control and electronic records are requirements too, not assumptions.
  • No unique IDs. Without them, you cannot build a traceability matrix, and the whole package becomes hard to defend.

How it connects to everything else

Each URS requirement should trace forward to a specification and to a test, and back again, in the traceability matrix. That is how you demonstrate, at inspection, that every requirement is tested and every test exists for a reason. A clean, atomic, uniquely-numbered URS makes that matrix almost write itself; a vague one makes it a nightmare.

Next