MagicDraw-需求图

需求图

建模者一般会使用六种关系来确立需求之间的可跟踪性，以及从需求到系统模型中的结构和行为的可跟踪性。你可以在需求图中使用多种标识法来说明这些关系，每种都有其优缺点。

系统的需求会表示其设计各个方面的信息。需求图是Sys ML 中的主要媒介，可用于向利益相关者传达这类信息。

目的

越来越被广泛使用的技术是创建用例（以及相关案例叙述）来替代基于文字的功能性需求，创建约束表达式来替换基于文字的非功能性需求。

那么当你需要显示那些需求，以及它们与其他模型元素之间的关系时，就可以创建需求图这种SysML图。

当看图者需要看到从需求到系统模型中依赖于它的元素的可跟踪性时，这种图尤其有价值。

何时创建需求图

向模型增加新的元素时，你会创建一种关系，从那些元素指回驱动创建它们的需求。以这种方式确立需求的可跟踪性是贯穿设计和开发的活动。你可能需要创建需求图，在这项工作中的任何时间点显示那些关系。

需求图外框

需求图的图类型缩写是req 。图外框所代表的模型元素类型可能是以下这些：

• package
• model
• modelLi brary
• view
• requirement

十字准线标识法和限定名称字符串标识法一一在需求图中也是有效的。

需求

需求的标识法是一个矩形，在名称之前有元类型＜＜requirement＞＞ 。需求有两种属性： id 和text ，这两种属性的类型都是String。

图l I. l 中的需求图显示了五个需求。其中三个一－Hohmann Transfer 、ThrusterBurn 和Altimetry－一代表的是原子需求，另两个一一－Mission Requirements Specification和DellSat-77 System Requirements Specification一一代表的是完整的需求说明。

需求关系

在系统模型中记录需求很有用。然而，需求和其他模型元素之间的关系有更大的价值。在建模工作中，你可能会使用六种需求关系： 包含、跟踪、继承需求、改善满足和验证。

这些关系在系统模型中确立了需求的可跟踪性，这在系统工程组织中一般是一个过程需求。然而，从实践出发． 在模型中记录这些关系可以让你使用建模工具自动生成需求可跟踪性和验证矩阵（ Requirement Traceability and Verification Matrice ,RTV M ），并在需求发生变更的时候（那是不可避免的），执行自动下游的影响分析。这些功能会节省大量时间，而那会直接转换成对成本的节省。

包含关系

需求也是一种命名空间，它也可以包含模型层级关系中的其他已命名元素。但它要比包多了一种约束： 需求只能包含其他需求。

在图l 1.1 中使用十字准线标识法表示DellSat-77 System Requirements Specification 元素包含了Hohmann Transfer 需求。使用限定名称字符串标识法表达Propulsion Subsystem Requirements Specification 元素包含了Thruster Burn 需求。类似地，另一个限定名称字符串表达Sensor Payload Requirements Specification 元素包含了Altimetry 需求。

跟踪关系

正式情况下，跟踪关系是一种依赖关系。眼踪关系的标识法和依赖关中的那个一样（带有开口箭头的虚线），只是在上面有<<trace>>元类型。

跟踪关系是一种弱关系。它只是表达了一种基本的依赖关系：对提供方元素（位于箭头端）的修改可能会导致对客户端元素（位于尾端）修改的需要。

跟踪依赖关系还是很有用，因为建模工具可以导航到那种关系，然后自动生成RTVM ，或者执行自动的下游影响分析。

继承需求关系

继承需求关系是另一种依赖关系。因此继承需求关系的标识法和依赖关系的一样，但它拥有＜＜deriveReqt＞＞元类型。这种关系必须在客户端和提供方端都有需求。继承需求关系表示客户端的需求继承了提供方的需求。

拥有多级继承关系完全是合法的，并且依赖关系是可传递的。因此，如果基本的需求发生变更，那么下游的影响会贯穿整个继承需求关系链。

另外要注意的很重要一点是，继承的需求不需要包含在与提供方相同的命名空间中；它可能嵌套在模型层级关系的其他位置。

精化关系

