SysML实践指南第二版（中文翻译：刘亚龙）第13章 需求图

1. 建模基于文本需求使用需求图

本章描述基于文本需求如何被绘制在模型中并关联其它模型元素。本章也描述在一个SysML模型中表示需求的方法和符号。

1. 1. 概述

正如描述在SysML标准中[1],一个需求必须指定（或应该）被满足一种能力或条件，一个系统必须执行的功能,或系统必须达到性能条件。

需求有许多来源，有时需求被直接提供通过为系统提供经费的个人和组织,诸如，一个客户雇佣一个开发商来建造他或她的房子。其它情形,需求被生成通过开发系统的组织，诸如，一个汽车制造商必须确定它的产品的消费取向。需求的来源常常反映多个利益相关者的关注。在汽车制造商的情形中,需求包含排放控制和安全性的*法律,以及消费者的直接偏好。

无论来源,分组一个系统、元素、或组件的相似需求到一个需求规格中是通用的做法。单个需求应该被表示使用清晰和无歧义的术语,对于开发组织使用来开发一个系统是充分的，满足涉众需求。然而,经典的系统工程挑战是：确保需求是协调的(不是矛盾的)并是可行的,充分反映实际的涉众需求被确认,确保需求被满足通过系统设计和实现被验证。

需求管理工具被广泛用来管理需求和它们之间的关系。需求常常被维护在一些数据库类型中。SysML包含一个需求建模功能，为维护在需求管理工具中的基于文本需求和系统模型之间架起一座桥梁。使用需求管理和配置管理过程来保持需求与模型的同步。这种功能试图在整个系统的生命周期内显著的改善需求管理，通过使能基于文本的需求并表示系统设计、分析、实现和测试用例的模型元素之间严格的可追溯性。

单个文本需求可以被导入到系统建模工具从一个需求管理工具或需求规格文本,或直接生成在系统建模工具中。需求规格典型的被组织在模型的一个包结构层次中，对应一个规范树。每个需求规格包含多个需求,诸如，系统需求规格包含系统的需求,组件需求规格包含每个组件的需求。包含在每个需求规格的需求通常被建模在一个树结构上，对应每个需求规格如何被组织。个体或聚合的需求在容器层次内的，可以随后与其它需求规格中的需求、和表示系统设计、分析、实施、和测试用例的模型元素连接。

SysML包含需求关系：衍生、满足、验证、提炼、和追溯，支持一个健壮的功能对应关联一个需求与另外一个需求和其它模型元素。除了绘制需求和它们的关系外,SysML包含一个功能来捕捉原理或一个特定决策的基础,并连接原理与任何模型元素。这包含连接原理到一个需求或到需求和其它模型元素之间的一个关系。

拷贝（copy）关系也被提供，适应于需求文本的重用。

每个个体文本需求可以被绘制在模型中作为一个SysML需求。需求包含一个名称、文本字符串和id,和也可以包含附加的用户定义的属性，诸如，风险。

SysML提供多种方式绘制需求和它们的联系在需求图和需求表中。需求图可以被用来表示这些关系。此外, 在任何其它SysML图上，紧凑的图形化符号可用来描述需求关系。通常提供工具的需求的浏览器视图，同时也提供一个重要的机制来可视化查看需求和它们的关系。SysML也支持需求和它们的关系表示的表格视图。

在许多使用UML和SysML的基于模型的方法中，用例被用来支持需求分析。不同的开发方法可以选择使用用例与SysML需求的结合。用例是典型的最有效的方式捕捉功能需求,但不能作为捕捉广泛范围内的其它需求,诸如，物理需求(例，重量,尺寸,振动)；可用性需求；或其它所谓的非功能性需求。基于文本需求合并到SysML有效适应范围更广的需求。

用例类似其它任何模型元素,可以与需求关联使用需求关系(例，refine关系)。此外,用例常常对应一个用例描述(参考第12.4.2节)。在用例中描述的步骤可以被捕捉作为个体文本需求,并随后与其它模型元素关联,在用例和模型之间提供更细粒度的可追溯性。

1. 1. 需求图

在SysML中需求可以被描绘在一个需求图上, 在图形上描绘需求规格和需求的层次是特别有用的。由于这个图可以描述一个单一的需求和它的大量的关联,它是有用的来表示一个单一的需求的可追溯性，通过检查需求如何被满足、验证、提炼、和来检查它与其它需求的衍生关系。需求图标题如下:

