IEEE 29148-软件工程中的系统操作概念

2.1.1 标识

包括本 OpsCon 适用的系统或子系统的识别号、标题和缩写（如适用）。如果已以分层或网络方式开发了整个系统的相关 OpsCon 文档，则应描述本文档相对于其他 OpsCon 文档的位置。

2.1.2 文档概述

总结并阐述 OpsCon 文档的目的和动机。还应提及文档的目标受众。描述与使用 OpsCon 相关的任何安全或隐私考虑。概述本指南的其余部分。在大多数情况下，OpsCon 文档的目的将是：向采购方和/或供应商传达用户对拟议系统的需求和期望；或者传达采购方或供应商对用户需求的理解以及系统如何运行以满足这些需求。但是，OpsCon 文档也可能用于其他目的，例如在多个用户组、多个收购方组织和/或多个供应商之间建立共识。

OpsCon 文档的受众可以是各种各样的人：

• 用户可能会阅读它来确定他们的需求和愿望是否已被其代表正确指定或验证供应商是否理解他们的需求。
• 采购方可能会阅读它来了解用户的需求和/或供应商对这些需求的理解。-
• 供应商通常会使用 OpsCon 文档作为系统生命周期活动的基础，并让新团队成员熟悉问题域和 OpsCon 适用的系统。

2.1.3 系统概述

简要说明 OpsCon 适用的拟议系统或子系统的用途。描述系统的一般性质，并确定项目发起人、用户机构、供应商组织、支持机构、认证机构或认证机构以及将运行该系统的运营中心或站点。还要确定与当前或拟议系统相关的其他文档。强烈建议提供系统的图形概述。这可以是上下文图、顶级对象图或描述系统及其环境的其他类型的图表。可能引用的文档包括但不限于：项目授权、相关技术文档、重要信函、有关相关项目的文档、风险分析报告和可行性研究。

2.3.1 背景、目标和范围

概述当前系统或情况，包括背景、任务、目标和范围（如适用）。除了提供当前系统的背景之外，本节还应简要概述当前系统的动机。系统动机的示例可能包括某些任务的自动化或应对某些威胁情况。还应定义当前系统的目标，以及用于实现这些目标的策略、解决方案、战术、方法和技术。操作模式、用户类别和操作环境接口定义了拟议系统的范围，本节将对此进行总结，并在后续章节中更详细地定义。

2.3.2 运营政策和限制

描述适用于当前系统或情况的任何运营政策和约束。运营政策是针对当前系统运营而预先确定的管理决策，通常以指导决策活动的一般性陈述或理解的形式出现。政策限制了决策自由，但确实允许一定的自由裁量权。运营约束是对当前系统运营的限制。运营约束的示例包括：

• 对系统运行时间的限制，可能受到安全终端访问的限制；
• 操作系统可用人员数量的限制；
• 对计算机硬件的限制（例如，应在计算机 X 上运行）；
• 办公空间等运营设施的限制。

2.3.3 当前系统或情况的描述

提供当前系统或情况的描述，包括以下内容（如适用）：

• 操作环境及其特点；
• 主要系统要素及其之间的互连；
• 与外部系统或程序的接口；
• 当前系统的能力、功能/服务和特性；
• 描述输入、输出、数据流 ⁵、控制流以及手动和自动过程的图表和随附说明，足以从用户的角度了解当前系统或情况；
• 系统运行成本；运营风险因素；
• 性能特征，如速度、吞吐量、容量、频率、工作负载；
• 质量属性 ⁶，例如：可用性、正确性、效率、可扩展性、灵活性、互操作性、可维护性、可移植性、可靠性、可重用性、可支持性、可生存性和可用性；
• 紧急情况下的安全、保密、完整性和业务连续性规定；
• 支持系统的物流要求。

由于本节的目的是描述当前系统及其运行方式，因此使用任何可用于此目的的工具和/或技术都是适当的。系统描述必须足够简单和清晰，以便文档的所有目标读者都能完全理解。同样重要的是要记住，OpsCon 文档是使用用户的术语编写的。应尽可能使用图形工具，特别是因为 OpsCon 文档应该能够被不同类型的读者理解。有用的图形工具包括但不限于工作分解结构 (WBS)、N2 图表、序列或活动图表、功能流程图、结构图、分配图、数据流图 (DFD)、对象图、上下文图、故事板和实体关系图。