改善关系是另一种依赖关系。改善关系的标识法和依赖关系的相同，但会带有《refine》元类型。改善关系表示客户端的元素要比提供方端的元素更加具体（也就是没那么抽象）。

满足关系

满足关系是另一种依赖关系。满足关系的标识法和依赖关系的相同，但会带有《satisfy》元类型。这种关系在提供方端必须有一个需求。SysML 没有对客户端所能够出现的元素种类施加限制。然而，客户端元素通常是模块。

验证关系

验证关系是另一种依赖关系。验证关系的标识法和依赖关系的相同，但会带有《verify》元类型。和满足关系一样，验证关系必须在提供方端有一个需求。

需求关系标识法

SysML 提供了多种标识法显示需求关系：直接标识法、分隔框标识法、插图标识法、矩阵和表格。每种标识法都有其自身的优缺点，使得它们根据你的需求和限制，比其他标识法更适合于具体的情况。然而，这些可选的标识法只对于基于依赖的需求关系可用：跟踪、继承需求、改善、满足和验证。

直接标识法

直接标识法指的就是依赖关系标识法本身： 带有开口箭头的虚线，带有表示特殊关系的元类型。

分隔框标识法

所有可以显示分隔框的元素（例如： 模块、需求、测试案例）都可以使用分隔框标识法来显示需求关系。每种关系都会显示在单独的分隔框中。分隔框名称会指定关系的类型，以及根据另一端元素所确定的方向。

这种标识法的优点在于，它比直接标识法和插图标识法更紧凑。它可以显示多个需求关系，所有关系都在一个元素的边界之内。

当你需要把重点放在元素的特性上，其次关注它们的关系时，这种标识法就是很好的选择。

这种标识法的缺点在于，它仅能用于可以显示分隔框的元素类型。并且，即便它比直接标识法和插图标识法更紧凑，但还是要比矩阵和表格消耗更多的空间。

插图标识法

插图标识法指的是连接在一个元素上的注释（见图11.3 ） 。插图标识法的内容和分隔框标识法的内容相同：它指定关系的类型，以及恨据另一端元素所决定的方向。然后它会指定位于另一端的元素的类型和名称。和单独的分隔框一样，单独的插图可以列举多个元素，只要它们都参与到同一种关系中。

这种标识法的优点在于它的多功能性，它可以附着在任意类型图中的任意类型元素上。缺点在于它最浪费空间。

矩阵

矩阵在系统工程文档中非常常用。矩阵并不是一种图形标识法（而大多数SysML标识法都是图形标识），然而， SysML 支持矩阵标识法，因为它是在最少空间中表示多种关系的最佳机制。

矩阵标识法有两个缺点。它不会显示元素的特性，止于它们之间的关系。在建模工具中易于阅读（读者有滚动条），当需要把它插人到打印文档中的时候，就会变得不易于阅读。

表格

SysML之所以支持表格，是因为它们节省空间。表格没有矩阵那么紧凑。然而，表格既可以显示元素的属性（例如id ），也可以显示它们之间的关系，如图l 1.5 所示。

基本原理

SysML 需求拥有两个属性： id 和text o 遗憾的是，这种语言并没有为需求定义“基本原理”属性。然而，它提供了另一种方式在的模型中记录基本原理一一一种可以应用于所有类型元素和关系的机制，而不仅仅针对需求。

在SysML 模型中，基本原理会被记录为一种特殊的注释。

基本原理元素的标识法是在注释体前面带有元类型<<rationale>>的笔记符号，如图l 1.6 所示。

把基本原理附着给任何类型元素以及两个元素之间的任何类型的关系都是合法的。

总结

需求图是SysML 中用于沟通以文字形式记录的系统需求的一种主要媒介。建模者通常会创建需求图来表示需求之间的可跟踪性，以及从需求到系统结构和行为的可跟踪性。

在SysML 模型中记录这种可跟踪性，让你可以使用建模工具执行自动化的下游影响分析一一生成一系列目标系统结构和行为，当它们所依赖的需求随时间变化而发生改变的时候，你可能需要对其进行修改。这种功能极大地减少了在系统生命周期中实现设计的变更所需要的时间和成本。