2027高项专题储备·原课程第17讲：搞清楚业主到底要什么？需求分析与 UML

本文取自2027版高项72讲课程第17讲，编号仅表示原课程位置。当前作为免费专题储备，暂不安排公众号或博客发布日期；文中的上下讲、作业和封面数字均沿用原课程编号。

本次全文免费公开。 本文保留完整课程、练习和解析，供同学按顺序学习。

【虚构案例声明】 本课程中的"美好家园"物业集团、"清华园社区"、"智慧邻里2.0"项目及全部人物均为教学所用的虚拟项目与虚构人物，详见第 01 讲首次声明。

一、上节作业讲评

1.1 五个人五种诉求怎么分

上一讲的核心作业：方姐说报修模块的需求是一笔糊涂账，李经理要工单统计报表，客服要一键派单，维修工要手机上看图片，业主要能催单，张主管要和门禁联动。要你回答这五种诉求是谁的需求、什么层面、先做哪个、用什么方法变成需求文档。提示是"谁要、要什么、系统怎么做"三层。

先分层。教材把需求分成业务需求、用户需求和系统需求三个层次，"从目标到具体，从整体到局部，从概念到细节"。“查看工单统计报表”本身是用户任务；经进一步访谈，假设确认她的业务目标是"报修 24 小时解决率从七成提到九成"，报表只是看这个目标的窗口。业务需求是改善解决率的目标，报表诉求仍属于用户需求，不能因提出者是总经理就改变层次。客服的一键派单、维修工的看图片、业主的催单，是三类用户各自"使用产品必须要完成的任务"，这是用户需求。张主管的“门禁联动”还只是待澄清的能力诉求。只有补齐授权主体、触发条件、通行范围、有效时间与失败处理等约束后，才能形成可测试的系统需求，不能仅凭技术名词定层次。

再定先后。业务需求是根，先定它：24 小时解决率九成。然后看哪些用户需求直接支撑这个根：一键派单缩短派单时间，看图片减少跑空，这两个直接支撑；催单是业主体验，间接支撑；门禁联动是锦上添花。所以二期做派单和图片，催单做简化版，门禁联动放三期。这不是拍脑袋，是用业务需求当尺子量用户需求。

最后答方法。教材的需求过程四步：需求获取、需求分析、需求规格说明书编制、需求验证与确认。方姐的团队现在停在第一步，把五个人的话记下来了，但没做第二步。第二步是把"杂乱无章的用户要求和期望转化为用户需求"，教材说这些要求"有重复的地方，也有矛盾的地方"，不能直接当设计依据。方法上，用面向对象分析建用例模型：先识别参与者，李经理、客服、维修工、业主、门禁系统，再按参与者实际交互识别用例，"查看工单统计""派单""查看现场图片""催单"，然后为每个用例写用例规约，最后按教材 GB/T 8567 的模板编成需求规格说明书，开评审会验证。

这道作业的关键不在答案，在那把尺子：需求应有来源和依据；业务目标是重要依据，法律合规、合同、安全与无障碍约束也可形成必须满足的需求。不能因为一项安全需求不直接提高解决率就推迟它。

二、需求是一笔糊涂账的根源：本讲目标

2.1 为什么需求最难

教材在需求获取那段说了一句实话："需求获取是一件看上去很简单，做起来却很难的事情"，原因是"大部分用户无法完整地描述需求，而且也不可能看到系统的全貌"。清华园一期就是这么来的：业主说"能刷脸就行"，上线以后才发现逆光识别不了、访客没法进、老人不会用二维码。需求没做透，后面的架构、设计、测试再好也是在错的地基上盖楼。

高项对这一节的考法很稳定：需求三层次、获取方法、结构化分析的三个模型分别用什么图、面向对象分析的用例关系、统一建模语言的基本概念。2015 到 2022 年这一节几乎年年有题，2023 年以后综合知识的题转到了项目管理部分的"收集需求"过程，但教材第 5 章课后练习六道选择题里有四道出在这一节，命题人从课后练习取材的趋势第 8 讲说过。

