IEEE Std 29148-2018 is the international standard for requirements engineering, published jointly by IEEE and ISO/IEC as ISO/IEC/IEEE 29148:2018. It defines the processes, activities, and tasks associated with the engineering of requirements for systems and software products throughout the lifecycle. It replaces and consolidates earlier standards IEEE 830 (software requirements), IEEE 1233 (system requirements), and IEEE 1362 (concept of operations).
The standard defines characteristics of individual requirements: each shall be necessary, implementation-free, unambiguous, consistent, complete, singular, feasible, traceable, and verifiable. It also defines characteristics of a requirements set as a whole: complete, consistent, affordable, and bounded. The verifiable characteristic is particularly important for hardware: a requirement that cannot be tested is not a requirement — it is a wish.
IEEE 29148 provides guidance on requirements elicitation, analysis, specification, and validation. For hardware engineers, the most actionable guidance covers writing measurable acceptance criteria (the 'shall' statement with quantified limits and test conditions), organizing requirements into a traceable hierarchy (stakeholder → system → subsystem), and managing requirements changes through a formal baseline and change control process.
Practical Example
A requirement written to IEEE 29148 standards: 'SRS-042: The power management module shall maintain output voltage within 5.0V ± 0.1V under load currents from 0 to 3A and input voltages from 6V to 15V DC.' — specific, measurable, implementation-free, and testable.
How SpecZero handles this
SpecZero's requirements structure aligns with IEEE 29148 principles: each requirement has an ID, a title, and a target value field for the measurable specification. The essential/non-essential lane distinction maps to the MoSCoW prioritization concept in requirements engineering.
Related terms
System Requirements Specification(SRS)
A formal document defining all requirements a system must satisfy, derived from stakeholder needs.
Functional Requirements
Statements of what a system must do — behaviors, inputs, outputs, and capabilities.
Non-Functional Requirements(NFR)
Requirements that define quality attributes — how well a system performs, rather than what it does.
Requirements Traceability Matrix(RTM)
A document that links requirements to their sources, design elements, and verification tests.