进行系统定义活动是为了创建和详细描述利益系统(SoI)，以满足确定的需求。这些活动被分组并描述为一般过程，包括系统需求定义、系统架构定义、系统设计定义和系统分析。系统的体系结构定义可能包括相关逻辑体系结构模型和物理体系结构模型的开发。在任何迭代期间和/或结束时，执行间隙分析，以确保所有系统需求都映射到体系结构和设计。

系统定义活动建立在来自概念定义的工件和决策的基础上，主要是(SoI)任务的明确表述、利益相关者的需求和需求，以及初步的操作概念。请参阅生命周期过程和企业需求，以获得关于需求和需求从概念定义中描述的业务或企业和利益相关者抽象级别到系统定义中描述的系统和系统元素抽象级别转换的进一步详细信息。

系统定义活动(系统需求、体系结构和设计)的产品是系统实现的输入。

系统定义活动的具体活动和顺序以及它们与任何系统的生命周期活动的关系，特别是与概念定义和系统实现活动的密切结合，将取决于所使用的生命周期模型的类型。有关这些关系的并发性、迭代性和递归性的进一步讨论，请参阅应用生命周期过程。

主题

SEBoK 的每个部分都分为知识领域 (KA)，这些知识领域是具有相关主题的信息分组。 Kas 反过来又分为主题。 本 KA 包含以下主题：

• 系统需求
• 系统架构
• 逻辑架构模型开发
• 物理架构模型开发
• 系统设计
• 系统分析

有关第 7 部分中包含的案例研究和小插曲与第 3 部分中涵盖的主题的映射， 请参阅文章实施示例矩阵。

系统视图和系统元素

针对已定义概念的 工程系统 >解决方案包括一组工程元素、特性和属性。 这些元素以两种方式分组：

• 需求和需求视图
• 架构和设计视图

架构视图包括对感兴趣系统 (SoI) 的边界和接口的识别， 然后可以将其进一步细化为系统元素及其关系的集合。

需求和需求视图

需求提供了 系统作为一个整体旨在满足的目的和任务的总体视图，以及系统解决方案应该做什么的独立于技术的视图。 它们通常分为两种类型：

• 业务或任务需求和利益相关者需求 在 概念定义 KA 中定义和讨论。

• 系统需求，描述系统作为一个整体应该满足的功能以满足利益相关者的需求，并以一组适当的视图表达，非功能性需求表达安全性、安全性、可靠性等水平，这是需求的。 这些共同构成了生命周期后期验证 的基础

系统需求和利益相关者需求密切相关。 在实现两者之间的一致性之前，两者都不能被认为是完整的，正如可追溯性所证明的那样，可能需要多次迭代。

用于识别、设计和管理系统需求的过程活动 在 KA 的 系统需求文章中有进一步的描述。

架构和设计视图

给定的工程系统是一种可以解决/回答问题或机会（通过需求视图表示）的解决方案； 解决方案可能或多或少复杂 。 由于问题/解决方案的特征或属性，一个复杂的解决方案不能用单一的视图或模型来理解（参见系统 复杂性） ）。 特征被构造为类型或实体； 类型相互关联。 类型集的实例化可以理解为系统的架构。 系统架构的大多数解释都是基于相当无形的结构概念。 因此，系统架构和设计用功能、接口、资源流项、信息元素、物理元素、节点、链接等类型或实体的集合形式表示。这些实体可能具有维度、环境等属性/特征。弹性、可用性、可靠性、可学习性、执行效率等。实体通过关系的方式相互关联，并且通常被分组以表示系统架构和设计的视图/模型。

视点 和视图 有时在 架构框架中指定。 视图通常由模型生成。 许多系统工程实践使用逻辑和物理视图来对系统架构和设计进行建模。

• 架构的逻辑视图 支持系统在其整个生命周期中的逻辑操作，并且可能包括功能、行为和时间视图/模型。 操作场景将任务细化为 描述任务如何执行（行为）的功能和动态结构的集合。

• 体系结构的物​​理 视图是一组执行系统功能的 系统元素。 这些系统元素可以是物质的或非物质的（例如，由硬件、软件和/或人类角色制成的设备）。

系统架构的边界取决于工程师在 SoI 范围内和之外包括哪些内容。 这一决定标志着从问题上下文的表征到解决方案定义的开始的转变。

面对构成物理体系结构的系统元素的潜在数量，可以将系统元素集分组以形成系统。 SoI（最高层）的分解可能包括对几层系统（系统的中间层）的分解，直到技术系统元素（最低层）被定义。 任何分解层都可能包括系统和不可分解的技术系统元素。 每一层之间的关系是 递归的； 由于系统元素也是一个工程系统，因此可以在其自身的上下文中使用先前的视图来对其进行表征。

系统架构的逻辑和物理表示相互映射。 系统元素之间的交互由接口定义，其复杂性很大程度上取决于定义系统架构和设计的方式。 概念定义的输出和系统解决方案之间的关系，以及可用于描述系统元素之间更完整的一组特征的系统其他视图的范围，在 逻辑架构模型开发 和 物理模型中进一步讨论。系统定义的体系 结构模型开发 部分。

系统合成与分解

系统定义是通过将 SoI 系统地合成 为系统和系统元素来管理的。 解决方案综合可以是自上而下或自下而上的，如 综合可能的解决方案中所述。 然而，随着系统架构定义的推进，系统和系统元素的分解出现了； 这形成了系统分解结构（SBS）。 出于项目管理的目的，SBS 的每个系统都可以包含在一个 构建块 中，这是在 (ANSI/EIA 1998) 中引入的一个概念，也称为 系统块 。

利益相关者需求和 系统需求 存在于 SBS 的所有层。 在 ISO/IEC/IEEE 29148 系统和软件工程 - 需求工程 (ISO 2011) 中，这些层被称为抽象层。 除了系统地引入系统层外，架构和设计过程还 通过抽象级别 系统需求图 1 说明了这种方法。

图 1. 自上而下的架构和设计开发以及需求（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

如图1所示：

• 白色椭圆代表抽象层次递减的需求，箭头代表使用架构和设计过程在各个层次上对这些需求的转换。 利益相关者对需求、期望和约束的表达被转化为利益相关者的需求。
• 下一个转换跨越了问题和解决方案区域之间的边界，将利益相关者需求转换为系统需求，反映了有限的解决方案空间。
• 在 SoI 级别开发系统架构，用于识别系统和系统元素，并确定它们如何一起运行以满足 SoI 需求。

这种方法递归地应用于每个抽象/分解级别，认识到相同的通用过程应用于多个抽象级别。 在这种分解的任何级别，一个或多个解决方案选项都可以作为系统架构呈现。在系统分析 过程中讨论了选择和证明最适合系统需求、相关利益相关者需求和更广泛生命周期关注点的解决方案的 过程。

下面的图 2 描绘了每个系统块中发生的工程。 必要时，系统元素通过系统元素需求集定义，这些需求成为其他系统块（ 级别 n+1 ）的输入。 然后使用系统定义过程递归地应用该方法。

图 2. 定义过程的递归实例化（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

在 n+1 级别，系统或系统元素还可以收集与此架构和设计级别直接相关的其他利益相关者需求。 每个系统中的流程都是通用的，但在本地用途、范围和上下文方面是独一无二的。

有关系统需求和体系结构过程的迭代和递归应用的讨论， 请参阅应用生命周期过程，有关将需求和需求转换为系统和系统元素抽象级别的更多详细信息，请参阅 生命周期过程和企业需求 。

SEBoK 第 2 部分讨论了系统思维 如何适用于系统定义的不同方面。 特别是，请参阅Engineered System Context 中关于系统的递归性质和工程系统上下文的讨论；综合可能的解决方案中自上而下和自下而上方法之间的对比以及 解决方案架构选项和选择在替代解决方案之间的分析和选择 中的作用。

系统需求

系统需求是系统级别 的所有需求， 描述了系统作为一个整体应满足利益相关者需求的功能，并以文本陈述、视图和非功能性需求的适当组合来表达； 后者表示必要的安全、安保、可靠性等水平。

系统需求在系统工程中扮演着重要角色，因为它们：

• 形成系统架构和设计活动的基础。
• 形成系统 集成 和 验证 活动的基础。
• 作为 验证和利益相关者接受的参考。
• 在整个项目中进行交互的各种技术人员之间提供一种沟通方式。

利益相关者需求的引出从 概念定义开始，最初将通过访谈和任务分析进行开发。在系统定义 期间会详细考虑系统需求 。 在实现两者之间的一致性之前，两者都不能被认为是完整的，正如可追溯性所证明的那样，可能需要多次迭代。

需求的定义和目的

需求是识别产品或过程操作、功能或设计特征或约束的声明，它是明确的、可测试的或可测量的，并且对于产品或过程的可接受性是必要的（ISO 2007）。

为避免与需求有关的众多术语混淆，请考虑以下分类：

• 过程角色或状态 ：需求在定义过程中扮演的角色； 例如，它在系统块中的位置（例如，已翻译、派生、满意）或其协议状态（例如，建议、批准、取消）。
• 抽象级别 ：需求所代表的定义过程中的级别； 例如，利益相关者需求、系统需求、系统元素需求。
• 需求类型 ：需求本身的性质； 例如，功能、性能、约束等。

任何单个需求可能同时处于特定状态、特定抽象级别和特定类型。 有关需求类型之间差异的更多说明，请参阅（Martin 1997，第 2 章）。

管理系统需求的原则

与利益相关者需求和逻辑架构的关系

一组 利益相关者的需求 被澄清，并从需求陈述翻译成面向工程的 语言，以实现适当的架构定义、设计和验证活动，这些活动是系统需求分析的基础。

