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 procurement team writes a URS for engineered handling equipment, from a single requirement statement to the verification matrix that carries it 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 can surface 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 comparable step in the NASA Systems Engineering Handbook is Technical Requirements Definition, which the handbook describes 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 enable the description of all inputs, outputs, and required relationships between inputs and outputs, including constraints, and the system's interactions with operators, maintainers, and other systems.

For a custom handling system, the stakeholders include several groups. A coil car in an aluminum rolling mill has an operations owner, a maintenance department, a safety group, a controls group that must support the PLC for decades, and a purchasing team that must compare bids. The URS is where those interests are reconciled before a supplier starts design.

The handbook's Table 4.2-1 lists benefits of well-written requirements, among them:

  • They establish the basis for agreement between stakeholders and developers on what the product is to do.
  • They reduce the development effort, because careful review of the requirements can reveal omissions, misunderstandings, and inconsistencies early in the development cycle, when these problems 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 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 defines the construct of a good requirement and provides attributes and characteristics of requirements, and its publisher states that its content can be added to the requirements-related processes of the software and system life cycle standards or used independently; the current system life cycle standard is ISO/IEC/IEEE 15288:2023 (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. 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 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 those machined interfaces.
  • 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 and is not an acceptable self-derived requirement, the handbook says it should be assumed either that the traceability process is flawed and should be redone or that the requirement is "gold plating" and should be eliminated. It also asks the team to ensure that all top-level parent document requirements have been allocated to the lower-level requirements. 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.

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," 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. The requirement is stated positively, as opposed to negatively ("shall not").
  • 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 validation checklist also asks whether tolerances are overly tight, defendable, and cost-effective, and what the worst thing that could happen is if a tolerance were doubled or tripled. Each requirement should carry an intelligible rationale, including any assumptions, because the reason for a requirement is often not obvious and may be lost if not recorded (NASA/SP-2016-6105 Rev2, Appendix C.1 to C.4, §4.2.1.2.3, and the Rationale box).

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

The NASA handbook's Appendix C completeness check asks whether any requirements are missing, for example 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.
  • Facility and transportation: floor or foundation capacity, pits, clearances, and the shipping envelope and site access.
  • 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.

As engineering reasoning, 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 observatory instrument fixture by positioning accuracy and allowable acceleration; a sawmill infeed by cycle rate and wear. The handbook's reminder applies: 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 may be issued before every number is known, and the way unknowns are handled affects 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, examples of 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.

The handbook notes that knowing a KDR's impact on the design allows better management of requirements; flagging each one lets the owner decide whether it 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?​

As engineering reasoning, an under-specified intelligence layer can cause much rework, because the supplier's controls decisions 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. A controls section for a handling machine should cover at least:

  • 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 tasks can be configured as continuous, periodic, or event, and a periodic task executes automatically based on a preconfigured interval, so a URS can require that interlock and motion logic run in a periodic task at a stated period.
  • 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. ISO 13849-1:2023 specifies a methodology and provides related requirements, recommendations and guidance for the design and integration of safety-related parts of control systems (SRP/CS) that perform safety functions in high demand and continuous modes of operation; it does not specify the safety functions or required performance levels for particular applications.
  • 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.
  • 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 feature a safe torque-off function with hardwired and integrated safety connection options, and their commissioning procedure includes a step to test and 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+AMD1:2021 applies to electrical, electronic, and programmable electronic equipment and systems of machines not portable by hand while working, including a group of machines working together in a coordinated manner, starting at the point of connection of the supply; 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 2198-UM002E-EN-P, Kinetix 5700; ISO 13849-1:2023; IEC 60204-1:2016+AMD1:2021).

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 specifies principles of risk assessment and risk reduction to help designers achieve safety in machine design, and ISO 13849-1:2023 applies to the SRP/CS that perform safety functions, in high demand and continuous modes of operation; a URS can name the risk assessment as a deliverable and state 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, after January 2, 1990, 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. As engineering reasoning, 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 that, following the application of lockout or tagout devices, all potentially hazardous stored or residual energy be relieved, disconnected, restrained, and otherwise rendered safe;
  • the equipment information the owner needs to write the machine-specific procedure, which under 1910.147(c)(4)(ii) must include, among other items, specific steps for shutting down, isolating, blocking, and securing machines or equipment and specific requirements for testing to verify the effectiveness of lockout devices, tagout devices, and other energy control measures.

The failure mode these requirements address 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?​

The verification method should be decided when the requirement is written. The NASA handbook's Table 4.2-2 gives examples of requirement metadata that might be useful; it includes the verification method (test, inspection, analysis, demonstration), which 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, generally a basic confirmation of performance capability, differentiated 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 can be 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 an example Requirements Verification Matrix whose columns include requirement number, source document and paragraph, the "shall" statement, verification success criteria, verification method, facility or lab, phase, whether the requirement is also verified during initial acceptance testing of each unit, 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?​

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 all parties, including the owner, the buyer, and the vendor, to clearly establish and agree on the scope of activities and responsibilities involved in performing these tests; the 2024 third edition added the optional FIT and replaced the earlier annex forms with checklists for developing project-specific test plans.

As engineering practice, the link is the verification matrix. Each row 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 separates two questions: verification ensures that products are consistent with the technical data package and that "the product was built right"; validation against stakeholder expectations ensures that "the right product was built." As engineering reasoning, a machine can pass every FAT step and still fail validation if the URS left out a requirement the operators needed, one reason 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?​

Some URS templates come from the pharmaceutical industry, where two frameworks are worth understanding before borrowing from them. ASTM E2500-25 is a guide for the specification, design, and verification of pharmaceutical and biopharmaceutical manufacturing systems and equipment. Its scope makes it applicable to all elements of those systems, including utility and process equipment and associated monitoring, control, and automation systems, that have the potential to affect product quality, availability, and/or patient safety, throughout the life cycle from concept to retirement. Its Significance and Use section says application of the approach is intended to satisfy international regulatory expectations in ensuring that manufacturing systems and equipment are fit for intended use. 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. As engineering reasoning, a URS built only from a pharmaceutical template can therefore omit the machine-safety and energy-control requirements a heavy handling system needs.
  • Product focus. E2500-25's scope is framed around systems with the potential to affect product quality, availability, and/or patient safety. A steel mill, sawmill, or hydroelectric plant needs the same traceability discipline applied to load, duty, temperature, and personnel safety instead.

As engineering reasoning, the useful transfer is the discipline itself: requirements owned by the user, traced to risk, and verified before acceptance, which also suits laboratory handling fixtures (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. As engineering reasoning, several of its techniques for minimizing creep carry over 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, and, as engineering reasoning, the trace matrix is a natural 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 may not be 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's page keywords include drawing numbering and identification, part or identifying number (PIN), and notes. A URS that names it gives the supplier a defined basis for the drawings the owner will rely on for later revisions.

A deliverables list for a custom handling system can include:

  • 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 2198-UM002E-EN-P (2018): Kinetix 5700 Servo Drives User Manual. Rockwell Automation, 2018.
  • IEC 60204-1:2016+AMD1:2021 CSV (Ed. 6.1): Safety of Machinery -- Electrical Equipment of Machines -- Part 1: General Requirements. International Electrotechnical Commission, 2021.
  • 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 — Factory acceptance test (FAT), site acceptance test (SAT), and site integration test (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