本讲要拿下三件事：

第一，教材 5.1.2 节前半部分：需求定义、三层次、质量功能部署三类需求、需求过程四步、获取五方法、好需求八特性、结构化分析三模型、面向对象分析的用例模型和分析模型。

第二，教材 5.1.2 节后半部分统一建模语言的概念骨架：结构三部分、事物四类、关系四种、十四种图的名字和分组、五个视图。十四种图逐图怎么画，第 18、19 讲。

第三，把报修模块的五种诉求变成一份需求文档：参与者、用例、用例规约、需求规格说明书的结构。

2.2 本讲任务地图

三、核心内容精讲：需求的定义、层次与过程

3.1 软件需求的定义与三个层次

教材口径：软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。根据 IEEE 的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

简单版是教材自己给的："软件需求就是系统必须完成的事以及必须具备的品质"。完成的事是功能，具备的品质是性能、安全这些非功能。

教材口径：需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。

三层次是这一节的第一考点。2015 年上半年第 6 题和 2015 年下半年第 5 题连考两次：业务需求"反映了组织结构或客户对系统、产品高层次的目标要求"，用户需求"描述了用户使用产品必须要完成的任务"。注意那两道老题里第三层叫"功能需求"或"功能及非功能需求"，教材第 4 版统一叫"系统需求"，考试按第 4 版。

教材还引入了一个工具。教材口径：质量功能部署是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度，它将软件需求分为三类，分别是常规需求、期望需求和意外需求。2021 年上半年第 9 题就考这三类，缺的那个是期望需求。三类的意思：常规需求是用户说得出来的，"能报修"；期望需求是用户不说但默认该有的，"报修以后有人回电话"；意外需求是用户没想到、给了会惊喜的，"维修工到门口时业主手机弹出他的照片和工号"。做产品的人常说"超预期"，说的就是意外需求。

3.2 需求过程四步：获取、分析、编制、验证

教材口径：需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。教材口径：常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。2017 年上半年第 6 题问哪个不是获取需求的方法，答案是"决策分析"，其他三个问卷调查、会议讨论、获取原型都算。五种方法用清华园说：访谈李经理和张主管；给两千户业主发问卷；采样抽三个月的报修电话录音听；情节串联板就是把业主从发现漏水到维修完成画成一串场景图；联合需求计划是把客服、维修工、业主代表拉到一个会议室一起定。

需求分析要把获取来的"杂乱的"要求转化为用户需求。教材口径：需求分析的关键在于对问题域的研究与理解，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解为若干个基本元素，然后对元素之间的关系进行建模。建模有两条路，结构化分析和面向对象分析，第四节和第五节分别讲。

需求规格说明书编制。教材口径：软件需求规格说明书是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。它的模板来自国家标准 GB/T 8567《计算机软件文档编制规范》，规定需求规格说明书应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。教材还提到 GB/T 9385《计算机软件需求说明编制指南》，但说它"年代久远，一些情况已经与现实不符，可以考虑作为写作的参考之用"。考试出"需求规格说明书的模板出自哪个标准"，答 GB/T 8567。第 16 讲说过 2025 年上半年第 12 题考文档分类，需求规格说明属于开发文档。

需求验证与确认。教材说在系统分析阶段检测需求规格说明书中的错误"所采取的任何措施都将节省相当多的时间和资金"。验证的内容五条：正确地描述了预期的系统行为和特征；软件需求是从系统需求、业务规格和其他来源中正确推导而来的；需求是完整的和高质量的；需求的表示在所有地方都是一致的；需求为继续进行系统设计、实现和测试提供了足够的基础。方法是需求评审和需求测试，教材口径：需求评审就是对需求规格说明书进行技术评审，它可以发现那些二义性的或不确定性的需求；需求测试要"在业务需求基本明确，用户需求部分确定时，同步进行"。