系统需求基于对与性能和其他质量测量相关的任何解决方案系统所需功能的识别和综合，并为评估候选解决方案和验证完整系统提供基础。 系统需求以对架构和设计有用的 技术语言表达：明确、一致、连贯、详尽和可验证。 当然，与利益相关者密切协调是必要的，以确保翻译准确并保持可追溯性。 这导致了一组系统功能和需求，这些功能和需求指定了可测量的特性，这些特性可以形成系统实现的基础。

逻辑架构 定义了 系统边界和功能，从中可以得出更详细的系统需求。 这个过程的起点可能是从利益相关者需求中识别功能需求，并以此开始架构定义，或者从高级功能架构视图开始，并将其用作构建系统需求的基础。 所采用的确切方法通常取决于系统是已经了解的产品或服务的演变，还是新的和前所未有的解决方案（请参阅 综合可能的解决方案）。 然而，当流程启动时，重要的是利益相关者需求、系统需求和逻辑架构都是完整的、相互一致的，并且在系统生命周期模型中的适当点上一起评估。

架构和设计期间的可追溯性和系统需求分配

需求可追溯性提供了跟踪信息的能力，从利益相关者需求的来源，到顶层需求和系统层次结构中所有级别的其他系统定义元素（请参阅 应用生命周期过程）。 在提出工程改进或变更请求的情况下执行影响分析时，可追溯性还用于提供对变更程度的理解作为输入。

在体系结构定义和设计期间，可以使用多种方法在系统层次结构中将需求从一个级别分配到较低级别，视情况而定 - 参见表 1。

表 1. 系统需求的评估类型。 （SEBoK 原创）

系统需求分类

根据需求定义方法和/或所应用的体系结构和设计方法，系统需求的几种分类是可能的。 (ISO 2011) 提供了表 2 中总结的分类（有关其他分类，请参见参考资料）。

表 2. 系统需求分类示例。 （SEBoK 原创）

需求管理

执行需求管理以确保系统和系统元素需求与系统的其他表示、分析和工件保持一致。 它包括提供对需求的理解、获得承诺、管理变更、维护需求之间以及与系统定义的其余部分的双向可追溯性，以及与项目资源和进度保持一致。

有许多工具可用于为需求管理提供支持基础设施； 最好的选择是与项目或企业的流程相匹配的。 需求管理还与基线管理和控制的配置管理密切相关。 当需求被定义、记录和批准后，需要将它们置于基线管理和控制之下。 基线允许项目分析和了解正在进行的提议变更的影响（技术、成本和进度）。

过程方法

方法的目的和原则

系统需求分析过程的目的是将所需服务和属性的利益相关者、面向用户的视图转换为满足用户操作需求的产品技术视图。 这个过程构建了一个系统的表示，它将满足利益相关者的需求，并且在限制允许的情况下，并不意味着任何特定的实施。 它产生了可测量的系统需求，从供应商的角度指定了它必须具备哪些性能和非性能特征才能满足利益相关者的需求（ISO 2015）。

进程的活动

在此过程中的主要活动和任务包括：

1. 分析利益相关者的需求，以检查预期服务和操作场景、条件、操作模式和约束的完整性。
2. 定义系统需求及其基本原理。
3. 使用建议的分类对系统需求进行分类（参见上面的示例）。
4. 将派生的需求（来自架构和设计）合并到系统需求基线中。
5. 建立与利益相关者需求和需求的向上可追溯性。
6. 在系统层次结构的相邻级别的需求之间建立双向可追溯性。
7. 验证每个系统需求的质量和完整性以及系统需求集的一致性。
8. 根据一组利益相关者需求验证每个系统需求的内容和相关性。
9. 识别 系统需求可能产生的潜在风险（或威胁和危害）。
10. 综合、记录和管理系统需求和潜在的相关风险。
11. 在批准需求后，建立控制基线以及其他系统定义元素以及已建立的配置管理实践。

检查系统需求的正确性

应检查系统需求以衡量它们是否表达得很好和适当。 有许多特征可用于检查系统需求，例如标准的同行评审技术以及将每个需求与一组需求特征进行比较，这些在“需求的呈现和质量”的表 2 和表 3 中列出" 部分（下）。 可以使用“方法和建模技术”（下文）部分中描述的需求获取和基本原理捕获来进一步验证需求。

方法和建模技术

需求获取和原型设计

需求启发需要用户参与，并且可以有效地获得利益相关者的参与和支持。 质量功能部署 (QFD) 和原型设计是可以应用并在本节中定义的两种常见技术。 此外，访谈、焦点小组和 Delphi 技术经常被用于引出需求。

QFD 是一种强大的技术，可以引出需求并将设计特征与用户需求进行比较（Hauser 和 Clausing 1988）。 QFD 应用程序的输入是用户需求和操作概念，因此用户参与至关重要。 应包括整个生命周期的用户，以确保用户需求的所有方面都得到考虑和优先考虑。

早期原型设计可以帮助用户和开发人员以交互方式识别功能和操作需求以及用户界面约束。 这可以实现真实的用户交互、发现和反馈，以及一些敏感性分析。 这提高了用户对需求的理解，增加了满足他们实际需求的可能性。

捕获需求原理

将利益相关者需求转化为系统需求的一种强大且具有成本效益的技术是捕获每个需求的基本原理。 需求基本原理只是关于需求存在的原因、所做的任何假设、相关设计研究的结果或任何其他相关支持信息的陈述。 这支持进一步的需求分析和分解。 基本原理可以直接在需求数据库中获取（Hull、Jackson 和 Dick 2010）。

这种方法的一些好处包括：

• 减少需求总数 - 该过程有助于识别重复项。 减少需求数量将降低项目成本和风险。
• 早期暴露不良假设
• 删除设计实现 ——许多写得不好的利益相关者需求是变相的设计需求，因为客户有意或无意地指定了一个候选实现。
• 改善与利益相关者社区的沟通 ——通过捕获所有利益相关者需求的基本原理，用户和设计人员之间的沟通渠道得到了极大的改善。 （改编自 (Hooks and Farry 2000) 的第 8 章）。

建模技术

当需求必须详细或细化时，或者在涉及利益相关者需求定义和任务分析期间未考虑的主题时，可以使用的建模技术包括：

• 状态图模型（ISO 2011，第 8.4 节）
• 场景建模（ISO 2011，第 6.2.3.1 节）
• 仿真、原型制作（ISO 2011，第 6.3.3.2 节）
• 质量功能部署（INCOSE 2011，第 83 页）
• 系统建模语言 (SysML) 序列图、活动图、用例、状态机图、需求图 (OMG 2010)
• 操作场景的功能流程图（Oliver、Kelliher 和 Keegan 1997）

需求的呈现和质量

通常，需求以文本形式提供。 存在编写良好需求的指南； 它们包括关于需求陈述的语法、措辞（排除、概念的表示等）和特性（具体、可测量、可实现、可行、可测试等）的建议。 请参阅（INCOSE 2011，第 4.2.2.2 节）和（ISO 2011）。

需求和需求集都有几个特征，用于帮助开发和验证需求在解决方案中的实现。 表 3 提供了单个需求的特性列表和描述，表 4 提供了一组需求的特性列表和描述，改编自（ISO 2011，第 5.2.5 和 5.2.6 节）。

表 3. 个别需求的特征。 （SEBoK 原创）

注意：一些来源认为可追溯性是一种特性（ISO 2011）。 然而，最近的观点是，可追溯性实际上是需求的一个属性。 也就是说，附加到需求的东西，而不是需求的内在特征（INCOSE 2011）。 可追溯性特征或属性被定义为： 需求可向上追溯至特定的书面利益相关者需求声明、更高层次的需求或其他来源（例如，贸易或设计研究）。 该需求还可以向下追溯到较低层需求规范或其他系统定义工件中的特定需求。 也就是说，需求的所有父子关系在跟踪中被识别，以便需求跟踪到它的源和实现。

表 4. 一组需求的特征。 （SEBoK 原创）

表格中的需求

可以在表格中提供需求，特别是在为系统或系统元素指定一组参数时。 提供标准表格模板是一种很好的做法。 对于表，以下约定适用：

• 调用需求集中明确指向该表的每个需求表。
• 用唯一的标题和表号标识每个表。
• 在表格标题中包含“需求”一词。
• 在紧接其前的文本中确定表格的用途，并解释如何阅读和使用表格，包括上下文和单位。
• 对于独立因变量情况，以最适合信息使用的方式组织表格。
• 每个单元格最多应包含一个需求。

流程图中的需求

流程图通常包含图形形式的需求。 这些需求可能包括必须纳入系统的逻辑、操作需求、过程或程序需求，或由一系列相互关联的步骤以图形方式最佳定义的其他情况。 对于流程图，以下约定适用：

• 在明确指向流程图的需求集中调用流程图。
• 用唯一的标题和图号标识每个流程图。
• 在流程图的标题中包含“需求”一词。
• 在流程图中清楚地指出和解释代表需求的独特符号。

图纸需求

图纸还提供了定义需求的图形方式。 图纸中定义的需求类型取决于图纸的类型。 以下约定适用：

• 当图纸可以帮助描述以下内容时，请使用图纸：
  • 空间需求
  • 接口需求
  • 布局需求
• 在明确指向图纸的需求集中调用图纸。

工件

此过程可能会创建多个工件，例如：

• 系统需求文件
• 系统需求证明文件（用于可追溯性目的）
• 系统需求数据库，包括可追溯性、分析、基本原理、决策和属性（如适用）。
• 系统外部接口需求文档（该文档描述了系统的接口与其使用环境的外部元素；接口需求可以集成或不集成到系统需求文档中。

