需求工程-软件建模与分析（第3版）课件 第6章 复杂情景分析

第六章：复杂情景分析2026/9/7目录概述非功能需求分析业务过程分析特征分析目录12026/9/7概述引入问题分析、目标分析和涉众分析是比较基本的需求分析活动，是所有项目都需要做得的，它们基本解决了前期阶段的核心分析工作。有些项目会遇到一些复杂情景，会需要使用特殊的分析技术。概述2026/9/72复杂情景概述质量要求高与非功能需求分析大多数的分析技术是针对功能需求的，无法处理系统的高质量要求。它们需要专门的非功能需求分析技术——使用目标模型的NFR分析。业务过程复杂与业务过程分析要保证复杂业务过程中的协同高效、可控、不出错误，需要使用专门的业务过程分析技术。产品族与特征分析在为多用户尤其是多层级用户开发业务系统时，经常会碰到产品族的差异性和多变性问题，这需要使用专门的分析技术——特征分析。概述2026/9/73目录概述非功能需求分析为什么需要非功能需求分析非功能需求分析的困难使用目标模型分析非功能需求的过程整合功能需求和非功能需求的目标模型示例业务过程分析特征分析目录42026/9/7为什么需要非功能需求分析原因需求工程分析技术忽略了非功能需求功能需求与非功能需求都是需求的重要

部分。需求工程分析技术主要关注在功

能需求的开发上，忽略了非功能需求，

尤其是质量需求。决定项目成败非功能需求有缺陷在实践中经常导致系

统故障甚至项目失败。大型复杂系统的

开发中非功能需求已经超过功能需求成

为决定项目成败的关键因素。非功能需求分析2026/9/75非功能需求分析的困难非功能性需求不独立，依赖于功能需求非功能需求是对功能需求的约束，不具有独立存在的价值。处理非功能需求时很难脱离功能需求进行独立考虑。作为非功能需求主体的质量需求比较复杂，需要按层次结构分解。非功能需求的处理技术要考虑“特征-子特征”的层次结构，“特征”与“子特征”之间既相互关联，又有固定的匹配关系。非功能需求分析2026/9/76非功能需求分析的困难非功能性需求不独立，相互冲突、依赖不同非功能需求之间却可能存在着紧密的联系。所以处理多个非功能需求时要折中、权衡的因素远多于单个非功能需求的内容。例如性能与安全就是一对冲突的非功能需求——安全性越高性能越低，反之亦然。有些非功能需求不集中，散布在系统的多个功能之中很多非功能需求是分散的，一个非功能需求可能会被分布在很多个功能任务中。例如数据安全访问的非功能需求会和所有访问数据的功能都相关。非功能需求分析2026/9/77使用目标模型描述非功能需求概述非功能需求分析的根本困难是不独立性能够在关联结构中分析非功能需求，能够将独立非功能需求及其对外依赖关系综合考虑。用面向目标的方法和目标模型分析非功能需求非常合适。非功能需求分析2026/9/78目标模型非功能需求独立性分析使用目标模型描述非功能需求将非功能需求建模为非功能目标在早期信息较为抽象和不充分时建模为软目标。后期添加“目标满足标准”修正为硬目标。这样非常符合需求开发的基本过程，还可以提醒需求开发者要定量描述非功能需求。

非功能需求分析2026/9/79使用目标模型描述非功能需求非功能目标可以依赖于功能目标功能需求可以建模为功能目标，非功能需求可以建模为非功能目标。让非功能目标支持、阻碍或精化功能目标，描述非功能需求对功能需求的依赖关系。

非功能需求分析2026/9/710使用目标模型描述非功能需求高层非功能目标精化为子层次非功能目标，描述非功能需求的层次结构关系可以使用质量属性模型的层次分解关系，进行质量需求目标的精化。

非功能需求分析2026/9/711使用目标模型描述非功能需求使用支持、阻碍（冲突）精化描述不同非功能目标之间的折中与冲突关系

非功能需求分析2026/9/712使用目标模型描述非功能需求让单个非功能目标依赖多个不同的功能目标，描述非功能需求的散布特性

