Introduction
Drawings cannot be right if the specifications behind them are wrong. Many engineering failures—delivered machines that do not meet expectations, costly design changes late in development, and customer disputes at acceptance testing—trace back not to calculation errors or manufacturing defects, but to inadequately defined specifications. Requirements were ambiguous. Critical constraints were assumed, not stated. Customer expectations and engineering deliverables were never formally reconciled.
Converting customer requirements into unambiguous engineering specifications is one of the most valuable skills a mechanical designer can develop. It is also one of the least taught. This article presents a systematic approach to specification development, with specific techniques for eliminating ambiguity before drawings begin.
Why Specification Failures Are So Costly
In product development, the cost to correct an error increases roughly tenfold with each phase of development: a specification error caught during requirements review costs a meeting; caught during design, it costs design rework; caught during prototype testing, it costs tooling changes and retest; caught after customer delivery, it may cost field modifications, contractual penalties, or lost business relationships. Investing time in rigorous specification development is not overhead—it is cost avoidance.
The most common specification deficiencies are: missing requirements (constraints the customer assumed obvious but never stated); unmeasurable requirements (“reliable,” “robust,” “easy to use”—qualitative terms that cannot be verified); conflicting requirements (two specs that cannot both be satisfied simultaneously, discovered only during design); and scope creep (requirements added incrementally after specification freeze without corresponding cost and schedule adjustment).
The Specification Development Process
Step 1: Capture Customer Requirements Completely
Begin with structured interviews or workshops with the customer to capture requirements systematically. Use a requirements capture template that prompts for: functional requirements (what the machine must do), performance requirements (how well it must do it, with numerical targets), environmental requirements (temperature, humidity, dust, vibration, chemical exposure), interface requirements (mechanical, electrical, software), safety requirements (applicable regulations and standards), and constraints (budget, schedule, weight, envelope dimensions).
Do not stop at the first answer. Probe for boundary conditions: “What is the maximum load?” is a good question, but follow with “What happens if that load is exceeded by 10%?” and “What is the emergency stop load?” The boundary conditions often reveal requirements the customer has not consciously articulated.
Step 2: Translate Customer Language into Engineering Language
Customer requirements are often expressed in operational terms (“the machine must handle parts up to 5 kg”) that must be translated into engineering specifications (“maximum payload 5 kg acting at the end effector, center of mass within 100 mm of mounting flange, 3-axis inertia not to exceed…”). Each customer requirement may translate into multiple engineering specifications. Record this mapping explicitly—it allows traceability when a specification is later questioned.
Translate every qualitative requirement into a measurable form. “Must not overheat” becomes “operating temperature at all electronics surfaces ≤ 70°C at 40°C ambient, 24-hour continuous duty.” “Must be easy to clean” becomes “no external surfaces with crevices < 2 mm wide; all contact surfaces accessible by standard cleaning tool; IP65 minimum for all external surfaces.”
Step 3: Check for Completeness, Consistency, and Measurability
Review the specification draft systematically against three criteria:
- Complete: Is there a verifiable requirement for every functional aspect of the machine? Use a functional decomposition tree to ensure no subsystem or interface is unaddressed.
- Consistent: Do any requirements conflict? Check pairs of requirements that could constrain the same design variable. Conflicting requirements must be resolved before design begins—prioritization (which requirement yields if both cannot be met) must be agreed and documented.
- Measurable: Can each requirement be tested or inspected? If not, rewrite it. If a requirement genuinely cannot be made measurable, it should be removed or replaced with a proxy that can be measured.
Step 4: Freeze and Manage Changes
A specification that can be changed without process control is not a specification—it is a wish list. Once the specification is agreed, implement a formal change control process: changes require written request, impact assessment (cost, schedule, technical risk), approval by both parties, and update of the specification document with a revision record. This is not bureaucratic overhead—it protects both the designer and the customer from misunderstanding.
Common Specification Pitfalls and How to Avoid Them
| Pitfall | Example | Correct Approach |
|---|---|---|
| Unmeasurable requirement | “Machine must be reliable” | “MTBF ≥ 5,000 hours at rated load” |
| Missing boundary condition | “Max speed 500 mm/s” | “Max speed 500 mm/s; emergency deceleration ≤ 2 m/s²” |
| Assumed interface | No mention of input power | “Supply: 3-phase 400V 50Hz ± 10%; max 15 kVA” |
| Conflicting requirements | Low noise AND high throughput | Prioritize: throughput is primary, noise ≤ 75 dB(A) at 1 m is secondary |
| Scope creep | Post-freeze additions without impact review | Formal change request with documented cost/schedule impact |
FAQ
Q: The customer says they do not know all the requirements yet. How do we proceed?
A: This is a very common situation. The appropriate response is not to begin designing with incomplete specifications, but to identify which requirements are unknown and agree on a plan to resolve them. Separate known requirements from unknown ones. For unknown requirements, agree on a date by which each will be resolved, and identify the cost/schedule risk if resolution is delayed. For truly open-ended requirements (e.g., the customer does not yet know the production rate), design with documented assumptions and establish explicit design margins that allow the specification to be updated within defined bounds without triggering full redesign.
Q: How detailed should a specification be? We worry about over-constraining the design.
A: The specification should specify what the machine must achieve, not how it must achieve it. Specify the output (force, speed, accuracy, cycle time, noise level, service life) and the constraints (envelope, weight, interfaces, regulatory compliance). The design solution—which components, what geometry, which materials—belongs in the design, not the specification. Over-specification occurs when implementation details are written into requirements rather than outputs. Under-specification occurs when requirements are vague or absent. The boundary is the interface between the customer’s needs and the designer’s freedom to solve them.
Q: Our organization does not have a formal specification process. Where should we start?
A: Start with a simple requirements checklist template that every new project must complete before drawing release. Even a one-page template covering: function, performance values, dimensional envelope, environment, interfaces, safety standards, and acceptance criteria will catch most specification failures. Build from there as the organization’s capability matures. Perfect is the enemy of good—a structured checklist used consistently is infinitely more valuable than a comprehensive process that no one follows.
コメント