Clause 6.4.1: Purpose: system requirements definition
The process transforms the user's view of wanted capabilities into the technical view of the solution needed to meet the operational need.
What clause 6.4.1 asks
The process transforms the user's view of wanted capabilities into the technical view of the solution needed to meet the operational need. It produces measurable system requirements that state, from the supplier's side, the characteristics, attributes, functions and performance the system must have. The requirements should not imply a specific implementation beyond the constraints. The process succeeds when the system description and interfaces are defined; the function, performance, process, quality and interface requirements are defined, along with the design constraints; critical performance measures are defined; the set is analyzed; enabling systems are available; and traceability to the stakeholder requirements exists.
Why it matters
This is the process that creates the set a supplier can design against. The outcome list separates the description of the system from the requirements on it, which is a useful distinction: a context diagram is not a requirement. The clause also keeps implementation freedom alive by treating design constraints as a named category rather than as ordinary requirements.
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
Start with the boundary and the interfaces, then write the requirements by type. Keep the design constraints in their own register. Define the critical performance measures early enough to shape the architecture, not after it.
Evidence an assessor asks for
The assessor will ask which stakeholder requirement a system requirement serves, and which design constraint is really a constraint. Both questions are answered by the register structure.
- System description The boundary, interfaces, functions and context of the system of interest
- Requirement set by type Requirements by type: function, performance, process, quality and interface, with the design constraints separate
- Critical performance measures The measures that will show each critical requirement is achieved
- Traceability The links from the system requirements to the stakeholder requirements
Where it commonly fails
- The system description is a block diagram with no boundary statement
- Design constraints are mixed into functional requirements, so the design space looks narrower than it is
- Traceability is built after the design, when it is too late to find the missing requirements
What to do before the revision
Create the boundary and interface set first. It is the part that changes most often and the part that causes the most rework when it is wrong.
Read across
- 6.1 Requirement processes
- 6.4.3.2 Prepare for system requirements
- 6.4.3.3 Define system or software requirements
- 6.4.3.5 Manage system or software requirements
← 6.3.3.7 Manage stakeholder needs and requirements 6.4.3.2 Prepare for system requirements →
Source for clause 6.4.1: ISO/IEC/IEEE 29148:2018, Clause 6.4.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.