Clause 6.5.1: Requirements activities in architecture definition
The requirements work in architecture defines the interfaces and interactions that system elements have with each other and with external systems, and partitions, aligns and allocates requirements across architectural entities and the system elements.
What clause 6.5.1 asks
The requirements work in architecture defines the interfaces and interactions that system elements have with each other and with external systems, and partitions, aligns and allocates requirements across architectural entities and the system elements. Interface requirements, whether mechanical, electrical, data or envelope, are documented and traced by both parties at the interface. The links from each requirement to the architecture are maintained, and verification and validation criteria are recorded as derived requirements are generated.
Why it matters
Allocation is where a requirement acquires an owner at the next level. The clause makes interface requirements a first-class type because they are shared by two programs and are the most common source of integration failure. It also expects the verification criteria to be recorded when the derived requirement is created, not after the design.
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
Maintain an interface control document for each external interface, with both sides named. Allocate each requirement to one architectural element and record the derived requirements. Add the verification criterion at the same time.
Evidence an assessor asks for
The assessor will pick an interface and ask for the document both programs use. A one-sided interface description is a change waiting to happen.
- Interface control documents Each interface, both sides, the type and the trace to the requirements it carries
- Allocation matrix Each requirement to its architectural element, with the derived requirements
- Architecture trace The bidirectional link between requirements and architecture
- Verification criteria The criterion recorded for each derived requirement
Where it commonly fails
- Interface requirements live in one program's specification only
- A requirement is allocated to two elements with no statement of which owns it
- Derived requirements appear without verification criteria
What to do before the revision
Treat each external interface as a small contract: two owners, one document, one version. It is the cheapest integration control available.
Read across
- 6.4.3.3 Define system or software requirements
- 6.4.3.5 Manage system or software requirements
- 6.5.2 Requirements activities in verification
- 6.6.2.2.2 Configuration identification
← 6.4.3.5 Manage system or software requirements 6.5.2 Requirements activities in verification →
Source for clause 6.5.1: ISO/IEC/IEEE 29148:2018, Clause 6.5.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.