Clause 6.4.3.5: Manage system or software requirements
The process obtains explicit agreement on the system or software requirements, maintains bidirectional traceability, and provides the key artefacts and information items for baselines.
What clause 6.4.3.5 asks
The process obtains explicit agreement on the system or software requirements, maintains bidirectional traceability, and provides the key artefacts and information items for baselines. Traceability runs downward to lower level requirements, to the architecture and system elements, to the verification or test entities and their models, and upward to the parent requirements and the stakeholder needs. Derived requirements are traced to the study that produced them. The requirements are configuration controlled, with rationale, decisions, assumptions and change history.
Why it matters
The clause lists the four directions of traceability, which is the clearest test of a traceability claim. Many projects can trace down but not up, or to the design but not to the test. The configuration control requirement is what makes the baseline a baseline rather than a snapshot.
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
Build the trace matrix with the four directions as columns. Check that every derived requirement has a study or a parent. Put the set under configuration control before the agreement is recorded.
Evidence an assessor asks for
The assessor will choose a test case and trace it back to a requirement, then to a stakeholder need. A break in either direction is the finding.
- Agreement record The explicit agreement on the system or software requirements, with the version
- Trace matrix Downward, upward, architecture and verification links for each requirement
- Derived requirement record Each derived requirement, its parent and the study that produced it
- Configuration record The baseline, the change history, the rationale, the decisions and the assumptions
Where it commonly fails
- Traceability stops at the system requirement, so the stakeholder need cannot be shown
- Derived requirements are recorded without the study that justified them
- The baseline is a folder with no change history
What to do before the revision
Add the upward and verification columns to the trace matrix before the baseline review. They are the two that expose the real gaps.
Read across
- 5.2.8 Requirements attributes
- 6.4.3.4 Analyze system or software requirements
- 6.5.2 Requirements activities in verification
- 6.6.2.2.2 Configuration identification
- 6.6.2.2.3 Configuration change control
← 6.4.3.4 Analyze system or software requirements 6.5.1 Requirements activities in architecture definition →
Source for clause 6.4.3.5: ISO/IEC/IEEE 29148:2018, Clause 6.4.3.5, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.