Clause 5.2.5: Characteristics of individual requirements
Every stakeholder, system and system element requirement has to be necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming.
What clause 5.2.5 asks
Every stakeholder, system and system element requirement has to be necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming. Necessary means it is currently needed and not made obsolete by time; a requirement with an expiry or applicability date says so. Appropriate means the detail fits the level of the entity and does not force a design. Unambiguous means one reading. Complete means the statement can be understood without another document. Singular means one capability, characteristic, constraint or quality factor, although it may have several conditions. Feasible means it can be built within cost, schedule and technical limits with acceptable risk. Verifiable means its realisation can be shown. Correct means it represents the need it came from. Conforming means it follows the agreed template and style.
Why it matters
The nine words are the most quoted part of the standard and the most often reduced to a checklist with no test. Each one has an operational question behind it. The singular rule is not violated by multiple conditions; it is violated by two capabilities in one sentence. The appropriate rule is what keeps a requirement from becoming a design.
No clause level change is public for this unit; the DIS keeps the title and scope, and the requirement text is not released.
What good looks like
Use a review sheet with one column per characteristic and a short question for each. Apply the same sheet to a supplier requirement set before acceptance. Mark a statement, not a document. Where a characteristic cannot be judged without another artefact, record the artefact and the reviewer. Do not accept a pass with no evidence.
Evidence an assessor asks for
The assessor will choose one characteristic, usually unambiguous or verifiable, and ask two reviewers to read the statement independently. A difference in reading is the finding.
- Requirement review sheet One row per requirement with the nine characteristics and the reviewer's judgement
- Expiry record The applicability or expiry date for any requirement that is time limited
- Design independence note The reviewer's note that the statement does not prescribe a design beyond the agreed constraint
- Verification link The method and success criterion that make the requirement verifiable
Where it commonly fails
- Nine boxes ticked in a template with no reviewer name and no evidence
- A statement with two functions joined by and, marked singular because it is one sentence
- A design decision written as a requirement, with no constraint that justifies it
What to do before the revision
Take the ten most expensive requirements and review them first. The cost of a defect is highest where the design and test effort is largest. Record the review, not only the result.
Read across
- 5.2.4 The requirements construct
- 5.2.6 Characteristics of a set of requirements
- 5.2.8 Requirements attributes
- 6.4.3.4 Analyze system or software requirements
← 5.2.4 The requirements construct 5.2.6 Characteristics of a set of requirements →
Source for clause 5.2.5: ISO/IEC/IEEE 29148:2018, Clause 5.2.5, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.