Clause 6.4.3.3: Define system or software requirements
The process defines each function the system must perform, the required states or modes, the implementation constraints, the requirements that relate to risk, criticality or critical quality, and the requirements with their rationale and attributes.
What clause 6.4.3.3 asks
The process defines each function the system must perform, the required states or modes, the implementation constraints, the requirements that relate to risk, criticality or critical quality, and the requirements with their rationale and attributes. The attribute list is specific: data elements and structures; user interfaces, documentation and training; interfaces with other systems and services; functions and non functional characteristics, including cost targets; transition and migration from existing systems; and attributes such as priority, traceability, test cases, verification method, baseline status and risk. The output is a system requirements specification and, where 12207 applies, a software requirements specification.
Why it matters
The clause is the content specification for the technical set. Its value is in the list that teams forget: data retention, user documentation, transition and migration, and verification method. A set that covers functions and performance but not migration will fail at cutover.
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 requirement set against the six content groups in the clause. Check reuse of an existing requirement against the new context before accepting it. For each requirement, record the type, the verification method and the rationale. Review the transition and migration requirements with the operations owner, because they are the ones usually missing.
Evidence an assessor asks for
The assessor will look for the requirement that covers migration or user documentation. A set with no transition requirements usually has a cutover risk.
- System requirements specification The baselined set, organized by function, mode, interface and quality
- Attribute set The attributes from the clause, including verification method, test case, baseline and risk
- Transition requirements Migration, installation and acceptance requirements, reviewed with operations
- Rationale record The source and reason for each requirement, including derived requirements
Where it commonly fails
- The set covers functions only, with interfaces and data retention left to design
- Verification method is added after the design, so some requirements cannot be tested
- Derived requirements have no parent and no rationale
What to do before the revision
Use the six content groups as sections in the specification. A section that does not apply is marked not applicable with a reason, not deleted silently.
Read across
- 5.2.4 The requirements construct
- 5.2.8 Requirements attributes
- 6.4.3.2 Prepare for system requirements
- 6.4.3.4 Analyze system or software requirements
- 9.5 SyRS content
- 9.6 SRS content
← 6.4.3.2 Prepare for system requirements 6.4.3.4 Analyze system or software requirements →
Source for clause 6.4.3.3: ISO/IEC/IEEE 29148:2018, Clause 6.4.3.3, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.