这些工件的内容、格式、布局和所有权将根据创建它们的人以及它们将在哪个域中使用而有所不同。 在它们和过程的输出之间，活动应该涵盖本文第一部分中确定的信息。

关于系统需求的实际考虑

如表 5 中所讨论的，有几个 缺陷 会抑制一组最佳系统需求的生成和管理。

表 5. 系统需求定义的主要缺陷。 （SEBoK 原创）

表6 中 经过验证的实践 已被反复证明可以降低项目风险和成本，提高客户满意度，并产生成功的系统开发。

表 6. 经验证的系统需求实践。 （SEBoK 原创）

系统架构

系统架构 活动的目的是根据逻辑上相互关联和一致的原则、概念和属性来定义一个全面的解决方案。 解决方案架构具有尽可能满足由一组系统需求（可追溯至任务/业务和利益相关者需求）和生命周期概念（例如，运营、支持）所表达的问题或机会的特性、属性和特性并且可以通过技术实现（例如，机械、电子、液压、软件、服务、程序、人类活动）。

系统架构是抽象的、面向概念化的、全局性的，并且专注于实现系统的任务和生命周期概念。 它还侧重于系统和系统元素的高级结构。 它解决了利益系统的架构原则、概念、属性和特征。 它也可以应用于一个以上的系统，在某些情况下，形成了类似或相关系统的类或族的通用结构、模式和一组要求。

一般概念和原则

结构的概念

SEBoK认为系统工程涵盖了系统创建的所有方面，包括系统架构。

系统架构的大多数解释都是基于结构的相当无形的概念(即元素之间的关系)。一些作者限制了建筑结构的类型;例如，限制自己的功能和物理结构。最近的实践已经扩展了对结构的考虑，包括行为、时间和其他维度。

ISO/IEC/IEEE 42010系统和软件工程——体系结构描述(ISO 2011)提供了一个有用的体系结构描述，它考虑了涉众的关注点、体系结构观点、体系结构视图、体系结构模型、体系结构描述以及整个生命周期的体系结构。

关于系统架构特性的讨论可以在(Maier和Rechtin 2009)中找到。

INCOSE英国建筑工作组(Wilkinson et al. 2010, Wilkinson 2010)描述了一种试图开发和应用系统方法来表征系统工程中的建筑信仰系统的尝试。

系统架构描述

架构框架包含标准化的视点、视图模板、元模型 、模型模板等，这些有助于开发系统架构的视图（参见 架构框架的示例）。 ISO/IEC/IEEE 42010 (ISO 2011) 规定了与架构描述相关的架构框架、视点和视图的规范性特征。 一个观点解决了一个特定的利益相关者关注点（或一组密切相关的关注点）。 视点指定了用于开发系统架构以解决该关注点（或关注点集）的模型类型，模型应该生成的方式，以及模型如何关联并用于组成视图。

逻辑和物理模型（或视图）通常用于表示系统架构的基本方面。 必须使用其他互补的观点和观点来表示系统架构如何解决利益相关者的关注，例如成本模型、流程模型、规则模型、本体模型、信念模型、项目模型、能力模型、数据模型等。

原则和启发式分类

工程师和建筑师混合使用数学原理 和 启发式方法（启发式方法是从经验中吸取的教训，但未经数学证明）。 当通过系统要求识别和定义问题时，原则和启发式方法可能会也可能不会解决它。 系统视图/模型中使用的原则和启发式可以根据使用这些系统视图/模型的域进行分类，如下所示：

1. 静态域 涉及分解为系统和系统元素的 SoI 的物理结构或组织。 它处理分区系统、系统元素和物理接口。
2. 动态域 涉及逻辑架构模型，特别是系统行为的表示。 它包括对功能（即输入流到输出流的转换）和系统功能之间以及外部对象或系统功能之间的相互作用的描述。 它考虑了对启动或停止系统功能执行的事件的反应。 它还涉及系统的有效性（即性能、操作条件）。
3. 时域 涉及系统功能执行的时间不变性水平。 这意味着每个功能都根据循环或同步特性执行。 它包括决策级别，这些决策级别是某些功能行为的异步特征。
4. 环境领域 涉及促成因素（生产、后勤支持等），还涉及 系统对自然灾害或威胁作出反应的生存能力，以及系统对内部潜在危险作出反应的完整性 。 这包括，例如，气候、机械、电磁和生物方面。

可以在 (Maier and Rechtin 2009) 中找到更详细的启发式分类。

从系统需求过渡到逻辑和物理架构模型

该方法的目的是从系统需求（从供应商/设计人员的角度表示问题，尽可能独立于技术）通过逻辑架构的中间模型将 逻辑 构模型的元素分配给系统元素候选物理架构模型。

（系统需求和逻辑架构模型有许多共同点，因为它们都是按功能线组织的，独立于实现。一些作者（Stevens 等人，1998）甚至将两者混为一谈，这简化了同时处理多个意见。是否采用这种方法取决于开发组织的具体实践以及合同边界的划分位置。）

根据性能标准和非功能性要求选择设计决策和技术解决方案，例如运行条件和生命周期约束（例如，环境条件、维护约束、实现约束等），如图 1 所示。 创建中间模型，例如逻辑架构模型，有助于根据系统要求验证系统的功能、行为和时间属性，这些要求在系统、物理接口或技术层的生命周期内没有重大技术影响，无需完全质疑系统的逻辑功能。

图 1. 在架构和设计期间使用中间逻辑架构模型（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

逻辑和物理架构模型开发之间的迭代

正如系统需求中所讨论的，综合解决方案所采用的确切方法 通常取决于系统是已了解的产品或服务的演变，还是新的和前所未有的解决方案（请参阅综合可能的解决方案）。

无论采用何种方法，架构活动都需要在逻辑架构模型开发和物理架构模型开发之间进行多次迭代，直到逻辑和物理架构模型一致并提供必要的详细程度。 最初的架构活动之一是创建基于 （功能的）名义场景的逻辑架构模型。物理架构模型用于确定可以执行系统功能的主要系统元素并对其进行组织。

随后的逻辑架构模型迭代可以考虑到系统元素的功能分配以及来自物理解决方案选择的派生功能。 它还通过引入以前未考虑的其他场景、故障分析和操作要求来补充初始逻辑架构模型。 派生功能分配给系统元素； 反过来，这会影响物理架构模型。

其他迭代的重点是生成解决方案的完整且一致的逻辑和物理视图。

在系统设计期间，技术选择可能会带来新的功能、新的输入/输出和控制流以及新的物理接口。 这些新元素可以导致创建新的系统需求，称为 派生需求。

接口的概念

接口的概念 是定义系统架构时要考虑的最重要的概念之一。 接口的基本方面是功能性的，并被定义为功能的输入和输出。 由于功能由物理元素（系统元素）执行，功能的输入/输出也由物理元素承载； 这些被称为物理接口。 因此，在接口的概念中考虑了功能和物理方面。 对接口的详细分析显示，功能 “发送”位于一个系统元素中，功能 “接收”位于另一个系统元素中，功能 “携带”由支持输入/输出流的物理接口执行（参见图 2）。

图 2. 完整的界面表示（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

在系统元素之间复杂交换的背景下，特别是在软件密集型系统中，协议被视为承载数据交换的物理接口。 然而，输入/输出流可以包括除数据之外的许多其他交换，例如能量。

新兴属性

系统的总体架构可能具有设计属性或操作效果，这些属性或操作效果来自 系统元素之间的排列和交互，但它们可能不是任何单个元素的属性，也可能不是针对整个系统的属性。

工程系统 的元素 在它们之间相互作用，可以产生理想或不理想的现象，例如抑制、干扰、共振或任何特性的增强。系统的定义包括对系统元素 之间相互作用的分析， 以防止不良属性并加强所需属性。

从系统中产生的属性可以有多种来源，从单个系统元素到多个元素之间的相互作用（Thome，B. 1993）。 一些作者使用术语 紧急属性来识别从系统中出现的任何属性，而其他人可能将此称为协同作用和保留紧急属性，以解释在系统开发期间未充分考虑但在运行期间出现的意外属性或属性。 SEBoK 第 2 部分讨论了涌现的系统概念（请参阅涌现 ）。

表 1. 属性和紧急属性。 （SEBoK 原创）

物理架构设计将包括识别可能的协同作用和紧急属性，并在逻辑或物理架构模型中包含派生的功能、组件、安排和/或环境约束，以在可接受的范围内避免、减轻或限制它们。 当相应的 派生需求影响利益的系统 (SoI) 时，应将它们添加到系统需求基线中。 这可以通过系统工程师的知识和经验或通过应用统模式来实现. 然而，在架构开发过程中，通常不可能预测、避免或控制所有出现的属性。 只有通过系统定义、 系统实现和系统部署和使用 之间的迭代，才能充分处理突发事件的后果（Hitchins，2008）

在架构和设计过程中应用了涌现的概念，以突出必要的派生功能； 此外，内部涌现通常与复杂性的概念相关联。 复杂自适应系统 (CAS) 就是这种情况，其中各个元素独立行动，但根据共同的约束和目标共同行动（Flood 和 Carson 1993）。 CAS 的例子包括：一个国家或国家集团内的全球宏观经济网络、股票市场、复杂的跨境控股公司网络、制造企业、地缘政治组织等（Holland, J. 1999 和 2006）。

系统元素的重用

系统工程师经常利用现有的系统元素。 这种重用约束必须被识别为系统需求，并在架构和设计过程中仔细考虑。 可以区分涉及系统元素重用的三种一般情况，如表 2 所示。

