Skip to main content

Writing a User Requirement Specification (URS) for Custom Machinery

A user requirement specification (URS) is the buyer's written statement of what a custom machine must do, how well it must do it, and how each requirement will be proven before the machine is accepted. UTEC Industrial designs, engineers, machines, fabricates, and installs custom material handling systems for aerospace and heavy industry from its Spokane Valley, WA facility, integrating Allen-Bradley PLC and motion control with in-house CNC machining, heat treating, and stress relief. This article explains how a project engineer or engineering procurement team writes a URS for engineered handling equipment, from the form of a single requirement statement through the controls and safety sections to the verification matrix that carries each requirement into factory and site acceptance testing. A custom handling system is built along one chain, design → engineering → parts machining → fabrication → assembly → weld fatigue → stress relief → drives → controls → tuning → monitoring, and a requirement that is missing or ambiguous at the top of that chain surfaces later as rework in the shop, a surprise at commissioning, or a dispute at acceptance.

What is a user requirement specification for custom machinery?​

A URS is the document in which the owner of a future machine turns operational needs into requirements a supplier can design to, price, and be held to. The NASA Systems Engineering Handbook describes the equivalent step, Technical Requirements Definition, as the process that transforms stakeholder expectations into a definition of the problem and then into a complete set of validated technical requirements expressed as "shall" statements. The requirements should describe all inputs, outputs, and required relationships between them, including constraints and the system's interactions with operators, maintainers, and other systems.

For a custom handling system, the stakeholders are rarely one person. A coil car in an aluminum rolling mill has an operations owner, a maintenance department, a safety group, an electrical and controls group that must support the PLC for decades, and a purchasing team that must compare bids. A telescope instrument handling cart at a research observatory, a positioner on an aerospace assembly line, or a runner-handling fixture at a hydroelectric plant has the same spread of interests. The URS is where those interests are reconciled before a supplier starts design.

The handbook lists the practical benefits of well-written requirements in its Table 4.2-1:

  • They establish the basis for agreement between stakeholders and developers on what the product is to do.
  • They reduce rework, because omissions, misunderstandings, and inconsistencies are found before design, when they are easier to correct.
  • They provide a basis for estimating cost and schedule and for evaluating bids or price estimates.
  • They provide the baseline for verification and validation, and give the stakeholders a basis for acceptance of the system.

The documented failure mode is the opposite case. The handbook warns that a team relying only on the requirements it receives, without iteration with stakeholders, runs the risk of misunderstanding them and implementing an unwanted solution to a different interpretation of the requirements. ISO/IEC/IEEE 29148:2018 is the international standard that defines the construct of a good requirement and the attributes and characteristics of requirements, and its publisher states that its content can be added to the requirements-related life cycle processes of the system life cycle standard ISO/IEC/IEEE 15288:2023 or used independently (NASA/SP-2016-6105 Rev2, §4.2 and Table 4.2-1; ISO/IEC/IEEE 29148:2018; ISO/IEC/IEEE 15288:2023).

Where does the URS sit in the chain from design to monitoring?​

The URS is the parent document for every link in the build chain. A single operational need, such as "move the part from the furnace to the quench station," flows down into requirements for the structure, the machined interfaces, the welds, the drives, the PLC logic, and the monitoring that will operate the machine for its service life. The NASA handbook shows this as a flowdown of requirements from mission objectives to system functional and performance requirements, and then to allocated and derived requirements at each subsystem (Figure 4.2-3).

The discipline that holds the chain together is bidirectional traceability. The handbook's Requirements Management Process maintains bidirectional traceability between stakeholder expectations, customer requirements, technical product requirements, product component requirements, design documents, and test plans and procedures. Tracing one load requirement for a heavy transfer car through the chain in order, design → engineering → parts machining → fabrication → assembly → weld fatigue → stress relief → drives → controls → tuning → monitoring, shows what that means in practice:

  • Design and engineering: the maximum load and its center-of-gravity envelope set the frame section, deck deflection limit, and wheel loads.
  • Parts machining: the wheel and axle fits and bearing seats that carry that load are toleranced on the drawings.
  • Fabrication: the welded frame is built to the section and joint details that the stated load requires.
  • Assembly: the wheel sets, bearings, and drive train are fitted to the machined interfaces that carry the load.
  • Weld fatigue and stress relief: the welded joint details are checked against the load cycles the URS states, and the frame is stress-relieved before final machining so the machined interfaces hold their position.
  • Drives: the traction motor, gearbox, and VFD are sized to accelerate and stop the loaded car.
  • Controls and tuning: the PLC slowdown points and the drive ramps are set for the loaded inertia.
  • Monitoring: motor current and brake counts are trended against the duty cycle the URS stated.