运行环境的描述应该识别用于操作现有系统的设施、设备、计算硬件、软件、人员和操作程序（如适用）。这种描述应尽可能详细，以便让读者了解所用操作设备的数量、版本、容量等。例如，如果当前系统包含数据库，则应指定存储单元的容量，前提是该信息对用户的操作能力有影响。同样，如果系统使用通信链路，则应指定这些链路的容量，如果它们对用户能力、响应时间或吞吐量等因素有影响。

应该描述对当前系统的运行或运行环境产生影响的安全、保障和隐私方面。本节中的信息应根据系统或情况进行适当组织，只要能清晰地描述现有系统即可。如果部分描述篇幅过长，可以将其包含在附录中或通过引用纳入。可以包含在附录中的材料示例是数据词典。可以作为引用纳入的材料示例可能是当前系统的操作政策和程序的详细手册。

2.3.4 当前系统或情况的运行模式

描述当前系统或情况的各种操作模式（例如，操作、降级、维护、培训、紧急、备用站点、平时、战时、地面、飞行、活动和空闲模式）。应包括适用于所有类别用户的所有模式。重要的模式是降级、备份和紧急模式（如果存在）。如果这些模式涉及对系统操作方面有重大影响的不同地理位置和设备，则尤其如此。

本节可进一步细分为较低级别的章节，每个章节针对所描述的每种模式。系统流程、程序和能力或功能应酌情与每种模式相关联，或许可以使用交叉引用矩阵。

2.3.5 用户类别及其他涉及人员

用户类别通过用户与系统交互的方式进行区分。区分用户类别的因素包括共同的职责、技能水平、工作活动以及与系统交互的方式。不同的用户类别可能具有与系统交互的不同操作场景。在这种情况下，用户是与现有系统交互的任何人，包括操作用户、数据输入人员、系统操作员、操作支持人员、软件维护人员和培训师。

如果有助于传达内容，则可以进一步组织本节，如下所示。

2.3.6 支持环境

描述当前系统的支持概念和支持环境，包括支持机构、设施、设备、支持软件、维修或更换标准、维护级别和周期以及存储、分发和供应方法。

2.4.1 变更的理由

本节应该：

• 简要概述用户需求、任务、目标、环境等方面的新增或修改内容，接口、人员或其他需要新系统或修改系统的因素，
• 总结当前系统或情况的缺陷或局限性，使其无法应对新的或变化的因素，
• 为新系统或修改后的系统提供依据。
  • 1. 如果拟议的系统是为了满足一个新的机会，描述为什么应该采用新系统的原因并加以发展以满足这一机遇。
  • 2. 如果拟议的系统改进了当前的操作，请描述修改现有系统决定背后的理由（例如，降低生命周期成本或提高人员效率）。
  • 3. 如果拟议的系统实现了一项新的功能，请解释为什么该功能是必要的。

2.4.2 期望变更的描述

总结新的或修改后的能力、功能、流程、接口，以及为应对 2.4.1 中确定的因素而需要的其他变更。变更应基于现有系统。如果没有现有系统作为变更的基础，则总结新系统将提供的能力。此描述应酌情包括以下内容：

• 功能变化。描述为使新系统或修改后的系统满足其目标和要求而需要添加、删除和修改的功能和特性。
• 系统处理变化。描述数据转换过程中的变化，这些变化将导致使用相同数据产生新输出、使用新数据产生相同输出，或两者兼而有之。
• 接口变更。描述会导致接口变更的系统变更，以及会导致系统变更的接口变更。
• 人员变动。描述由于新需求、用户类别变化或两者共同引起的人员变动。
• 环境变化。描述运行环境的变化，这些变化将导致系统功能、流程、接口或人员的变化，和/或由于系统功能、流程、接口或人员的变化而应在环境中进行的变更。
• 运营变更。描述上述变更导致的用户运营政策、流程、方法或日常工作惯例的变更。
• 支持变更。描述由于系统功能、流程、接口或人员的变化而引起的支持要求的变更，和/或由于支持环境的变化而引起的系统功能、流程、接口或人员的变化。
• 其他变更。描述将对用户产生影响但不属于上述任何类别的其他变更。

