基于模型的系统工程(MBSE)是一种形式化的方法，它支持与复杂系统开发相关的需求、设计、分析、验证和确认。数字建模环境中的MBSE提供了基于文档的系统工程无法提供的优势。这些优势已经导致越来越多的采用MBSE，因为MBSE可以通过减少开发时间来节省成本，并提高生产安全和功能的软件的能力。SEI CERT部门已经开始研究如何在系统开发过程的早期使用MBSE来降低安全风险，从而使系统在设计上是安全的，而不是在开发过程的后期添加安全特性的常见做法。

尽管MBSE没有规定任何特定的过程，任何MBSE过程都应该涵盖四个系统工程领域:需求/能力、行为、架构/结构，以及验证和确认。在这篇博客文章中，我描述了MBSE如何解决这些领域中的第一个:需求，它描述了要解决的问题。

传统上，任何项目、系统或产品或系统中的变更的起点都是需求——对未来系统应该解决的问题的初始描述。需求可以描述未来系统的逻辑和物理方面。 它们可以以包含用户愿望的文档、业务分析过程的结果、变更请求、用户论坛期间的口头请求或来自赞助商的请求的形式出现。 在将它们放入 MBSE 模型之前，需求需要分类、重复数据删除和重新措辞。

尽管模型中可以表示各种类型的需求，但这里是 三种主要类型 ：

• 业务需求： 对组织的目标、目的或需求的高级陈述。 它们通常描述与组织有关的问题。
• 用户需求： 特定利益相关者或利益相关者群体需求的中级陈述。 它们通常描述某人希望如何与预期的解决方案进行交互。 用户需求通常位于高级业务需求和更详细的解决方案需求之间。
• 系统需求： 通常是解决方案所需的能力、行为和信息的详细说明，包括解决方案必须保持有效的条件、解决方案必须具备的质量或必须在其中运行的约束条件的详细说明。 系统需求包括非功能性需求，例如安全性、可用性、可测试性和可修改性。

在我之前的博客文章“基于模型的系统工程 (MBSE) 简介”中，我将语言作为建模用来实现其目标的四种工具之一。在这篇和以后的文章中，我将使用系统建模语言 (SysML)，它通常用于系统建模。SysML 对元素之间的关系和连接有严格的语法和规则，这有助于避免歧义。读者可以假设，除非另有说明，否则当我提到 MBSE 时，我指的是带有 SysML 的 MBSE。 MBSE with SysML 提供通用元素类型需求以及子类：业务需求、可用性需求、功能需求、性能需求、接口需求、物理需求和设计约束。对于是否使用不同类型的需求没有严格的规定。所有需求都可以建模为通用需求类型。或者，可以通过使用所有提供的类型甚至添加自定义类型来创建复杂的模型。中间路线是将业务需求、具有附加构造型的通用需求和其他需要的 MBSE 需求类型混合在一起——请参见下面的图 1。的刻板印象元素类型从统一建模语言 (UML)来到 SysML ，是UML 中的三种扩展机制之一。

图 1：需求类型示例

主要需求类型到 SysML 的映射很简单：

• 业务需求 --> SysML 业务需求
• 用户需求 --> 具有 用户需求构造型的 SysML 通用 需求
• 系统功能需求 --> 带有 系统需求构造型或 SysML 功能需求子类的 SysML 通用 需求
• 系统非功能需求 --> SysML 设计约束、可用性需求、性能需求、接口需求、物理需求

需求类别

其中的工程系统技术需求分析是分类。 需求可以根据功能、它们描述的业务流程的一部分或与其相关的子系统和组件分为不同的类别。

为了开发一个组织良好的需求模型，SysML 建议使用包，它们是文件夹状的结构，以分层方式包含需求（图 2）。 这些包可以有自己的内部结构，可以从一些复杂的需求中解脱出来。 太深的结构增加的复杂性会抑制模型导航。 在大多数情况下，三层就足够了。 如果需要更多层，重新设计封装结构并使其更宽更扁平可能是个好主意。

图 2：需求包结构示例

如果需求分类需要有额外的维度， 则可以使用 SysML 构造 型元素。 它就像一个标签，但可以有自己的属性。 如果有需要，可以将构造型应用于需求（图 3）。 之后，原型化的需求可以在一个视图（例如表格）中呈现（图 4），或者在整个模型中标识并显示在 Used By视图中（图 5）。

图 3. 具有自定义构造型的需求