非功能需求分析2026/9/713使用目标模型分析非功能需求的过程依赖功能需求识别、获取非功能需求目标在涉众表达功能需求时，会附带很多“关注”因素，这些因素往往就是高层次的非功能目标。例如，如果强调该功能一定要“好用”，就意味着存在易用性目标（UsabilityGoal）。例如，如果强调用户比较多、数据比较多或计算比较复杂，就意味着可能有性能目标（PerformanceGoal）。首先，按照目标分析的过程获取、分析并描述功能需求目标。然后，分析功能需求目标描述中的“关注”因素，发现依赖于功能需求目标的非功能需求目标非功能需求分析2026/9/714使用目标模型分析非功能需求的过程根据非功能需求层次结构，精化非功能需求目标很多时候获取到的非功能需求是比较复杂、抽象的，典型情况是只获取到了质量模型的特征级质量需求。依据质量模型的层次结构，将特征级的质量需求目标精化为子特征级的质量需求目标。非功能需求分析2026/9/715使用目标模型分析非功能需求的过程量化底层非功能需求目标的验收标准在高层NFR目标模型中，因为复杂、抽象等原因，主要使用软目标描述非功能需求目标。最终的规格化及验证需要可以验收的非功能需求目标。到了NFR分析后期，要为NFR目标模型中的底层非功能需求目标确定量化验收标准。非功能需求分析2026/9/716确定量化验收指标使用目标模型分析非功能需求的过程案例金蝶为安徽港航搭建的数据展示平台依赖功能需求识别、获取非功能需求目标功能目标“集团运营状况可视化展示”中的文字“可视化”可能意味着人机交互有质量要求，仔细描述后可以发现，可视化意味着：将众多复杂数据清晰地显示在一个屏幕上；实时刷新动态数据。

非功能需求分析2026/9/717使用目标模型分析非功能需求的过程案例金蝶为安徽港航搭建的数据展示平台根据非功能需求层次结构，精化非功能需求目标图所示的“及时反映数据变动”可以进一步描述，“画面要匹配所有数据”也可以精化为多个子目标。非功能需求分析2026/9/718使用目标模型分析非功能需求的过程案例金蝶为安徽港航搭建的数据展示平台量化底层非功能需求目标的验收标准确定数据更新的周期长度，确定每种数据类型能够显示的数量。非功能需求分析2026/9/719整合功能需求和非功能需求的目标模型示例概述与案例功能需求和非功能需求都使用目标模型进行描述，那么它们就可以整合起来，更丰富的描述系统需求。如图描述的是会议安排系统。非功能需求分析2026/9/720整合功能需求和非功能需求的目标模型示例案例——获取功能需求为了让时间适合，首先需要以自动或手动的方式找到所有可能的参与人，并得到他们的时间规划。得到“自动匹配”、“手动匹配”、“发现合适的参与人及时间”、“得到参与人及其时间规划”等需求。

