关键词：Operational Concept（OpsCon）、Scenario、mode
一、GJB5000/CMMI中的运行方案和场景
先看CMMI 1.2 RD专用目标SG3 Analyze and Validate Requirements（分析和确认需求）。
英文释义：The requirements are analyzed and validated, and a definition of required functionality is developed。GJB5000A翻译：“分析和确认需求，并开发所需功能性的定义。”
注：1）functionality翻译为“功能性”让人困惑，Functionality是功能的实现程度，功能实际表现如何。2）在GJB438B/C所对应的MIL-STD 498的SSS/SRS “3.11 Software quality factors”文档中，… functionality (the ability to perform all required functions)，很可惜GJB438B/C都没有保留这个解释。3）大家有兴趣的话可以搜索function和Functionality的区别。
其中专用实践3.1 Establish Operational Concepts and Scenarios（GJB5000A翻译：制定运行方案和场景）。
英文释义：Establish and maintain operational concepts and associated scenarios。GJB5000A翻译：建立和维护运行方案和相关联的场景。
对于该实践的说明对照如下。
英文原文：
Refer to the Technical Solution process area for more information about detailed development of operational concepts that are dependent on the selected designs.
A scenario is a sequence of events that might occur in the use of the product, which is used to make explicit some of the needsof the stakeholders. In contrast, an operational concept for a product usually depends on both the design solution and the scenario. For example, the operational concept for a satellite-based communications product is quite different from one based on landlines. Since the alternative solutions have not usually been defined when preparing the initial operational concepts, conceptual solutions are developed for use when analyzing the requirements. The operational concepts are refined as solution decisions are made and lower level detailed requirements are developed.
Just as a design decision for a product may become a requirementfor product components, the operational concept may become the scenarios (requirements) for product components.
The scenarios may include operational sequences, provided those sequences are an expression of customer requirements rather than operational concepts.
GJB5000A翻译:
关于详细开发运行方案的更多信息参见技术解决方案过程域，该运行方案依赖于选定的设计。
场景是使用产品时可能发生的事件序列，用来使利益相关方的某些需要更明确。而产品的运行方案通常既依赖于设计解决方案（design solution），也依赖于场景。例如，基于卫星的通信产品的运行方案与基于地面线路的通信产品的运行方案就迥然不同。由于准备初始运行方案时一般尚未定义可供选择的解决方案，所以在分析该需求时开发一个草拟的解决方案提供使用。随着解决方案决策的制定和较低层详细需求的开发而对运行方案进行改进。
正如产品的设计决策可以变成产品部件的需求，运行方案也可以变成产品部件的场景（需求）。演变运行方案和场景使产品部件解决方案的选择更容易，当这些解决方案实现时，它们就能够满足产品预期的使用。不论什么工程学科，运行方案和场景都要用文档记录产品部件与环境、用户、其他产品部件的交互。
场景可以包括运行序列，所提供的这些运行序列是顾客需求而不是运行方案。
二、需求工程标准中的operational concept和scenario
注1）在ISO/IEC/IEEE 29148和NASA、INCOSE的标准中，operational concept 简写为OpsCon。
ISO/IEC/IEEE 29148《Requirements engineering》的定义：operational concept 是“组织对特定系统或相关新系统、现有系统或修改系统的操作或一系列操作的假设或意图的口头和图形说明。运行方案旨在从用户和操作员的角度，给出组织运行环境中使用一个或多个特定系统或一组相关系统的运行的总体情况。它是企业或组织想要达到的目标。”
运行方案要涵盖使用（功能性）、支持、维护和退役全过程，提供用于开发或评价一组场景的环境（context，即context of use），提供从用户角度看待系统或产品的视图。ISO/IEC/IEEE 29148中，对context of use的解释是“用户、任务、设备(硬件、软件和材料)以及使用产品的物理和社会环境”。
场景也叫“operational scenario”，描述想象中的事件或活动序列，包括产品或服务与其环境和用户的交互，以及产品或服务组件之间的交互的一系列事件。场景可用于定义运行方案，并限定系统产品、预期操作环境和接口系统、平台或产品的预期使用范围。场景有助于识别可能被忽视的需求。将场景分解为更小的部分可以帮助识别需求。
三、不同层次的operational concept
ISO/IEC/IEEE 29148在业务需求和利益相关方需求相关章节中，都要求建立operational concept。
在业务需求规格建立时叫着High-level operational concept。
在利益相关方需求规格建立时叫Operational concept，也叫System Operational Concept。
在ISO/IEC/IEEE 29148附录A.2中专门给出了Operational concept document (OpsCon)的格式，文档内容非常类似于GJB438B/MIL-STD-498中OPERATIONAL CONCEPT DESCRIPTION (OCD)。
其中“A.2.7 Operational scenarios”关于场景的完整说明如下：
A scenario is a step-by-step description of how the proposed system should operate and interact with its users and its external interfaces under a given set of circumstances. Scenarios should be described in a manner that will allow readers to walk through them and gain an understanding of how all the various parts of the proposed system function and interact. The scenarios tie together all parts of the system, the users and other entities by describing how they interact. Scenarios may also be used to describe what the system should not do.
场景是对拟议系统在给定情况下应如何操作以及如何与用户及其外部接口交互的逐步描述。场景的描述方式应允许读者浏览并了解拟议系统的各个部分是如何运作和交互的。这些场景通过描述系统的所有部分、用户和其他实体如何交互，将它们联系在一起。场景也可以用来描述系统不应该做什么。
Scenarios should be organized into sections and subsections, each describing an operational sequence that illustrates the roles of the system, its interactions with users and interactions with other systems. Operational scenarios should be described for all operational modes and all classes of users identified for the proposed system. Each scenario should include events, actions, stimuli, information and interactions as appropriate to provide a comprehensive understanding of the operational aspects of the proposed system. Prototypes, storyboards and other media, such as video or hypermedia presentations, may be used to provide part of this information.
场景应分为部分和子部分，每个部分描述一个操作序列，说明系统的角色、与用户的交互以及与其他系统的交互。应描述拟议系统的所有操作模式和所有用户类别的操作场景。每种情景都应酌情包括事件、行动、刺激、信息和交互，以全面了解拟议系统的操作方面。原型、故事板和其他媒体，如视频或超媒体演示，可用于提供部分信息。
In most cases, it may be necessary to develop several variations of each scenario, including one for normal operation, one for stress load handling, one for exception handling, one for degraded mode operation, etc.
在大多数情况下，可能需要为每种情况开发几种变体，包括一种用于正常运行，一种用于压力负载处理，一种用作异常处理，一个用于降级模式运行等。
Scenarios play several important roles. The first is to bind together all of the individual parts of a system into a comprehensible whole. Scenarios help understand how all the pieces interact to provide operational capabilities. The second role of scenarios is to provide operational details for the proposed system. This enables better understanding of the users’ roles, how the system should operate and the various operational features to be provided.
场景扮演着几个重要的角色。第一种是将系统的所有单独部分结合在一起，形成一个可理解的整体。场景有助于理解所有部分如何相互作用以提供操作能力。场景的第二个作用是为拟议的系统提供操作细节。这有助于更好地理解用户的角色、系统应如何运行以及要提供的各种操作功能。
Scenarios can also support the development of simulation models that help in the definition and allocation of derived requirements, identification and preparation of prototypes to address key issues. In addition, scenarios can serve as the basis for the first draft of the users’ manual and as the basis for developing acceptance test plans. Scenarios are also useful for the acquirer and the supplier to verify that the system design will satisfy the stakeholders’ needs and expectations.
场景还可以支持仿真模型的开发，这些模型有助于定义和分配衍生需求，识别和准备原型以解决关键问题。此外，场景可以作为用户手册初稿的基础，也可以作为制定验收测试计划的基础。场景对于收购方和供应商验证系统设计是否满足利益相关者的需求和期望也很有用。
Scenarios can be presented in several different ways. One approach is to specify scenarios for each major processing function of the proposed system. Using this approach, this section would contain one section for each process. Each section would then contain several more lower-level sections, one for each scenario supported by that process. An alternative approach is to develop thread-based scenarios, where each scenario follows one type of transaction type through the proposed system. In this case, each section would contain one scenario for each interaction type, plus scenarios for degraded, stress loaded and back-up modes of operation. Other alternatives include following the information flow through the system for each user capability, following the control flows or focusing on the objects and events in the system.
场景可以用几种不同的方式呈现。一种方法是为拟议系统的每个主要处理功能指定场景。使用这种方法，本节将为每个流程包含一个部分。然后，每个部分将包含多个较低级别的部分，每个部分对应该过程支持的每个场景。另一种方法是开发基于线程的场景，其中每个场景在拟议的系统中遵循一种事务类型。在这种情况下，每个部分将包含每种交互类型的一个场景，以及降级、压力加载和备份操作模式的场景。其他替代方案包括遵循系统中每个用户能力的信息流、遵循控制流或关注系统中的对象和事件。
Scenarios are an important element of an OpsCon and should therefore receive substantial emphasis. The number of scenarios and level of detail specified will be proportional to the perceived risk and the criticality of the project.
场景是OpsCon的一个重要组成部分，因此应该得到充分的重视。指定的场景数量和详细程度将与项目的感知风险和关键性成正比。
GJB438B/C和MIL-STD-498中的OCD文档解释如下：
在GJB5000A/CMMI 1.2中对第三个专用目标有个解释：“本特定目标的特定实践支持专用目标1“开发顾客需求”和专用目标2“开发产品需求”两方面需求的开发。与这个特定目标相关的特定实践涉及关于用户的预定环境分析和需求确认。”，也就是说，“Establish Operational Concepts and Scenarios”，对“开发顾客需求（利益相关方需求）”和“开发产品需求（系统/子系统需求）”这2个专用目标都需要进行，这个与ISO/IEC/IEEE以及INCOSE/NASA等标准都是一致的。
四、关于concept这个词的含义
在《INCOSE Guide for Writing Requirements 2019》中，解释concept这个词。
Concepts are typically narrative descriptions of ways in which the organization (and entities within an organization) expects to manage, acquire,develop, operate, support, and retire the business capability.
翻译为：concept通常是对组织（以及组织内的实体）期望管理、获取、开发、运营、支持和退役业务能力的方式的叙述性描述。
从图中可以看到，业务需求（Business Management层）、利益相关方需求（Business Operations层）、系统和子系统（System和System Element）都需要建立OpsCon。图中另外一个词ConOps（Concept of Operations）解释为：“一个组织对某一行动或一系列行动的设想或意图的概括的口头和图形的陈述。”
注:concept of operations经常体现在长期战略计划和年度执行计划中。在后一种情况下，计划中的concept of operations包括一系列相互关联的行动，这些行动将同时或相继执行。这个concept的设计是为了给出组织运作的总体情况。
五、回到GJB5000和GJB438B/C
GJB5000A/CMMI 1.2中专用实践3.1 制定运行方案和场景典型工作产品如下：
很显然，建立Operational Concepts and Scenarios是建立需求（Requirements）时要做的工作。由于大部分实施GJB5000的单位，项目的用户需求（或者OCD文档）应该是用户来提出，因此我们以系统需求/软件需求（系统元素或部件）为例，到底将Operational Concepts和Scenarios写在哪里呢？
既然上面提到用例（use case），我们就以需求的用例建模给出一个例子。
先按照OMG的定义给出用例和场景的定义。
用例描述了一个离散的、独立的序列，参与者可以执行该序列来实现有价值的结果；
actor和系统之间的一系列特定的活动和交互，也称为用例实例(use case instance)；实例是系统执行的一系列活动，这些活动产生了对某个参与者而言可观察的返回值；实例是使用系统或用例的某一条执行路径（Flow of Events），一个实例就有一个场景。
包括三种路径：基本路径（也称main flow, basic flow, normal course, primary scenario, main success scenario, sunny-day scenario, and happy path）、备选路径（Secondary scenarios）、异常。
ü Basic Path(Normal flow)：如用现金成功购买商品
ü Alternate Path(Alternative flow)：如现金不够换用信用卡付款，成功购买商品
ü Exception：如因现金和信用卡不够，购买失败
下面使用建模工具给出一个完整用例。
将用例生成活动图，则可以看到多条路径（实例）。
再看GJB438B/C，由于系统需求规格说明与软件需求规格说明基本一致，因此仅以软件需求规格说明为例。
对应的MIL-STD-498中对Requriments的说明，在GJB438B/C中丢掉了，且mode被翻译为了“方式”。
我们来看看mode（模式）的解释，在ISO/IEC/IEEE 29148中有一段内容如下：
A2.4.5 Modes of operation for the current system or situation
Describe the various modes of operation for the current system or situation (e.g., operational, degraded, maintenance, training, emergency, alternate-site, peacetime, wartime, ground-based, flight, active and idle modes). All of the modes that apply to all classes of users should be included. Important modes to include are degraded, backup and emergency modes, if such exist. This is especially true if these modes involve different geographical sites and equipment that have significant impacts on the operational aspects of the system.
描述当前系统或情况的各种操作模式（例如，操作、降级、维护、训练、应急、备用站点、和平时期、战时、地面、飞行、活动和空闲模式）。应包括适用于所有类别用户的所有模式。重要的模式包括降级、备份和紧急模式（如果有的话）。如果这些模式涉及对系统操作方面有重大影响的不同地理位置和设备，则尤其如此。
This section can be further divided into lower-level sections, one for each mode described. System processes, procedures and capabilities or functions should be related to each mode, as appropriate, perhaps using a cross-reference matrix.
本节可进一步分为较低级别的部分，每种模式各一个。系统过程、程序和能力或功能应酌情与每种模式相关，或许可以使用交叉参考矩阵。
因此，运行方案要覆盖多种模式，显然在SRS3.1中不同模式下可能存在不同需求，当然同一个（类）需求也可能属于多种不同的模式。