Write the URS Before You Build

Why Requirements Come First for Facilities, Equipment, and Processes

By Kate Evans, PhD, and Andrew Samann · Intrepid Scientific · 2026-10-08

Companion pieces: Compliant by Design (the facility URS in detail) · Requirements Before Walls (the testing-laboratory version) · Built to Be Qualified (the equipment side).

The cheapest time to decide what a facility, a piece of equipment, or a process must do is before anyone has drawn it, bought it, or run it. A complete User Requirement Specification (URS) is how that decision gets made and written down.

Most labs and manufacturing sites know they need a URS. Fewer write it first. The usual pattern is that a vendor quote, an architect's drawing, or an urgent production need arrives, the project starts moving, and the URS gets written afterward to match what was already chosen. That document satisfies a checklist. It does not do the job a URS exists to do.

This article covers two things. First, why writing the URS before you build is one of the highest-return activities in a capital or process project. Second, what a URS actually is, in plain language, for anyone who has been handed one and asked to sign it.

1. Why Write the URS Before You Build

A URS written first shapes the project. A URS written later only describes it. Here are the reasons that matter most, whether the project is a new cleanroom, a new autoclave, or a new production process.

You cannot verify what you never specified. Every qualification activity that follows, from design review through installation, operational, and performance qualification, is a test against requirements. If the requirements were written after the equipment arrived, the tests prove only that the equipment does what the equipment does. Regulators understand this. EU GMP Annex 15 expects the specification for equipment, facilities, utilities, and systems to be defined in a URS, and it names the URS as the point of reference throughout the validation life cycle. An inspector who finds a URS dated after the purchase order will ask what the qualification was actually qualifying.

Changes get more expensive the later they happen. A requirement that costs an hour to add to a document can cost a week to add to a drawing, a month to add to fabricated equipment, and a quarter to add to a commissioned facility. Each stage locks in decisions the next stage builds on. A missing drain slope, an undersized HVAC zone, a data export the lab system cannot produce, or a cleaning step the line cannot accommodate are all cheap to catch in a URS review and expensive to catch anywhere else.

It gives suppliers something to bid against. Without a URS, suppliers quote what they normally sell. Each bid describes a different product, so the comparison is meaningless and the lowest price usually wins. With a URS, every supplier answers the same questions, and the gaps in each proposal become visible before the contract is signed. The URS also becomes the basis of the contract, so a shortfall discovered at factory acceptance is the supplier's problem to fix rather than yours.

It forces the right conversation at the right time. Writing a complete URS requires quality, operations, engineering, maintenance, EHS, and IT to agree on what the thing must do. That agreement is hard. It is also unavoidable, and the only choice is whether it happens around a document or around a half-built installation. Operators know which transfers are awkward, maintenance knows which parts fail, and quality knows which records the next audit will ask for. The URS is where that knowledge is captured while it can still change the design.

It makes the verification effort proportionate and defensible. A URS is where requirements are classified as critical to product quality, patient safety, or data integrity, or as ordinary business needs. That classification drives the risk assessment and decides where testing effort goes. Without it, teams either test everything to the same depth, which wastes months, or test what is convenient, which fails inspection. With it, a lean qualification package has a documented reason for being lean.

It protects you from building the wrong thing well. Projects without a URS tend to drift toward what the vendor offers, what the architect has done before, or what the loudest stakeholder wants. The result can be installed perfectly, qualified fully, and still not fit the process it was meant to serve. The URS anchors the project to the intended use, which is the only standard that matters.

2. What It Looks Like When the URS Comes Late

Consider a composite example that will be familiar to anyone who has worked on a site expansion. A contract manufacturer wins a new product and needs a second filling line. The vendor who supplied the first line offers a near-identical machine at a good price with a short lead time. The project is approved on that basis. The URS is assigned to a validation engineer and written in a week, largely from the vendor's own functional description.

The line is installed and qualified without incident. Then production starts. The new product uses a different container that the line can run only at reduced speed. The customer's quality agreement requires batch records in a format the line's controller cannot export, so operators transcribe by hand. The cleaning procedure needs a solvent the gasket material was never rated for. None of these were tested in qualification, because none of them were requirements.