If a requirement has no parent, the handbook states that either the trace is flawed or the requirement is "gold plating" and should be eliminated. If a parent has no child, something in the design was never asked for. UTEC Industrial stress-relieves and machines the welded frame of a transfer car before assembly, which is the kind of downstream step a traceable load requirement reaches (NASA/SP-2016-6105 Rev2, Figure 4.2-3 and §6.2.1.2.2 to §6.2.1.2.3).

How should each requirement in a URS be written?​

Each requirement should be one sentence, with one "shall," stating what the product must do rather than how the supplier must do it. The NASA handbook's Appendix C sets the vocabulary: "shall" states a requirement, "will" states a fact or declaration of purpose, and "should" states a goal. A URS that mixes the three without discipline leaves the supplier guessing which lines are binding.

The Appendix C editorial and validation checklists give a writer a practical test for each line:

  • Form. A product requirement takes the form "product ABC shall XYZ," in the active voice, and each statement expresses one thought, with one subject and one predicate.
  • Tolerances. Performance values are complete with tolerances, such as less than, greater than or equal to, or plus or minus.
  • Free of implementation. The requirement states what is needed, not how to provide it. The checklist suggests asking why the requirement is needed, because the answer may point to the real requirement.
  • Free of operations. Sentences such as "the operator shall…" are almost always operational statements, not requirements, and belong in the concept of operations.
  • Positive statement. Requirements are stated positively rather than as "shall not" where possible.
  • Unverifiable terms. The checklist asks whether the text is free of terms such as flexible, easy, sufficient, safe, adequate, accommodate, user-friendly, when required, fast, maximize, minimize, and quickly, along with other "-ly" and "-ize" words.

A requirement such as "the car shall move loads quickly and safely" fails three of those checks at once. A rewrite that passes them reads "The transfer car shall travel [distance] ft between the furnace stop and the quench stop in no more than [time] s with a load of [maximum load] lb," with the bracketed values supplied by the owner's process. The handbook also asks the writer to test each tolerance by asking what the worst thing that could happen is if the tolerance were doubled or tripled; tolerances that cannot survive that question are usually driving cost without a process reason. Every requirement should carry a rationale, including its assumptions, so that the reason survives after the author leaves the project (NASA/SP-2016-6105 Rev2, Appendix C.1 to C.4 and §4.2.1.2.3).

Which requirement areas should a URS for handling equipment cover?​

Most URS defects are omissions rather than errors. The NASA handbook's Appendix C completeness check asks whether any of these requirement areas have been overlooked: functional, performance, interface, environment (development, manufacturing, test, transport, storage, and operations), facility, transportation, training, personnel, operability, safety, security, appearance and physical characteristics, and design. Its §4.2.1.2.2 distinguishes functional requirements, which define what functions need to be performed, from performance requirements, which define how well the system needs to perform them.

Applied to heavy in-plant handling equipment, those areas translate into a working outline:

  • Functional: each move, lift, rotation, or index the machine performs, and each state it must hold, such as holding a load with power removed.
  • Performance: load range and center-of-gravity envelope, speeds, positioning accuracy, cycle time, and duty cycle in cycles per hour and per year.
  • Interface: mechanical interfaces to rails, foundations, furnaces, cranes, and machine tools; electrical supply; and network interfaces to the plant control system.
  • Environment: part temperature at pickup, ambient heat, dust, chips, coolant, moisture, and outdoor exposure for yard equipment in lumber or mining operations.
  • Facility and transportation: floor or foundation capacity, pits, clearances, and the shipping envelope and site access for delivery of a large machine.
  • Training, personnel, and operability: operator and maintainer skills, HMI language, and the maintenance access the owner's crews need.
  • Safety and security: the hazards identified by risk assessment, the required safety functions, energy isolation, and control-network access.