表 2. 系统元素重用案例（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

有一个普遍的想法是重用是 免费的； 但是，如果没有正确处理，重用可能会带来对项目来说可能很重要的风险（成本、期限、复杂性）。

过程方法

目的

系统架构过程的目的是生成系统架构备选方案，选择一个或多个能够构建利益相关者关注点并满足系统要求的备选方案，并在一组一致的视图中表达这一点。 （ISO 2015）。

应该注意的是，下面的架构活动与系统定义和概念定义活动重叠。 特别是，运营和业务环境的关键方面，以及因此的某些利益相关者的需求，强烈影响着架构开发和描述所采用的方法。 此外，架构活动将推动选择并适应已选择 的任何解决方案综合方法。

进程的活动

在此过程中执行的主要活动和任务包括：

1.初始化系统架构的定义

• 了解需要系统的环境/使用环境，以便深入了解利益相关者的关注点。 为此，分析相关的市场、行业、利益相关者、企业、业务、运营、使命、法律和其他有助于理解可以指导系统架构视图和模型定义的观点的信息。
• 捕获跨越系统生命周期阶段的利益相关者关注点（即期望或约束）。 这些关注点通常与与阶段相关的系统的关键特征有关； 应将它们转化为或纳入系统要求。
• 标记处理会影响架构元素定义的操作条件（例如，安全、安保、可靠性、人为因素、接口、环境条件）和生命周期约束（例如，维护、处置、部署）的系统需求。
• 建立架构路线图和策略，其中应包括方法、建模技术、工具、对任何支持系统、产品或服务的需求、过程要求（例如，测量方法和方法）、评估过程（例如，审查和标准）。
• 计划支持产品或服务的获取（需求、要求、采购）。

2. 定义必要的架构观点

• 根据确定的利益相关者关注点，确定可能支持模型和视图开发的相关架构观点和架构框架。

3. 开发候选架构模型和视图

• 使用相关的建模技术和工具，并结合相关利益者需求和需求过程以及系统需求过程，确定利益的系统上下文，包括与外部环境元素的边界。 该任务包括识别利益系统与外部元素的关系、接口或连接、交换和交互。 该任务能够定义或理解其使用环境中的预期操作场景和/或系统行为。
• 定义架构实体（例如，功能、输入/输出流、系统元素、物理接口、架构特征、信息/数据元素、容器、节点、链接、通信资源等），以解决不同类型的系统需求（例如、功能要求、接口要求、环境要求、运行条件[可靠性、人为因素等]、约束[物理尺寸、生产、维护、处置]）。
• 将架构实体与与利益系统架构的决策相关的概念、属性、特征、行为、功能和/或约束相关联。 这产生了架构特性（例如，通用性、模块化、可操作性、效率、简单性）。
• 选择、调整或开发系统候选架构的模型，例如逻辑和物理模型（请参阅 逻辑架构模型开发和 物理架构模型开发）。 有时使用逻辑模型和物理模型既没有必要也不够。 要使用的模型是最能解决关键利益相关者关注的模型。
• 从候选架构的模型中，组成与利益相关者关注点和关键或重要要求相关的视图。
• 定义由架构实体的必要实例（例如，功能、接口）和结构配置（例如，约束、操作条件）引起的派生系统需求。 使用系统需求定义过程来定义和形式化它们。
• 检查模型和视图的一致性并解决任何已识别的问题。 ISO/IEC/IEEE 42010, 2011 可用于此。
• 如果建模技术和工具允许，通过执行或仿真来验证和验证模型。 在可能的情况下，使用设计工具检查可行性和有效性，和/或实施部分模型，或使用可执行架构原型或模拟器。

4. 将系统架构与系统设计联系起来

• 定义反映架构特征的系统元素（当架构旨在与设计无关时，这些系统元素在设计发展之前可能是概念性的）。 为此，对系统元素进行分区、对齐和分配体系结构特征和系统要求。 建立系统设计和演进的指导原则。 有时，使用这些概念系统元素创建“参考架构”作为传达架构意图和检查设计可行性的手段。
• 为架构的详细程度和理解所必需的接口定义接口。 这包括系统元素之间的内部接口和与其他系统的外部接口。
• 确定适用于系统元素的设计属性 以满足架构特性。
• 对于构成系统的每个系统元素，开发与设计属性和系统要求对系统元素的分配、对齐和划分相对应的要求。 为此，请使用相关利益者需求和需求定义流程以及系统需求定义流程。

5. 评估架构候选并选择一个

• 使用架构评估标准评估候选架构。 这是通过应用系统分析、测量和 风险管理 流程来完成的。
• 选择首选架构。 这是通过应用决策管理 过程来完成的。

6. 管理选定的架构

• 建立并维护架构、架构框架、观点、模型类型和架构模型的备选方案和决策之间的所有选择的基本原理。
• 管理架构描述的维护和演变，包括模型和视图。 这包括一致性、完整性、环境或上下文变化引起的变化，以及技术、实施和操作经验。 分配和可追溯性矩阵用于分析对架构的影响。 本过程在系统演进发生的任何时候执行。
• 建立架构治理的方法。 治理包括角色、职责、权限和其他控制功能。
• 协调对架构的审查以达成利益相关者的一致意见。 利益相关者需求和系统需求可以作为参考。

工件、方法和建模技术

这个过程可能会创建几个工件，例如系统架构描述文档和系统论证文档（可追溯性矩阵和架构选择）。

这些工件的内容、格式、布局和所有权可能会因创建它们的人和使用它们的域而异。 过程活动的输出应涵盖本文第一部分中确定的信息。

实际考虑

缺陷

表 3 提供了在规划和执行系统架构时遇到的一些关键缺陷。

表 3. 系统架构定义的缺陷。 （SEBoK 原创）

成熟的实践

表 4 提供了从参考文献中收集到的一些经过验证的实践。

表 4. 系统架构定义的成熟实践。 （SEBoK 原创）

逻辑架构模型开发

逻辑体系结构模型开发可以用作活动“开发候选体系结构模型和视图”的任务，或者是系统体系结构定义过程(参见系统体系结构)的子过程。它的目的是细化未来工程系统的功能和行为的模型和视图，因为它应该在服务中运行。一个工程系统(SoI)的逻辑架构模型由一组相关的技术概念和原则组成，这些概念和原则支持系统的逻辑操作。它可能包括功能体系结构视图、行为体系结构视图和时间体系结构视图。在体系结构框架中还建议其他视图，具体取决于领域。

注意:术语逻辑架构是表达系统架构的逻辑视图的缩写。

概念和原则

功能体系结构模型

功能架构模型是一 组功能及其子功能，它们定义了系统为完成其任务而执行的转换。

功能和输入-输出流 ——在系统架构的上下文中，功能和输入-输出流是架构实体。函数是一种 转换输入并生成输出的动作，涉及数据、材料和/或能量。 这些输入和输出是函数之间交换的流项。 函数的一般数学符号是 y = ƒ( x ,t) ，其中 y 和 x 是可以用图形表示的向量，t = 时间。

为了定义系统的完整功能集，必须识别系统所需的所有功能及其派生需求，以及这些功能的相应输入和输出。 一般来说，有两种功能：

1. 直接从功能和接口需求推导出来的功能。 这些功能表达了系统满足其系统要求所必需的预期服务。
2. 从物理架构 模型的替代解决方案派生和发布的功能， 并且取决于设计的结果； 此外，他们依靠技术选择来实现逻辑架构模型元素。

功能层次结构/功能分解 - 在层次结构的最高级别（图 1），可以将系统表示为一个独特的中心功能（定义为系统的任务），在许多方面类似于“黑匣子” ”（图 1 中的 A-0 计划中的“F0”）。 为了详细了解系统的功能，将此“层级负责人”（F0）分解为子功能（F1、F2、F3、F4），分组形成层级的子级别（计划 A0）等等。 功能层次结构的最后一级的功能可以称为叶功能（计划 A2 中的 F21、F22、F23、F24）。 层次结构（或分解）将一个复杂的或全局的功能分解为一组功能，这些功能的物理解决方案是已知的、可行的或可以想象的。

这种功能层次视图代表了功能的静态视图，根据所使用的综合方法 ，这些功能将在多次迭代中以不同级别填充。 通常，它不是由单个自上而下的分解创建的。 静态功能层次结构本身并不代表输入和输出流的交换效率，可能需要与下面的其他模型一起查看。

图 1. 功能分解（Faisandie 2012）。Sinergy'Com 授予的许可。所有其他权利均由版权所有者保留。

行为架构模型

行为架构模型是功能及其子功能以及接口（输入和输出）的排列，它定义了执行顺序、控制或数据流的条件以及满足系统要求（ISO/IEC）所必需的性能 水平 26702:2007)。 行为架构模型可以描述为一组相互关联的功能和/或操作模式场景。

控制（触发器） - 控制流是一个元素，它激活一个函数作为其执行的条件。 此元素的状态或它所代表的条件激活或停用功能（或其元素）。 控制流可以是信号或事件，例如将开关移至 打开 位置、警报、触发器、温度变化或按下键盘上的键。

场景（函数） - 函数场景是一系列函数，它们作为序列执行并由一组控制流同步，以实现输入到输出的全局转换，如下图所示。 函数场景表达了上层函数的动态。 通过考虑功能层次结构的每个级别和系统层次结构的每个级别的两种情况来开发行为架构。 在表示功能和行为架构模型的场景时，使用图表作为建模技术是合适的，例如功能流程图 (FFBD) (Oliver, Kelliher, and Keegan 1997) 或使用 SysML (OMG 2010) 开发的活动图。 图 2 和图 3 提供了这些图表的示例。