3.3 好需求的八个特性

教材口径：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。

八个特性拿报修模块的一条需求来检验："系统应快速派单"。无二义性：快速是多快？不合格。可测试性：没有数字没法测。改成"客服提交工单后系统在 10 秒内推荐维修工"，八个特性就过了大半。可跟踪性是说这条需求要能追到业务需求"24 小时解决率九成"和后面的设计、测试用例，2015 年下半年第 64 题考过需求跟踪的方向：从设计、代码、测试用例回查是否都能在需求规格说明书中找到出处，叫逆向跟踪。第 31 讲范围管理会讲需求跟踪矩阵，那是把这八个特性里的可跟踪性做成一张表。

四、核心内容精讲：结构化分析与面向对象分析

4.1 结构化分析三模型

教材口径：使用结构化分析方法进行需求分析，其建立的模型的核心是数据字典。围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。在实际工作中，一般使用实体关系图表示数据模型，用数据流图表示功能模型，用状态转换图表示行为模型。

三图三模型的对应是这一节的高频考点：2019 年下半年第 7 题问功能模型和行为模型分别用什么表示，答案是数据流图、状态转换图；2020 年下半年第 8 题问实体联系图表示什么模型，答案是数据模型；2022 年上半年第 9 题问结构化分析不使用的工具，答案是业务流程图，因为三个工具是实体关系图、数据流图、状态转换图。2016 年上半年第 12 题考数据流图的四个组成部分：数据流、加工、数据存储和外部实体。

三图各一句：实体关系图主要描述实体、属性，以及实体之间的关系；数据流图从数据传递和加工的角度，通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况；状态转换图通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为。

报修模块用结构化分析画三张图：实体关系图里有业主、房产、工单、维修工四个实体，业主拥有房产、房产产生工单、工单指派给维修工；数据流图里外部实体是业主和维修工，加工是受理、派单、维修、回访，数据存储是工单库和业主库；状态转换图里工单有待派单、已派单、维修中、待回访、已关闭五个状态，事件是提交、派单、到场、完成、确认。数据字典把这三张图里每个数据项的名字、类型、长度、取值定清楚，比如"报修位置"是"楼栋加单元加房号，必填"，这一条就堵住了第 12 讲位置字段为空的问题。

4.2 面向对象分析：用例模型四阶段

教材口径：面向对象的分析的基本任务是运用面向对象的方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。面向对象分析模型独立于具体实现，这也是它和面向对象设计的区别所在：分析的任务是"做什么"，设计的任务是"怎么做"。面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。

教材在这里对比了结构化分析的两个缺点：一是"很容易混淆需求和设计的界限"，描述里已经包含了部分设计；二是"分割了各项系统功能的应用环境"，从功能项入手很难了解它们如何相互关联。用例方法的基本思想是站在用户角度：用户"并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务"。

教材口径：构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必须的。

识别参与者。参与者是与系统交互的所有事物，"该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟"，并且"参与者一定在系统之外，不是系统的一部分"。教材给了九个找参与者的问题：谁使用、谁安装、谁启动、谁维护、谁关闭、哪些其他系统使用、谁从这个系统获取信息、谁为这个系统提供信息、是否有事情自动在预计的时间发生。报修模块按这九问找：业主、客服、维修工、李经理使用；张主管维护；门禁系统和主数据服务是"其他系统"；"每晚零点自动汇总工单"说明系统时钟也是参与者。

合并需求获得用例。三步：把获取到的需求分配给相关的参与者，明确为什么合并再合并，把参与者和用例用用例图整理出来得到用例模型的框架。

细化用例描述。教材有一句很多人不知道的话：用例建模的主要工作是书写用例规约，而不是画图。用例规约的内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括非功能需求和用例优先级。方姐团队画了一张用例图就交差，问题就在这里，图只是框架，规约才是开发依据。

调整用例模型。利用用例之间的关系抽取公共信息便于复用，下一节讲。