2.4.3 变更之间的优先级

确定所需更改和新功能的优先级。每个更改都应归类为必需、可取或可选。可取和可选更改应在其类别中按优先级排序。如果没有现有系统作为更改的基础，本节应对拟议系统的功能进行分类和优先级排序。

基本功 ⁸能。新系统或修改后的系统应提供的功能。应针对每个基本功能解释如果不实现这些功能将产生的影响。

可取的功能。新系统或修改后的系统应提供的功能。应优先考虑可取的功能。应针对每个可取的功能解释其可取性的原因。

可选功能。新系统或修改后的系统可能提供的功能。应优先考虑可选功能。应解释每个可选功能为可选功能的原因。

将所需的更改和新功能分为必需、可取和可选类别，对于指导拟议系统生命周期内的决策过程非常重要。这些信息在预算或计划削减或超支的情况下也很有用，因为它可以确定哪些功能必须完成，哪些功能可以推迟或省略。

2.4.4 考虑但未包括的变更

确定 2.4.2 中考虑但未包括的变更和新功能，以及不包括它们的理由。通过描述考虑但未包括在拟议系统中的变更和功能，作者记录分析活动的结果。这些信息对参与系统的其他人员很有用，无论是用户、采购方还是供应商，如果他们想知道是否考虑过某个更改或功能，如果是，为什么没有包括它。特别是在软件中，很少有外在迹象表明哪些已经改变、改进或仍然不安全或不可靠（例如，在某些场景或变通方法中）。

2.4.5 假设和约束

描述适用于所识别的变更和新功能的任何假设或约束。这应包括在新系统或修改后的系统的生命周期内会影响用户的所有假设和约束。假设是被视为真实的条件。假设的一个例子是系统工作量将在未来两年内翻倍，因此需要性能更高的新系统。约束是对新系统或修改后的系统或所用流程施加的外部限制。约束的例子包括外部接口要求以及进度和预算的限制。

2.5.1 背景、目标和范围

概述新系统或修改后的系统，包括背景、任务、目标和范围（如适用）。除了提供拟议系统的背景之外，本节还应简要概述该系统的动机。系统动机的示例可能包括某些任务的自动化或利用新机会。还应定义新系统或修改后系统的目标，以及为实现这些目标而提出的策略、解决方案、战术、方法和技术。操作模式、用户类别和操作环境接口定义了拟议系统的范围，本节将对此进行总结，并在后续章节中更详细地定义。

2.5.2 运营政策和限制

描述适用于拟议系统的运营政策和约束。运营政策是预先确定的管理决策，涉及新系统或修改后的系统的运营，通常以指导决策活动的一般性声明或理解的形式出现。政策限制了决策自由，但也允许一定的自由裁量权。运营约束是对拟议系统运营的限制。运营约束的示例包括：

• 系统运行时间受到限制，
• 可能受到安全终端访问的限制，
• 操作系统可用人员数量受到限制，
• 对计算机硬件的限制（例如，应在计算机 X 上运行），以及对办公空间等运营设施的限制性约束。

2.5.3 拟议系统的描述

本节将包含拟议系统描述的主要部分。它提供了拟议系统的描述，包括以下内容（视情况而定）：

• 运行环境及其特点，
• 主要系统元件及其之间的相互连接，
• 与外部系统或程序的接口，
• 拟议系统的能力或功能，
• 描述输入、输出、数据流以及手动和自动过程的图表和随附说明，足以从用户的角度理解所拟议的系统或情况，
• 系统运行成本，
• 运营风险因素，
• 性能特征，如速度、吞吐量、容量、频率，
• 质量属性，如：可靠性、可用性、正确性、效率、可扩展性、灵活性、互操作性、可维护性、可移植性、可重用性、可支持性、生存性和可用性，
• 以及紧急情况下的安全、保密、完整性和业务连续性的规定，
• 支持系统的物流要求。