req [model element type] model element name [diagram name]

需求图可以表示一个包或一个需求,正如说明通过在方括号中的模型元素类型。模型元素名称是包含需求的包名称或需求名称。图名称是用户定义的，并常常描述图的目的。图13.1显示一个需求图的一个通用例子，其包含一些最常见的标志。

这个例子强调许多不同的需求关系和可选的符号。例如, Camera满足Sensor Decision需求。除了satisfy关系,图也可以是包含容器和deriveReqt和verify关系。关系被描写使用直接符号、舱段符号、和标注符号的一种组合。在实践中,仅这些中符号中的一个符号典型使用在一种特定的图上。关系和符号选项被讨论在本章的后面。SysML的需求符号完整的包含在附录表A.25到A.27中。

需求可以被直接显示在模块定义图、包图、和用例图上。需求和其它模型元素之间的关系可以被表示在所有图上使用舱段和/标注符号；参考第13.5.2和13.5.3节，例如，可选的方式来显示需求被讨论在第13.7节(表格视图)和第13.9.1节(浏览器视图)。

图13.1 一个需求图的通用例子

1. 1. 在模型中表示一个文本需求

被绘制在文本中的一个需求被表示使用SysML的«requirement»模型元素。一旦需求被捕捉到,它可以与其它需求和到其它模型元素关联通过一组特定关系集。每个需求包含多个预先定义的属性：一个唯一的标识符和一个文本字符串。

图13.2是一个基于文本需求例子，称为Operating Environment被表示在SysML中。它被区分通过关键字«requirement»并将一直包含最小的属性集：名称、id和文本。这个相同信息可以被显示在一个表格格式中，描述在本章后续部分。

图13.2一个需求的例子描写在SysML中

需求通过添加属性可以被客户化，诸如，验证方法、验证状态、严重等级、风险、和需求分类。验证方法属性，例如,通过一个枚举类型称为VerifiyMethodKind并包含值，诸如，观测、分析、演示、测试。一个风险或严重等级属性可以包含值：高、中、低。一个需求分类属性可以包含值，诸如，功能、性能、或物理。

生成需求分类的一个备选的方法是来定义需求构造类型的附加子类(参考第15.3节获取有关构造类型讨论)。构造类型使建模者能添加约束，其限制模型元素的类型，可以被赋值来满足需求。例如,一个功能需求可以被约束，所以它可以进一步被满足通过一个行为模型元素，诸如，活动、状态机、或交互。SysML标准[1]的附录C包含一些非正式的需求子类,其也被显示在表13.1。

正如显示在表中的,每个分类表示作为一个通用的SysML的«requirement»的构造类型，表也包含分类的一个简短描述。构造类型增加的属性或约束可以被添加作为适当的应用。

表13-1 可选的需求的构造类型来自SysML 1.0附录C.2

构造类型	基础类	属性	约束	描述
«extendedRequirement»	«requirement»	source: String risk: RiskKind verifyMethod: VerifyMethodKind	N/A	一个附加的构造类型，其添加约束到通用使用的需求的属性
«functionalRequirement»	«extendedrequirement»	N/A	被满足通过一个操作或行为	需求，其指定一个操作或行为，一个系统或系统的部分，必须执行
«interfaceRequirement»	«extendedrequirement»	N/A	被满足通过一个端口,连接器, 流动项,和/或约束属性	需求，指定端口对应链接和可选的可以包含流动项；贯穿链接器和/或接口约束
«performanceRequirement»	«extendedrequirement»	N/A	被满足通过一个数值属性.	需求，数量测量扩展到一个系统，系统的部分或满足一个需求功能或条件
«physicalRequirement»	«extendedrequirement»	N/A	被满足通过一个结构元素	需求其指定物理特征，和/或系统的物理约束或一个系统的部分
«designConstraint»	«extendedrequirement»	N/A	被满足通过一个模块或一个组成部分。	需求，其指定一个约束在系统或系统执行的部分，注入“系统必须使用一个商业现成的组件”。

需求分类的其它例子可以包含操作需求, 指定需求对应可靠性和可维护性、存储需求、控制需求、和一个高层级涉众需求。应用一个需求配置文件的一些指导如下。(关于一个配置文件使用的指导被包含在第15.4节。)