4.3 用例之间的三种关系与分析模型

教材口径：用例之间的关系主要有包含、扩展和泛化。

2017 年上半年第 27 题给了一张图，取款要先识别客户、验证账号，问是什么关系，答案是包含。2019 年上半年第 25 题问执行者与用例之间的关系，答案是关联关系，参与者和用例之间是关联，用例和用例之间才是包含、扩展、泛化，这两类关系不要混。

分析模型。教材口径：分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）。起点是领域模型，又称为概念模型或域模型，"也就是找到那些代表事物与概念的对象，即概念类"。每一个用例对应一个类图，用例的实现主要通过交互图来表示，用例的事件流会对应产生一个顺序图。建立分析模型的过程包括定义概念类、确定类之间的关系、为类添加职责、建立交互图，前三个步骤统称为类-责任-协作者建模。

类之间的关系六种：关联、依赖、泛化、聚合、组合和实现。其中聚合和组合最容易考：2016 年上半年第 26 题说需求描述中的"包含""组成""分为部分"等词意味着什么关系，答案是聚集。聚合和组合的区别，教材的说法是聚合的"部分"可能同时属于多个"整体"、生命周期可以不相同，比如车子坏了车轮还可以用；组合的"部分"只能属于一个"整体"，随整体的创建而创建、随整体的消亡而消亡，比如公司倒闭了部门也就没有了。报修模块里，工单和工单里的图片是组合，工单删了图片没意义；小区和维修工是聚合，维修工可以调到别的小区。

五、核心内容精讲：统一建模语言

5.1 结构、事物、关系

教材口径：统一建模语言是一种定义良好、易于表达、功能强大且普遍适用的建模语言，它的作用域不限于支持面向对象分析和面向对象设计，还支持从需求分析开始的软件开发的全过程。从总体上来看，它的结构包括构造块、规则和公共机制三个部分。

三部分各一句：构造块有三种基本的，事物、关系和图，事物是重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合；规则是构造块如何放在一起的规定，包括命名、范围、可见性、完整性、执行；公共机制主要包括规格说明、修饰、公共分类和扩展机制四种。

UML 是什么、不是什么，是最老也最稳的考点。教材第 5 章课后练习第 2 题问描述不正确的，错误项是"行为事物是模型中的静态部分"，行为事物是动态部分；其他三项，适用于各种软件开发方法、适用于软件生命周期的各个阶段、不是编程语言，都对。2016 年下半年第 26 题、2017 年上半年第 26 题、2018 年上半年第 26 题反复考这几句，错误选项换来换去："是一种编程语言""不适用于迭代式的开发过程""是一种可视化编程语言"，都错。记住三句：它是建模语言不是编程语言，它适用于各种开发方法，它适用于生命周期各阶段。

事物四类。教材口径：事物也称为建模元素，包括结构事物、行为事物、分组事物和注释事物。结构事物在模型中属于最静态的部分，有七种：类、接口、协作、用例、活动类、构件和节点；行为事物是模型中的动态部分，两种主要的，交互和状态机；分组事物只有一种，称为包，"包纯粹是一种概念上的事物，只存在于开发阶段，而构件可以存在于系统运行阶段"；注释事物是模型的解释部分。

关系四种。教材口径：主要有四种关系：依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义；关联描述一组对象之间连接的结构关系；泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象；实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。四种关系的记法：依赖是"我用你"，关联是"我连你"，泛化是"我是你的一种"，实现是"我照你的合同干"。

5.2 十四种图总览与五个视图

教材口径：UML 2.0 包括 14 种图。我把它们按静态和动态分两组列出，逐图的画法和考法第 18、19 讲：

