Why Your URS Is a Wish List — and What That’s Costing You
A User Requirements Specification for automation equipment is supposed to define what the equipment must do. In practice, most manufacturers write a wish list — things they’d like, not binding requirements. The gap between those two documents is where change orders live. Getting from a wish list to a real URS isn’t complicated, but it requires knowing what a vendor can actually be held accountable for.
There’s a version of the URS that procurement teams in medical device and IVD manufacturing write all the time. It says things like “accurate dispensing,” “easy to clean,” and “compliant with applicable regulations.”
Vendors read those specifications and quote accordingly. They interpret “accurate dispensing” to mean whatever their standard equipment does. They interpret “compliant with applicable regulations” to mean CE-marked. They build the machine. It shows up. The qualification testing finds the gaps.
That’s when the change orders come.
The frustrating part isn’t that vendors behave badly. It’s that the URS gave them permission to guess. An equipment specification written in vague language is less a requirement document and more a list of hopes. Hopes don’t hold vendors accountable. Tolerances do.
This post covers exactly what a URS needs to say to function as a binding specification — not just a document that satisfies your QA team’s template requirement.
The Difference Between a Wish and a Requirement
Most of the language teams put in a URS isn’t wrong — it’s just not specific enough to be enforceable.
Here’s what that looks like in practice.
| Wish | Requirement |
|---|---|
| “The equipment shall dispense accurately.” | “The equipment shall dispense to ±2.0% CV across the operating flow rate range of 10 µL to 1 mL, at all production speeds, across 3 consecutive production runs.” |
| “The system shall comply with applicable FDA regulations.” | “The system shall comply with 21 CFR Part 11 electronic records requirements, including audit trail, electronic signature, and access control. The vendor shall provide an IQ/OQ/PQ protocol package and participate in a 3-day FAT at their facility.” |
| “The equipment shall be easy to maintain.” | “All product-contact components shall be accessible without tools. Scheduled maintenance tasks shall be completable by a single operator in under 30 minutes. Spare parts shall be available from stock within 5 business days.” |
Notice what changed. The requirements version specifies the condition, the measure, and the context. Any vendor reading the requirement version knows exactly what they’ll be tested against. That specificity is what closes the change order door.
According to SCIENION’s analysis of why automation projects fail at the URS stage, underspecified requirements are the leading driver of cost overruns in custom automation builds. The insight holds for capital equipment procurement in regulated manufacturing: every requirement you leave vague becomes an assumption the vendor makes for you.
What a Vague URS Actually Costs
Change orders on capital automation equipment in medical device manufacturing aren’t small. A single change order to modify software scope after the machine is built typically runs $15,000–$50,000. Mechanical rework or reinstallation runs higher.
But the dollar figure on the change order form understates the real cost. A change order during build delays delivery. A change order during qualification delays your 510(k) or PMA timeline. In consumable diagnostics and IVD manufacturing, delayed product launch has a cost that doesn’t show up on the change order form at all.
Per Cybertrol Engineering’s analysis of scope creep in automation projects, scope creep doesn’t start during build — it starts during requirements. By the time a vendor quotes, the assumptions are already baked in. The change order is just when you find out what the assumptions were.
This is why the GAMP process starts at the CRD, before the URS. A Conceptual Requirements Document captures what the equipment needs to do in plain language before anyone writes a technical specification. That step prevents the most common failure mode: writing the URS before you’re clear on what you actually need.
The Seven Sections That Have to Be in a Real URS
A URS for capital automation equipment in a regulated manufacturing environment isn’t just a bullet list of desired features. It’s a technical specification that becomes the acceptance criteria for every downstream document — the FAT protocol, the IQ/OQ/PQ, the SOPs.
These seven sections are where most vague URSs fail:
- Performance and throughput. Not just “high speed” — the target output rate in units per hour at a specified yield, across the operating range, at your actual process parameters.
- Accuracy and repeatability tolerances. The specific tolerance, the method for measuring it, the number of samples required to demonstrate it, and the conditions (speeds, volumes, temperatures) under which it must hold.
- Material compatibility. Which product-contact materials are acceptable. Which aren’t. Compatibility data required from the vendor, or your own compatibility testing that defines the spec.
- Utilities and facility interface. The electrical service (voltage, phase, amperage), pneumatic supply (pressure, flow, quality), water (if applicable), and environmental conditions (temperature range, humidity, cleanroom class). Not “standard utilities” — your actual facility specifications.
- Software and data requirements. Recipe management specifics. Audit trail depth and storage. User access levels. 21 CFR Part 11 scope. LIMS or ERP interface requirements. HMI language and format.
- Regulatory and validation scope. Which standards apply (ISO 13485, FDA 21 CFR Part 820, applicable harmonized standards). What the vendor is responsible for (FAT support, IQ/OQ/PQ protocol authoring, on-site installation support). What the qualification timeline looks like.
- Maintenance and service requirements. Scheduled maintenance interval and estimated time. Required tooling. Spare parts availability commitment. Service response time.
Assembly Magazine’s 2022 guide to URS development covers some of these categories for general assembly automation — but medical device and IVD manufacturers carry an additional layer of regulatory specificity that general automation guidance doesn’t address. The software and validation scope sections in particular require a different standard than what a commercial manufacturing URS needs.
The URS as FAT Protocol Foundation
This is the piece most manufacturers miss when they write the URS.
The URS doesn’t just define what you want the equipment to do. It defines what the vendor has to prove the equipment does, at their facility, before it ships. The Factory Acceptance Test protocol is the URS in test form — each requirement becomes a test, with a pass/fail criterion, an operator, and a signature line.
If the URS says “accurate dispensing,” the FAT can’t test it properly. What does “accurate” mean? What’s the pass criterion? Who signs off?
If the URS says “dispense to ±2.0% CV across 10 µL to 1 mL at all production speeds,” the FAT protocol writes itself. The vendor knows what they have to prove. The FAT engineer knows what constitutes a pass. And when the equipment arrives at your facility, the IQ/OQ/PQ just confirms that it still does at your site what it proved it could do at theirs.
The change order prevention logic is sequential. A specific URS → a meaningful FAT → an IQ/OQ/PQ that doesn’t uncover surprises. The URS written as a wish list breaks every downstream document, not just the first one.
Who Should Write the URS
This one matters more than most procurement teams realize.
The URS needs to be written by someone who understands three things simultaneously: what the equipment needs to do for your process, what your quality system requires from a regulatory standpoint, and what vendors can realistically build and be held accountable for.
That’s a fairly unusual combination. Most QA engineers are strong on the regulatory side and less experienced with equipment performance requirements. Most operations engineers know the process but haven’t written GAMP documentation before. Most vendors are strong on what their standard equipment does and less objective about what your requirements actually are.
This is part of why the URS is chronically underspecified. It usually gets written by whoever has bandwidth, not whoever has the right combination of experience to write it well.
Working exclusively on the manufacturer’s side — not as a vendor representative, not as a validation consultant working from the quality template — means MEPSCo GAMP’s URS development work covers the full scope: process requirements, regulatory requirements, and what the vendor needs to be held accountable for. The result is a specification that closes the assumption gaps before the RFQ goes out.
For more on the full GAMP process from CRD through qualification, see what GAMP documentation actually costs and what’s included.
What Happens When the URS Gets Treated as a Wish List
You can usually tell a wish list URS from a real one by looking at what happens after the equipment is ordered.
When the URS is vague, the vendor’s Functional Requirements Specification (FRS) comes back with their assumptions spelled out. QA reviews the FRS and flags items that don’t match expectations. Someone has to negotiate which items were “requirements” and which were “nice to haves.” Some of those conversations happen before the machine is built. Some don’t.
The ones that happen after the machine is built are change orders.
The ones that get missed entirely show up in IQ/OQ/PQ testing — which is the most expensive time to find a gap between what the equipment does and what your quality system requires.
Getting the URS right before the RFQ is the intervention that breaks this chain. It’s not about doing more paperwork — it’s about doing the specification work at the stage where it’s cheapest, before anyone has committed to building anything. If you’re starting a capital equipment procurement and want a URS review before the RFQ goes out, schedule a project review with MEPSCo GAMP.
Questions on URS Development for Automation Equipment
What’s the difference between a URS and a wish list in automation procurement?
A wish list states desired outcomes in vague language — “accurate dispensing,” “easy to clean,” “compliant with regulations.” A URS states specific, measurable, testable requirements — exact tolerances, test methods, sample sizes, and pass criteria. Vendors can be held accountable to requirements. They can’t be held accountable to wishes, and change orders are what happens when the gap surfaces.
What sections are typically missing from a weak URS?
The most commonly missing or vague sections are: performance tolerances (the exact accuracy and repeatability spec, not just “accurate”), utility interface specifications (actual facility pressures, flows, and electrical service), software scope (21 CFR Part 11 requirements, audit trail depth, recipe structure), and validation support scope (what the vendor is responsible for in FAT and IQ/OQ/PQ). These four gaps generate the majority of change orders in regulated manufacturing equipment projects.
Can the vendor write the URS?
A vendor can provide input, but they shouldn’t author the URS. A vendor-authored URS gets written to their equipment’s capabilities, not your requirements. The specification should define what you need; the vendor’s job is to propose how they’ll meet it. When the vendor writes the URS, the result usually is a specification that’s easy for them to satisfy — which means it may not capture what you actually needed.
How does the URS connect to the IQ/OQ/PQ?
Every requirement in the URS eventually becomes a test in the IQ/OQ/PQ. Installation Qualification confirms the equipment was installed to specification. Operational Qualification confirms it operates within the URS parameters. Performance Qualification confirms it produces acceptable output under production conditions. A URS written in vague language produces vague qualification protocols — and vague qualification protocols create audit risk when FDA inspectors ask what you were qualifying against.
When should the URS be written in the procurement timeline?
The URS should be complete before the RFQ goes out — ideally after a Conceptual Requirements Document (CRD) captures the plain-language operational requirements, but before any vendor conversations. The common mistake is starting vendor conversations first, letting vendor capabilities shape the specification, and then writing the URS to match what the preferred vendor can build. That’s the order that guarantees change orders.
Get the URS Right Before the RFQ Goes Out
A specification that defines tolerances, test methods, and acceptance criteria is what holds a vendor accountable — and what keeps change orders off your build. MEPSCo GAMP writes URS documentation exclusively on the manufacturer’s side, from CRD through qualification.