Clause 5.2.4: The requirements construct
Stakeholder, system and system element requirements have to be well formed.
What clause 5.2.4 asks
Stakeholder, system and system element requirements have to be well formed. A well formed statement does at least one of five things: it states something the system must be or do to solve a problem, reach an objective or answer a concern; measurable conditions qualify it; constraints bound it; it specifies what the system does for a stakeholder rather than what the user does; or it can be verified. The clause also fixes the language conventions: shall for a binding requirement, should for a preference, may for a permission, will for a statement of fact or intent, and must is best avoided.
Why it matters
The construct is the grammar of a requirement, separate from its quality. A sentence can be grammatical and still fail the characteristics in 5.2.5. The language convention matters because a reader has to know which sentences are binding. Negative statements, passive voice and the phrase shall be able to are called out because they hide the actor or the test.
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
Agree the keyword convention at the start of the specification and put it in the document's front matter. Then review each statement for actor, action, condition and verification. A condition action table or a use case can carry a requirement, but the requirement itself still needs a testable statement.
Evidence an assessor asks for
The assessor will pick a requirement and ask what the system must do, under what condition, and how it will be shown. A statement that cannot answer all three is not yet a requirement.
- Keyword convention A short style rule in the specification front matter defining shall, should, may, will and the treatment of must
- Statement review A sample of requirements marked with the actor, action, condition and verification
- Condition record The measurable conditions attached to each qualified requirement
- Constraint record The constraints that bound the requirement, with the source of each
Where it commonly fails
- Shall and will used interchangeably, so no one knows which statements bind the supplier
- A requirement written as a negative or in the passive voice, with the actor left out
- Conditions buried in a design note rather than attached to the requirement
What to do before the revision
Run a ten-statement sample through the four questions. Fix the convention before fixing the individual sentences, because the convention decides what the review is looking for.
Read across
- 5.2.5 Characteristics of individual requirements
- 5.2.7 Requirement language criteria
- 5.2.8 Requirements attributes
- 6.4.3.3 Define system or software requirements
← 5.2.3 Transformation of needs into requirements 5.2.5 Characteristics of individual requirements →
Source for clause 5.2.4: ISO/IEC/IEEE 29148:2018, Clause 5.2.4, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.