• 分类应该被采用对应特定的应用或组织，并反映在配置文件中。这包含有关分类的协议和它们相关的描述,构造类型的属性、和约束。附加的需求分类可以被添加通过进一步分类构造类型显示在表13.1,或生成附加的构造类型在同级层次。
• 应用更明确的需求构造类型(功能、接口、性能、物理、设计约束)作为可应用的并确保与描述、构造类型的属性、和这些需求的约束的一致性。
• 一个特定的文本需求可以包含超过一个需求分类的应用,在其中情形中，每个构造类型应该被显示在一个逗号分隔列表在括号内部，标志被称作为书名号(«»)。
  1. 需求关系的类型

SysML包含特定的关系来关联需求到其它需求以及到其它模型元素。这些包含关系对应定义一个需求层次,衍生需求、满足需求、验证需求、提炼需求、和拷贝需求。

表13.2汇总这些特定关系，随后被讨论在本章。衍生（derive）和拷贝（copy）关系可以仅关联一个需求与另外一个需求。满足（satisfy）、验证（verify）、提炼（refine）和追溯（trace）关系可以关联需求与其它模型元素，容器（Containment）可以被用来关联一个需求到另外一个需求,或到像一个模块或一个包的另外一个命名空间。

1. 1. 在SysML图中表示交叉关系

需求可以关联出现在不同图上的模型元素。如果需求和关联的模型元素位于相同的图上关系可以直接显示。如果模型元素不出现在相同的图上,它们可以一直被显示通过使用舱段或标注符号。直接符号可以被使用,例如,为了在一个需求图上显示一个衍生需求关系在2个需求之间。舱段或标注符号可以被使用在需求图上来引用其它模型元素,或可以被使用在其它图上来引用到需求。一个例子是一个模块定义图，其使用舱段或标注符号来建立一个满足关系在一个模块和一个需求之间，它们没有显示在相同的图上。

除了这些图形表示方式，SysML也提供一种灵活的表格符号表示需求和它们的关系。注：分配关系描述在第14章,被表示使用描述在这里的相同的符号方法。

表13.2需求关系和舱段符号

关系名称	关键字描述在关系上	供应者 (箭头)端 Callout/Compartment	供应者 (非箭头) 端 Callout/Compartment
满足（Satisfy）	«satisfy»	被满足通过 «model element»	满足«requirement»
验证（Verify）	«verify»	被验证通过 «model element»	验证«requirement»
提炼（Refine）	«refine»	提炼通过 «model element»	提炼«requirement»
衍生需求（Derive Requirement）	«deriveReqt»	衍生 «requirement»	衍生自«requirement»
拷贝（Copy）	«copy»	(No callout)	主«requirement»
追溯（Trace）	«trace»	追溯 «model element»	追溯从«requirement»
容器（需求分解）（Containment (Requirement decomposition)）	(Crosshair icon)	(No callout)	(No callout)

1. 1. 1. 直接地描绘需求关系

当需求和模型元素关联被显示在相同的图上,这种关系可以被直接描绘。直接符号描绘这种关系作为一条带有箭头的虚线，关系的名称显示为一个关键字(例，«satisfy»、«verify»、«refine»、«deriveReqt»、«copy»和«trace»)。

图13.3显示一个«satisfy»关系的一个例子，一个Camera模块和一个Sensor Decision需求之间,其中Camera是设计的部分被断定来满足需求。注：箭头指向到需求。

图13.3直接符号描绘一个Satisfy关系的例子

重要的是认识箭头方向的意义。在SysML中，由于大多数需求之间的关系是基于UML的依赖关系,箭头指向依赖的模型元素(称为客户端)到独立的模型元素(称为供应端)。这种联系的解释是，摄像头模块是依赖于需求,意味着如果需求变更,设计必须变更。相似的,一个衍生的需求将依赖于原始需求。在SysML中,箭头方向是相反的，典型的被使用对应需求细化其中高层需求指向到底层的需求。

1. 1. 1. 描述需求关系使用舱段符号

