基于模型的系统工程（MBSE）及MWORKS实践 课件 5 MBSE教材讲义 第五章 使命任务定义与需求分析

立足航天、面向工业、服务行业基于模型的系统工程及MWORKS实践聂兰顺教授2024年11月08日立足航天、面向工业、服务行业使命任务定义与需求分析聂兰顺教授2024年11月08日概述基于统一模型开展使命任务定义与需求分析等工作，论证使命任务过程、能力、任务所需的资源的约束条件，对系统产品的需求进行逐层细化分析，保证使命任务定义的正确性、利益相关方及其需求识别的完整性、需求传递的一致性、系统功能需求定义的合理性与可行性，实现系统正向设计的一体化能力提升使命任务定义完成使命任务是复杂装备研制的最根本出发点，是评价研制效果与效能的最终目标，也是系统工程、MBSE技术体系第一个过程/阶段的目标；以科研团队、作战指挥控制团队、运营商等最终用户甚至更高层次管理机构的战略任务为核心输入，识别出全生命周期各阶段的任务场景、边界以及利益相关方，开展各层级典型任务场景的数字化建模，定义装备系统与外部系统、环境、用户之间的交互响应关系，从而完成对使命任务的描述、分析、细化，并支撑提炼出利益相关方的应用需求。使命任务定义使命任务定义的输入最终用户期望是最终用户所预设的系统核心任务，既可以表现为简短的使命任务策划，也可以表现为较为复杂的任务书；对复杂装备总体系统，最终用户期望是指装备战略目标，以及由之分解而来的系统能力以及外部接口关系；对分系统及以下层级的产品，最终用户期望是指在向上一层级交付此目标产品时，上一级系统对其的功能预期其他利益相关方期望是指除直接用户之外的利益相关方期望；测试性、可靠性、维护性、保障性即为此类利益相关方期望的明确表达继承性需求是系统需要满足更高级用户或者更高级系统的整体性要求，此类需求有天然的继承性要求，能够帮助建立本层级的用户期望使命任务定义使命任务定义的主要活动利益相关方识别确定与系统相关的各利益相关方，为需求收集、任务场景设计与建模等工作提供完整的角色清单，从而保证任务分析、系统需求分析过程的完整性和准确性；利益相关方期望识别以战略目标、使命任务、需求输入等不同方式识别出利益相关方对系统的预期要求；任务场景设计与建模描述最终用户所要求的任务场景，根据其他利益相关方的诉求，尽可能完整地开展任务场景描述，界定相关内外部系统的物理与逻辑结构，识别和确定各类任务场景中系统与外部环境、外部系统之间的交互关系，明确定义系统的输入和输出；利益相关方需求收集根据任务场景中所描述的系统接口、能力要求、操作过程等来收集利益相关方需求。使命任务定义利益相关方识别利益相关方利益相关方是指其权益会被系统能力或研制应用过程影响的群体或个人；系统用户一般是最重要的利益相关方；针对系统的不同层级、不同专业，可能需要面向不同的利益相关方；实际工作中，也需要根据不同的业务流程开展工作；利益相关方类型管理人员；投资者；用户；维护人员；培训人员；可用性和效能专家；政府；标准机构；监管部门利益相关方期望识别用例图描述核心使命任务或者系统战略目标；主要包含用例和参与者两个元素。利益相关方期望识别用例图作为运行使用构想的结构化表达，是获取并描述利益相关方期望的重要手段，用于确定系统需求和运行边界，是系统中与用户相关联的需求开发和结构开发的出发点，是此后各类系统设计模型、仿真模型、描述文档的开发基础。使命任务定义利益相关方期望识别示例如图为某深空探测工程系统用例图该用例包括三个参与者及四个用例。三个参与者分别为地面指挥系统、目标星体（火星）及太空。四个用例分别代表探测工程所需执行的场景，即发射与部署、轨道控制与导航、仪器操作与控制、数据采集与传输。使命任务定义概述任务场景模型是对利益相关方期望的具体化表示，是对运行构想的展开描述，是系统需求中的重要根据，其建模元素可以包括用例图、活动图等行为模型，通过完善的描述并考察任务场景，经常能揭示出可能会被忽视的需求和设计要求任务分解任务场景建模应考虑运行使用的所有环节，包括在集成、试验、部署直到废弃/处置过程中的全部计划和非计划运行使用。为了开发可用的、完备的任务场景模型，需要从战略目标、使命任务出发，以类似穷举的方式，对其中包含的子任务或者具体的工作场景进行完整分析，同时还当考虑典型的故障、退化等故障模式下的运行使用场景，从而能够正确指导系统设计与验证。任务场景模型中包含的典型信息有：系统生命周期各个阶段的典型场景、运行使用时间基线、运行使用场景、故障管理策略、人机接口、维修保障需求、系统端到端通信过程、运行使用设施、任务逻辑过程与关键事件等任务场景设计与建模使命任务定义任务场景设计任务场景设计的具体工作过程与任务特点联系紧密；需要形成与行业特点相匹配的具体执行路线；以某飞行器的任务分析过程为例，可以采用飞行任务剖面的方法描述飞行器的任务及环境，该剖面说明了飞行器系统在全生命周期经历的事件以及事件顺序、持续时间、环境及系统工作方式。飞行任务执行是基于任务事件列表实现的。任务事件列表是指包含完成标称任务以及突发性场景所必需的所有任务事件的顺序集合，包括任务段、任务节以及分系统活动三个层次，分别对应飞行任务的顶层、中间层和底层描述。其中，任务段描述飞行任务的主要任务阶段；每个任务段包含若干任务节，对应于该任务段中需要完成的主要事件；分系统活动是底层也是最细节的任务描述，每个任务段与任务节都是通过顺序执行分系统活动序列来实现的。因此任务分析涉及的元素包括任务、子任务、任务段、任务事件、子事件、活动、状态等。使命任务定义任务场景建模任务场景建模从战略级目标出发，按照层级和分解关系，对系统使命任务进行初步分解任务场景模型既可以从零开始全新创建，也可以从外部任务模型或需求文件导入，设置任务参数与核心技术指标，通过用例图识别任务利益相关方、外部环境对象、系统边界等任务场景通用元素，并建立其形式化定义，明确各个场景的核心活动、内外部系统以及用户与系统之间的交互活动。使命任务定义任务场景设计与建模示例某型号军舰能同时具备以下几种功能：①在指定海域对抗外军驱逐舰；②进行对海或对空打击；③执行反恐作战；在MBSE方法中，采用模型的方式来描述功能需求，因为用例图能较好地表示系统边界、使用者以及使用者使用系统进行的顶层活动，所以，对军方的功能需求，采用如图所示的用例图进行描述；该用例图仅仅表示了顶层的功能需求，为了进一步细化需求，还需要进行专门的作战推演；在某些场合，任务分析过程还可以进一步细化，将用例图展开细化为活动图，从而将其转化为系统功能需求列表。使命任务定义利益相关方需求来源与利益相关方交谈承担这项任务的人员需要善于沟通，能够从与利益相关方的交谈中挖掘出真正的需求；提取利益相关方需求是一项与人有关的问题而不是技术问题，因此需要提前了解利益相关方的领域。从非正式文件中提取需求非正式文件可能包含隐含需求；这类需求也应明确提出，要注意记录需求来源。从场景中识别能力需求开发出任务场景模型之后，可以直接从场景中识别能力需求。需求研讨会是快速获取和捕获需求的有效方式；研讨会应具有一定的形式，而且也应该迭代。从经验中借鉴还可以从经验中借鉴，提取需求。利益相关方需求收集使命任务定义利益相关方需求收集方法将利益相关方需求与任务场景相关联利益相关方需求与任务场景之间具有很强的关联性，需要在模型层面加以表达。通过图形化视图与条目化视图的关联映射，将需求条目与用例节点相关联，开展需求分解、属性定义，并支持阶段任务节点、系统需求节点与用例节点的关联映射，支持这三种建模元素之间的追溯性、覆盖性分析与初步量化计算。将需求与用例关联，同时根据用例指标为需求创建指标，一一对应，形成需求条目利益相关方需求收集使命任务定义任务需求分解任务需求可以整理为层级化的形式，既可以采用需求图、需求汇总表的形式进行建模，也能采用树状图进行组织，直观地表现出任务需求的分解与继承关系，每个需求节点还可以进行参数化定义，并给出具体解释。使命任务定义利益相关方需求完善在上述基础上，还需要根据装备特征、经验、设计规范等对需求及其指标进行完善，包括系统性能方面以及非功能特性方面的需求形成需求结构树，并补充每个需求条目对应的值、单位、引用变量、描述、备注等信息，从而形成每条需求的完整描述。全部需求可以根据其层次化关系进行编号，具有相同的模型结构，能够以列表或者矩阵的形式进行统一展示，形成最终的条目化需求汇总表需求分析转换成经过初步评估的系统功能需求完备集，传统上，装备系统研制采用基于文档的系统工程，系统需求的表述强调其文字格式以利益相关者期望、任务场景和利益相关者需求为出发点，对系统任务场景的执行过程开展进一步的细化分析，将利益相关者需求转化成为系统功能需求模型和资源约束模型，从而能够指导系统功能和架构设计需求分析利益相关方需求以利益相关方团队为主要关注点，主要描述的是系统在全生命周期内的应用、维护、保障特性，是从外部视点对装备系统特性的表达；需要在利益相关方需求的基础上，进一步将其展开为不同任务场景下的功能逻辑，并识别出功能需求列表，支持系统功能和架构设计；功能需求分析之前，需要通过对任务场景进行细化，将任务场景分解为任务执行过程中的系统活动，识别出任务场景对系统的功能需求；分析满足利益相关方需求所需要具备的功能，进行功能定义和分解，通过功能库和指标库对功能输入输出参数和行为指标进行定义，通过搭建活动图细化用例图，并将冗余功能合并，最后确定功能指标并进行配置，进行功能覆盖性需求分析，完成功能需求分析过程，得到功能模型和功能需求。功能需求分析需求分析以水下无人航行器（UUV）的建模过程为例，UUV初始航行活动图包括初始航行参数确定，由电路信息系统进行功能承载，声自导系统和动力系统的开启也由电路信息系统承载，声自导系统工作由探测系统承载，动力系统工作由动力系统承载，其中，声自导系统工作和动力系统工作都能够继续细化；在上述活动图基础上，对系统的工作过程进行分解，根据任务逻辑的分支状态，对系统的状态变化进行定义，以状态机图的形式，对其进行建模，从而能够更加科学地进行分解和设计；继续以上述UUV的建模过程为例，对UUV总体攻击过程进行分析，将UUV攻击过程分为搜索目标状态、追踪目标状态、攻击目标状态和完成任务状态；在系统总体功能分析基础上，还可以围绕下一级任务场景或者系统活动进一步逐条开展每项子任务的功能分析，然后将每项子任务的工作过程表现为顺序执行的活动图，也可以进一步完善和丰富系统状态机图模型，从而实现系统功能分析、功能需求定义和功能逻辑定义的逐步迭代完善；上述攻击过程可以进一步分解为平台发射、目标博弈对抗和声对抗、初始航行、搜索目标、捕获目标、稳定追踪目标、命中目标及毁伤目标等，每个子任务还可以表达为多个系统功能之间的配合关系，以白盒活动图的形式对其进行建模描述。其中，稳定追踪目标活动图如图所示。功能需求分析需求分析需求分析稳定追踪目标活动图还可以进一步分解；对任务场景逐一进行分析，提炼出系统的大量功能需求，全部系统功能需求可以汇总成为功能需求总图，然后可以根据功能的相似性或者模块化特点进行组合，形成功能需求的层级化分类关系，形成需求图模型；功能需求条目是系统设计的直接目标；在功能需求之外还会定义系统性能指标。需求分析在系统设计早期，往往还要考虑到不同分系统对系统功能的支持作用，需要根据系统的初始概念架构对其进行分解分配，对系统功能逻辑进行细化分解，描述不同分系统在任务执行过程中的功能定位，表达各个系统在执行任务过程中的先后工作顺序以及逻辑接口关系，分解成为各个子系统需求。功能需求分解与分配需求分析UUV探测系统功能分解需求分析资源约束分析约束表达式基于使命任务定义和需求分析的结果，对系统所依赖的资源进行约束分析。通过数学关系来定义资源约束表达式，约束表达式中的变量称为约束参数。约束参数从它们绑定的值属性那里获得值，也就是被约束的值属性时间约束时间约束会指定单个事件发生所需要的时间间隔期间约束期间约束会指定两个事件发生所需的时间间隔状态常量状态常量是一个条件，可以在特定的事件发生之前（紧挨着的）指定给特定的生命线需求分析资源约束分析利益相关方约束和系统需求约束利益相关方约束是指利益相关方希望得到的结果。系统需求约束是指影响产品品质的“专业”或工程约束，所有利益相关方约束都必须在系统需求约束中阐明。利益相关方约束有时必须