四种交互图是常考点：顺序图、通信图、定时图、交互概览图。2017 年下半年第 26 题问哪个属于交互图，选项里类图、状态图、对象图都不是，答案是定时图。2018 年上半年第 27 题问哪个不是 UML 图，答案是"继承图"，没有这种图。2015 年下半年第 26 题和 2016 年上半年第 27 题都问"从用户角度描述系统功能、理解需求"的是哪个图，答案是用例图。2015 年下半年第 27 题和 2018 年下半年第 27 题考状态图，"描述一个特定对象的可能状态以及由于各种事件的发生而引起的状态之间转移"。

五个视图。教材口径：UML 对系统架构的定义是系统的组织结构，包括 5 个系统视图：逻辑视图也称为设计视图，表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集；进程视图是可执行线程和进程作为活动类的建模，是逻辑视图的一次执行实例，描述了并发与同步结构；实现视图对组成基于系统的物理代码的文件和构件进行建模；部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构；用例视图是最基本的需求分析模型。2017 年下半年第 27 题直接问"又称为设计视图"的是哪个，答案是逻辑视图。

教材最后一句也值得记：它"允许在一定的阶段隐藏模型的某些元素，遗漏某些元素，可不保证模型的完整性，但模型逐步地要达到完整和一致"。需求阶段的图可以不完整，这是允许的。

六、核心内容精讲：智慧邻里2.0 报修模块需求文档

6.1 从五种诉求到一份文档

把本讲内容装配成方姐要的那份需求文档，按需求规格说明书的骨架走：

范围。 报修模块覆盖业主报修、客服受理派单、维修工执行、回访关闭四段，不含门禁联动（三期）。

引用文件。 集团数据标准（第 12 讲）、服务级别协议（第 11 讲）、架构说明书（第 16 讲）。

需求。 先给需求分层表：

再给用例模型：以本次报修系统为边界，已明确外部交互的参与者为业主、客服、维修工、李经理和主数据服务五类；张主管若只参加需求评审，不因此成为运行时参与者，内部定时器也不能直接当作外部参与者。八个业务用例为，提交报修、催单、受理、派单、转外包派单（扩展派单）、查看现场图片、回访关闭、查看工单统计，"验证业主身份"作为被包含的抽象用例。每个用例一份规约，写用例名、参与者、目标、前置条件、基本事件流、扩展事件流、后置条件。"派单"的基本事件流：客服打开待派单工单，系统按位置和技能推荐三名维修工，客服选一名确认，系统通知维修工并把工单状态改为已派单；扩展事件流：推荐列表为空时转外包派单。

分析模型给一张领域类图：业主、房产、小区、工单、图片、维修工、外包单位七个概念类，工单和图片是组合，小区和维修工是聚合，工单关联业主和维修工。再给"派单"的顺序图，客服、派单服务、主数据服务、维修工四个对象的消息时序。

合格性规定。 每条系统需求配验收方法，10 秒推荐用系统测试计时，图片限制用边界值测试。

需求可追踪性。 一张表，每条用户需求追到业务需求，每条系统需求追到用户需求，为第 31 讲的需求跟踪矩阵打底。

尚未解决的问题。 门禁联动的接口方式待三期确定；催单次数上限待业委会确认。

这份文档交给方姐，她的团队照着开发；交给李经理，她能看到自己的目标在第一行；交给张主管，他能看到自己提的联动在"尚未解决"里没被忘。

6.2 需求文档和项目管理的关系

需求规格说明书在项目管理里的位置有三处。第 31 讲范围管理的"收集需求"过程，输出是需求文件和需求跟踪矩阵，本讲的需求分层表和可追踪性表就是它们的技术版本。第 41 讲质量管理，合格性规定就是质量测量指标。第 59 讲配置管理，需求规格说明书通过评审后建立需求基线，2016 年下半年第 65 题考过"在需求分析规格说明书通过同行评审后建立需求基线"，这是对的做法。

6.3 需求分析与建模自测

以下六道为依据教材第5章相关概念改编的原创练习，不冒充历年真题。限时8分钟，先作答再看解析，每题选择一项，并用一句话说明理由。

