What Are Requirements?
According to IEEE Standard 29148-2018, a requirement is:
“A condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification, or other formally imposed document.”
In practical terms, a requirement answers the question: “What must this system do, and how well must it do it?” Requirements are not solutions — they define the problem space. A requirement states what is needed; the design states how to achieve it.
The Three Types of Hardware Requirements
ISO/IEC/IEEE 15288:2015 defines three core requirement categories for hardware systems:
Functional Requirements
What the system must do. These describe system behaviours, operations, and capabilities.
Example: The device shall detect motion within a 5-metre radius.
Performance Requirements
How well the system must perform — speed, accuracy, power consumption, reliability, and similar measurable attributes.
Example: The device shall respond to a motion event within 200 ms at 25°C ambient.
Constraint Requirements
Design limitations imposed by regulatory, physical, cost, or environmental factors.
Example: The enclosure shall comply with IP67 (IEC 60529) and not exceed 50 × 30 × 15 mm.
Why Requirements Matter in Hardware
Research from MIT's System Design and Management program shows:
70%
of hardware project failures trace back to poor requirements
100×
more expensive to fix requirements errors post-production vs. during planning
43%
faster project completion for teams using structured requirements
Source: MIT System Design and Management, 2024
Writing SMART Requirements (IEEE 29148)
IEEE 29148 defines the SMART criteria for well-formed requirements:
Specific
Unambiguous and precise. Not "long battery life" — "shall provide ≥ 8 hours of continuous operation at 25°C."
Measurable
Include quantifiable acceptance criteria. The requirement must be verifiable through test, inspection, or analysis.
Achievable
Technically feasible with available materials, components, and manufacturing processes.
Relevant
Traceable to a stakeholder need, regulation, or design constraint. Every requirement must have a reason.
Time-bound
Tied to a phase gate, milestone, or delivery date — especially for staged development programmes.
Poor vs Good Requirements: Examples
Vague requirements are the #1 cause of scope creep, rework, and component mismatches. Here's how to spot and fix them:
Poor
The device should be small.
Good
The device enclosure shall not exceed 50 mm × 30 mm × 15 mm (L×W×H) to fit in a standard shirt pocket per ANSI/HFS 100-2007 anthropometric data.
Why it works: Specific dimensions with a traceable standard replace an ambiguous adjective.
Poor
The battery life should be long.
Good
The device shall provide a minimum of 8 hours of continuous operation at a 10 Hz sensor sample rate and 25°C ambient temperature.
Why it works: Measurable conditions and context make the requirement verifiable.
Poor
The system should be reliable.
Good
The system shall achieve a Mean Time Between Failures (MTBF) of ≥ 5,000 hours under normal operating conditions as defined in MIL-HDBK-217F.
Why it works: A quantified reliability metric with a reference standard is testable.
Poor
The firmware should update easily.
Good
The device shall support over-the-air (OTA) firmware updates via BLE 5.0 with a maximum update time of 90 seconds for a 512 KB image.
Why it works: The mechanism, protocol, and acceptance criteria are all specified.
Requirements Traceability
Traceability is the ability to link every requirement to its origin (stakeholder need, regulation) and to the design decisions, components, and tests that address it. ISO/IEC/IEEE 15288:2015 requires traceability as a core system engineering discipline.
Traceability chain example:
Stakeholder need: Device must fit in a pocket
Requirement REQ-003: Enclosure ≤ 50×30×15 mm
Concept decision: Selected injection-moulded ABS enclosure (Decision Log #4)
BOM item: ABS enclosure 48×28×14 mm, Qty 1
Test: Physical measurement verification at DVT
A traceability matrix ensures that every requirement is addressed by a design decision, and every design decision is justified by a requirement. It also makes design reviews, audits, and regulatory submissions significantly faster.
Free Requirements Template
SpecZero includes a structured requirements workflow aligned with IEEE 29148 principles. When you create a project, you get:
- ✓Functional, performance, and constraint requirement categories
- ✓Concept comparison linked directly to each requirement
- ✓Decision log with rationale tracing back to requirements
- ✓Master BOM items linked to requirements and concepts
- ✓Activity timeline for full audit traceability
Managing Requirements with SpecZero
SpecZero's concept planner workflow implements requirements engineering principles directly in your browser:
Requirements by lane
Organise requirements into Functional, Performance, and Constraint lanes matching ISO/IEC/IEEE 15288.
Concept comparison
For each requirement, compare multiple design concepts side-by-side with pros, cons, and cost tiers before committing.
Decision log
Every design choice is recorded with its rationale, linked back to the requirement it addresses.
Master BOM traceability
BOM items are linked to concepts and requirements, creating a full traceability chain from need to part.