The industry changes the emphasis, not the outline. A hot-coil car in a steel or aluminum mill is dominated by environment and duty; an instrument handling fixture at an observatory is dominated by positioning accuracy and allowable acceleration on a delicate payload; a sawmill infeed is dominated by cycle rate and wear. The handbook's reminder applies to all of them: consideration and inclusion of all types of requirements is needed to form a complete and consistent set (NASA/SP-2016-6105 Rev2, §4.2.1.2.2 and Appendix C.4).

How should a URS handle TBDs, assumptions, and key driving requirements?​

A URS is often issued before every number is known, and the way unknowns are handled decides whether bids are comparable. The NASA handbook's Appendix C advises that "To Be Determined" (TBD) values be minimized, and that it is better to use a best estimate marked "To Be Resolved" (TBR) with the rationale, what should be done to eliminate the TBR, who is responsible, and by when. A URS for a mining concentrator's liner handler that lists the heaviest liner weight as "TBD" invites every bidder to assume a different number; one that lists a best-estimate weight as TBR, owned by the plant's maintenance engineer and due before design review, lets the bids be compared on the same basis.

Assumptions get the same treatment. The checklist asks whether all assumptions have been explicitly stated and notes that assumptions should be confirmed before the document is baselined. A URS that assumes a floor slab can carry a transfer car's wheel loads without stating the slab design, or assumes a crane will be available to set a positioner at install, carries a hidden requirement that someone will pay for later.

The handbook also calls for identifying Key Driving Requirements (KDRs), defined as requirements that can have a large impact on cost or schedule when implemented, and notes that a KDR can have any priority or criticality. In heavy handling equipment, typical KDRs include:

  • a positioning accuracy that forces servo control instead of VFD control;
  • a part temperature that rules out conventional bearings, seals, or sensors near the load;
  • a hazardous-location classification that changes every electrical component;
  • a shipping or site-access envelope that forces the machine to be built in field-bolted sections.

Flagging these explicitly lets the owner decide whether each is truly needed before paying for it (NASA/SP-2016-6105 Rev2, §4.2.1.2.3 and Appendix C.3 to C.4).

Which controls and sensing requirements belong in a URS?​

The intelligence layer of a handling system is where an under-specified URS causes the most rework, because controls decisions made by the supplier become the owner's maintenance burden for decades. The NASA handbook's Appendix C validation checklist asks whether all external and internal interfaces are clearly defined, whether error detection, reporting, handling, and recovery requirements exist, and whether undesired events such as data loss or operator error have been considered and their required responses specified. For a handling machine, that translates into a controls section covering at least the following:

  • Controller platform and program structure. If the plant standardizes on Allen-Bradley Logix controllers, the URS should say so, since that choice fixes the programming software, spare parts, and skills the owner's technicians need. Logix 5000 controllers organize code into continuous, periodic, and event tasks, and a URS can require that interlock and motion logic run in a periodic task at a stated period rather than in the continuous task.
  • Safety control partition. A URS should require that safety functions such as emergency stop, guarded-zone entry, and safe speed run in a safety controller, and state the required performance level from the risk assessment. On a GuardLogix 5580 controller, only the safety task can be used for safety functions; Rockwell Automation rates a GuardLogix 5580 primary controller with a safety partner for applications up to SIL 3 and PL e (Cat. 4), and one without a safety partner up to SIL 2 and PL d (Cat. 3). The required rating therefore determines hardware.
  • Interfaces to adjacent equipment. Where a car, conveyor, or positioner interlocks with a crane, furnace door, or robot cell, the URS should name each signal exchanged and whether it is a safety signal. GuardLogix controllers can exchange safety data with other CIP Safety devices over the plant network, which is one way to meet that requirement.
  • Drives and sensing. The URS should state which axes need position feedback and to what accuracy, where load cells are needed and what they must block, which limit and end-of-travel devices are required, and whether servo axes need safe torque-off. Kinetix 5700 servo drives have safe torque-off built into the drive, and their commissioning procedure includes a step to tune each axis.
  • Monitoring and data. The URS should list the values the plant wants trended, such as motor current, drive faults, brake operations, and bearing temperature, and the network and historian they must reach.
  • Electrical equipment basis. IEC 60204-1:2016 applies to the electrical, electronic, and programmable electronic equipment of machines not portable by hand while working, including groups of machines working together, from the point where the supply connects; a URS can name it as the electrical design basis.