练习1。 物业提出“希望把报修24小时解决率从七成提高到九成”，这句话最直接属于哪一层需求？

甲：业务需求；乙：用户需求；丙：数据表设计；丁：接口设计。

练习2。 客服提出“我要查看待派单工单并完成派单”。分析这句话时，最合适的做法是什么？

甲：因为客服不是领导，所以不记录；乙：识别为用户任务，再细化系统行为与约束；丙：直接确定数据库表；丁：把它当作已验证的业务收益。

练习3。 要描述报修数据从业主提交，经受理加工，再进入工单存储的流转，应优先使用哪种结构化分析工具？

甲：实体关系图；乙：数据流图；丙：部署图；丁：组织结构图。

练习4。 在约定的业务规则中，每次提交报修都必须验证业主身份；只有超时未处理时才允许业主发起催办。对“提交报修”与“验证身份”，以及“催办”与正常处理的补充行为，最恰当的判断是什么？

甲：两个都是继承；乙：前者可建包含，后者在明确扩展点和条件后可建扩展；丙：两个都是部署；丁：参与者与用例之间也是包含。

练习5。 张主管参加了需求评审，但系统运行时不与系统直接交互。仅凭这个事实，他是否必然是用例参与者？

甲：是，所有干系人都是参与者；乙：是，职位高就是参与者；丙：否，要看所选系统边界外是否存在与系统的实际交互角色；丁：否，参与者只能是自然人。

练习6。 王主任要知道工单从“待受理”到“已派单”“处理中”“已关闭”如何随事件转换，优先用哪种图？

甲：状态图；乙：包图；丙：类图；丁：部署图。

答案与解析。 练习1选甲，描述的是组织期望达到的目标，九成是教学目标而非已有成效。练习2选乙，需求层次取决于内容而非职位，用户任务还需落成可验证的系统需求。练习3选乙，数据流图描述数据传递与加工；实体关系图侧重实体及关系。练习4选乙，包含表达必需复用行为，扩展需要条件和扩展点；不能把所有流程先后都画成包含，也不能把参与者关联画成用例包含。练习5选丙，干系人与参与者范围不同，外部系统也可能是参与者。练习6选甲，题目关注特定对象的状态与触发事件；若关注跨角色业务步骤可选活动图，若关注对象消息先后可选顺序图。

七、考点锚定

本讲对应教材第 4 版 5.1.2 节需求分析。2023 年以后的综合知识没有直接命中本节，可查证的历年真题落点如下：

本讲考法总结，五句话：

1. 需求三层次业务用户系统，从目标到具体；质量功能部署三类常规期望意外；需求过程四步获取分析编制验证。
2. 获取五方法访谈问卷采样情节串联板联合需求计划；好需求八特性无二义完整一致可测试确定可跟踪正确必要；需求规格说明书模板出自 GB/T 8567，八部分范围引用文件需求合格性规定可追踪性未解决问题注解附录。
3. 结构化分析核心是数据字典，三模型数据功能行为对应实体关系图数据流图状态转换图；数据流图四组成数据流加工数据存储外部实体。
4. 面向对象分析做什么设计怎么做；用例模型四阶段识别参与者合并需求获得用例细化用例描述调整用例模型，前三必须；主要工作是写规约不是画图；用例三关系包含扩展泛化，参与者与用例是关联；类关系六种，聚合部分可共享组合部分同生死。
5. UML 结构三部分构造块规则公共机制；事物四类结构七种行为两种分组一种注释；关系四种依赖关联泛化实现；十四种图，交互图四种顺序通信定时交互概览；五视图逻辑进程实现部署用例，逻辑视图又称设计视图，用例视图是最基本的需求分析模型。

八、论文跨界一段

需求分析在论文里最适合放进范围管理，说明"需求怎么从模糊到清晰"。如果论文题是"论信息系统项目的范围管理"，可以这样接：