图 2. 场景说明 (eFFBD)。（SEBoK 原创）

图 3. 场景图解（活动图）。 （SEBoK 原创）

操作模式 - 可以通过抽象将输入转换为每个功能的输出并关注功能及其控件的活动或非活动状态来查看功能场景。 此视图称为 模式场景 ，它是一系列模式，作为系统各种模式之间的一系列转换执行。 从一种模式到另一种模式的转换是由控制流（事件/触发器）的到达触发的。 如下图 4 所示，可以在事件或触发器到达后在两种模式之间的转换中生成动作（功能）。

图 4. 运营模式情景（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

行为模式 ——在定义场景或行为架构模型时，架构师可以选择识别和使用已知模型来表示预期的转换和行为。 模式是通用的基本模型，根据处理的复杂性可能或多或少复杂（Gamma、Helm、Johnson 和 Vlissides 1995）。 一个模式 可以用不同的符号表示。 行为模式分为几类，可以在以下示例中看到（另见 SEBoK 第 2 部分：系统思维模式）：

• 基本模式或构造链接功能 - 例如序列、迭代、选择、并发、多个出口、带出口的循环和复制。
• 复杂的模式——例如监控治疗、交换消息、人机界面、模式监控、流程的实时监控、队列管理和带监督的持续监控。
• 故障检测、识别和恢复 (FDIR) 模式 - 例如被动冗余、主动冗余、半主动冗余和性能降低的处理。

时间架构模型

时序架构 模型是根据 执行频率级别推导出的系统功能分类。 时间架构模型包括功能的同步和异步方面的定义。 系统内部发生的决策监视遵循相同的时间分类，因为决策与功能的监视有关。

时间和决策层次概念 - 并非系统的每个功能都以相同的频率执行。 频率根据时间和功能启动和执行的方式而变化。 因此，必须考虑几类性能。 有循环执行的同步函数和在事件或触发器发生后执行的异步函数。

更具体地说， 实时 系统和 命令控制 系统结合了循环操作（同步）和事实方面（异步）。 循环操作包括根据频率共享功能的执行，这取决于捕获或分派输入/输出和控制流的约束。 可以区分两种类型的异步事件：

1. 高频干扰（图 5 底部）- 在它们发生的级别或上一级做出的决定。 目标是阻止干扰影响低频，以便系统继续实现其任务目标。 这是引入异常操作的方式，典型的例子与操作问题、故障或失败有关。
2. 低频变化（图 5 顶部）——与上层做出的变化有关的决定。 最终目标是将它们传送到底层以实施修改。 一个典型的例子涉及操作员的操作、维护操作等。

图 5. 时间和决策层级（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

过程方法

目的

逻辑架构模型开发的目的是定义、选择和综合系统的逻辑架构模型，以提供一个框架来验证未来系统在所有操作场景中是否满足其系统要求，其中系统之间的权衡在开发此类系统时可以探索需求。

流程的通用输入包括系统需求、架构师识别和用于回答需求的通用架构模式、系统分析流程的结果以及系统 验证 和 确认流程的反馈 。 根据所选择的生命周期模型，将有这些输入和输出以及它们之间的关系在整个过程中演变和变化的迭代（另请参见应用生命周期过程）。

流程的一般输出是单个逻​​辑架构模型或一组候选逻辑架构模型以及所选的独立逻辑架构模型及其选择的基本原理。 它们至少包括视图和模型。 这些涉及功能、行为和时间视图，逻辑架构模型元素和系统需求之间的可追溯性矩阵。

进程的活动

在此过程中执行的主要活动和任务包括：

• 识别和分析功能和行为要素：
  • 通过分析功能、接口和操作需求，从系统需求中 识别功能、输入-输出流、操作模式、模式转换和操作场景。
  • 为每个功能和输出定义必要的输入和控制（能量、材料和数据流），从而扣除必要的功能以使用、转换、移动和生成输入-输出流。
• 将系统要求分配给功能和行为元素：
  • 通过分配性能、有效性和约束要求，正式表征函数表达式及其属性。 特别是，研究需求的时间方面，以将持续时间、响应时间和频率分配给功能。
  • 通过分配接口、有效性、操作、时间和约束要求，正式表征输入、输出和控制流表达式及其属性。
  • 在系统需求与这些功能和行为元素之间建立可追溯性。
• 为每个候选定义候选逻辑架构模型：
  • 分析系统要求（如果有）中所述的操作模式和/或使用先前定义的元素来模拟操作模式的序列和模式的转换。 最终将模式分解为子模式，然后为每个操作模式建立一个或几个功能识别和/或使用相关通用行为模式的场景。
  • 整合这些功能场景以获得系统的行为架构模型（动态行为的完整图景）。
  • 根据需要分解先前定义的逻辑元素以实现实现。
  • 将时间约束分配和合并到先前定义的逻辑元素，例如时间段、持续时间、频率、响应时间、超时、停止条件等。
  • 为与决策级别对应的功能定义多个级别的执行频率，以便监控系统操作，在此时间基础上优先处理处理，并在这些执行频率级别之间共享功能以获得时间架构模型。
  • 执行功能故障模式和影响分析，并根据需要更新逻辑架构元素。
  • 使用模拟器执行模型（如果可能）并调整这些模型以获得预期的特性。
• 综合选定的独立逻辑架构模型：
  • 通过根据评估标准（与系统需求相关）评估候选逻辑架构模型并比较它们来选择逻辑架构，使用系统分析过程执行评估和决策管理过程以进行选择（请参阅系统分析和决策管理主题）。 这种选择的逻辑架构模型被称为 独立的逻辑架构模型 ，因为它尽可能地独立于实现决策。
  • 识别和定义为设计的必要性创建的派生逻辑架构模型元素，并与派生的系统需求相对应。 将这些要求分配给适当的系统（当前研究的系统或外部系统）。
  • 验证和验证选定的逻辑架构模型（尽可能使用可执行模型），根据需要进行更正，并在系统需求和逻辑架构模型元素之间建立可追溯性。
• 反馈逻辑架构模型开发和系统需求。 此活动在物理架构模型开发过程之后执行：
  • 如果可以将分配的逻辑架构 建模 到系统和系统元素，并根据需要添加任何功能、行为和时间元素以同步功能和处理。
  • 定义或整合由所选逻辑和物理架构模型引入的派生逻辑和物理元素。 定义相应的派生需求并将它们分配给适当的逻辑和物理架构元素。 将这些派生的需求合并到受影响系统的需求基线中。

工件、方法和建模技术

逻辑架构描述使用归类于以下模型类型的建模技术。 已经开发了几种方法来支持这些类型的模型（一些是可执行模型）：

• 功能模型——包括结构化分析设计技术 (SADT/IDEF0)、系统分析和实时 (SA-RT)、增强功能流程图 (eFFBD) 和功能分析系统技术 (FAST) 等模型。
• 语义模型——包括实体关系图、类图和数据流图等模型。
• 动态模型——这些模型包括状态转换图、状态图、eFFBD、状态机图 (SysML)、活动图 (SysML) (OMG 2010) 和 petri 网。

根据领域的类型（例如国防、企业），架构框架提供的描述可以帮助表示架构的其他方面/视图 - 请参阅企业系统工程关键概念中的“企业架构框架和方法”部分。 另请参阅使用与 ISO/IEC/IEEE 42010 (ISO 2011) 相关的通用模板的实用方法。

实际考虑

如上所述，逻辑架构模型的目的是描述系统必须能够做什么才能满足规定的需求。 这应该有助于确保所有利益相关者的需求和/或关注点都能通过任何解决方案得到解决，并且可以考虑创新解决方案以及基于当前解决方案技术的解决方案。 在实践中，问题利益相关者推动他们自己的议程以及解决方案架构师或设计师提供他们熟悉的解决方案是人类的天性。 如果逻辑架构模型没有在选定的生命周期中正确实施，问题和解决方案的利益相关者很容易忽略它并恢复他们自己的偏见（请参阅第 5 部分：启用系统工程）。 如果逻辑架构模型本身成为终结或与主要生命周期活动脱节，则这种情况会更加严重。 这可以通过使用抽象语言或符号、详细程度、所花费的时间或与创建它的目的不匹配的过于复杂的最终架构来实现。 如果架构的语言、范围和及时性与问题利益相关者或解决方案提供者不匹配，他们就更容易忽视它。 接下来的两节将描述有助于避免与逻辑架构模型相关的问题的关键缺陷和良好实践。

缺陷

表 1 提供了开发逻辑架构时遇到的一些关键缺陷。

表 1. 逻辑架构开发的缺陷。 （SEBoK 原创）

实践证明

表 2 提供了从参考文献中收集到的一些经过验证的实践。

表 2. 经验证的逻辑架构开发实践。 （SEBoK 原创）

物理架构模型开发

物理架构模型开发可用作“开发候选架构模型和视图”活动的任务，或系统架构定义流程的子流程（请参阅 系统架构文章）。 其目的是详细说明物理的、具体的解决方案的模型和视图，以适应 逻辑架构模型并满足和权衡系统要求。 一旦定义了逻辑架构模型（请参阅逻辑架构模型开发)，必须确定具体的物理元素，这些元素可以支持功能、行为和时间特征以及从非功能系统需求推导出的系统的预期属性（例如，限制更换过时产品，和/或持续的产品支持） .

物理架构模型是为产品 、 服务 或 企业 提供解决方案 的物理元素（ 系统元素和 物理接口）的排列 。 它旨在满足逻辑架构元素和系统要求 ISO/IEC/IEEE 26702 (ISO 2007)。 它可以通过技术系统元素来实现。 系统需求被分配给逻辑和物理架构。 最终的系统架构通过系统分析进行评估，完成后成为系统实现的基础。