图 4. 带有附加“应用陈规定型”列的需求表

图 5. 自定义构造型“Protocols”的“Used By”操作的结果

需求可追溯性和关系

需求建模最重要的方面之一是对来源、工程过程中的步骤和系统架构元素的可追溯性。 需求图使系统工程师能够为每个需求讲述一个故事。 该图映射了需求的来源。 该图揭示

• 他们在哪个版本的系统需求文档 (SRD)中发布给利益相关者
• 其他要求是否源自它们
• 他们是否改进了任何用例
• 是否有相关的测试用例需要验证
• 他们满足解决方案架构的哪些部分

图 6 提供了一个故事示例。

图 6. 需求图示例

图 6 包括一个特殊的元素类型。

根据需求的数量及其分解的深度，为高级需求和系统级需求提供单独的图表可能更有意义。 高级需求只能显示需求的分解和对源文档和 SRD 的可追溯性。 系统级需求图可以包含更多元素和关系，在同一图中显示多个需求。 但是，这样的图可能太繁琐且难以理解。

不是仅仅将高级需求和系统级需求放在同一张图中，表明模型中的两个对象应该一起考虑的最佳方法是在它们之间创建关系。 如果模型中的两个对象之间建立了关系，系统工程师可以创建它的许多不同视图。

表格是模型中需求的有用视图。 表格可以显示需求之间的各种属性和关系。 表视图对于发现模型中的错误也很有价值，例如在错误方向创建的关系。

例如，在图 7 中，我添加了两列： Derived和 Derived From。 在第一行，业务需求13有一个 Derived需求和另一个 Derived From需求，也就是说业务需求13是从用户需求14派生出来的，用户需求24是从业务需求13派生出来的。 知道业务需求是高层次的，不能派生自任何其他需求， 业务需求 的 派生自列应为空。 表格视图使这个错误很容易识别。 第 2 行中的系统要求是低级别的，只能派生： 派生列应为空。

图 7. 关系错误方向（第 1 行和第 2 行）的表

模型中的分析工具

该模型的主要优点之一是能够为每种类型的关系创建依赖矩阵。 每次模型中的对应关系发生变化时，依赖矩阵都会自动更新。 这些矩阵可以用作验证工具，类似于使用表格查找模型中的错误的方式。

图 8 显示了模型中由 验证关系 指示的需求和测试用例活动之间的依赖关系矩阵 。 该矩阵使您可以轻松查看哪些要求已得到验证，哪些要求未得到验证。

图 8.“验证”矩阵示例

图 9 和图 10 显示了 派生关系的 另一个视图 。 图 9 和图 10 之间的区别在于，图 9 显示 了模型中 派生关系的 所有状态 ，而图 10 显示了没有 派生关系的需求。 图 10 显示了所谓的“负空间”，即没有 派生关系的需求。 这种类型的矩阵有助于识别“孤立”需求，例如未映射的业务需求。

图 9.“派生”矩阵示例

图 10. 负“派生”矩阵示例

与 验证矩阵 类似 ， 满足依赖关系矩阵视图（图 11）显示 了识别范围内的 所有 满足关系。 所有矩阵都可以在一个或两个方向以及负空间中显示指定的关系。

图 11.“满足”矩阵示例

数字建模为我们提供了另一种分析工具——覆盖率指标，它使我们能够评估模型的当前状态。 除了计算测试用例（ 验证关系）或设计元素（ 满足关系） 覆盖多少需求的统计数据外 ，每个指标都记录了一个时间戳。 定期计算相同的指标允许用户及时监控模型特定方面的变化，如图 12 所示。

图 12. 覆盖率指标示例

最后，我想提一下依赖映射。 为位于树顶部的需求生成依赖关系图可以更全面地了解该树。 该地图在树的顶部显示了涉及需求的所有类型的关系。 它显示了这些关系的多个级别以及需求如何与其他领域相关，例如测试、安全、文档和系统行为。 这些不同的视图使我们能够在树的顶部或中间投射任何更改的影响。 它还提供了需求与模型中其他元素之间关系的另一种视图，如图 13 所示。

图 13. 依赖关系图示例

MBSE 中的功能

当产品和项目经理在系统的愿景和开发路线图的级别上查看未来系统或现有系统时，系统的功能就会发挥作用。 关注功能提供了独立于实现细节的系统的综合视图。 与需求一样，能力也是问题描述的要素； 能力和需求紧密相连，它们相互通知和完善。