Clause 5.2.7: Requirement language criteria
Textual requirements should say what is needed, not how to build it.
What clause 5.2.7 asks
Textual requirements should say what is needed, not how to build it. As requirements are allocated down the system, a higher level design decision can become a legitimate constraint, but that has to be a conscious exception. Vague and general terms have to be avoided because they cannot be verified or they allow several readings. The clause lists the families to remove: superlatives, subjective language, vague pronouns, ambiguous adjectives and adverbs, ambiguous logic, open ended phrases, comparisons, loopholes, terms that imply totality, and incomplete references. Assumptions are documented and validated in an attribute or an accompanying document, and definitions are written as declarative statements, not as requirements.
Why it matters
The list is practical because it names the phrases that survive review. A requirement that says as appropriate or if possible cannot fail, so it cannot be verified. A requirement that says all or never is almost impossible to verify. The clause also separates a definition from a requirement, which prevents a glossary entry from being counted as an obligation.
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
Put the banned families into the review checklist and into the tooling where possible. Search the set for each family, then read the hit in context. A hit is not automatically a defect, but it needs a reason to stay. Keep definitions in the glossary and link them.
Evidence an assessor asks for
The assessor will search for as appropriate, if possible, and/or and all. Each hit needs a disposition.
- Language check A search of the set for each banned family, with the disposition of every hit
- Assumption record Each assumption, where it is documented and how it was validated
- Glossary Definitions written as declarative statements, separate from the requirement set
- Exception note Any design constraint stated as a requirement, with the higher level decision that justifies it
Where it commonly fails
- Loophole phrases left in because the author says the reader will understand
- A definition written with shall, so a glossary entry looks like a requirement
- An assumption recorded nowhere, then treated as a requirement at test
What to do before the revision
Run the search before the review, not during it. Put the results in the pack so the reviewers spend their time on judgement, not on finding the phrases.
Read across
- 5.2.4 The requirements construct
- 5.2.5 Characteristics of individual requirements
- 5.2.8 Requirements attributes
- 9.2 General content
← 5.2.6 Characteristics of a set of requirements 5.2.8 Requirements attributes →
Source for clause 5.2.7: ISO/IEC/IEEE 29148:2018, Clause 5.2.7, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.