Every one of these problems was knowable before the purchase order. The container format was in the product dossier. The record format was in the quality agreement. The solvent was in the cleaning validation master plan. A complete URS would have asked each of those questions and sent the answers to the vendor before anything was built. Instead the site spent the first year of production on change controls, deviations, and a controller upgrade, with the customer watching.

Nothing in that story is unusual. It is simply what happens when the document that was supposed to define the project is written to fit the project instead.

3. What a URS Is, in Simple Terms

A User Requirement Specification is a written description of what something must do for the people who will use it, before anyone decides how it will do it.

The word that matters is user. The URS is written from the point of view of the operators, analysts, quality staff, and maintenance technicians who will live with the result. It describes the process they need to run, the products or samples they need to handle, the records they need to produce, and the conditions they need to maintain. It does not describe motors, valve types, or software vendors. Those are design decisions, and they belong to the people who answer the URS, not to the people who write it.

A useful way to think about it is a job description for a facility, a machine, or a process. A job description says what the role must accomplish, under what constraints, and how performance will be judged. It does not name the candidate. The URS does the same thing. It says what the system must accomplish, under what constraints, and how the site will know it is working. The design, the supplier, and the equipment are the candidates.

Each requirement in a URS is a single, testable statement. "The autoclave must hold 121 °C for 15 minutes at every location in a defined maximum load" is a requirement. "The autoclave must be reliable" is not, because no test can confirm it. Writing requirements this way is harder than it sounds, and it is where most of the value of the exercise comes from. Every vague statement that gets sharpened into a testable one is an argument the project will not have later.

The URS is also the first link in a chain. Design documents answer it, test protocols verify it, and the final report traces every requirement to the evidence that it was met. That chain is what a regulator inspects when they ask whether a system is fit for its intended use. If the first link is weak or missing, the rest of the chain has nothing to hold on to.

4. What a Good URS Contains

The exact structure varies by site and system, but a complete URS for a facility, equipment, or process covers the same ground.

Intended use. What the system is for, which products or processes it supports, and where it sits in the overall workflow.
Process and performance requirements. Throughput, capacity, ranges, tolerances, cycle times, and the operating conditions the system must hold.
Product and material requirements. What goes in and what comes out, including container formats, materials of construction, and compatibility with cleaning and sanitising agents.
Regulatory and quality requirements. The GxP expectations the system must meet, including data integrity, audit trails, electronic records, and the controls a future inspector will expect to see.
Facility and utility requirements. Space, environmental classification, HVAC, power, gases, water quality, drainage, and interfaces with adjacent systems.
Safety, environmental, and ergonomic requirements. Operator protection, containment, emissions, noise, and access for cleaning and maintenance.
Documentation, training, and support requirements. What the supplier must deliver with the system, including drawings, manuals, certificates, software documentation, and spare parts.
Constraints and assumptions. Budget, schedule, site standards, and anything the supplier must take as given.

Each requirement should carry a unique identifier, a classification of how critical it is, and enough precision that a test can confirm it. The document should be reviewed by every function that will use or support the system, and approved before it goes to suppliers.

What a URS is not. It is not a design specification, so it should not name components or dictate solutions unless the site has a genuine reason to. It is not a vendor brochure rewritten in the site's template. It is not a document that one engineer writes alone. And it is not finished when it is approved. A URS is a living document that is updated under change control as the project learns, but every update is deliberate, recorded, and traceable, which is exactly the point.

5. Where to Start

If a project is already on the calendar and the URS has not been written, write it now, before the next purchase order or design freeze. If the project has not started, make the URS the first deliverable and make its approval the gate that releases the budget. The document takes weeks, not months, when the right people are in the room, and it pays for itself at the first design review.

Three habits make the difference between a URS that drives a project and one that decorates it:

Start from the process, not the equipment. Describe what the site needs to make, test, or store, and let the requirements follow from that.
Involve the people who will use the system. Operators, analysts, and maintenance staff know what goes wrong. Quality knows what the next inspection will ask.
Make every requirement testable, and decide up front which ones are critical. That decision shapes everything that follows.

Intrepid Scientific helps labs and manufacturers write, review, and defend user requirement specifications for new facilities, equipment, and processes. If you are planning a build or an expansion and want the requirements right before the first drawing is issued, get in touch.