Clause 5.2.8: Requirements attributes
A well formed requirement carries descriptive attributes that help a reader find, understand and manage it.
What clause 5.2.8 asks
A well formed requirement carries descriptive attributes that help a reader find, understand and manage it. The standard gives examples: a unique identification that is never changed or reused; a version number; an owner who can approve changes and report status; a stakeholder priority; a risk value; a rationale that points to the analysis or trade study; a difficulty rating; and a type. The type examples are functional or performance, interface, process, quality or non functional, usability or quality in use, and human factors. The attributes live with the requirement in the repository, not in a separate spreadsheet that drifts.
Why it matters
The attributes are what make a requirement manageable after it is written. The identification rule is strict: an identifier is not reused even after the requirement is deleted, because a reused identifier breaks the history. The owner is a role with authority, not a name added for completeness. The rationale is the evidence that the requirement was not invented.
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
Make the attributes mandatory fields in the tool. Define the allowed values for type, priority, risk and difficulty. Link the rationale to the analysis artefact. Audit the fields quarterly, because repositories decay at the edges.
Evidence an assessor asks for
The assessor will sort the set by owner and by verification method. A large unassigned block is the finding.
- Repository export The requirement set with identification, version, owner, priority, risk, rationale, difficulty and type
- Identifier rule A note or tool setting that prevents an identifier from being reused after deletion
- Rationale links A link from each rationale to the analysis, trade study or source that supports it
- Attribute audit A dated check of the mandatory fields, with the empty fields named
Where it commonly fails
- Identifiers reused after a deletion, so the history points at the wrong requirement
- An owner field filled with a team name that cannot approve a change
- Rationale that says per customer request, with no source
What to do before the revision
Start with owner, rationale and verification method. Those three turn a list into a managed set. Add the rest once the first three are reliably populated.
Read across
- 5.2.5 Characteristics of individual requirements
- 6.6.2.2.2 Configuration identification
- 6.6.3.3 Perform requirements measurement
- 9.2 General content
← 5.2.7 Requirement language criteria 5.3.2 Iteration and recursion in requirements engineering →
Source for clause 5.2.8: ISO/IEC/IEEE 29148:2018, Clause 5.2.8, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.