UTEC Industrial, a Rockwell Automation Recognized System Integrator, builds UL 508A control panels and programs ControlLogix and CompactLogix systems, so these requirements map directly to what is built and tested (NASA/SP-2016-6105 Rev2, Appendix C.4; Rockwell Automation 1756-RM094N-EN-P-2025; Rockwell Automation 1756-RM012J-EN-P-2025; Rockwell Automation 2198-UM002E-EN-P, Kinetix 5700; IEC 60204-1:2016).

How should URS safety requirements trace to risk assessment and energy control?​

Safety requirements should not be a list of standards the supplier must "comply with." Each safety requirement in a URS should trace to a hazard identified in a risk assessment, and each should be verifiable. ISO 12100:2010 is the standard for general principles of machine design, risk assessment, and risk reduction, and ISO 13849-1:2023 covers the general principles for design of the safety-related parts of control systems; a URS commonly names the risk assessment as a deliverable and states the required performance of each resulting safety function.

Hazardous energy control is one area where a regulation writes a requirement directly into the purchase. OSHA 29 CFR 1910.147(c)(2)(iii) requires that whenever new machines or equipment are installed, or replacement or major repair, renovation, or modification is performed, energy isolating devices for that equipment be designed to accept a lockout device. Paragraph 1910.147(b) defines an energy isolating device as a mechanical device that physically prevents the transmission or release of energy, such as a disconnect switch, line valve, or block, and states that push buttons, selector switches, and other control-circuit-type devices are not energy isolating devices. A URS for a hydraulic positioner or a gravity-loaded lift should therefore require:

  • a lockable isolating device for every energy source, electrical, hydraulic, pneumatic, and gravity;
  • a means to relieve, disconnect, or restrain stored energy, because 1910.147(d)(5)(i) requires stored or residual energy to be rendered safe after lockout devices are applied;
  • the equipment information the owner needs to write the machine-specific procedure, which under 1910.147(c)(4)(ii)(A) to (D) must include procedural steps for shutting down, isolating, blocking, and securing the machine and requirements for testing to verify the effectiveness of the energy control measures.

The failure mode these requirements prevent is a machine delivered with an e-stop but no lockable point for a hydraulic accumulator or a raised table, leaving the owner to retrofit isolation after startup (ISO 12100:2010; ISO 13849-1:2023; OSHA 29 CFR 1910.147-1989, §1910.147 paragraphs b, c.2.iii, c.4.ii and d.5.i).

How is each URS requirement verified: test, inspection, analysis, or demonstration?​

A requirement that cannot be verified cannot be accepted, so the verification method should be decided when the requirement is written. The NASA handbook's Table 4.2-2 lists the verification method (test, inspection, analysis, demonstration) as requirement metadata that should be determined as the requirements are developed, along with the requirement ID, rationale, trace, owner, verification lead, and verification level. The handbook defines the four methods:

  • Analysis: mathematical modeling and analytical techniques used to predict suitability, generally when a fabricated product is not available; it can include verification by similarity to a heritage product.
  • Demonstration: showing that use of the end product achieves the specified requirement, a basic confirmation of capability distinguished from testing by the lack of detailed data gathering.
  • Inspection: visual examination of the realized product, which can include inspection of drawings, documents, or other records.
  • Test: use of the end product to obtain detailed data under controlled conditions; the handbook calls it the most resource-intensive verification technique.

For a heavy handling machine, a frame stress limit is often verified by analysis; a stress-relief cycle or a weld inspection by inspection of the record; an interlock sequence by demonstration; and a rated-load lift, a positioning accuracy, or a cycle time by test. The handbook's Appendix D gives a Requirements Verification Matrix with columns for requirement number, source document and paragraph, the "shall" statement, verification success criteria, verification method, facility or lab, phase, whether the requirement is also verified in acceptance testing, performing organization, and the documents that contain the objective evidence. Only "shall" requirements belong in the matrix, which is one more reason to keep goals written as "should" (NASA/SP-2016-6105 Rev2, Table 4.2-2, §5.3 Methods of Verification, and Appendix D Table D-1).

