基于MBSE的复杂装备系统设计：理论与实践 课件 2.3.1 需求图

总标题

——SysML需求图本幻灯片中的图片为教学中多年的积累，无法逐一列出出处，在此统一鸣谢！本幻灯片仅应用于教学，无任何商业用途说明：1.1需求概念1.2需求关系1.3需求标识1.4总结第X章SysML需求图需求概述1.1需求概念需求来自于多个来源，直接来自于支付系统的组织或个人，或研制系统的组织;需求的来源会反映出多个利益攸关者；针对系统、部件，将需求组织成规范(specification)；独立的需求应该是清晰的、无歧义的，充分的，可实现的，满足利益攸关者需要，可验证的；需求管理工具用于管理需求和需求间的关系；SysML提供了在文本化需求和系统模型之间的需求建模能力，同时可保持同步性；在文本化需求和模型元素之间实现全生命周期阶段的追溯性，包含系统设计、分析、实施和测试用例；从文本规范或需求管理工具可直接导入需求到建模工具中，代替手动创建需求；在模型结构中，规范以包的形式组织，形成规范树(specificationtree)；需求概述1.1需求概念每一个规范包含多个需求，如系统规范描述系统需求；每一个规范中的需求也是以树结构的形式被组织；需求可以被链接到其他规范中的需求，或表示系统设计、分析、实现和测试用例的模型元素；SysML的需求关系包含派生、满足、验证、细化、追踪、复制；针对某个特定决策，可定义设计原理，并绑定到某些元素上；需求结构包含名称、ID，也包含用户自定义的属性，如风险；SysML提供多种方式用于捕获需求和关系，图形化的、表格形式的标注；在一些建模方法论中，用例常被用做需求分析，用例更多覆盖功能需求，SysML的需求模型范围更广；需求图（RequirementDiagram）1.1需求概念需求图使需求文件可视化，并描述需求与其他元素的关系。需求图（RequirementDiagram）1.1需求概念需求的多种标识方法：直接符号Directnotation区段符号Compartmentnotation标注符合Calloutnotation需求图外框1.1需求概念需求图外框：req[modelelementtype]modelelementname[diagramname]需求图的类型是req，图外框所代表的模型元素类型包含如下：PackageModelmodelLibraryViewRequirement需求层级标识法有两种：十字准线标识法：包含在默认命名空间中；限定名称标识法：在模型层级关系的其他位置。需求定义1.1需求概念需求定义：一条需求描述了系统的至少一种属性或行为，且这些属性或行为必须始终被满足构造型：<<requirement>>SysML：需求

=ID+文本+…说明：在SysML中，需求条目被定义为一种特殊的类(class)，通常由唯一标识(ID)和描述文本(text)两部分组成，类型都是string。与SysML模型中普通的类不同，需求模型不包含属性(attribute)和操作(operation)，若需要标注需求的优先级或需求类型，可以使用扩展的构造性对需求进行标注。此外，需求也无法被泛化或创建实例，因为需求不存在可继承的属性或操作。需求可以被定义为原子需求、复合需求、需求说明书；包也可被用来代表需求说明书需求扩展1.1需求概念通过构造性实现需求扩展；可对需求添加属性；针对需求构造型添加子类subclass；可添加约束，用于限制所绑定的模型元素种类。需求关系1.2需求关系需求关系用于表示需求与模型元素之间的关系；关系有多种标识方法：直接符号区段符号标注符号表格符号需求规范树1.2需求关系需求被组织到包结构中；通过包结构定义出规范树；对应用于基于文档的方法，可便于配置管理；需求文档可直接从特定的包中生成。需求关系类型1.2需求关系命名空间包含关系（NamespaceContainment）

