How to Write a User Requirements Specification
Define what a system or equipment must do — the spine every qualification traces back to.
What a how-to is not
A how-to is SPEQ’s practitioner method, not a procedure. It does not replace your own SOP, it is not a validated approach, and the judgement calls in it belong to your quality unit.
A User Requirements Specification (URS) states what a system, equipment, or facility must do to meet the user’s and the process’s needs. It is the reference point for design qualification and every later verification. A vague URS makes qualification meaningless — you can only verify against requirements you actually wrote down.
- 1
Capture the real needs
Capture what the system actually has to do for the process and for the people who will operate it, gathered from those people rather than from the supplier’s feature list. Requirements written from a proposed solution describe that solution, and the test is simple: a requirement that names a product or a mechanism is usually a design decision that has been smuggled in ahead of the analysis.
- 2
Identify GxP-critical requirements
Identify which requirements are GxP-critical and say why, because those are the ones that will drive verification effort, and the reasoning has to survive the people who wrote it. Marking requirements critical by category produces a long list and no argument; deriving criticality from product-quality or patient-safety impact produces a short list that can be defended.
- 3
Write requirements that are testable
Write each requirement so that a test could fail it. Specific, singular, measurable, and free of words that cannot be verified — adequate, user-friendly, robust, as required. The discipline pays twice: once when the supplier quotes against something unambiguous, and again when verification can be planned without interpretation.
- 4
Make them traceable
Give each requirement a unique identifier and design the document so it can be traced forward to design, risk and verification, and backward from them. Traceability added later is reconstruction; built in from the start it is the mechanism that answers what a change affects, which is the question change control asks and usually cannot answer.
- 5
Review and approve
Review the document with operations, quality, engineering and — where relevant — the people who will clean and maintain the system, then approve it under change control. The requirements most often missing from a technically sound specification are about access, cleaning and maintenance, and they are cheapest to add here and most expensive to discover in use.
- !Requirements written as vague aspirations that cannot be tested.
- !Mixing "what" (requirements) with "how" (design), constraining the solution prematurely.
- !No identifiers, so requirements cannot be traced into qualification.
- !GxP-critical requirements not distinguished from the rest.
How to Write a User Requirements Specification: frequently asked questions
Common questions on write a user requirements specification.
What is a URS?
A User Requirements Specification defines what a system, equipment, or facility must do to meet the user and process needs. It states requirements (the "what"), not design (the "how"), and is the reference against which design qualification and later verification are performed.
Why must URS requirements be testable?
Because qualification verifies the system against the URS. A requirement that cannot be tested (vague or unmeasurable) cannot be verified, so it provides no assurance and creates ambiguity about whether the system is acceptable.
How does the URS relate to design qualification?
Design qualification (DQ) verifies that the proposed design meets the URS before building or buying. The URS is the input to DQ and the anchor of the traceability matrix that links requirements through design to qualification tests.