How to Write a Technical Specification Document for Machine Design

A machine design project that starts without a clear technical specification is almost guaranteed to end with either customer disappointment, scope creep, or both. The technical specification document (TSD) is the engineering contract between what the customer needs and what the design team will deliver — writing it well is one of the most valuable skills a mechanical engineer can develop.

This guide covers the structure and content of a technical specification document for machine design projects — from functional requirements through acceptance criteria. I’ll cover what to include in each section, how to write requirements that are testable rather than vague, the difference between functional and design requirements, and how to manage the document through design iterations and change control. These principles apply to custom machine design, automation equipment, industrial systems, and manufactured product development.

Why Technical Specifications Fail (and How to Prevent It)

Most specification documents fail for one of three reasons: they describe solutions instead of requirements (specifying how rather than what), requirements are untestable (vague language that can’t be verified at acceptance), or they’re incomplete at the start and never completed as the project evolves. Understanding these failure modes is the first step to writing specifications that actually work.

Solution-specifying requirements look like: “The machine shall use a servo motor drive system.” This specifies a solution (servo motor) rather than the performance requirement. The functional requirement might be: “The feed axis shall maintain positioning accuracy of ±0.05mm throughout its 500mm travel range under full load.” The servo motor is one solution to that requirement — but so are stepper motor systems with feedback, or hydraulic servos. Writing functional requirements first preserves design freedom and often reveals cheaper or more reliable solutions than the customer’s initial concept.

Untestable requirements use language like “the machine shall be reliable,” “the design shall be robust,” or “the system shall be easy to maintain.” None of these can be verified at acceptance. Every requirement in a technical specification should be verifiable — either through measurement, test, inspection, or demonstration. If you can’t describe how you’d verify a requirement, it’s not a requirement yet; it’s a wish.

Document Structure: Standard Sections

A technical specification for machine design typically contains these sections, in roughly this order:

1. Introduction and Scope — What is this document? What machine or system does it specify? What is the purpose and application of the machine? Who are the intended users? What is specifically excluded from scope? Clear scope definition prevents the most common source of project conflict — disagreement about what was included in the original requirement.

2. Reference Documents — Standards, codes, and other specifications that this TSD references or must comply with. Include: industry standards (ANSI, ISO, EN, JIS as applicable), safety standards (OSHA, CE machinery directive, IEC 60204 for electrical), customer-provided design guidelines, and any existing system documentation that this machine must interface with.

3. Functional Requirements — What the machine must DO. This is the most important section and should be written before any design work begins. See detailed discussion below.

4. Performance Parameters — Quantitative specifications of key performance metrics: throughput rate, cycle time, accuracy, force/torque capacity, speed range, environmental operating conditions. These are the measurable targets that the design must meet.

5. Interface Requirements — How the machine connects to the external world: utility inputs (electrical power specification, pneumatic supply pressure, cooling water requirements), physical interface dimensions (footprint, mounting provisions, clearances for operator and maintenance access), communication interfaces (fieldbus protocol, I/O specifications, control system integration), and process material interfaces (feed material specifications, output quality characteristics).

6. Safety Requirements — Applicable safety standards, required guarding, emergency stop requirements, electrical safety category, risk assessment methodology, and any customer-specific safety requirements.

7. Environmental and Operating Conditions — Temperature and humidity operating range, ingress protection (IP rating), vibration environment, altitude (affects electrical insulation and motor ratings), and any special environmental conditions (cleanroom classification, hazardous area classification, corrosive atmosphere).

8. Reliability and Maintainability Requirements — Mean time between failures (MTBF) targets, maintenance interval requirements (scheduled PM), mean time to repair (MTTR), spare parts list and stocking recommendations, and access requirements for maintenance operations (how many people, what tools, what time to perform specific maintenance tasks).

9. Acceptance Criteria and Test Procedures — The specific tests, measurements, and demonstrations that will be used to verify compliance with each requirement. See detailed discussion below.

Writing Good Functional Requirements

Functional requirements specify what the machine must do, not how it does it. Each requirement should be: complete (it defines a necessary capability), verifiable (you can test it), unambiguous (only one interpretation is possible), traceable (you can connect it to a stakeholder need), and necessary (the customer actually needs it, not just thinks they do).

Use the “shall” convention consistently: “The machine shall…” indicates a mandatory requirement. “Should” indicates a preference but not a mandatory requirement. “May” indicates an option. Being consistent with this language prevents requirement interpretation disputes during acceptance.