本项目在收集需求阶段面对的最大困难是干系人诉求分散且相互矛盾：物业总经理关注解决率指标，客服要求一键派单，维修工要求移动端查看现场图片，业主要求催单功能。我组织团队按业务需求、用户需求、系统需求三个层次对诉求分层，以"报修 24 小时解决率提升至九成"这一业务需求为标尺评估各项用户需求的优先级，将门禁联动等间接支撑的需求纳入后续阶段。需求分析采用面向对象方法建立用例模型，识别出五类外部交互参与者、八个业务用例，并另列一个复用的身份验证用例，为每个用例编写含前置条件、基本事件流、扩展事件流和后置条件的用例规约，并按国家标准的需求规格说明书模板形成文档，经需求评审确认后建立需求基线。这使范围定义有了可追踪、可测试的依据，范围与测试有了共同检查依据。此处为虚构教学示例，真实论文不能套用未经本人记录核实的变更减少比例。

一段话，把需求三层次、用例模型四阶段、需求规格说明书模板、需求评审和基线变成了范围管理的具体动作。第 31、32 讲范围管理会把这段接下去。

九、课后作业

第 1 题，联系生活（对应需求三层次与质量功能部署）。 想一个你最近想买的东西，比如一台新手机。写出你的业务需求（你到底要解决什么问题）、用户需求（你要用它完成哪些任务）、系统需求（你对参数的具体要求），再按常规、期望、意外各写一条需求。

第 2 题，案例思考（对应用例模型与类关系）。 完整题面：教学设定中，访客预约后，由业主确认，物业审核高风险来访；门禁在预约有效期内核验通行码，超过有效期拒绝通行；业主可撤销未使用的预约，门禁向系统回传通行结果，外部通知服务发送确认消息。以“访客预约系统”为边界，限时15分钟，列出至少五类实际交互角色和六项用户目标；对可复用的核验行为与有条件的补充行为各给一个候选关系并写出成立条件。再列出预约、访客、业主、通行记录等概念及关联。只有题设支持整体与部分的独立性或生命周期约束时才使用聚合、组合，证据不足可以只画关联并说明待确认项。回传参与者清单、用例清单及关系说明。

第 3 题，高级项目经理视角（核心作业，下一讲讲评）。 需求评审会上，业委会王主任看着用例图说："这图我看得懂，谁能干什么一目了然。但我想知道业主报修以后到底经历了什么，等多久、卡在哪，这张图看不出来。"方姐说可以再画几张图。请你回答：王主任要的信息该用统一建模语言的哪几种图表达，各表达什么；这几张图分别是静态的还是动态的；如果只能画一张给业委会看，你选哪张、为什么。提示：下一讲开始讲十四种图怎么画，你先用本讲 5.2 节那张表里"教材一句话"那列想。

十、老孙总结与下讲预告

三个心智模型：

模型一：需求应可追到业务目标、法规合同或其他明确依据。 考点是三层次、三类需求、八特性、需求过程四步。高项认知是用业务需求当尺子量用户需求，同时核对法规、合同与安全约束。

模型二：需求分析是建模，两条路各三样东西。 考点是结构化分析的数据字典加三模型三图、面向对象分析的用例模型加分析模型、用例四阶段三关系、类六关系。高项认知是用例建模的主要工作是写规约不是画图。

模型三：统一建模语言是沟通工具，先记骨架再学画图。 考点是结构三部分、事物四类、关系四种、十四种图和四种交互图、五个视图。高项认知是需求阶段的图可以不完整，但要逐步完整一致。

下讲预告： 第 18 讲《【重要考点】UML 图实战（上）》。今天作业里王主任要的"业主报修以后经历了什么"，答案是动态图。下一讲重点讲用例图、类图、对象图和包图；开头仍会讲评本讲的核心作业，先说明活动图、顺序图、状态图各能回答什么，具体动态图的画法在第19讲继续。

文中的下讲预告对应原课程内容顺序，专题公开日期另行安排。

#高项 #信息系统项目管理师 #软考