Introduction
The single most expensive mistake in mechanical design is starting detailed design work before requirements are clearly defined. Every hour spent designing to an ambiguous or misunderstood requirement becomes ten hours of rework when the misunderstanding surfaces — typically at prototype testing or, worse, at customer acceptance.
A well-written design specification is the bridge between what a customer wants (often expressed in qualitative, functional terms) and what an engineer needs to design to (specific, measurable, verifiable criteria). This article describes how to build that bridge systematically, with practical guidance on structure, content, and the common traps that produce specifications that look complete but aren’t.
Why Specifications Fail: The Most Common Traps
Before describing how to write a good specification, it’s worth understanding how specifications typically fail in practice:
- Requirement stated as solution: “The frame shall use 80×80 structural aluminum extrusion” is a solution, not a requirement. The underlying requirement is something like “the frame shall support 500N of vertical load with deflection less than 0.5mm at the midpoint.” When you specify solutions, you eliminate design freedom and often constrain to a suboptimal approach.
- Unmeasurable requirements: “The system shall be robust,” “the design shall be user-friendly,” “the product shall be reliable” — these are not requirements. They cannot be tested, they cannot be verified, and they mean different things to different people. Every requirement needs a measurable pass/fail criterion.
- Missing operational context: A requirement stated without its operational context is incomplete. “Maximum load: 1,000N” — applied how? At what speed? For how many cycles? In what environment? Over what product life?
- Conflicting requirements: Requirements from different stakeholders often conflict. A requirement for minimum weight and a requirement for maximum stiffness push in opposite directions. The specification must identify these conflicts and resolve them with explicit trade-off decisions before design begins.
The Requirements Development Process
Good specifications come from a structured requirements development process, not from a single brainstorming session. The process has four stages:
Stage 1: Elicit — Capture what stakeholders actually want
Requirements come from multiple sources: the direct customer, end users (who may differ from the buyer), regulatory bodies, internal standards, and service teams. Each source has different knowledge and different concerns. Structured elicitation techniques include:
- Interviews with end users focused on use cases and pain points with existing products
- Review of relevant standards and regulatory requirements
- Analysis of warranty or service data from predecessor products
- Review of competitor products and customer complaints about them
Document everything at this stage without filtering — the filtering happens in the next stage, not here.
Stage 2: Analyze — Separate real requirements from noise
Not everything captured during elicitation is a genuine requirement. Some items are assumptions, preferences, or solutions masquerading as requirements. Apply these tests to each captured item:
- Is it a requirement or a solution? Convert solutions to the underlying functional requirement.
- Is it measurable and testable? If not, either quantify it or categorize it as a design guideline rather than a hard requirement.
- Does it conflict with other requirements? Identify and escalate conflicts for explicit resolution.
- Is it traceable to a real customer or stakeholder need? Requirements that no one can trace to a real need are candidates for removal.
Stage 3: Specify — Write requirements in unambiguous language
Good requirements follow a consistent format. A widely used structure is the “shall” statement format:
[Subject] shall [verb] [object] [qualifier]
Example: “The drive assembly shall produce a maximum torque of 50 N·m at a rotational speed of up to 200 RPM under all operating temperature conditions.”
Each requirement should:
- Use “shall” for mandatory requirements, “should” for desirable but not mandatory, “may” for permitted but optional
- Contain exactly one requirement — compound requirements connected with “and” should be split into separate items
- Define the conditions or context under which the requirement applies
- Specify the verification method: test, analysis, inspection, or demonstration
Stage 4: Review — Validate the specification before design begins
The specification should be reviewed by the customer or customer representative, the design team, manufacturing, and quality before design begins. The review is specifically looking for: missing requirements, unmeasurable requirements, conflicting requirements, and requirements that are technically impossible or commercially infeasible at the target cost. A specification that passes this review gives the design team a solid foundation to build on.
Design Specification Structure
A mechanical design specification typically contains the following sections:
- Scope and purpose: What the specification covers, what product or system it applies to, and what decisions it is intended to support
- References: Standards, regulations, predecessor specifications, and interface specifications that apply
- Functional requirements: What the system must do — performance, output, functions
- Interface requirements: Mechanical, electrical, software, and environmental interfaces that constrain the design
- Environmental requirements: Operating and storage temperature, humidity, shock, vibration, IP rating, chemical exposure
- Physical constraints: Envelope dimensions, weight limits, mounting configurations
- Reliability and life requirements: Design life, target MTBF, maintenance intervals
- Regulatory and safety requirements: Applicable standards and certifications required
- Verification matrix: How each requirement will be verified, by whom, and at what design stage
Requirements Traceability
| Requirement ID | Requirement Text | Source | Verification Method | Status |
|---|---|---|---|---|
| REQ-001 | Max output torque ≥ 50 N·m at 200 RPM | Customer spec rev B | Test — dynamometer measurement | Open |
| REQ-002 | Operating temperature: -10°C to +60°C | Customer spec rev B | Test — thermal chamber | Open |
| REQ-003 | Mass ≤ 8.5 kg including all accessories | System interface spec | Inspection — weigh finished assembly | Open |
| REQ-004 | Design life: 20,000 operating hours | Customer spec rev B | Analysis — fatigue calculation | Open |
The Specification as a Living Document
A design specification is not written once and filed. Requirements evolve as customer understanding deepens, as design trade-offs necessitate requirement relaxation or tightening, and as new information surfaces during development. A well-managed specification has a controlled change process: every requirement change is documented, approved by relevant stakeholders, and reflected in an updated revision of the specification with a change log.
Design decisions made against an outdated or informally changed specification are a common source of late-project surprises. If your customer says “actually, we need this to operate at -20°C” during a design review, that is a specification change — it should be documented formally, not informally incorporated and forgotten.
FAQ
Q: How detailed should a design specification be? Is it possible to over-specify?
A: Yes — over-specification is a real problem. Specifying things that don’t matter functionally reduces design freedom, often increases cost, and creates verification burden for requirements that add no value. The right level of specificity is: specify everything that matters for function, safety, interface, and regulatory compliance; leave implementation details to the designer’s judgment. The test: if you cannot trace a requirement to a customer need, a safety concern, or an interface constraint, question whether it belongs in the specification.
Q: What happens when the customer doesn’t have a written specification — just a verbal description of what they want?
A: This is common, particularly with smaller customers or early-stage programs. Your job as the design engineer is to translate the verbal description into a written specification and then get the customer to review and approve it. This step — formalizing requirements that the customer considers obvious — consistently surfaces misunderstandings and missing requirements before they cost money. Present the draft spec as “here’s what I understood — please confirm or correct” rather than as a document you need them to sign. The tone matters for getting honest feedback.
Q: How do I handle requirements that are fundamentally in conflict with the target cost?
A: Explicitly. Do not silently design to a requirement that makes the cost target impossible, and do not silently ignore a requirement that is too expensive. Document the conflict as a design issue, quantify the cost impact of meeting versus relaxing the requirement, and escalate to whoever owns the cost-performance trade-off decision. This is usually a customer or program management decision, not an engineering decision, and it needs to be made explicitly with full information.
コメント