定义：使用“命名空间包含”关系描述一条需求包含在另一条需求中说明：需求之间存在不同的层级关系。某些起标题作用的总体需求，包含了许多更详细的需求条目。这种包含关系同时意味着，当所有子需求都被满足时则主需求被满足。该关系表明一条需求存在于其主需求的名称空间下因此子需求不能与主需求有相同的名称，此外同一条需求也不能被多条需求同时包含。需求关系类型1.2需求关系派生需求关系定义：使用“派生需求”关系描述一条需求包含在另一条需求中派生得到；派生需求关系是基于一个分析（analysis）而来构造型：<<deriveReqt>>说明：根据商业或业务需求可以派生出技术需求，同时技术需求也可以派生其他需求。这种“派生需求”关系只允许在需求之间使用。例如有以下两条需求“用户控制界面反应时间”和“用户体验需求”，其中前者派生自后者。需求关系类型1.2需求关系细化关系定义：使用“细化”关系表示模型元素对需求进行更详细的描述，减少需求歧义性构造型：<<refine>>说明：为了对一条需求进行更详细的描述，除了在需求的文本中进行描述，还可以使用细化关系将需求连接到其他模型元素，不限制元素种类，用于对需求进一步说明。该关系只用于模型内的元素之间而不对外部来源建立细化关系，例如外部需求库。需求关系类型1.2需求关系满足关系定义：使用“满足”关系描述一个设计元素满足某条需求构造型：<<satisfy>>说明：模型中的每一个设计元素都直接或间接地用于满足某条系统需求。使用满足关系时可以从任何模型元素指向需求，一般这些元素选择较为复杂的设计元素，例如包或者模块。需求和设计元素之间可以存在多对多的满足关系。满足关系是一种断言(asset)，说明客户端会满足提供方端的需求；断言并没有包括证明，证明用验证关系需求关系类型1.2需求关系验证关系定义：使用“验证”关系描述一个测试用例或其他模型元素验证某条需求被满足满足；验证关系用于证明断言是正确的/错误的。构造型：<<verify>>说明：验证关系必须在提供方端有一个需求。没有对客户端能够出现的元素种类施加限制，通常是测试用例。测试用例(TestCase)是在模型中定义的一种行为，为了触发特定结构的功能而创建，从而验证它是否满足需求分配给的一个或多个需求。测试用例可以是一下三种行为中的任一种:活动、交互或状态机。需求关系类型1.2需求关系跟踪（trace）关系定义：使用“跟踪”关系建立需求与任意其他模型元素之间的某种关系，这只是一种弱的关联关系，不代表特定的含义，不包含任何约束；构造型：<<trace>>说明：常被用于关联需求和源文档。需求关系类型1.2需求关系复制（copy）关系定义：使用“复制”关系建立需求的副本，并与原需求进行关联，以实现需求的复用构造型：<<copy>>说明：复制的需求文本与源需求一致，且为只读，ID不一样。需求关系标识法1.3需求标识直接符号定义：带有开口箭头的虚线，带有表示特殊关系的元类型优势：把关系本身作为图的关注点；缺点：耗费图的大量空间分割框符号定义：每种关系都会显示在单独的分隔框中，分隔框名称会指定关系的类型，以及根据另一端元素所确定的方向。优势：显示更紧凑，把多个需求关系都显示在一个元素的边界之内；缺点：作用单一，只能显示关系；占用图空间。需求关系标识法1.3需求标识标识符号定义：指的是连接在一个元素上的注释；可指定关系的类型，以及根据另一端元素所决定的方向，另一端元素的类型和名称。优势：可附着在任意图中的任意类型元素上；缺点：最浪费空间需求关系标识法1.3需求标识矩阵定义：在最少空间中表示多种关系的最佳机制。优势：节省空间，易于阅读；缺点：无法显示元素的特性；导出到文档后不易阅读。需求关系标识法1.3需求标识表格定义：需求除了以图形方式表达之外，还可以使用文本表格的方式记录，尤其在需要浏览大量需求条目时可以方便展示。表格的列中可以显示需求的ID和文本，以及其他相关属性。问题和原理1.3需求标识SysML语言并没有为需求定义“基本原理”属性，可以应用注释机制来实现；基本原理《rationale》被记录为一种特殊的注释，用于为特定决策做出合理性解释；问题《problem》用于识别特定问题，或标记出疑惑点；基本原理和问题常被应用到需求或需求关系上；但附着给任何类型元素以及两个元素之间的任何类型的关系都是合法的。1.4总结SysML需求建模能力充当传统基于文本需求和建模环境之间的桥梁，因此需求可导入或直接创建；需求包含名称、ID和