How to write an automation URS that aligns engineering, operations, and quality

Author:
Marc Fuentes
VP Commercial Growth

To write an automation user requirements specification (URS) that aligns engineering, operations, and quality, state what the system must achieve in numbers, assign every requirement an owner, and attach an acceptance test to each one. A strong automation URS defines throughput, overall equipment effectiveness (OEE), first-pass yield, changeover time, and data requirements as measurable targets, then links each to a factory acceptance test (FAT) or site acceptance test (SAT) criterion. Write it with all three functions in the room, before you request quotes. The payoff is a single document that suppliers can quote accurately, engineers can design against, and quality can verify.

Why do automation projects drift when the URS is vague?

Automation spending is rising, and so is the number of specifications written under schedule pressure. Deloitte’s 2026 manufacturing industry outlook reports that 80% of surveyed manufacturing executives plan to put 20% or more of their improvement budgets into smart manufacturing. The International Federation of Robotics counted more than 600,000 new industrial robots installed in 2025, an 11% jump that pushed the global operating stock to five million units.

Delivery has yet to keep pace with that ambition. McKinsey research suggests most large capital projects overrun cost or schedule by roughly 30 to 45 percent. An older but still widely cited PMI requirements management study from 2014 traced 47% of unsuccessful projects to inaccurate requirements management. In factory automation, that gap shows up as change orders, disputed acceptance tests, and a slow ramp to rate.

Key takeaways

What belongs in an automation URS?

A URS describes what the system must do and how you will prove it. The design stays with the supplier. Organize the document by owner so each function writes, reviews, and signs its own section.

What should engineering define?

Engineering sets the process and technical boundaries: product variants and tolerances, cycle time per station, footprint, utilities, safety standards, and plant standards for PLC platforms, industrial robotics, and machine vision. Include interface requirements for existing equipment and operational technology networks.

What should operations define?

Operations sets the performance the line must hold in daily production: throughput, OEE, changeover time, staffing per shift, and maintenance access. Add data requirements here, including MES and SCADA integration, Industrial IoT tags, and the signals a predictive maintenance or Industrial AI program will need later.

What should quality define?

Quality sets critical-to-quality characteristics, inspection methods, traceability depth, electronic record and audit trail needs, and the documentation required for validation. In regulated plants, these requirements drive design qualification, so they belong in the first draft.

How do you make each requirement measurable?

Give every requirement a unique ID, one “shall” statement, a number, a unit, and the conditions under which it applies. Mark each as mandatory or desired so suppliers know where trade-offs are welcome. The examples below are illustrative.

Describe the outcome and leave the method open. A requirement that names a specific robot model narrows the supplier’s options and can keep a better solution out of the quote.

How do you set acceptance criteria all three teams will sign?

Build a traceability matrix that links each URS ID to a design element, a test, and a pass threshold. Define sample size, run duration, and who witnesses each test. Agree on the matrix before the purchase order, because acceptance criteria negotiated during FAT cost schedule and goodwill.

Digital twins move part of that proof earlier. McKinsey lists digital twins among the technologies capital project teams use to optimize design and scope. Simulation checks cycle time, robot reach, and PLC logic against the URS before the build starts, and Eclipse RealitySync™ lets engineering, operations, and quality review the same live model together.

When should an automation partner join the URS process?

Bring a partner in before the URS is frozen. An early review tests whether targets are achievable, flags requirements that conflict, and attaches a cost to each desired item. Eclipse Automation’s advanced engineering services team supports this step across the factory automation lifecycle, from process discovery and simulation through installation and post-automation support. The result is a URS that suppliers quote accurately and your own teams can verify with confidence.

Explore the possibilities

Writing a URS for your next automation project? Book a discovery call to learn how Eclipse Automation supports automation requirements definition, from advanced engineering and simulation through acceptance testing.