非功能需求分析2026/9/721整合功能需求和非功能需求的目标模型示例案例——获取功能需求手动方式是逐一电话或邮件联系。自动方式是在系统中收集参与人的时间规划或日程。得到“手工得到”、“使用电话”、“使用邮件”、“自动获得”、“更新日程”和“收集时间规划”等需求。非功能需求分析2026/9/722整合功能需求和非功能需求的目标模型示例案例——获取功能需求找一个所有人都适合的时间可能无法实现，那么就让系统规划一个尽可能多人参与的日程安排，然后再用这个日程自动或手段匹配可能的参与者，匹配成功的邀请他们参与会议。得到“规划会议参与人”的需求。非功能需求分析2026/9/723整合功能需求和非功能需求的目标模型示例案例——识别非功能需求并精化会议的规划过程要尽可能的节省成本，包括收集日程的成本和匹配参与人时间的成本。手工方式都不利于降低成本，自动方式有助于降低成本。得到“规划会议人力成本”，“日程人力成本”、“匹配人力成本”等需求。非功能需求分析2026/9/724整合功能需求和非功能需求的目标模型示例案例——识别非功能需求并精化系统中的参与人及其日程时间涉及个人隐私，要保障数据安全。一是要防范非法用户的恶意访问，为此要求用户通过安全验证后才能访问数据。二是要防止合法用户的误访问，为此可以设计授权体系，拥有授权才能访问数据。得到“数据安全”、“防范恶意攻击”、“安全验证”、“阻止合法误访问”、“身份授权”等需求。非功能需求分析2026/9/725目录概述非功能需求分析业务过程分析概述活动图基本元素活动图关键：令牌平衡信号于事件机制异常与中断机制分区层次结构与图简化元素使用活动图进行业务过程分析特征分析目录262026/9/7概述历史业务过程的复杂性是随着1980s后期及1990s早期业务过程再造BPR（BusinessProcessReengineering）的广泛应用而被人们认识到的，人们开始寻找技术手段来描述企业的业务过程。人们依据DFD“流”处理的思想，建立了专门用来描述组织业务流程的业务过程模型BPM（BusinessProcessModel），并发展至今。BPM的思想被面向对象的主流技术UML吸收和采纳，建立了活动图（ActivityDiagram）。活动图活动图是描述业务过程和对象行为的模型，它以“流”（控制流和数据流）处理为侧重点描述过程与行为，以“令牌（Token）”平衡为手段实现过程中的复杂并发协同。业务过程分析2026/9/727活动图基本元素常用节点动作（Action）节点：每个动作节点都是一个可执行的任务或行为。动作的执行会产生一次过程处理或数据转换。在业务过程分析中，每个动作都是业务过程中的一个重要步骤，通常是涉众的一个任务和多个任务的集成。

业务过程分析2026/9/728活动图基本元素常用节点控制（Control）节点：控制节点用来协同活动图中其他节点之间的流转。初始（Initial）节点：活动开始流转的地方。结束（Final）节点：活动停止流转的地方。决策（Decision）节点：有一个流入流和多个流出流，决策节点在多个流出流中决策选择一个。合并（Merge）节点：有多个流入流和一个流出流，用于将多个可能的流入流转换为一个流出流。分叉（Fork）节点：将一个流入流分割为多个并发的流出流。汇合（Join）节点：汇合多个并发的流入流转换为一个流出流。业务过程分析2026/9/729活动图基本元素常用节点控制（Control）节点业务过程分析2026/9/730活动图基本元素常用节点对象（Object）节点：是指一个特定对象的实例，通常在活动图的特定时间点出现和使用。对象节点可以是动作节点的输入和输出，此时对象节点被称为动作的输入Pin或输出Pin。业务过程分析2026/9/731活动图基本元素流控制流（ControlFlow）：用于在前一个动作节点完成后启动下一个动作节点的活动边（ActivityEdge）。对象流（ObjectFlow）：一个能够传递数据和对象的活动边。业务过程分析2026/9/732活动图基本元素示例一文件问题报告修复业务流程业务过程分析2026/9/733活动图基本元素示例一文件问题报告修复业务流程过程开始，首先报告问题（FileProblemReport）报告问题之后并发进行两个工作一个是判断优先级是否为1如果是就评估影响（EvaluateImpact），然后修正时间计划（ReviseSchedule）。

如果不是，就什么都不做。另一个工作是修复问题（FixProblem），然后测试修复工作（TestFix）

如果上述两个工作都成功完成了（joinSpec=(AorB）andC)，就可以发布修复版本了（ReleaseFix）业务过程分析2026/9/734活动图基本元素示例二金蝶为安蔻文具开发的管易云C-ERP系统中从下单到拣货的业务流程安业务过程分析2026/9/735活动图基本元素示例二金蝶管易云C-ERP系统——从下单到拣货的业务流程过程开始，首先收集各平台店铺的订单信息接到订单后之后并发进行两个工作一个是判断订单商品的重量体积是否超过物流标准如果是就进行智能拆单

如果不是，就什么都不做。另一个工作是对订单进行智能分类。

