Clause 6.4.3.2: Prepare for system requirements
Preparation defines the functional boundary of the system (or the software system, or an element), described by the behaviour and properties it must provide.
What clause 6.4.3.2 asks
Preparation defines the functional boundary of the system (or the software system, or an element), described by the behaviour and properties it must provide. Three factors shape the boundary: the organization, including its mission and how the system will be used; the environment, including the maturity of the domain, the certainty of the interfaces and the role of the system among other systems; and the constraints, including cost, schedule, political, environmental and operational limits. The process also defines the requirements strategy, identifies the enabling tools and repositories, and obtains access.
Why it matters
Most scope arguments are boundary arguments. The clause makes the boundary a deliberate output and asks for the organization and environment to be considered alongside the technical scope. A boundary drawn only from the system diagram will miss the human and organizational interfaces.
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
Write a boundary statement with what is inside, what is outside and which interfaces cross the line. Record the three boundary factors. Then write the requirements strategy and name the repository.
Evidence an assessor asks for
The assessor will point at an interface and ask whether it is inside or outside. A boundary statement that cannot answer is not a boundary.
- Boundary statement What is inside and outside the system, with the interfaces that cross the boundary
- Organization and environment note The mission, domain maturity, interface certainty and the system's role among other systems
- Requirements strategy The approach, milestones, resources and the repository
- Enabling access The tools and repositories, with access confirmed
Where it commonly fails
- The boundary is copied from the architecture diagram, with no organizational or human interfaces
- Interface certainty is assumed, so an unstable external interface becomes a late change
- The repository is chosen after the requirements are written
What to do before the revision
Draw the boundary once with the stakeholders and date it. When the scope changes, redraw it rather than editing the old one, so the change is visible.
Read across
- 6.4.1 Purpose: system requirements definition
- 6.4.3.3 Define system or software requirements
- 6.5.1 Requirements activities in architecture definition
- 6.6.2.2.2 Configuration identification
← 6.4.1 Purpose: system requirements definition 6.4.3.3 Define system or software requirements →
Source for clause 6.4.3.2: ISO/IEC/IEEE 29148:2018, Clause 6.4.3.2, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.