How does the URS carry into factory and site acceptance testing?​

Acceptance testing is where the URS is either proven or argued over. IEC 62381:2024 defines requirements and checklists for the factory acceptance test (FAT), the factory integration test (FIT), the site acceptance test (SAT), and the site integration test (SIT), which its publisher describes as tests carried out to demonstrate that the automation system meets the requirements of the applicable specification. The same description states that the document provides a means for the owner, buyer, and vendor to clearly establish and agree on the scope of activities and responsibilities for these tests; the 2024 third edition added the optional FIT and replaced the earlier annex forms with checklists for developing project-specific test plans.

The practical link is the verification matrix. Each row that is marked for acceptance testing becomes a FAT or SAT step with the success criterion already written. Requirements that can be proven only with the machine on its foundation, such as interlocks to an existing crane or furnace, rail alignment, or throughput with the plant's actual parts, are assigned to SAT; requirements that can be proven on the supplier's floor are assigned to FAT, where a failure is cheaper to fix.

The NASA handbook frames the two questions acceptance must answer. Verification shows that "the product was built right" against the specification; validation shows that "the right product was built" against stakeholder expectations. A machine can pass every FAT step and still fail validation if the URS left out a requirement the operators needed, which is why the owner's operators and maintainers should witness acceptance. UTEC Industrial performs factory acceptance testing and on-site commissioning, so the URS verification matrix can be executed at both stages (IEC 62381:2024; NASA/SP-2016-6105 Rev2, §5.0 and Appendix D).

What do pharmaceutical and regulated-industry frameworks add to a URS?​

Many URS templates in circulation come from the pharmaceutical industry, and two of their source documents are worth understanding before borrowing from them. ASTM E2500-25 is a guide for specification, design, and verification of pharmaceutical and biopharmaceutical manufacturing systems, including process equipment, supporting utilities, and associated process monitoring, control, and automation systems. Its scope states that the approach is intended to ensure manufacturing systems and equipment are fit for intended use, and that the guide applies throughout the life cycle from concept to retirement. ISPE's GAMP 5, 2nd edition, addresses risk-based compliance of GxP computerized systems; its publisher notes that the GAMP specification and verification approach is not inherently linear and fully supports iterative and incremental methods, and that the guide is intended for regulated companies, suppliers, and regulators, with suppliers including equipment and system integration providers.

Two cautions apply when a heavy-industry team adopts these templates:

  • Scope gap. ASTM E2500-25's scope states that the guide does not address employee health and safety, environmental, or other non-GxP regulations. A URS built only from a pharmaceutical template can therefore omit the machine-safety and energy-control requirements that dominate a heavy handling system.
  • Product focus. Pharmaceutical requirements center on product quality and patient safety. A steel mill, sawmill, or hydroelectric plant needs the same traceability discipline applied to load, duty, temperature, and personnel safety instead.

The useful transfer is the discipline itself: requirements owned by the user, traced to risk, and verified before acceptance. That transfers directly to research and laboratory operations, where scientific instruments and handling fixtures often carry a similar documentation expectation (ASTM E2500-25; ISPE GAMP 5 2nd ed.).

How should URS changes be controlled after the purchase order?​

A URS changes during a project; what matters is that changes are deliberate. The NASA handbook states that once requirements have been validated and reviewed at the System Requirements Review, they are placed under formal configuration control, and thereafter any change should be approved by a Configuration Control Board or equivalent authority that assesses cost, performance, programmatic, and safety impact. It also warns that requirement changes during its Phases B and C, the preliminary design and the final design and fabrication phases, are more likely to cause significant adverse impacts to project cost and schedule.

The handbook names the failure mode: "requirements creep," the subtle way requirements grow imperceptibly during a project, resulting in a system that is more expensive and complex than originally intended, often through changes that are really enhancements in disguise. Its countermeasures apply directly to a custom handling project:

  • A good concept of operations, discussed and agreed with the customer and stakeholders, is the first line of defense.
  • Early requirements work should flush out the conscious, unconscious, and undreamed-of requirements that might otherwise go unstated.
  • Change requests should come through official channels, with the authority to submit them defined.
  • Each change should be assessed against the rest of the system and against the resource margins; a change that cannot be accommodated within them most likely should be denied.

