在本文中，我们将展示SysML建模语言如何有助于补充需求过程，即更好地定义和跟踪需求。系统建模语言（SysML：www.omgsysml.org）是一种通用的图形建模语言，由对象管理组（OMG）定义，基于众所周知的统一建模语言（UML：www.uml.org）。 。它用于指定，分析，设计和验证复杂系统，旨在提供简单但功能强大的构造，用于对各种系统工程问题进行建模。它在指定需求时特别有效：支持工程分析的系统属性的结构，行为，分配和约束。
本文将深入探讨SysML（与UML相比）提出的特定结构，以模拟需求和可追溯性。我们将看到需求图如何实现需求层次结构和派生的捕获，以及“满足”和“验证”关系如何允许建模者将需求与满足它的设计元素或验证它的测试用例相关联。我们还将就如何最好地使用这些特定的建模结构提供实用的建议。
1.什么是SysML？
1. SysML的起源
在所有领域，那些建筑复杂系统已经建模了很长时间：
- 利用复杂性
- 降低风险
- 沟通。
SysML™是一种通用图形建模语言，用于指定，分析，设计和验证可能包括硬件，软件，信息，人员，程序和设施的复杂系统。它是一个专门针对系统工程的UML配置文件。
为了可视化UML和SysML语言之间的关系，请考虑图1中所示的维恩图，其中组成语言的语言结构集分别显示为标记为“UML”和“SysML”的圆圈。标记为“由SysML重用的UML”的区域显示的两个圆的交集表示SysML重用的UML建模构造。图1中标记为“UML的SysML扩展”的区域表示为SysML定义的新建模构造，它们在UML中没有对应物，或者替换UML构造。请注意，还有一部分UML不是实现SysML所必需的，它由标记为“SysML不需要UML”的区域显示。
图1： SysML和UML之间的关系 - 来自[OMG1]
2. SysML图表类型
九个SysML图表类型在图2（白色框）中标识并总结如下。
图2： SysML图类型 - 来自[OMG2]
行为图包括用例图，活动图，序列图和状态机图。用例图提供了通过系统或系统部件之间的交互实现的功能的高级描述。活动图表示活动之间的数据流和控制。序列图表示系统的协作部分之间的交互。状态机图描述了系统或其部件响应事件而执行的状态转换和操作。
系统结构由块定义图和内部框图表示。块定义图描述了系统层次结构和系统/组件分类。内部框图描述了系统的部件，端口和连接器的内部结构。包图用于组织模型。参数图表示对系统属性值的约束，例如性能，可靠性和质量属性，并且用作将规范和设计模型与工程分析模型集成的手段。
UML vs SysML
系统建模语言（SysML）是工程系统的通用建模语言。SysML支持以图形符号分析，设计和验证复杂系统，包括硬件，软件，信息，人员，程序和设施。SysML被定义为使用UML概要机制的统一建模语言（UML） 子集的扩展， 并于2005年11月提交给对象管理组（OMG）.SysML提供基于语义基础的图形表示，用于建模系统行为，用于与其他工程分析模型集成的要求，结构和参数元素。SysML被定义为统一建模语言（UML） 子集的扩展 使用UML的配置文件机制并于2005年11月提交给对象管理组（OMG）。许多竞争规范提案由OMG合并并于2006年7月作为OMG SysML采用，并于9月推出OMG SysML™v1.0 2007年。
SysML图表类型在图中标识并总结如下。
2.用于建模基于文本的需求的SysML新构造
SysML定义了建模需求及其关系的特定元素，这些元素在更为人熟知的UML中不存在。它还包括与其他工件（如测试用例或设计块）的关系，以实现可追溯性。
所有这些结构将在以下段落中详细解释。
1. SysML中的需求概念
让我们引用SysML规范[OMG3]：“要求规定了必须（或应该）满足的能力或条件。要求可以指定系统必须执行的功能或系统必须达到的性能条件“。
用例（以UML存在）对于捕获功能需求是有效的，但不适合表达非功能性需求。将基于文本的要求纳入SysML有效地满足了广泛的要求。
标准SysML要求
标准SysML要求包括用于指定其唯一标识符和文本要求本身的属性，如图3所示。用户还可以指定其他属性，例如验证状态，优先级等。
图3： SysML要求
要求子类
建模者可以通过定义Requirement构造型的其他子类来自定义需求分类法。例如，建模者可能希望定义需求类别以表示操作，功能，接口，性能，物理，存储，**/停用，设计约束和其他特殊要求（如可靠性和可维护性），或表示高级别的利益相关者需求。构造型使建模者能够添加约束，这些约束限制了可以分配以满足要求的模型元素的类型。例如，可以约束功能需求，使得它只能通过诸如活动，状态机或交互的SysML行为来满足。
要求包
需求可以组织成包结构。典型结构可包括满足所有要求的顶级包装。此顶级包中的每个嵌套包可能包含来自不同规范（系统，子系统，组件等）的需求。每个规范包都包含该规范的基于文本的要求。此包结构对应于典型的规范树，这是用于描述项目需求范围的有用工件。
2.要求关系
捕获系统模型中的需求非常有用。但是，更大的价值在于您在需求和其他模型元素之间创建的关系。
指定了七个需求关系，使建模者能够将需求相互关联以及与其他模型元素相关联。这些包括用于定义需求层次结构，导出需求，满足需求，验证需求和精炼需求的关系。然而，这些关系的语义不是在形式上定义的，而是需要解释的。因此，有必要定义某种启发式，指导方针和实践，以便如何使用这些关系以获得一致的模型。
SysML中的所有可用关系将在下一段中详细说明。
遏制（综合要求）
复合需求可以包含使用命名空间包含机制指定的需求层次结构的子需求。复合要求可以说明系统应该做A和B，它可以被分解成系统应该做的A的子要求，系统应该做B（如图4所示）。
图4： 复合SysML要求
将复合需求划分为更简单的需求有助于建立完整的可追溯性，并显示各个需求如何成为进一步推导的基础，以及如何满足和验证它们。
派生关系
派生需求通常对应于系统层次结构的下一级别的需求。一个简单的例子是车辆加速要求，其被分析以得出对发动机功率等的要求，如图5所示。
图5： 派生关系的示例
它还用于表示层次结构的同一级别但不同抽象级别的需求之间的关系。例如，硬件或软件团队可以分析最初由系统工程团队指定的硬件或软件需求，以获得反映其他实现考虑因素或约束的更详细的需求。来自硬件或软件团队的更详细的要求可能与系统团队通过派生关系指定的原始要求相关。
优化关系
细化需求关系可用于描述如何使用模型元素或元素集来进一步细化需求。例如，可以使用用例或活动图来细化基于文本的功能要求，如图6所示。或者，它可以用于示出基于文本的要求如何细化模型元素。在这种情况下，可以使用一些精心设计的文本来细化不太细粒度的模型元素。
图6： 细化关系的示例
细化应阐明要求的含义或背景。它与派生关系的区别在于，需求与任何其他模型元素之间可以存在细化关系，而派生关系只能存在于需求之间。此外，派生关系旨在基于分析施加额外的约束。
满足关系
满足关系描述了设计或实现模型概念如何满足一个或多个要求。然后，系统建模者可以指定旨在满足要求的系统设计元素，如图7所示。
图7： 满足关系的示例
然而，重要的一点是，断言不构成证据。满足关系只是一种将需求分配给结构的机制。确实满足要求的证据将来自测试用例（见下一段）。
验证关系
验证关系定义了测试用例或其他模型元素如何验证需求，如图8所示。在SysML中，测试用例或其他命名元素可用作表示检查的任何标准验证方法的通用机制，分析，演示或测试。
图8： 验证关系的示例
复制关系
实际需要跨产品系列和项目重用需求。典型情景是适用于产品和/或项目的法规，法定或合同要求以及跨产品系列重复使用的要求。
SysML引入了从属需求的概念，如图9所示。
图9： 复制关系的示例
复制的需求的text属性是源需求的text属性的只读副本，但复制的需求具有不同的id，并且可能包含在不同的命名空间中。
跟踪关系
通用跟踪需求关系提供了需求与任何其他模型元素之间的通用关系，如图10所示。跟踪的语义不包含实际约束，因此非常弱。因此，我通常建议您使用之前提出的其他（更有意义的）需求关系之一。
图10： 跟踪关系示例
但是，跟踪关系可用于将需求与源文档相关联，或用于在结构树中建立规范之间的关系。
警告：箭头方向！
SysML中的大多数需求关系都基于UML依赖性。箭头从依赖模型元素（客户端）指向独立模型元素（供应商）。因此，在SysML中，箭头的方向与通常用于需求流的方向相反，其中较高级别的需求指向较低级别的需求。在绘制关系时要小心这一点！
3.要求图和表格
要求图
有效识别和管理需求可以使您的项目取得成功。SysML工具具有SysML需求图工具，可以在表示和管理系统需求时提供可视化方法。在需求图中，需求显示为块，其间包含连接器，说明需求的派生，依赖和分组。需求图工具允许您定义自己的需求类型，具有用户定义的属性和外观，并生成Excel的外部操作需求列表。导回文件以进行更新。
在市场上寻找最好的SysML建模工具?
-
Visual Paradigm 支持最新 SysML1.5 全部图表标准
你说出来，我们已经知道了！需求图，块定义图，内部框图，参数图，封装图，活动图，序列图和状态机图都支持Visual Paradigm。
-
可视化SysML模型
使用我们易于使用的图表编辑器，您只需点击几下即可绘制专业的SysML图表。
-
还有更多！
我们不仅支持SysML图表，还支持所有传统的UML图表类型。例如部署图，以及组合结构图和更多！
30天试用期不需要注册。