舱段符号一个可选的方法来显示在一个需求和另外一个支持舱段的模型元素之间的一个需求关系,诸如，一个模块、组成部分、或另外一个需求。这是一个简化的符号，可以被使用代替一个直接关系。它排除直接的一个需求显示也可以被使用于图，例如，一个内部模块图。在图13.4中,舱段符号被使用来显示相同的satisfy关系图13.3的需求。这应该被解释作为“传感器决策需求被满足通过摄像头（Sensor Decision is satisfied by the Camera）”舱段符号显示关系和方向(satisfiedBy),模型元素类型(«block»),和模型元素名称(Camera)。

图13.4舱段符号描述一个Satisfy关系的例子

1. 1. 1. 描绘需求关系使用标注符号

标注符号是一个可选的符号来描写需求关系。它是最不受限制的符号。它可以被用来表示任何需求和任何其它模型元素之间的关系在任何图中。这包含需求和模型元素之间的关系,诸如，引脚、端口、和连接器,其不支持舱段和因此不能使用舱段符号。

标注被描绘作为一个备注标志，其被图形化连接到一个模型元素。标注标志引用模型元素在关系的其它终点。标注符号描绘在图13.5中，显示相同的信息正如舱段符号在图13.4,并且它应该被解释作为“传感器决策需求被满足通过摄像头”。

图13.5 标注符号描写一个Satisfy关系的例子

1. 1. 描绘原理需求关系

一个基本原理是一个SysML模型元素，其可以是一个需求或需求之间的关系、或任何其它模型元素关联。正如名称隐含的,原理试图来说明一个特定决策的原因。尽管原理在这里被描述对应需求,它可以被应用贯穿所有模型来说明任何类型的决策。一个问题被描绘像一个原理,但被使用来标识一个特定的困难或需要解决的问题。

正如显示在图13.6,原理被表示使用一个带关键字«rationale»的备注标志。问题类似的表示使用«problem»关键字。文本在备注标志中可以直接提供原理或者引用一个外部文档(例，一个权衡分析报告或分析报告)或模型的另外一部分，诸如，一个参数图。引用可以包含一个超链接,尽管这是不明确的在语言中。在这个特定例子中,有一个引用到一个权衡分析T.1。这个特定原理的语境被显示在本章的后面的图13.14中。

一个原理或问题可以被附着到任何需求关系或需求。例如,一个原理或问题可以被附着到一个满足关系,并引用到一个分析报告或权衡分析，其说明断定，一个特定的设计满足需求。类似的,原理可以被使用与其它关系，诸如，衍生关系。一个原理也可被附着到一个满足关系，其引用一个测试案例，其验证需求被满足。

图13.6 原理的例子正如描写在任何SysML图上

1. 1. 描绘需求和它们的联系在表格中

在查看大量需求时，需求图有一个明显的缺点。大量的需求属性和关系是必要的描述，并涉及所有的需求，需要指定一个即使是中等复杂的表格形式。传统的显示需求在文档中的方法是一个很有效的表示方式相对显示它们在一个图中。现代需求管理工具典型的维护需求在一个数据库中,在数据库中查询的结果也可以明显并简洁的显示在表或矩阵中。SysML包含显示模型查询结果在表中，以及使用表作为一种数据输入机制,但生成表的细节被保留在工具执行中。

图13.7提供一个与显示在图13.1相同需求的简单的需求表例子。在这个例子中,表列举在System Specification包中的需求，正如说明通过标题。一个工具根据它的功能也可有查询和过滤准则从一个查询的模型来生成需求报告。这个报告可以表示一个模型的视图,正如描述在第6.9节。此外,工具也支持直接在表视图中编辑需求和它们的属性。

图13.7需求表例子

1. 1. 1. 描绘需求关系在表中

通过选择一个或多个需求(或其它模型元素)关系路径可以被形成,并从选择的需求导向这些关系。这个可以被表示采用表格形式,正如显示在图13.8。在这个例子中,D1是选择的需求。包含2个deriveReq关系带有方向，正如显示在图13.14,以及原理与每种关系。

关系路径可以任意深度的,也就是说,一个单一的关系导航从一个模型元素到下一个，或导航不同类型的关系从一个模型元素到下一个。进行需求变更影响分析时这是非常有用的。

图13.8表向下的deriveReqt关系的例子

1. 1. 1. 描述需求关系作为矩阵