如果上述两个工作都成功完成了，就可以通知拣货。通知后要提示拣货员订单所在的库位编号接着并发进行两个工作一个是智能拣货车帮助拣货一个是灯光播种墙光提示最后，拣货员将订单货品直接放入相应篮筐，完成拣货。业务过程分析2026/9/736活动图的关键：令牌平衡令牌平衡机制令牌类似于CPU的控制权，活动图中的动作节点只有得到令牌才能执行。初始节点发起令牌，结束节点回收令牌，其他节点传递令牌。动作节点一个动作节点接收到前面节点传递来的令牌后才能得以执行，该动作节点执行结束之后会按照活动图的定义将令牌传递给后续节点。一个动作节点接收到的令牌数量和传递出的令牌数量是一致的，不会有增减。业务过程分析2026/9/737活动图的关键：令牌平衡令牌平衡机制控制节点和流控制节点和流会影响到令牌的数量变化。一个控制流传递一个令牌。一个对象流传递一个令牌。决策节点从流入流接收到一个令牌后传递给多个流出流中的一个。合并节点从多个流入流中接收令牌，每接到一个就传递给流出流一个，总共接收到N个就传递给流出流N个。分叉节点从流入流接收一个令牌后，复制出多份令牌，给每个流出流都传递一个令牌。汇合节点从每个流入流都接收一个令牌，或者流入流的令牌接收情况符合汇合规格，就向流出流传递一个令牌。业务过程分析2026/9/738活动图的关键：令牌平衡令牌平衡机制令牌不平衡活动图的一个关键

是令牌平衡，它用

于验证活动图的业

务过程流转是否正

确。令牌缺失（有些节

点得不到令牌）令牌丢失（有些令

牌没有被传递到结

束就无法继续传递

了）令牌冗余（有多余

的令牌没有被处理）业务过程分析2026/9/739令牌不平衡的活动图示例正确的活动图活动图的关键：令牌平衡令牌元素为了既能保持令牌平衡，又能描述复杂的实际业务流终结（FlowFinal）为了解决业务过程失败的实际情况，活动

图引入了流终结。传递到流终结的并不是一个成功结束的令

牌，但却不会再继续传递。流终结不等同于令牌丢失，业务过程中的

流终结是有意设计的，流终结也是一个行

为。流终结可以保证业务过程失败时也能

令牌平衡。例如，在学校的人才培养过程中，入学是

初始节点，毕业是活动结束节点，但实际

情况中也会有中途退学的现象，学校也会

安排专人处理。业务过程分析2026/9/740活动图的关键：令牌平衡令牌元素CentralBuffer节点CentralBuffer节点是一个对象节点，管理多个对象输入和多个对象输出。CentralBuffer节点用于描述实际业务过程中的缓冲区或仓库，会将输入的令牌暂存排队，并最终随一个对象输出向后传递。CentralBuffer不影响令牌平衡，CentralBuffer从前面接收N个令牌，就能且只能向后面传递N个令牌。业务过程分析2026/9/741活动图的关键：令牌平衡令牌元素DataStore节点DataStore节点是一种特殊的

CentralBuffer节点，它暂存的

是可以一次生成无数次使用

的资源（例如数据库数据）。一个令牌传递到DataStore后

就像是消失了一样不再继续

传递，同时DataStore又可以

在需要时无限制地生成新的

令牌向后传递。DataStore对令牌平衡的计算

