Clause 5.2.1: General: the requirements engineering function
Requirements engineering is the function that sits between the acquirer and the supplier or developer and keeps the requirements of the system, software or service in a usable state.
What clause 5.2.1 asks
Requirements engineering is the function that sits between the acquirer and the supplier or developer and keeps the requirements of the system, software or service in a usable state. Its work covers discovery, elicitation, development, analysis, verification planning, validation, communication, documentation and change. The result is a set of requirements that is tied to a defined system, understood in the same way by the stakeholders, validated against a real need, possible to implement and usable as the reference for verifying the design.
Why it matters
The clause is a definition, but it carries a test. If a requirement set cannot be traced to a defined system, cannot be agreed by the people who must live with it, has not been checked against the need, or cannot be implemented, the function has not delivered what the clause describes. The set may live in one specification or several; the standard does not require a single document.
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
Treat the five results as a checklist for the requirements function itself, not only for a document. Ask who the acquirer is, which system the set describes, how the need was validated, what makes the set implementable and which design or test activity will use it.
Evidence an assessor asks for
An assessor will ask which system the set describes and who agreed it. A set that exists only because a template required it fails the first question.
- Requirements plan A plan that names the system of interest, the acquirer and supplier, the activities and the outputs
- Stakeholder agreement A record showing the set was reviewed and agreed by the representative stakeholders
- Validation note Evidence that the set was checked against the real need, not only against the wording
- Use record A link from the set to the design, verification or acceptance activity that consumes it
Where it commonly fails
- A requirements set with no named system boundary, so every reader assumes a different product
- Agreement recorded as a document approval by one manager, with no user or acquirer review
- The set is never used by design or test, so no one can show it was implementable
What to do before the revision
Write a one-page charter for the requirements function: system, acquirer, supplier, users, the activities, the outputs and the review points. Use it to onboard each new project and to check an inherited set.
Read across
- 5.2.2 Stakeholders
- 5.2.3 Transformation of needs into requirements
- 6.1 Requirement processes
- 7 The required information items
Source for clause 5.2.1: ISO/IEC/IEEE 29148:2018, Clause 5.2.1, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.