表格符号也可被使用来表示需求之间，以及需求与其它模型元素之前的多种复杂的相互关系以矩阵的形式。图13.9显示一个查询的结果在表格(矩阵)形式中；它描述满足和衍生关系。在这个例子中,需求被显示在左侧的列,和有一个衍生或满足关系的模型元素被显示在它的列中。过滤准则可以被应用来限制矩阵的大小。在这个例子中,没有包含需求属性，仅衍生和满足关系被包含在里面。这些关系被随后讨论在本章。再次,这是一种机制的一个例子可以使用来构建模型的一个视图，一个工具供应商应该提供这种支持。

图13.9 需求的表格视图的例子，表示需求之间的满足和衍生关系的矩阵

1. 1. 在包中建模需求层次

需求可以被组织在一个包结构中。一个典型的结构可以包含一个顶层包对应模型中的所有需求。这个包中每个内嵌的包可以包含需求来自不同的需求规格,诸如，系统需求规格、元素需求规格、和组件需求规格。每个需求规格包包含基于文本需求对应它的需求规格。这个包结构典型对应一个规范树，也即是一种描述项目需求范围的有用构件。

一个需求包结构,或规范树的一个例子,被显示在包图13.10。容器的所有者终点带有‘十’字标志，用来说明Customer Specification、System Specification、Camera Specification被包含在Requirements包中。第17.3.7节描述了一个使用需求图和追溯关系表示规范树的另一种形式。

图13.10一个包结构对应组织需求的例子

组织需求到相应的各种规格的包中，与基于文档的方法是一致的并且相当熟悉，并有利于对包的各个子规格的配置管理。此外，规范的文档或报告可以直接从适当的包的内容生成。

1. 1. 建模一个需求容器层次

容器被使用来表示一个组合需求如何可以被划分到一组简单的需求。容器可以被看作所包含的需求的逻辑‘与’（联合）的操作。组合需求划分到更简单的需求帮助建立完整的可追溯性，并作为个体需求如何进一步偏离的基础,和它们如何被满足和验证。

图13.11显示一个需求图带有一个简单的容器层次。图13.10的Customer Specification表示一个顶层需求规格，服务作为一个容器包含所有其它客户生成的需求。在这个例子中Customer Specification包含2个其它需求,正如描绘通过十字标志。注：代替使用一个包,一个需求规格可以被建模作为«requirement»，包含一个其它层次的需求,诸如，显示在图17.53。一个典型的需求规格可以包含成百上千个个体需求,但它们通常可以被组织进一个层次中，对应一个需求规格文档的组织。

图13.11 需求包含在一个包中的两个等效的例子

图13.12显示容器层次如何被用来生成多个层级的内嵌需求。在这个例子中Operating Environment需求包含两个附加的需求对应All Weather Operation和24/7 Operation。

图13.12 需求容器层次的例子

1. 1. 1. 一个容器层次的浏览器视图

一个典型的建模工具包含一个模型的浏览器视图,包括需求的层次结构。在图13.13中,需求规格对应图13.10，和需求容器对应图13.12对应的一个浏览器视图。这种表示方法是一种紧凑的方式查看需求容器层次结构。

图13.13需求容器在一个工具的模型浏览器中的例子

衍生关系的一个例子被表示在需求图13.14。关系被显示使用一条虚线带有关键字«deriveReqt»箭头指向原始需求。«rationale»可以被用来关联衍生关系，提供衍生关系的证据说明。注：«rationale»已经被与衍生关系关联并包含一个引用到一个权衡分析T.1。

图13.14 «deriveReqt»关系的例子，附加有原理说明

需求追溯矩阵，传统的被包含在需求规格文档中，显示需求与其它底层或高层需求规格之间的关系。这种关系常常语义上等价于一组SysML衍生关系。一个衍生关系常常显示需求规格层次之间的关系。它也被使用表示层次树的同级层次需求之间的一个关系,但处于一个不同的抽象层次。例如, 初始指定硬件或软件需求通过系统工程团队，可以被分析通过硬件或软件团队，并反映附加的执行考虑或约束的更详细衍生的需求。更详细的需求可以与原始需求关联通过一个衍生关系。

1. 1. 评估一个需求被满足

满足关系被使用来断定，一个对应设计或执行的模型元素满足一个特定的需求。实际的证据断言为true，伴随验证关系描述在下一节。图13.15通过提供满足关系的例子。

图13.15 需求的满足关系的例子和相关的标注符号