由于本节的目的是描述所拟议的系统及其应如何运行，因此使用任何可用于此目的的工具和/或技术都是适当的。有关进一步讨论，请参阅 2.3.3。

2.5.4 操作模式

描述拟议系统的各种运行模式（例如，常规、降级、维护、训练、紧急、备用站点、平时、战时、地面、飞行、活动和空闲模式）。包括适用于所有用户类别的所有模式。重要的模式是降级、备份和紧急模式（如果存在）。如果这些模式涉及对系统有重大影响的不同地理位置和设备，则尤其如此。

本节可进一步细分为较低级别的章节，每个章节针对所描述的每种模式。系统流程、程序和能力或功能应与每种模式相关。

2.5.5 用户类别及其他涉及人员

用户类别通过用户与系统交互的方式进行区分。区分用户类别的因素包括职责、技能水平、工作活动和与系统交互的方式。不同的用户类别可能具有与系统交互的不同操作场景。在这种情况下，用户是与拟议系统交互的任何人，包括操作用户、数据输入人员、系统操作员、操作支持人员、维护人员和培训师。如果有助于传达内容，则可以将此部分进一步划分为较低级别的部分。

2.5.6 支持环境

描述拟议系统的支持概念和支持环境，包括支持机构、设施、设备、支持软件、维修或更换标准、维护级别和周期以及存储、分发和供应方法。

2.7.1 运营影响

将本节进一步划分为较低级别的部分，以描述拟议系统运行期间对用户、支持和运营或维护组织的预期运营影响。这些影响可能包括以下内容：

• 与主要或备用计算机操作中心接口，
• 程序上的改变，
• 使用新的数据源，
• 输入系统的数据的数量、类型和时间的变化，
• 数据保留要求的变化，
• 基于紧急情况、灾难或事故情况的新运作模式，
• 如果所需数据不易获得，则提供输入数据的新方法，
• 运营预算的变化，
• 以及运营风险的变化。

2.7.2 组织影响

进一步细分本节，以描述拟议系统运行期间对用户、开发和支持或维护组织的预期运营影响。这些影响可能包括以下内容：

• 职责变更，
• 增加或取消职位，
• 培训或再培训用户，
• 人员数量、技能水平、职位标识或位置的变化，
• 以及紧急情况、灾难或事故发生后，在一个或多个备用地点进行应急行动所需的人员数量和技能水平。

2.7.3 开发过程中的影响

进一步细分本节，描述拟议系统开发项目期间对用户、开发和支持或维护机构的预期影响。这些影响可能包括以下内容：

• 参与合同授予前的研究、会议和讨论，
• 用户和支持人员参与审查和演示、评估系统的初始操作能力和演进版本、开发或修改数据库以及所需的培训，
• 新系统和现有系统并行运行，
• 以及对拟议系统进行系统测试期间的运行影响。

2.8.1 好处

提供拟建系统将提供的好处的定性（尽可能提供定量）摘要。此摘要应包括以下项目（如适用）。在每种情况下，好处都应与已发现的缺陷相关。

• 新功能。额外的新特性或功能。
• 增强能力。现有能力的升级。
• 已删除的功能。已删除未使用、过时、令人困惑或危险的功能。
• 提高性能。响应时间更短、存储要求更低、质量更高、系统/用户工作量减少等。

2.8.2 缺点和局限性

提供所拟议系统的缺点和/或局限性的定性（尽可能定量）摘要。缺点可能包括需要重新培训人员、重新安排工作空间或更改为新风格的用户界面，局限性可能包括用户想要但未包括的功能，降低现有能力以获得新功能，或者使某些复杂操作的响应时间超过预期。

2.8.3 考虑的替代方案

描述所考虑的主要替代方案、权衡分析结果以及所做决策的理由。在 OpsCon 文档中，替代方案是操作替代方案，而不是设计替代方案，除非设计替代方案可能受到新系统所需的操作能力的限制。这些信息可用于现在和以后确定是否分析和评估了给定的方法，或者为什么拒绝了某种方法或解决方案。如果不记录，这些信息可能会丢失。