在某些情况下，特别是当将多个系统定义为一个公共物理架构模型时，物理架构模型的驱动因素之一可能是接口标准； 这些物理接口很可能是这些系统最重要的问题之一。 这种接口标准很可能在系统要求的高层次上被强制要求。 另一方面，在物理架构模型开发过程中也有可能衍生出标准，这些标准可能是实现理想工程成果的关键推动因素，例如：系统系列、技术插入、互操作性和“开放系统”。 例如，今天的视频、高保真和计算机系统都受益于接口标准的采用。 其他例子存在于大多数工程领域，从螺母和螺栓，

注意：术语 物理架构 是 系统架构物理视图的缩写 。

概念和原则

系统元素、物理接口和物理架构模型

系统元素是系统的离散部分，可以实施以实现设计属性。 系统元素可以是硬件、软件、数据、人、过程（例如，向用户提供服务的过程）、程序（例如，操作员指令）、设施、材料和天然存在的实体（例如，水、有机体和矿物），或这些 ISO/IEC/IEEE 15288 (ISO 2015) 的任意组合。 物理接口 将 两个系统元素绑定在一起； 这类似于链接或连接器。 表 1 提供了一些系统元素和物理接口的示例。

表 1. 系统元素和物理接口的类型。 （SEBoK 原创）

由数以千计的物理和/或无形部分组成的复杂系统可以由多个系统层 和系统 元素构成。 一个系统的结构层次中的元素数量限制在少数，以便于管理系统定义； 一个共同的准则是 五个加或减两个 元素（参见图 1 中的插图）。

图 1. 系统层和系统元素（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

物理架构模型由系统、系统元素和这些元素之间的所有必要物理接口以及外部元素（所考虑层中的相邻或启用系统和/或系统元素以及全局上下文中的相关元素）构建而成。感兴趣的系统） - 参见图 2 中的插图。

图 2. 物理架构模型表示（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

设计属性

设计属性 是在系统架构期间获得的属性，并通过分配非功能性需求、估计、分析、计算、特定方面的模拟或通过定义与系统元素相关联的现有元素 创建 物理接口和/或物理架构。 如果定义的元素符合要求，则设计属性将与（或可能等于）要求相关。 否则，必须识别可能修改需求或设计属性的任何差异并检测任何偏差。

利益相关者的关注点与系统在操作、环境和/或物理约束以及更一般的生命周期约束中的预期行为相对应。利益相关者要求和系统要求 将这些关注点表达为系统的预期能力（例如，可用性、互操作性、安全性、可扩展性、环境适用性等）。 建筑师和/或设计师从需求中识别这些能力，并推断出相应的定量或定性设计属性，以适当地装备他们的物理架构模型（例如，可靠性、可用性、可维护性、模块化、稳健性、可操作性、气候环境耐受性、尺寸限制等） . 有关如何将其中一些属性包含在架构和设计中的进一步讨论，请参阅 相关学科 部分 中的 系统工程和质量属性一文。

逻辑元素到物理元素的分配和分区

为系统开发候选物理架构模型包括首先识别可以执行逻辑架构模型功能的系统元素，以及识别能够执行输入-输出流和控制流的接口。 在识别潜在元素时，系统工程师需要在逻辑架构中分配设计属性； 这些属性是从系统要求 推导出来的。 分区和分配是分解、收集或分离功能的活动，以便于识别支持这些功能的可行系统元素。 它们要么存在并且可以重用或重新利用，要么可以被开发并在技术上实现。

分区和分配使用标准来查找功能之间的潜在关联。 系、能源和材料）、集中式或分布式控制、接近频率水平的执行、可靠性条件、环境阻力水平和其他企业约束。

当需要几组不同的技术、知识和技能来建立候选物理架构模型时，需要采用并行工程方法。 在对各种系统元素进行功能划分和分配期间尤其如此，其中系统工程师必须考虑兼容性问题和 紧急属性。 （有关可能的方法的讨论， 请参见 SEBoK 第 2 部分：综合可能的解决方案。）

开发候选物理架构模型

物理架构模型开发活动的目标是提供由合适的系统、技术系统元素和物理接口组成的最佳物理架构模型（即，根据商定的限制或余量，最多可以满足所有系统要求的架构）每个要求）。 最好的方法是产生几个候选的物理架构模型，对它们进行评估和比较，然后选择最合适的一个。

候选物理体系结构模型根据亲和性标准进行详细说明，以构建一组系统元素（即，分离、聚集、连接和断开系统元素的网络及其物理接口）。 这些标准与用于对系统元素进行分区和分配功能的标准相同。 物理架构模型开发可能以不同的方式关注，例如，它可能解决：

• 减少物理接口的数量
• 可单独测试的系统元素
• 兼容技术
• 空间元素接近度的度量
• 易于处理（重量、体积和运输设施）
• 优化元素之间共享的资源
• 模块化（即元素的相互依赖性低）
• 弹性（即高度可靠、可维护或可替换的元素）

评估和选择首选候选人

可行的物理架构模型能够实现逻辑架构模型中指定的所有必需功能或能力。 架构和设计活动包括评估以获得设计属性、成本、风险等之间的平衡。通常，系统的物理架构模型更强烈地由非功能性需求（例如，性能、安全性、安全性、环境条件、约束等）而不是按功能。 可能有许多（物理）方法来建立功能，但满足非功能性需求的方法较少。 首选物理架构模型代表系统元素、它们的物理关系和接口的选择。 通常， 在做出任何剩余的权衡并最终确定系统的算法和参数之后，这种物理架构仍将进行进一步的系统工程以实现完全优化的系统。 需要进行某些分析（效率、可靠性、成本、风险等）以获得足够的数据来表征候选架构在系统要求方面的全局行为和结构； 这通常被广泛称为系统分析。 其他分析和评估需要来自不同相关技术和专业（机械、电子、软件、热力学、电磁兼容性、安全性、安保等）的知识和技能。 它们是通过系统的相应专家分析来执行的。

遗留系统和系统系统

很少有系统在不与系统上下文 中的其他系统交互的情况下存在或运行 。 这些交互可能与其他运营系统或维护和支持系统有关，而这些系统又可能是遗留系统（已经在使用）或未来遗留系统（正在开发中并且可能与未来感兴趣的系统一起运行）。

最佳选择的方法将取决于 感兴趣系统(SoI) 与其更广泛的上下文之间的交互强度。 虽然这些交互很小，但可以通过定义一组系统必须遵守的静态外部接口要求（例如技术标准）来解释它们，方法是将这些作为约束条件包含在系统要求中，并通过设计保证确保合规性。

在交互更密集的情况下（例如，在与其他系统交换连续信息的情况下），这些将必须被视为 系统上下文系统的一部分，而将被视为企业系统工程 方法的一部分。

另一个重要的考虑因素可能是在 SoI 和其他系统之间共享技术或系统元素，通常作为系统系列的一部分（许多示例发生在汽车和航空航天工业中）或重用现有遗留系统元素。 这里需要一定程度的自上而下或中间出设计工作，以确保感兴趣的系统体现所需的系统元素，同时尽可能符合利益相关者和系统要求，任何妥协都被理解和管理。

如果感兴趣的系统旨在用于一个或多个服务系统或 系统配置系统，这将影响其物理架构模型。 这些 SoS 的特性之一是使用中的组件系统的后期绑定。 此类组件系统必须使用开放或可配置的接口进行架构，必须具有明确定义的功能，并以与使用它们的 SoS 相关的方式打包，并且必须包含一些方法，以便在需要时识别并包含在 SoS 中.

服务系统和 SoS 都将由高级物理架构模型定义，该模型将用于定义应包含在概念定义 中的相关 SoS 关系、接口和约束。 结果将嵌入利益相关者和系统需求中，并在开发、实现和使用过程中通过接口协议和跨项目通信进行处理。

有关构建 SoS 的特殊注意事项的更多信息， 请参阅 SEBoK 第 4 部分：系统工程的应用。

过程方法

目的

物理架构模型开发的目的是定义、选择和综合一个能够支持逻辑架构模型的系统物理架构模型。 物理架构模型将具有解决利益相关者关注或环境问题并满足系统要求的特定属性。

由于使用环境或技术可能性的演进，由系统元素组成的物理架构 应该沿着系统的生命周期演进，以便在其所需的有效性范围内继续执行其任务. 根据演化是否影响逻辑架构 模型元素，对系统元素的分配可能会改变。 物理架构模型配备了特定的设计属性，以不断挑战进化。

通用输入 包括选定的逻辑架构模型、系统需求、架构师识别和利用以回答需求的通用模式和属性、系统分析的结果以及系统验证和系统确认的反馈。

通用输出 是选定的物理架构模型、功能元素到物理元素的分配矩阵、具有系统需求的可追溯性矩阵、构成物理架构模型的每个系统和系统元素的利益相关者需求以及被拒绝的解决方案。

进程的活动

在此过程中要执行的主要活动和任务包括：

• 将功能元素划分并分配给系统元素：
  • 寻找能够执行功能和物理接口以承载输入输出和控制流的系统元素或技术。 确保系统元素存在或可以设计。 使用从设计属性推导出来的标准（它们本身从非功能性系统需求推导出来）评估每个潜在的系统元素。
  • 使用给定的标准对功能元素（功能、场景、输入输出、触发器等）进行分区，并将分区集分配给系统元素（使用相同的标准）。
  • 当无法识别对应于分区功能集的系统元素时，分解功能直到可以识别可实现的系统元素。
  • 检查技术的兼容性以及所选系统元素之间接口的兼容性。