满足关系被显示带有一条虚线和关键字«satisfy»，箭头指向需求，断定：Camera 满足需求。一个可选的标注符号也被显示来表示这种关系。«rationale»与满足关系关联，说明为何这个设计被断定满足需求。在图13.16,相同的满足关系来自图13.15被显示在模块定义图使用舱段符号。

图13.16 满足关系使用舱段符号的例子

1. 1. 验证一个需求被满足

验证关系是一个需求和一个测试案例或其它模型元素之间的一种关系，其被使用来验证那个需求被满足。正如描述在先前的章节,满足关系是一个断言，模型元素表示设计或执行满足需求,但验证关系被使用来证明断言是true(或false)。

一个测试案例指定输入激励、条件、和期望的响应来验证一个或多个需求被满足。观测、分析、演示和测试，这些标准的验证方法可以被用来执行一个测试案例。如果需要来表示不同的验证方法，附加的构造类型可以被定义通过用户。测试案例可以参考一个记录的验证过程,或它可以表示验证方法的一个模型,诸如，一个交互(序列图)。来自测试案例的执行结果被称为判决结果,其可以包含一个值的传递,失败,不确定的,或一个特定值。

图13.17提供一个使用验证关系的例子。验证关系显示使用一条带有关键字«verify»的虚线，箭头指向从Water Spray Test测试案例到All Weather Operation需求，也即All Weather Operation需求被验证。一个可选的舱段符号也被显示来表示这种联系。

图13.17 验证关系的例子

一个测试案例可以是一个行为或一个操作,并使用一个序列图、活动图、或状态机图,来指定测试案例方法。应用测试案例关键字到一个交互(被表示通过一个序列图)的一个例子显示在图13.18。这显示一个spray tester使用一个sprayer:Nozzle应用到first production:Camera，其处于测试中(设计通过关键字«sut»)。注：spray tester期望观察装配摄像头的水泄露，在开始测试前。一个测试案例的一个例子也即被建模作为一个活动图，可以被查找在图17.55。

图13.18一个测试案例交互的例子,描述作为一个序列图

一个测试案例被建模作为一个行为,通常,可以表示包含的结构特征的几乎所有的特征一个测量。例如,测试用例可以表示测量系统重量的一个行为。在这个意义上,一个测试案例是一种通用的机制来验证需求。此外,其它模型元素可以被用来验证一个需求。一个例子可以包含使用一个约束模块来验证一个需求通过分析。

在SysML中，测试案例的使用与UML测试配置文件是兼容的[48]。这个配置文件提供附加的语义来表示测试环境的其它方面。SysML建模工具和验证工具之间的集成被简短介绍在第18.3.5节，作为工具之间信息流的讨论的部分。

1. 1. 减少需求歧义性使用提炼关系

正如讨论在第6.8节,提炼（refine）关系提供一种能力来降低歧义性在一个需求通过关联一个SysML 需求到另外一个模型元素，其阐明并常常格式化需求。这种关系典型的用来提炼一个基于文本需求使用模型的部分,但它也可以被使用来提炼一个模型的一部分使用一个基于文本需求。例如,一个基于文本功能需求可以被提炼使用一个更精确的表示，诸如，一个用例和它的实现活动图。可选的是,模型元素或元素可以包含需要的系统接口一个相对抽象的表示，其可以被提炼通过一个接口的文本规范，其包含一个接口协议或一个物理接口封装绘制的一个详细描述。

需求的提炼应该澄清需求意义或语境。它明显与一个衍生关系区别，一个提炼关系可以存在于一个需求和任何其它模型元素之间,其中作为一个衍生关系仅是需求之间的。此外,一个衍生关系试图来施加基于分析的附加约束。

一个提炼关系的一个例子被提供在图13.19；它显示All Weather Operation需求如何被提炼通过一个建模天气条件和转变状态机。提炼关系被显示通过一条带有关键字«refine»的虚线箭头从精确表示的元素指向到被提炼的元素，一个可选的舱段符号也表示这种联系。注：Weather Model状态机仅部分提炼需求。Detect Scenario用例可以解决,例如,特定测试期望在每种天气条件中。

图13.19 refine 关系应用到需求的例子

1. 1. 使用通用的追溯关系