会有影响。业务过程分析2026/9/742活动图的关键：令牌平衡令牌元素令牌竞争在实际业务过程中，有些业务流转的目的地是随机的，活动图就将这种情况描述为竞争。令牌竞争不影响令牌平衡，多个随机目的地中只有一个能够得到令牌。例如，如果有一个课程同时开设了两个班，那么学生就可以随机地选择一个班上课，但不会同时在两个班上课。业务过程分析2026/9/743信号与事件机制概述为了描述异步协同的业务过程，活动图引入了信号与事件机制。业务过程分析2026/9/744信号与事件机制发送信号动作（SendSignalAction）动作从输入中创建一个信号实例，并传送给目的地。发送的信号可以仅是控制信号，也可以是带有数据的对象信号。发送信号是异步协同，所以发送信号时并不向目的地传递令牌，发送信号动作的令牌仍然保留在本地，继续向后续节点传递。业务过程分析2026/9/745信号与事件机制接收事件动作（AcceptEventAction）动作等待一个符合特定条件的事件的发生。有两种类型的接收事件动作。等待接收发送信号动作发送的信号。它不会产生新的令牌。一个有令牌的信号接收事件接收了一个信号时，令牌并不会增多，还是一个，传递给后续节点。等待时间事件的发生。它会产生新的令牌。时间事件可以是绝对时间事件（如1949年10月1号），也可以是相对时间事件（如10分钟后）。业务过程分析2026/9/746异常与中断机制概述为了描述实际业务过程中的异常情况，活动图引入了异常与中断机制。异常处理（ExceptionHandler）如果保护节点出现了特定类型的异常，就自动执行异常处理动作。如果异常没有被捕获，就会被传递给上一层被封装的保护节点。如果异常一直被传递到最顶层都没有被捕获，系统就可能会出现未预料的行为。业务过程分析2026/9/747异常与中断机制可中断活动区（InterruptibleActivityRegion）可中断活动区是一个支持中断其中令牌的活动组。只要区域内存在令牌，该区域就可以接收中断事件。只要接收到中断事件，区域内的所有令牌都会终止，并沿着中断边向外传递一个令牌。业务过程分析2026/9/748分区概述活动图的节点与边可以依据特定的目的归类为活动组（ActivityGroup），一个节点或边可以被同时归类为多个活动组。活动分区（ActivityPartition）是一种最常用的活动组形式，它通常按照组织单位或涉众角色将节点、边划分到不同分区。分区可以有层次嵌套结构，也开始是多维的，其图示可以使用泳道（Swimlane）也可以直接标记在节点上。业务过程分析2026/9/749分区示例业务过程分析2026/9/750层次结构与图简化元素概述为了防止单个活动图过于复杂，难以描述和阅读，活动图使用“活动”（Activity）元素来建立层次性的活动图结构，将单个复杂业务过程分解为多个更简洁的活动图。活动活动使用控制流和数据流模型，描述包含动作元素的下级行为的协同执行。简单地说，活动就是一个可以带有输入/输出参数的子活动图。活动可以有输入/输出参数，也可以没有，可以标记前置/后置条件，也可以不标记，但必须有一个活动名称，这也是它被调用时的标识。业务过程分析2026/9/751层次结构与图简化元素活动示例业务过程分析2026/9/752层次结构与图简化元素活动调用在活动图中，使用右边的图像表示调用一个活动。业务过程分析2026/9/753调用部分示例被调用部分示例层次结构与图简化元素连接件为了不让复杂活动图中表示控制流和数据流的箭头交叉混乱，活动图使用了连接件（Connector）元素。连接件是成对出现的，就像传送门一样，将从一个连接件端流入的流传送到另一个连接件端流出。业务过程分析2026/9/754使用活动图进行业务过程分析确定活动图的上下文环境活动图是对业务过程的描述，建立活动图首先要确定业务过程的处理界限。分析业务过程中的主要处理步骤的行为复杂的业务过程总是会按照一定的步骤顺序执行，要发现并列举这些主要的处理步骤。分析清楚这些步骤之间的先后衔接顺序。分析业务过程中的主要数据流业务过程往往会利用数据的传递作为工作衔接的重要手段，要发现这些具有重要意义的被传递数据，并分析这些数据在业务过程中不同步骤下的状态差异。业务过程分析2026/9/755使用活动图进行业务过程分析识别参与者在复杂的业务过程当中，识别主要的流程参与者。这些参与者将分享业务过程中的各项职责与行为，构成活动图中的不同泳道。在业务过程比较简单时，可以不进行参与者识别的工作。进行职责分配将业务过程的处理步骤划分到不同的泳道，并将处理步骤和数据流的传递组织起来，建立活动图。业务过程分析2026/9/756使用活动图进行业务过程分析添加活动图的详细信息，完善活动图描述分析不同动作之间的协同是同步还是异步，同步使用控制流和数据流，异步使用信号与事件。分析是否存在业务过程失败场景，添加流终结节点。分析是否存在较为复杂的行为，为其建立活动。分析业务过程中是否有异常，补充异常处理。始终要检查令牌平衡，修正不平衡的节点。业务过程分析2026/9/757使用活动图进行业务过程分析案例电商中心的交易业务过程描述业务过程分析2026/9/758使用活动图进行业务过程分析案例确定活动图的上下文环境整个业务过程以卖家发布商品开始，到交易完成结束。卖家与买家注册的问题不属于业务过程范围，可以不予处理。卖家和买家中途取消交易的申请不在业务过程范围内，可以另行描述交易取消申请过程。派送状态查询也可以描述为其他业务过程，不纳入交易业务过程范围内。业务过程分析2026/9/759使用活动图进行业务过程分析案例分析业务过程中的主要处理步骤的行为（卖家）发布商品、（卖家）通知准备发货、（卖家）选择物流公司、（卖/买家）查询状态（买家）选择商品、（买家）预付款、买家（验收）（中介商）预付款监管（物流公司）派送物品、（物流公司）更新状态中介商（付款）（审核人员）交易取消。业务过程分析2026/9/760使用活动图进行业务过程分析案例分析业务过程中的主要数据流商品信息，卖家发布供买家查看；预付款，买家交付中介商；商品派送状态，物流公司更新供卖家、买家查询；货款，中介商交付卖家；货物，卖家交付物流公司，再交付给买家。业务过程分析2026/9/761使用活动图进行业务过程分析案例识别参与者卖家；中介商；物流公司；中介商；审核人员进行职责分配按照上述描述内容建立泳道框架，分配动作，初步连接控制流和数据流。仔细完善货物和实际付款两个数据流转比较关键，必须使用同步协同，其他的流转都可以使用异步协同——通过共享系统数据实现异步通信。描述中表明取消交易是复杂行为，可以建立活动。派送也涉及一个复杂的物流过程，也需要建立为活动。交易取消的行为就是异常。业务过程分析2026/9/762使用活动图进行业务过程分析案例业务过程分析2026/9/763业务过程分析的活动图目录概述非功能需求分析业务过程分析特征分析面向特征的领域分析FODA特征模型特征建模过程目录642026/9/7面向特征的领域分析FODA概述特征分析技术是由面向特征的领域分析FODA（FeatureOrientedDomainAnalysis）方法引入的，用来分析产品族（ProductFamily）中大量差异、多变的功能特征。产品族随着业务的扩展，很多软件都出现了多个应用产品之间具有颇多共性的现象。这些具有相似性的应用产品都来自于同一个应用领域，具有大量的共性特征，也有少量的差异特征，这些产品就被称为产品族。对产品族的开发显然不适宜使用从头构建的传统开发过程，它应该以复用为关注点。特征分析2026/9/765面向特征的领域分析FODA产品线以软件复用为核心，建立产品族的方法被称为产品线。产品线的开发方法分为领域工程和应用工程两个部分领域工程负责分析、设计和建立可复用的软件制品。应用工程负责以可复用制品为基础，建立既包含共性又各有特色的各种最终产品。特征分析2026/9/766面向特征的领域分析FODA领域分析领域分析是领域工程的一个重要活动。它的职责是发现、分析并定义可复用的需求。领域分析需要仔细研究产品族背后的问题世界，在应用环境中发现相关业务的共性与差异性，定义共性和差异性可能的存在方式。领域设计就可以依据这些共性和差异性设计可复用的软件架构和应用组件，它们再经过领域实现之后就构成了产品线中最基础的可复用制品。面向特征的领域分析（FODA）的核心是特征模型。特征分析2026/9/767特征模型概述特征模型是领域分析最为常见的分析技术，它使用“特征”树来分析和描述领域的共性与差异性。特征是软件系统中独特的功能特性、质量或用户可见特征。业务过程分析2026/9/768特征树特征树的每个树节点是一个特征。特征树的层次结构意味着高层次的特征分解后具