• 构成候选物理架构模型。
  • 因为分区的功能集可能很多，所以通常有太多的系统元素。 为了定义可控架构，必须将系统元素分组为称为系统元素组的更高级别的系统元素，在工业中通常称为子系统。
  • 构成若干不同的系统元素群，对应于基本系统元素的不同组合。 一组系统元素组加上一个或几个不可分解的系统元素形成了所考虑系统的候选物理架构模型。
  • 表示（使用模式）每个系统元素组的物理架构模型，将其系统元素与承载输入输出流和触发器的物理接口连接起来。 根据需要添加物理接口； 特别是，将带有外部元素的接口添加到系统元素组中。
  • 表示从系统元素组、不可分解系统和继承自系统元素组的物理架构模型的物理接口构建的所考虑系统的综合物理架构。
  • 增强物理架构模型的设计属性，如模块化、进化能力、对不同环境的适应性、鲁棒性、可扩展性、对环境条件的抵抗力等。
  • 如果可能，使用可执行架构原型（例如，硬件-软件 (HW-SW)-in-the-loop 原型）来识别潜在缺陷并根据需要更正架构。
• 评估物理架构模型候选并选择最合适的模型：
  • 使用系统分析过程执行评估（请参阅系统分析主题）。
  • 使用决策管理流程来支持交易和首选备选方案的选择（请参阅决策管理主题）。
• 综合选定的物理架构模型：
  • 形式化物理元素和属性。 验证是否满足系统要求以及解决方案是否切合实际。
  • 识别为架构和设计的必要性以及相应的系统要求而创建的派生物理和功能元素。
  • 在系统需求和物理元素之间建立可追溯性，并在功能元素和物理元素之间分配矩阵。

工件、方法和建模技术

物理架构描述使用建模技术来创建和表示物理架构。 一些常见的物理模型包括结构块、体量、布局和其他模型。 建模技术可能是：

• 物理框图 (PBD)
• SysML 块定义图 (BDD)
• 内部框图 (IBD) (OMG 2010)
• 可执行架构原型
• 等等。

根据要使用的领域类型（国防、企业等）， 架构框架可以提供有助于权衡候选架构的描述。 请参阅企业系统工程关键概念中的“企业架构框架和方法”部分。

实际考虑

接下来的两节将描述与物理架构开发相关的关键缺陷和良好实践。

缺陷

表 3 提供了在执行物理架构模型开发过程中遇到的一些关键缺陷。

表 3. 物理架构开发的缺陷。 （SEBoK 原创）

===经过验证的实践===+

表 4 提供了从参考文献中收集到的一些经过验证的实践。

表 4. 物理架构开发的成熟实践。 （SEBoK 原创）

系统设计

系统设计的目的是通过提供对系统元素的实现有用和必要的信息和数据来补充系统架构。 设计定义是通过以适合实现的形式描述的一整套设计特征，对系统架构的实现进行开发、表达、记录和交流的过程。

概念和原则

设计理念

在工业实践中， 设计 一词通常用于表示架构和 设计 。 最近，专业人士在处理更简单的技术产品时使用了“ 设计 ”一词——这些产品不包括硬件、软件、运营商、服务等多种不同且相互关联的技术组件。在开发新的多技术产品时和服务，专业人士已经认识到 系统 概念在处理 复杂性 （互连级别、多技术、涌现等）方面的有用性。

正是由于复杂性，对构成系统的元素进行结构化变得有必要。 此结构解释了系统架构 中描述的系统的功能、行为、时间、物理和其他方面 。 从业者发现术语 结构 不足以描述系统的所有这些方面。 术语 架构 和 架构设计 已经使用了大约 30 年，尤其是在软件密集型系统和其他领域，例如航天工业。 不同类型和相互关联的结构的集合可以理解为系统的架构。

今天的趋势是将系统架构和系统设计视为不同且独立的活动集，但同时存在且紧密交织。

系统设计包括使用原则和概念构思一组系统元素的活动，这些元素可以满足特定的预期目的； 它包括评估和决策，以选择构成系统、适合系统架构并符合权衡的系统要求的系统元素。 它是以适合实施的形式描述的完整的详细模型、属性和/或特征集。

设计特征和设计促成因素

每个技术领域或学科都拥有其独特的法律、规则、理论和促成因素，涉及其构成材料、能量或信息的部分的转换、结构、行为和时间特性。 这些特定的部分和/或它们的组成是用典型的设计特征和促成因素来描述的。 这些允许通过在系统架构定义过程中分配的设计特征（例如，可操作性级别、可靠性率、速度、安全级别）所需的各种转换和交换来实现每个系统元素。

设计定义提供了对实现所需的设计特征和设计使能的描述。 设计特征包括尺寸、形状、材料和数据处理结构。 设计促成因素包括形式表达式或方程式、绘图、图表、指标表及其值和边距、模式、算法和启发式。

• 固体力学中的通用设计特征示例：形状、几何图案、尺寸、体积、曲面、曲线、抗力、力分布、重量、运动速度、时间持久性
• 软件中通用设计特征的示例：处理分布、数据结构、数据持久性、过程抽象、数据抽象、控制抽象、封装、创建模式（例如，构建器、工厂、原型、单例）和结构模式（例如，适配器, 桥, 复合, 装饰器, 代理)

与系统架构的关系

系统设计旨在成为系统架构（无论何时在系统工程过程的特定应用中定义此里程碑）与构成系统物理架构模型的技术系统元素的实现之间的链接。

设计定义由指定的需求、系统架构以及更详细的性能和可行性分析驱动。 它解决了实施技术及其同化问题。 设计提供了定义的“如何”或“实施”级别。

设计涉及由实施技术组成的每个系统元素，例如需要特定工程流程的机械、电子、软件、化学、人类操作和服务。 系统设计向父系统架构提供反馈，以合并或确认架构特征和设计属性对系统元素的分配和划分。

设计描述符

设计描述符是一组通用设计特征及其可能值。 如果存在相似但不精确的系统元素，则可以分析这些元素以确定它们的基本特征。 每个特征的可能值的变化决定了潜在的候选系统元素。

整体设计

整体设计是一种将被设计的系统视为一个相互关联的整体的方法，这也是更大事物的一部分。 整体概念可以与系统在其上下文中（例如，系统参与的企业或任务）以及机械设备的设计、空间布局等一起应用于整个系统。 这种方法通常包含对环境的关注，考虑设计将如何影响环境并试图减少对环境的影响。 整体设计不仅仅是试图满足系统要求。

过程方法

目的

系统设计过程的目的是提供有关系统及其系统元素的足够详细的数据和信息，以使实施与系统架构模型和视图中定义的架构实体一致（ISO/IEC/IEEE 15288 [ISO 2015 ]）。

通用输入包括父系统的体系结构描述和系统元素要求。

通用输出是对实现所必需的设计特征和设计促成因素的描述。

进程的活动

在此过程中要执行的主要活动和任务包括：

1.初始化设计定义

• 规划整个系统的技术管理。 确定构成和实施系统元素及其物理接口的技术（机械、电力、电子、软件、生物学、操作员等）。
• 确定哪些技术和系统元素在系统运行阶段有过时或演变的风险。 计划他们的潜在替代者。
• 确定每个系统元素的每种技术的设计特征或属性的类型。
• 定期评估设计特征并随着系统的发展进行调整。
• 记录设计定义策略，包括执行设计的任何支持系统、产品或服务的需要和要求。

2. 建立与每个系统元素相关的设计特征和设计促成因素

• 对系统架构过程中未完全解决的所有需求和系统元素执行、合并或详细分配系统需求（通常，每个系统需求都将在系统架构过程中转换为架构实体和架构特征，然后通过直接分配或某些分区分配给系统元素）。
• 定义与架构特性相关的设计特性并检查它们是否可实现。 使用设计促成因素，例如模型（物理和分析）、设计启发法等。如果设计特征不可行，则评估其他设计替代方案或实现选项，或执行其他系统元素定义的交易。
• 定义系统架构流程未定义的接口或随着设计细节的发展需要改进的接口。 这包括系统元素之间的内部接口和与其他系统的外部接口。
• 记录适用工件中每个系统元素的设计特征（它们取决于所使用的设计方法和技术）。
• 提供有关选择主要实施选项和促成因素的理由。

3. 评估获取系统元素的备选方案

• 识别现有实施的系统元素（COTS/NDI、重用或其他未开发的系统元素）。 可以研究要开发的新系统元素的替代方案。
• 使用源自设计特征的选择标准评估系统元素的设计选项。
• 选择最合适的替代品。
• 如果决定开发系统元素，则使用其余的设计定义过程和实施过程。 如果决定是购买或重复使用系统元素，则可以使用获取过程来获取系统元素。

4. 管理设计

• 捕获并维护在设计、架构特征、设计促成因素和系统元素来源的备选方案和决策中的所有选择的基本原理。
• 评估和控制设计特征的演变，包括与架构的一致性。
• 建立和维护设计特征和架构特征之间的可追溯性，以及必要时的需求。
• 为配置管理提供基线信息。
• 维护设计基线和设计定义策略。

实际考虑

与系统设计相关的关键缺陷和经过验证的实践将在接下来的两节中描述。

缺陷

表 1 提供了执行系统设计时遇到的一些关键缺陷。

表 1. 系统设计的缺陷。 （SEBoK 原创）

实践证明

表 2 提供了从参考文献中收集到的一些经过验证的实践。

表 2. 经过验证的系统设计实践。 （SEBoK 原创）