追溯关系提供一种通用的一个需求和任何其它模型元素之间的关系。这也被讨论在第6.8节。追溯语义不包含任何约束和因此是非常弱的。然而, 关联需求和源文档一或需求规格和规范树之间追溯关系可以非常有用(参考第17.3.7节)。

正如显示在图13.20,追溯关系被使用来关联一个特定需求到一个作为需要分析的部分市场调查。追溯关系被显示使用一条虚线使用关键字«trace»箭头指向源文档。调查被表示作为一个用户定义的模型元素使用关键字«document»。

图13.20追溯关系连接一个需求到一个元素表示一个外部文档的例子

1. 1. 重使用需求使用拷贝关系

在SysML中，一个需求不像一个模块，在其中没有规范(注:一个需求的构造类型可以被指定正如讨论在第节13.3)。然而,一个需求可以被拷贝。拷贝关系关联一个拷贝的需求到原始的需求来支持需求的重用。一个需求存在于一个命名空间或容器层次和有特定的意义在他的包含语境中。为了支持需求的重用,拷贝的需求是一个需求，它的文本属性是一个来自原始需求的文本的只读的文本,但有一个不同的id。

一个拷贝关系的一个例子被显示在图13.21。拷贝关系被显示带有一条虚线带有关键字«copy»箭头从拷贝的需求指向原始需求。在这个例子中,原始需求被拷贝是一个来自一个技术标准的需求，其被重用在许多不同的需求规格中。

1. 1. 小结

SysML可以被用来建模基于文本需求和关联它们到其它需求和到其它模型元素。下面是一些建模概念的关键。

• SysML需求建模功能服务作为基于文本的需求和需求建模之间一个桥梁。需求可以被导入从一个需求管理工具,或需求规格文本,或直接生成在建模工具中。

图13.21一个需求拷贝关系的例子

• 作为一个最小一个需求属性包含一个id、名称、文本。附加的用户定义的属性诸如，风险和验证方法也可以被包含。需求分类的特定类型也可被生成,除了多个预先定义的分类在SysML中(例，功能、接口、性能)。
• 每个需求规格被通常绘制在一个包中。包结构可以对应于一个传统的规范树。每个需求规格依次包含一个需求容器层次在需求规格内部。在多数工具中，浏览器试图可以被用来查看需求的容器层次。
• 个体或聚合的需求包含在一个需求规格中可以被关联到其它需求在其它规范中，以及表示设计、分析、执行、和测试用例的。需求关系包含：derive、satisfy、verify、refine、trace和copy。这些关系提供一个健壮的功能对应管理需求和支持需求追溯。
• 有多个符号表示使需求能被关联到其它模型元素在其它图上；它们包含直接符号、舱段符号、和标注符号。需求图通常使用来表示一个容器层次或来表示一个特定需求的关系。表格符号也是有效的报告需求和它们的联系。
  1. 问题

1. 需求图的图的类型是什么?
2. 那种类型的模型元素可以是一个需求图的框架表示的?
3. 那个标准属性被表示在一个SysML需求中?
4. 您如何可以添加附加属性和约束到一个需求?
5. 什么类型的需求关系可以仅存在在需求之间?
6. 用一句话解释图13.3?
7. 您如何表示需求关系在图13.3，使用标注符号?
8. 您如何表示需求关系在图13.3使用舱段符号?
9. 您如何来表示Reqt A和Reqt B之间的一个«deriveReqt»关系一个矩阵中？
10. 如何来表示原理对应衍生的需求在图13.14，衍生基于xyz分析?
11. 一个Satisfy关系用来做什么?

1. 来确保一个需求被满足
2. 来断言一个需求被满足
3. 来更明确的表示一个需求

1. 什么是元素类型发现在一个验证关系的终点?
2. 什么被使用作为一个衍生的关系的记住?

1. 分析
2. 设计
3. 测试案例

1. 考虑需求A,使用文本“System shall do x and system shall do y”。您会显示需求A的分解到两个需求A.1和A.2使用容器?
2. 那种关系您会使用来关联一个需求到一个文档?(选择从答案a–d。)

1. deriveReqt
2. satisfy
3. verify
4. trace

1. 为何需求被包含在SysML中?(这可以是一个讨论主题而不是一个问题。)
   1. 1. 讨论主题

一个需求图的不同使用是什么?

何时您使用一个需求图或一个需求表?

需求如何可以和用例一起使用?