Annex A.2.6: OpsCon: concepts for the proposed system
The section describes the proposed system and how it will operate.
What annex A.2.6 asks
The section describes the proposed system and how it will operate. It covers the operational concept, the support concept and the other life-cycle concepts that apply, the operational scenarios, and the user classes and interactions. The operational scenarios are the representative sequences that show how the system will be used, including the degraded and emergency cases. The section is the basis for the stakeholder requirements and the system requirements.
Annex A is normative content and part of a full conformance claim.
Why it matters
The proposed-system concept is where the scenarios become concrete. The clause expects the operational and support concepts together, because a system that cannot be supported in the proposed environment is not a complete concept. The scenarios are the test of the concept: if a scenario cannot be described, the capability is not understood.
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 the operational and support concepts first. Then build the scenario set, including normal, degraded, emergency and maintenance. For each scenario, name the users, the trigger, the flow and the outcome. Derive the requirements from the scenarios rather than from the org chart.
Evidence an assessor asks for
The assessor will choose a scenario and ask which requirements it produces. A scenario with no requirements is either unnecessary or not yet understood.
- Operational concept How the proposed system will be used in the organization, with the intended outcomes
- Support concept The support infrastructure, maintenance, supply and training arrangements
- Scenario set Normal, degraded, emergency and maintenance scenarios, with users, triggers, flows and outcomes
- User interactions The user classes, their interactions and the factors that affect them
Where it commonly fails
- The concept describes the system but not how it will be supported
- Only the normal scenario is written, so the emergency requirements are missing
- The scenarios are written after the requirements, to illustrate them
What to do before the revision
Write one degraded and one emergency scenario before the requirements baseline. They are the cheapest way to find the missing non functional requirements.
Read across
- A.2.5 OpsCon: justification and nature of changes
- A.2.7 OpsCon: impacts and analysis
- 6.3.3.4 Develop the operational concept
- 6.3.3.5 Transform needs into stakeholder requirements
← A.2.5 OpsCon: justification and nature of changes A.2.7 OpsCon: impacts and analysis →
Source for annex A.2.6: ISO/IEC/IEEE 29148:2018, Annex A.2.6, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.