系统分析

系统分析允许开发人员客观地对系统进行定量评估，以选择和/或更新最有效的系统架构，并生成衍生工程数据。 在工程设计期间，每次做出技术选择或决定以确定是否符合系统要求时，都应进行评估。

系统分析为技术决策提供了一种严格的方法。 它用于进行权衡研究，包括建模与仿真、成本分析、技术风险分析和有效性分析。

管理系统分析的原则

系统工程师的主要任务之一是评估在系统工程(SE) 过程中创建的工程数据和工件。 评估是系统分析的中心，提供手段和技术：

• 根据系统要求 定义评估标准；
• 与这些标准相比， 评估每个候选解决方案的设计特性；
• 在全球范围内对候选解决方案进行评分并证明分数的合理性；
• 决定适当的解决方案。

第 2 部分的 应用于工程系统知识领域 (KA)的系统方法中的替代解决方案之间 的分析和选择文章 描述了与在已识别问题或机会的可能系统解决方案之间进行选择相关的活动。 定义了以下系统分析的 一般原则：

• 系统分析基于基于问题或机会系统描述的评估标准。
  • 这些标准将基于理想的系统描述，假设 可以定义硬系统问题上下文。
  • 在所有可能的更广泛的系统上下文和环境中，标准必须考虑完整解决方案所需的系统行为和属性。
  • 这些必须考虑非功能性问题，例如系统安全性、安全性等。（ 有关合并非功能性元素的更多讨论，请参阅系统工程和专业工程。）
  • 这种“理想的”系统描述可以得到软系统描述的支持，从这些描述中可以定义额外的“软”标准。 例如，利益相关者对某些解决方案的偏好或反对，相关的社会、政治或文化习俗等。
• 评估标准应至少包括利益相关者可接受的成本和时间范围的限制。
• 贸易研究提供了一种对替代解决方案进行分析的机制。
  • 贸易研究应考虑一套评估标准，并适当了解各个标准之间的局限性和依赖性。
  • 贸易研究需要处理客观和主观标准。 必须小心评估整体评估对特定标准的敏感性。

权衡研究

在系统定义的上下文中，权衡研究包括比较每个系统元素和每个候选系统架构的特征，以确定最能平衡评估标准的解决方案。 在成本分析、技术风险分析和有效性分析中收集了分析的各种特征（NASA 2007）。

对所有类型的系统环境进行贸易研究的指导都体现在上述原则中，并在替代解决方案之间的分析和选择主题中进行了更详细的描述。 SE 分析特别感兴趣的是技术有效性、成本和技术风险分析。

有效性分析

工程系统解决方案的有效性 包括以下分析列表中通常收集的几个基本特征，包括（但不限于）：性能、可用​​性、可靠性、制造、维护或支持、环境等。这些分析突出了候选各个方面的解决方案。

必须建立一个分类，将分析次数限制在真正重要的方面，例如关键性能参数。 有效性分析的主要难点是对有效性方面进行排序和选择； 例如，如果产品是为一次性使用而制造的，那么可维护性将不是相关标准。

成本分析

成本分析 考虑了整个生命周期的成本。 可以根据项目和系统调整成本基准。 全球生命周期成本 (LCC) 或 总拥有成本(TOC) 可能包括示例性劳动力和非劳动力成本项目，例如表 1 中所示的项目。

表 1. 成本类型。 （SEBoK 原创）

计划主题 中描述了确定成本的方法。

技术风险分析

每个领域的风险 分析都基于三个因素：

1. 分析潜在威胁或不良事件及其发生概率。
2. 分析这些威胁或不良事件的后果及其按严重程度分类。
3. 将威胁的概率和/或有害影响的水平降低到可接受值的缓解措施。

当系统不再满足系统要求时，技术风险就出现了。 原因在于需求和/或解决方案本身。 它们以效率不足的形式表现出来，并且可能有多种原因：对技术能力的错误评估； 高估系统元素的技术成熟度； 零件故障； 故障； 设备、零件或软件的损坏、过时、供应商的弱点（不合规的零件、延迟供应等）、人为因素（培训不足、错误的调整、错误处理、不合适的程序、恶意）等。

技术风险不应与项目风险混淆，即使管理它们的方法相同。 尽管技术风险可能导致项目风险，但技术风险针对的是系统本身，而不是其开发过程。 （有关 详细信息， 请参阅风险管理。）

过程方法

该方法的目的和原则

系统分析过程用于： (1) 为技术决策、需求冲突的解决和替代物理解决方案（系统元素和物理架构）的评估提供严格的基础；(2) 确定满足系统要求和派生要求的进度 ； (3) 支持风险管理； (4) 确保仅在评估成本、进度、性能和风险对系统工程或再工程的影响后做出决策（ANSI/EIA 1998）。 该过程也被 NASA (2007, 1-360) 称为决策分析过程，用于帮助评估技术问题、备选方案及其不确定性，以支持决策制定。 （见 决策管理 更多细节。）

系统分析支持其他系统定义过程：

• 利益相关者需求定义和系统需求定义 过程使用系统分析来解决与需求集之间的冲突相关的问题； 特别是与成本、技术风险和有效性（性能、操作条件和限制）相关的那些。 讨论了高风险或需要不同架构的系统要求。
• 逻辑架构模型开发和 物理架构模型开发 过程使用它来评估候选逻辑和物理架构的特征或设计属性， 为选择在成本、技术风险和有效性（例如，性能、可靠性）方面最有效的架构提供论据、人为因素等）。

像任何系统定义过程一样，系统分析过程是迭代的。 每个操作进行多次； 每一步都提高了分析的精度。

进程的活动

在此过程中执行的主要活动和任务包括：

• 规划权衡研究：
  • 确定要分析的候选解决方案的数量、要使用的方法和程序、预期的结果（要选择的对象示例：行为架构/场景、物理架构、系统元素等）以及理由项目。
  • 根据模型、工程数据（系统要求、设计属性）、技术人员和程序的可用性安排分析。
• 定义选择标准模型：
  • 从非功能性要求（性能、操作条件、约束等）和/或设计属性中选择评估标准。
  • 对评估标准进行排序。
  • 为每个评估标准建立一个比较量表，并根据每个评估标准与其他评估标准的相对重要性来衡量每个评估标准。
• 确定候选解决方案、相关模型和数据。
• 使用先前定义的方法或程序评估候选解决方案：
  • 进行成本分析、技术风险分析和有效性分析，将每个候选解决方案置于每个评估标准比较范围内。
  • 将每个候选解决方案打分作为评估分数。
• 向调用过程提供结果：评估标准、比较量表、解决方案的分数、评估选择以及可能的建议和相关论点。

工件和本体元素

此过程可能会创建多个工件，例如：

• 选择标准模型（列表、秤、称重）
• 成本、风险和有效性分析报告
• 理由报告

这个过程在系统分析中处理表 2 的本体元素。

表 2. 系统分析中处理的主要本体元素。 （SEBoK 原创）

检查系统分析的正确性

系统分析中要检查的主要项目是：

• 模型和数据在系统使用环境中的相关性，
• 与系统使用环境相关的评估标准的相关性，
• 模拟结果和计算的再现性，
• 比较尺度的精度水平，
• 估计的置信度，以及
• 解决方案分数与评估标准权重相关的敏感性。

有关其他观点，请参见 Ring、Eisner 和 Maier (2010)。

方法和建模技术

• 模型的一般用法 ：可以在系统分析的上下文中使用各种类型的模型：
  • 物理模型 是允许模拟物理现象的比例模型。 它们特定于每个学科； 相关工具包括模型、振动台、测试台、原型、减压室、风洞等。
  • 表示模型 主要用于模拟系统的行为。 例如，增强功能流程图（eFFBD）、状态图、状态机图（基于系统建模语言（SysML））等。
  • 分析模型 主要用于建立估计值。 我们可以认为确定性模型和概率模型（也称为随机模型）本质上是分析性的。 分析模型使用方程或图表来接近系统的实际操作。 它们可以非常简单（加法）到难以置信的复杂（具有多个变量的概率分布）。
• 根据项目进度 使用正确的模型
  • 在项目开始时，最初的研究使用简单的工具，允许粗略的近似，其优点是不需要太多时间和精力。 这些近似值通常足以消除不切实际或外向的候选解决方案。
  • 在项目的开发过程中，越来越有必要提高数据的精度，以比较仍在竞争的候选解决方案。 如果创新水平高，工作就比较复杂。
  • 单独的系统工程师无法对复杂系统进行建模； 他或她必须得到来自不同学科的技术人员的支持。
• 专家专长 ：当评估标准的价值不能客观或准确地给出时，或者由于主观方面占主导地位，我们可以要求专家提供专业知识。 估计分四个步骤进行：

1. 选择受访者以收集有关领域合格人员的意见。
2. 起草问卷； 一份精确的问卷可以进行简单的分析，但过于封闭的问卷可能会导致忽略重要点。
3. 用问卷采访数量有限的专家，包括深入讨论以获得准确的意见。
4. 与几个不同的人分析数据并比较他们的印象，直到就评估标准和/或候选解决方案的分类达成一致。

表 3 总结了系统分析中常用的分析模型。

表 3. 系统分析环境中常用的分析模型。 （SEBoK 原创）

实际考虑

与系统分析相关的关键和良好实践将在接下来的两节中描述。

缺陷

表 4 提供了在规划和执行系统分析时遇到的一些关键。

表 4. 系统分析的。 （SEBoK 原创）

实践证明

表 5 提供了从参考文献中收集到的一些经过验证的实践。

表 5. 经过验证的系统分析实践。 （SEBoK 原创）