Continue reading with these related posts
In precision manufacturing, tolerances are the invisible rules that determine whether your assembly will work flawlessly or fail catastrophically. Understanding how to specify and control these tolerances is fundamental to successful mechanical engineering.
Engineering first principles involve breaking down complex problems into their most fundamental parts and methodically solving each component. This approach, pioneered by innovators like Elon Musk and used extensively in scientific and engineering disciplines, can transform how we tackle challenges in our daily lives.
Master the art of fixture design to achieve consistent quality, reduce cycle times, and justify tooling investments that pay for themselves in production.
You've validated your product concept. Now comes the phase where most engineering projects either find their footing or start to stumble: requirements engineering. This is where "we need a faster conveyor" transforms into "transport 120 units/minute with ±2mm positioning accuracy while accommodating parts between 50-150mm length."
The difference between vague desires and precise requirements isn't just semantics—it determines whether your design team spends six weeks or six months iterating, whether your first prototype works or needs three revisions, and whether your final product delights customers or disappoints them.
After 17 years developing products across aerospace, automotive, and industrial automation, I've seen brilliant concepts fail because requirements were treated as a checkbox exercise, and mediocre concepts succeed because someone took the time to define success properly. This article walks you through the systematic approach we use to transform validated concepts into actionable engineering specifications.
Here's an uncomfortable statistic: studies show that fixing a requirements defect found during testing costs 10-100× more than fixing it during requirements definition. Yet most engineering teams spend 90% of their time on design and 10% on requirements.
The math doesn't add up.
Requirements engineering isn't about creating bureaucratic documentation—it's about answering fundamental questions before you invest in design:
Good requirements engineering provides:
Clarity for your team: Designers know what they're solving for. No more "I thought you meant..." conversations.
Alignment with stakeholders: Everyone agrees on what success looks like before you spend money building the wrong thing.
Measurable success criteria: Objective pass/fail tests replace subjective judgment calls.
Change management foundation: When requirements inevitably evolve, you have a baseline to assess impact against.
Risk reduction: Hidden assumptions and conflicts surface early when they're cheap to address.
The goal isn't perfect requirements—no set of requirements survives contact with reality unchanged. The goal is good enough requirements that prevent expensive surprises and enable confident decision-making throughout design and development.
The first distinction you need to master is functional versus non-functional requirements. Most engineers intuitively understand functional requirements but underspecify non-functional ones, leading to products that technically work but fail in real-world use.
Functional requirements describe specific behaviors, features, and capabilities. They answer "what must the system do?"
Examples:
Good functional requirements are:
Non-functional requirements define qualities, constraints, and operational characteristics. They answer "how well must it work?"
Common categories include:
Performance:
Reliability and availability:
Usability and maintainability:
Environmental and operational conditions:
Safety and regulatory:
Manufacturing and cost:
Most requirements documents are 80% functional, 20% non-functional. This is backwards. In our experience:
You can often meet functional requirements multiple ways, but non-functional requirements constrain which solutions are actually viable. A conveyor that moves 120 parts/minute (functional) but requires 10kW of power (non-functional failure) doesn't help anyone.
Not all requirements are created equal. Organize them hierarchically:
Level 1 - System requirements: High-level capabilities and constraints
The automated packaging system shall process 120 units/minuteLevel 2 - Subsystem requirements: Derived requirements for major subsystems
The conveyor subsystem shall transport units at 2.4m/minute
The orientation subsystem shall correct skew to ±2 degreesLevel 3 - Component requirements: Specific design requirements
The drive motor shall provide 0.5 Nm continuous torque
The proximity sensor shall detect parts 10mm before stationThis hierarchy helps you trace requirements from customer needs through to component specifications, ensuring nothing gets lost in translation.
Not all requirement statements are equally useful. Compare these:
Poor requirement: "The system should be fast"
Better requirement: "The system shall have high throughput"
Good requirement: "The system shall process ≥120 units/minute during sustained operation (8-hour shift)"
Use this structure consistently:
[System/Component] shall [action/capability] [quantified performance] [under specified conditions]Examples:
"The pneumatic clamp shall apply 500-600N clamping force to parts with 50-150mm diameter within 0.8 seconds of actuation signal"
"The control system shall detect and log fault conditions with timestamp accuracy of ±10ms throughout the operational temperature range of 5-40°C"
Each requirement should include:
Unique identifier: For traceability (REQ-FNC-001, REQ-PRF-012)
Priority:
Source: Who requested it and why (links to stakeholder need)
Verification method:
Acceptance criteria: How you'll verify it's met
Rationale: Why this requirement exists (prevents "why do we need this?" debates)
Before accepting a requirement, verify it's:
Your requirements come from stakeholders, but what stakeholders say they want often isn't what they actually need. Effective interviewing uncovers the real requirements hidden beneath initial requests.
Don't just talk to the person who signed the contract. For a typical industrial equipment project, stakeholders include:
Direct stakeholders:
Indirect stakeholders:
External stakeholders:
Each has different priorities and perspectives. The operator cares about ease of use and ergonomics. The maintenance tech cares about accessibility and diagnostic tools. The finance person cares about total cost of ownership.
When a stakeholder states a requirement, dig deeper to understand the underlying need:
Stakeholder: "We need the system to run faster" You: "Why do you need it faster?" Stakeholder: "Our current bottleneck is this operation" You: "Why is this operation a bottleneck?" Stakeholder: "Because we can't keep up with upstream production" You: "Why can't you add a second line?" Stakeholder: "We don't have floor space" You: "Why is floor space constrained?" Stakeholder: "We have inventory storage taking up space that could be production area"
Now you've uncovered the real problem: it's not speed, it's space optimization. Maybe the solution is better inventory management, not a faster machine. Or maybe you need to design a more compact system.
Open-ended questions to explore broadly:
Probing questions to dig deeper:
Quantifying questions to get specifics:
Hypothetical questions to test boundaries:
Negative questions to identify must-nots:
Some stakeholders don't speak up but have critical requirements. Maintenance technicians often fall into this category—no one asks their opinion until the system is deployed and impossible to service.
Tactics to engage quiet stakeholders:
Stakeholders often have contradictory priorities. The production manager wants maximum throughput. The maintenance tech wants easy access for service. The purchasing agent wants lowest cost. These create inherent conflicts.
Don't hide conflicts—surface them explicitly:
"Production needs ≥120 units/minute, but maintenance needs quick access to bearings for monthly service. A fully enclosed high-speed design meets production goals but makes service difficult. Options:
Which trade-off best balances priorities?"
This forces stakeholders to make conscious trade-offs rather than discovering them late in the project.
For complex projects with many stakeholders, run structured workshops:
Agenda:
This approach builds consensus and ensures everyone hears each other's priorities directly.
Create a stakeholder needs matrix:
| Stakeholder | Need Statement | Priority | Impact if Unmet | Derived Requirements |
|---|---|---|---|---|
| Production Manager | Increase throughput | High | Production targets missed | REQ-PRF-001: ≥120 units/min |
| Maintenance Tech | Quick bearing replacement | Medium | Extended downtime | REQ-MNT-003: < 30 min bearing swap |
| Safety Coordinator | No pinch points | High | Regulatory non-compliance | REQ-SAF-005: Guarding per ANSI B11.19 |
This becomes your traceability document linking stakeholder needs to formal requirements.
Requirements describe what you need. Specifications prescribe how it will be achieved. The distinction matters.
Requirement: "The system shall process 120 units/minute" Specification: "The conveyor belt shall operate at 2.4 m/minute with servo-driven variable speed control"
Requirements are somewhat implementation-agnostic. Specifications nail down specific solutions. Move too fast to specifications and you constrain design creativity. Move too slow and you don't provide enough guidance.
A well-organized specification follows this structure:
1. Introduction
2. System overview
3. Requirements
4. Design constraints
5. Verification and acceptance
6. Appendices
Specifications should be:
Imperative: Use "shall" for mandatory requirements, "should" for recommended, "may" for optional
Quantitative: Include numbers with units and tolerances
Singular: One requirement per statement
Avoid ambiguity:
Don't forget interfaces—where components, subsystems, or systems connect:
Mechanical interfaces:
Electrical interfaces:
Software interfaces:
Human interfaces:
Interface requirements are where many integration problems hide. Be exhaustively specific here.
This distinction is subtle but important:
Performance specification: Describes required outcomes
"The braking system shall bring the conveyor to a complete stop within 50mm of travel after emergency stop activation, from maximum speed"Design specification: Prescribes specific implementation
"The braking system shall use a spring-applied, electrically-released brake on the drive motor shaft"Generally prefer performance specifications—they give designers freedom to find optimal solutions. Use design specifications only when:
Traceability ensures no requirement gets lost and every design decision connects back to a need. Verification ensures requirements are actually met.
Create a bidirectional traceability matrix linking:
Example matrix:
| Need ID | System Req | Subsystem Req | Component Spec | Verification Method | Test ID | Status |
|---|---|---|---|---|---|---|
| NEED-001 | REQ-PRF-001 | REQ-CONV-003 | SPEC-MTR-008 | Test | TEST-045 | Pass |
| NEED-002 | REQ-SAF-005 | REQ-GARD-012 | SPEC-SNS-003 | Inspection | INSP-022 | Pass |
This seems bureaucratic, but when a stakeholder asks "why does this cost so much?" you can trace expensive components back to their requirements back to stakeholder needs. It justifies design decisions with data.
For each requirement, define how you'll verify it's met:
Test: Physical measurement or functional testing
Analysis: Calculation, simulation, or modeling
Inspection: Visual or dimensional verification
Demonstration: Operational proof in representative environment
Document the verification method in your specification. Don't wait until testing to figure out how you'll verify requirements—the verification method often influences design decisions.
| Requirement ID | Verification Method | Test Procedure | Accept/Reject Criteria | Responsible Party | Planned Date |
|---|---|---|---|---|---|
| REQ-PRF-001 | Test | TP-THRPT-001 | ≥120 units/min over 30 min | Test Engineer | Week 12 |
| REQ-SAF-005 | Inspection | IP-GARD-003 | Guarding per ANSI B11.19 | Safety Coord. | Week 10 |
| REQ-MNT-003 | Demonstration | DM-MAINT-002 | < 30 min bearing swap | Maint. Tech | Week 13 |
This becomes your testing roadmap and links directly to acceptance criteria.
Here's the reality: requirements will change. The question isn't whether to allow changes—it's how to manage them without derailing the project.
Common causes:
Some changes are legitimate and necessary. Others are scope creep that should be resisted.
Implement a formal process:
1. Change request submission
2. Impact assessment
3. Change review board
4. Implementation
5. Verification
CHANGE REQUEST FORM
CR Number: CR-2024-007
Date Submitted: 2024-XX-XX
Submitted By: [Name, Role]
Current Requirement:
REQ-PRF-001: System shall process ≥120 units/minute
Proposed Change:
Increase to ≥150 units/minute
Justification:
Customer production targets increased after line expansion. Current specification would create new bottleneck.
Impact Assessment:
- Technical: Requires upgraded drive motor (+\$600) and faster sensors (+\$200)
- Schedule: +2 weeks for component procurement and testing
- Cost: +\$1,400 in parts, +\$2,000 in engineering time
- Risk: Moderate - increases mechanical loads by 25\%
- Affected Requirements: REQ-PRF-001, REQ-PWR-003, REQ-SAF-007
Alternatives Considered:
1. Add parallel line (rejected - space constrained)
2. Optimize cycle time elsewhere (investigated - limited gains)
3. Accept 120 units/min and add shift (customer rejected)
Recommendation: Approve with caveat that customer accepts cost and schedule impact
Change Board Decision: [Approved / Rejected / Deferred]
Date: _________
Signatures: _____________________Establish a requirements baseline—a formally approved version—early in the project (typically after concept development, before detailed design). This baseline becomes your reference point for measuring scope creep.
Baseline versions:
Use version control for requirements documents just like you would for CAD files. Git works great for text-based specifications.
When requirements change, update:
Then communicate to:
Failed communication causes more problems than the change itself. Someone working from outdated requirements wastes time building the wrong thing.
Not all changes should be approved. Protect your project from scope creep:
Red flags:
Responses to scope creep:
Be firm but diplomatic. Most scope creep comes from enthusiasm, not malice.
Problem: "The system should be user-friendly and reliable"
Why it fails: Unmeasurable, subjective, open to interpretation
Fix: "Operators shall complete setup in < 5 minutes after one day of training. MTBF shall exceed 2000 operating hours."
Problem: Specifying tighter tolerances, higher performance, or more features than actually needed
Why it fails: Drives up cost and complexity unnecessarily
Example: Specifying ±0.001" tolerance when ±0.010" would function perfectly well
Fix: Challenge every requirement—what happens if we relax this? Often "nice to have" masquerades as "must have."
Problem: "The system shall use a 0.5 HP three-phase induction motor"
Why it fails: Prescribes solution before exploring alternatives
Fix: "The system shall provide sufficient torque to maintain 2.4 m/min belt speed under full load (15kg distributed)"
Let designers choose the motor based on performance requirements.
Problem: Specifying what the system does but not how well
Why it fails: Products work in lab but fail in real-world conditions
Fix: Systematically address performance, reliability, usability, maintainability, environmental, safety categories.
Problem: Requirements exist in isolation, not linked to needs or verification
Why it fails: Can't justify design decisions, can't verify completeness
Fix: Maintain traceability matrix linking needs → requirements → specifications → tests
Problem: "We defined requirements in week 1, we're done"
Why it fails: Requirements evolve as understanding improves
Fix: Plan for requirements evolution with change control process
Problem: Only talking to one stakeholder or group
Why it fails: Miss critical requirements from other perspectives
Fix: Systematically identify and interview all stakeholder categories
Problem: Treating all requirements as equally important
Why it fails: When trade-offs arise, no basis for decisions
Fix: Label requirements as "must have," "should have," "nice to have" with clear criteria
Spreadsheets (Excel, Google Sheets):
Document-based (Word, Google Docs):
Best practice: Use both—spreadsheet for structured data, documents for narrative context
For larger projects or organizations:
Jama Connect: Full-featured requirements management platform
Helix RM (formerly Polarion): ALM platform with strong requirements features
Modern Tools (Notion, Airtable, ClickUp): Flexible database tools
For most small-to-medium engineering projects: Start with spreadsheets. Migrate to specialized tools when you hit pain points (typically 500+ requirements or 5+ concurrent projects).
Requirements document template:
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions and acronyms
1.4 References
2. System Overview
2.1 System context
2.2 Major subsystems
2.3 Operational modes
3. Stakeholder Needs
[Matrix of stakeholders, needs, priorities]
4. Requirements
4.1 Functional Requirements
4.2 Performance Requirements
4.3 Interface Requirements
4.4 Environmental Requirements
4.5 Safety Requirements
4.6 Maintenance Requirements
5. Verification
5.1 Verification methods
5.2 Acceptance criteria
5.3 Test procedures
6. Appendices
A. Traceability Matrix
B. Change Log
C. Stakeholder Interview SummaryStakeholder interview template:
Interviewee: ___________
Role: ___________
Date: ___________
Context Questions:
1. Describe your typical day/process
2. What works well currently?
3. What are the pain points?
Requirements Questions:
4. What must the new system do?
5. How well must it perform?
6. What are your constraints?
7. What are deal-breakers?
Prioritization:
8. If you could only have 3 features, which?
9. What would make