Poor requirement example: “The machine shall process parts quickly and accurately.” Better requirement: “The machine shall process parts at a minimum rate of 120 parts per hour (±5%) when running standard parts per the sample set provided in Appendix A, measured over any 60-minute continuous production run.” The improved requirement specifies a rate, an acceptable variation, the specific parts it applies to, and the measurement method. There’s no ambiguity about whether it’s met.

Requirements should be numbered systematically (REQ-001, REQ-002…) to enable traceability. Each requirement number should be unique throughout the document’s lifetime — if a requirement is deleted, its number is retired, not reused. This allows change records to unambiguously reference specific requirements.

Performance Parameters: Getting the Numbers Right

Performance parameters should be specified with tolerance ranges, not single values, wherever technically appropriate. A throughput requirement of “120 parts/hour” with no tolerance is unusual — does 119.5 parts/hour constitute a failure? A specification of “120 parts/hour minimum, measured as described above” is clearer. Similarly, positioning accuracy of “±0.05mm” is a range specification that implicitly allows any error within ±0.05mm.

Distinguish between capacity requirements and duty cycle requirements. A machine that must process 120 parts per hour doesn’t necessarily need to sustain that rate continuously — if production runs are typically 4 hours, followed by a 30-minute changeover, designing for 120 parts/hour continuous operation may be unnecessarily demanding on thermal management and component fatigue life. Specify the actual duty cycle alongside the rate requirement to enable appropriate design.

Coordinate safety factors with acceptance test conditions. If a machine is specified for 1000kg payload capacity and acceptance testing loads it to 1000kg, the design safety factor is entirely consumed by the test load. Typical practice: specify operational capacity (1000kg), specify a proof load test at 1.25–1.5× operational capacity (1250–1500kg) during acceptance, and design for structural safety factor beyond the proof load. Make the test load explicit in the acceptance criteria, not assumed.

Interface Definitions: The Most Often Forgotten Section

Interface requirements are the section that most machine design specifications handle poorly — and the one that causes the most expensive surprises. Every boundary between the machine and the outside world must be explicitly defined: what voltage, phase, and amperage does the machine require? At what pressure and flow rate must pneumatic supply be provided? What is the floor loading? What are the anchor bolt locations and loads?

For machines that integrate into production lines, the upstream and downstream interface must be defined precisely: what is the incoming part condition (temperature, orientation, cleanliness)? What are the interface dimensions and tolerances between this machine and adjacent conveyors or stations? Who is responsible for what at each physical interface — the machine builder provides up to a certain point; the customer provides from that point. Explicit interface ownership prevents the most expensive category of scope disputes.

Acceptance Criteria: Making Requirements Verifiable

Every mandatory requirement should have a corresponding acceptance criterion — a specific test or demonstration that confirms the requirement is met. Acceptance criteria should be written alongside requirements, not added at the end of the project when disputes arise about what was required.

Acceptance test structure: specify the test setup (fixture, test loads, instrumentation calibration requirement), the test procedure (steps in sequence), pass/fail criteria (the measurement result that constitutes acceptance), the number of test repetitions required, and who witnesses and approves the test. A well-written acceptance test procedure can be handed to a test engineer who was not involved in the design and executed correctly on the first attempt.

Factory Acceptance Testing (FAT) versus Site Acceptance Testing (SAT): for complex machines, FAT is performed at the builder’s facility before shipment to verify the machine meets requirements in a controlled environment. SAT is performed after installation at the customer’s site under actual production conditions. Both phases should be defined in the TSD with separate criteria — some requirements (interface integration, production environment performance) can only be verified during SAT.

Version Control and Change Management

A technical specification without version control is a liability — if the specification is revised during the project and not formally tracked, disputes about “the current requirement” become impossible to resolve. Implement formal version control from the first release: each revision has a version number, a date, a description of changes, and approval signatures from both parties (customer and supplier for contracted work).

Changes to requirements after project start should go through a formal change order process: the change is documented, its cost and schedule impact is assessed, and both parties agree to the change in writing before design work reflecting the change begins. This protects both the machine builder (who would otherwise absorb cost for changes without compensation) and the customer (who would otherwise not know that a requirement change has cost or schedule implications until too late to make an informed decision).

Conclusion

A well-written technical specification document is one of the most valuable engineering outputs of a machine design project — it defines success, prevents scope disputes, enables objective acceptance testing, and provides the traceability needed to defend design decisions when problems occur. The time investment to write a thorough specification at project start is always recovered through reduced rework, clearer communication, and faster acceptance. Treat it as an engineering design output deserving the same rigor as a mechanical drawing or analysis report, and version-control it with the same discipline.