For a machine already in fabrication, a late change to load or speed can reach back up the chain into frame design, weld details, drive sizing, and PLC logic at once, which is why the trace matrix is the first tool for pricing it (NASA/SP-2016-6105 Rev2, §6.2.1.2.4 and §6.2.1.2.5).

What documentation deliverables should a URS require?​

The URS should list every document the owner needs to operate, maintain, modify, and eventually replace the machine, because deliverables not required in the purchase are often not delivered. Engineering drawings are the core of that package. ASME Y14.100-2017 establishes the essential requirements and reference documents applicable to the preparation and revision of manual or computer-generated engineering drawings and associated lists, unless tailored by a specialty standard; its publisher lists subjects such as drawing numbering and identification, part or identifying numbers, and notes. A URS that names it gives the supplier a defined basis for the drawings and associated lists the owner will rely on when the plant revises the machine years later.

A typical deliverables list for a custom handling system includes:

  • general-arrangement and detail drawings with associated parts lists, to ASME Y14.100-2017 or the owner's drawing standard;
  • electrical schematics, panel layouts, and network drawings, with the PLC and HMI programs in native, editable form;
  • the risk assessment and the safety-function list with required performance levels;
  • lockout points and energy-source information supporting the owner's procedure under 29 CFR 1910.147;
  • the completed Requirements Verification Matrix, with the documents containing objective evidence for each "shall," as the handbook's Appendix D matrix provides;
  • inspection records for critical fabricated and machined parts, including weld inspection and dimensional reports;
  • drive parameter files and tuning records, so a replaced drive can be restored to its commissioned settings.

UTEC Industrial performs NDT and CMM inspection on the parts it fabricates and machines, the kind of objective evidence a verification matrix calls for (ASME Y14.100-2017; NASA/SP-2016-6105 Rev2, Appendix D; OSHA 29 CFR 1910.147-1989).

Related Articles

References​

  • NASA. NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2. National Aeronautics and Space Administration, 2016.
  • ISO/IEC/IEEE 29148:2018: Systems and software engineering — Life cycle processes — Requirements engineering. ISO/IEC/IEEE, 2018.
  • ISO/IEC/IEEE 15288:2023: Systems and software engineering — System life cycle processes. ISO/IEC/IEEE, 2023 (Ed.2).
  • Rockwell Automation 1756-RM094N-EN-P-2025: Logix 5000 Controllers Design Considerations. Rockwell Automation, 2025.
  • Rockwell Automation 1756-RM012J-EN-P-2025: GuardLogix 5580 and Compact GuardLogix 5380 Controllers Safety Reference Manual. Rockwell Automation, 2025.
  • Rockwell Automation 2198-UM002E-EN-P (2018): Kinetix 5700 Servo Drives User Manual. Rockwell Automation, 2018.
  • IEC 60204-1:2016 (Ed. 6.0): Safety of Machinery -- Electrical Equipment of Machines -- Part 1: General Requirements. International Electrotechnical Commission, 2016.
  • ISO 12100:2010: Safety of machinery — General principles for design — Risk assessment and risk reduction. ISO, 2010.
  • ISO 13849-1:2023: Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design. International Organization for Standardization, 2023.
  • OSHA 29 CFR 1910.147-1989: The Control of Hazardous Energy (Lockout/Tagout). Occupational Safety and Health Administration, 1989.
  • IEC 62381:2024: Automation systems in the process industry — FAT, SAT, FIT and SIT. IEC, 2024 (Ed.3).
  • ASTM E2500-25: Standard Guide for Specification, Design, and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and Equipment. ASTM International, 2025.
  • ISPE. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, 2nd ed. ISPE, 2022.
  • ASME Y14.100-2017: Engineering Drawing Practices. ASME, 2017.

Ready to Discuss a Material Handling System?​

UTEC Industrial designs, engineers, machines, fabricates, and installs custom material handling systems for heavy industry, from the stress-relieved structure and drives to the Allen-Bradley PLC controls, tuning, and monitoring that run them, at its Spokane Valley, WA facility. Send UTEC the application, loads, and duty cycle to start a system review.

Request a Quote →

Questions? Call (509) 922-1832 or email sales@utec.co

Last updated on