掌握系统功能用例图：5步轻松绘制出清晰的软件蓝图

很多用例图“看起来像 UML”，却无法真正帮助需求评审：角色画了十几个，椭圆塞满页面，include 和 extend 也都用上了，但没人能回答“谁在什么边界内完成了什么目标”。我在整理软件需求时反复遇到同一个问题：图画得越复杂，沟通成本反而越高。系统功能用例图真正要做的，不是展示功能数量，而是把需求中的角色、目标和责任边界压缩成一张可讨论的软件蓝图。本文将用 5 步方法，从一段自然语言需求开始，完成一张结构清晰、可评审、可继续拆解的系统功能用例图。

一、先讲核心结论：用例图不是“功能清单”，而是“交互边界图”

1. 一张合格的用例图必须回答三个问题

第一，谁会与系统发生交互；第二，这些角色希望通过系统完成什么目标；第三，哪些能力属于当前系统，哪些能力来自外部服务。只要这三个问题没有回答清楚，即使图形符号完全正确，用例图仍然缺乏实际价值。

我通常不会在打开绘图工具后立刻拖拽图形，而是先把需求文字拆成三张清单：参与者清单、用户目标清单和系统边界清单。这个顺序看似慢，实际上能减少后续反复改图的次数。尤其是在多人评审时，返工往往不是因为线条没对齐，而是因为大家对“谁负责什么”没有形成共同理解。

我的判断标准是：如果拿掉图形，只看参与者和用例名称，读者仍然能够复述系统主要职责，这张图才算画到了核心。

2. 用例图和其他软件图的区别

最常见的误解，是把“系统功能用例图”理解成“系统功能结构图”。功能结构图可以把“订单管理”作为一个模块，但用例图需要进一步问：用户是查询订单、取消订单，还是修改收货地址？管理员是审核退款，还是导出订单报表？模块是组织方式，用户目标才是用例的核心。

3. 先建立“最小可用用例图”

如果系统刚刚立项，需求还在变化，我建议先画最小可用版本，而不是一次性覆盖所有异常情况。最小可用用例图只保留核心参与者、核心用户目标和关键外部系统，目标是让产品、研发、测试和业务方先确认范围。

例如，一个校园报修系统的第一版总览图，可以只保留“学生、维修人员、管理员、消息通知服务”四类参与者，以及“提交报修申请、查询报修进度、分派维修工单、更新维修状态、发送维修通知”五个核心用例。权限细节、异常处理和字段校验可以在后续需求文档中展开。

二、绘制前先做需求清洗：不要把原始文字直接搬进图里

1. 从动词中识别用户目标

需求原文通常不是用例名称。它可能写成“系统提供报修管理功能”“后台支持订单管理”“用户可以进行账户操作”。这些说法对开发范围有帮助，但对用例图来说太宽泛。

我会先圈出需求中的动词，再判断这个动作是否代表一个相对完整的用户目标。比如“查看”“提交”“审核”“分派”“导出”“支付”“取消”“修改”通常比“管理”“处理”“维护”更容易形成清晰用例。

一个实用检查方法是“完成句测试”：把角色名称放在前面，再读一遍用例。例如“学生可以提交报修申请”很自然，“学生可以报修模块”就说明命名仍然停留在模块层级。

2. 区分参与者、部门和具体人员

参与者不是“谁在组织架构里存在”，而是“谁以某种角色与系统交互”。同一个人可能同时扮演多个参与者角色。例如，维修主管既可以作为“维修人员”更新工单，也可以作为“管理员”分派任务。用例图关注的是交互角色，不是员工花名册。

外部系统同样可以成为参与者。支付平台、统一身份认证服务、短信服务、物流接口等，只要位于当前系统边界之外，并与系统发生交互，就可以被表示为参与者。把这些外部系统错误地画进系统内部，会让责任边界变得模糊。

3. 判断一个功能是否值得单独成为用例

我通常使用三个问题判断用例粒度。第一，是否存在一个明确的发起者；第二，是否能形成一个对发起者有价值的结果；第三，是否能被单独讨论、测试或验收。

“填写手机号”一般不是独立用例，因为它只是完成注册过程中的一个步骤；“提交报修申请”则通常可以单独成为用例，因为它有明确发起者，也会产生一张可查询的报修记录。

三、5步绘制系统功能用例图

1. 第一步：确定系统主题和边界

先写清楚“这张图描述的系统是什么”。系统名称最好具体到一个可以被评审的范围，例如“校园报修系统”“电商订单管理系统”“企业费用审批系统”，而不是笼统地写“信息管理平台”。名称越宽泛，后续参与者和用例越容易失控。

确定名称后，用一个矩形表示系统边界。矩形内部放置由当前系统提供的用例，矩形外部放置用户和外部系统。系统边界不是装饰，而是责任声明：边界内的能力由当前系统负责，边界外的对象只是使用、触发或支撑这些能力。

2. 第二步：找出参与者

可以从需求文档中的角色名、岗位名和外部服务名开始。常见参与者包括普通用户、审核人员、运营人员、系统管理员、支付平台、认证服务和消息服务。

但不要机械地把所有部门都画成参与者。部门只有在以某种角色直接登录、调用或接收系统结果时，才适合作为参与者。比如“财务部”可能过于宽泛，而“财务审核员”更能表达实际交互角色。

3. 第三步：提炼核心用例

将每个核心用户目标画成椭圆，并统一采用动宾短语命名。命名最好控制在较短范围内，避免把业务规则、字段条件和异常处理全部塞进椭圆。

一张总览图不需要展现每个按钮。我的经验是，首次绘制时先让每个主要参与者拥有 2 至 5 个核心目标，再根据评审意见拆分细节。若一开始就把“填写地址、上传附件、选择分类、确认提交”全部画成独立用例，图很快会变成操作步骤图。

4. 第四步：连接参与者与用例

先使用最基本的关联线，连接参与者与其可以发起或参与的用例。此时不要急于使用复杂关系。很多初学者认为线条越丰富越专业，实际情况恰恰相反：没有明确语义的箭头越多，评审越难进行。

完成基本关联后，再判断是否存在参与者泛化或用例之间的关系。只有当多个角色共享一组稳定权限，或者某个用例确实复用另一个必需行为时，才值得引入更复杂的 UML 关系。

5. 第五步：整理布局并做一致性检查

最后一步不是简单“美化”，而是对语义进行复核。参与者应尽量放在系统边界外，用例放在边界内；同一类角色可以放在同一侧；核心用例靠近中心，外部服务尽量放在边缘。

我会把图缩小到屏幕的 60% 左右再看一次。如果缩小后仍能判断主要角色和功能，说明层级关系比较清楚。如果只能靠放大和逐条追线才能理解，通常意味着用例数量过多、边界不清或关系没有分组。

6. include、extend 和普通关联线怎么判断

include 适合表达必需发生的复用行为。如果基础用例每次执行都必须调用另一个用例，可以考虑使用 include。例如“提交报修申请”每次都必须“验证用户身份”，但是否把身份验证单独画出来，还要看它是否是当前图需要重点沟通的业务能力。

extend 适合表达带条件的可选扩展。例如“查询报修进度”在用户点击投诉入口时，可能进入“提交服务投诉”。投诉并不是每次查询都发生，因此更接近条件扩展。

需要特别注意，include 和 extend 不是普通流程箭头的替代品。它们描述的是用例语义关系，而不是“先做 A，再做 B”。如果只是想表达先后顺序，应使用活动图、流程图或文字流程说明。

四、完整案例：用校园报修系统走完一遍

1. 先把需求写成可分析的版本

下面是一个用于演示的校园报修系统案例，不代表某所学校的真实系统。系统允许学生提交宿舍设备报修，查看处理进度；管理员接收并分派工单；维修人员更新维修状态；系统通过消息服务发送状态通知。

这段需求看似简单，但已经包含了四类不同性质的对象：学生和维修人员属于业务角色，管理员属于运营角色，消息服务属于外部系统。若不先分类，初学者很容易把“消息服务”画成系统内部模块，或者把“报修记录”错误地画成参与者。

2. 识别参与者和目标

这里有一个值得注意的取舍：我没有把“上传故障照片”立即作为总览图中的核心用例。它可能是提交报修申请中的可选步骤，也可能在某些业务中非常关键。如果照片是验收或责任判定的必要依据，再单独展开；如果只是辅助信息，就留在“提交报修申请”的详细规约中。

3. 判断哪些内容应该留在图外

“报修地点不能为空”“图片大小不能超过 10MB”“维修人员必须在 24 小时内响应”都属于业务规则或非功能要求，不应该直接堆在用例图里。它们可以进入用例规约、验收标准或需求详情。

用例图负责搭建交互骨架，详细规则负责填充骨架。把所有规则塞进一张图，最终得到的不是更完整的需求，而是一张无法阅读的说明书。

4. 复盘这张图是否真的有用

我会从三个方向读图。先从角色看：学生、管理员和维修人员是否都能找到对应目标。再从用例看：每个核心功能是否有明确参与者。最后从边界看：消息通知服务是否仍然位于系统外部，系统本身是否只承担通知触发和业务状态管理。

如果某个用例没有任何参与者关联，要么它是内部实现细节，要么是遗漏了触发者。如果一个参与者连接了十几个互不相关的用例，也要检查是否把“超级角色”或整个部门直接塞进了图里。

五、最容易画错的六类问题，以及我的修正方法

1. 把模块名称当成用例

“用户管理”“订单中心”“数据分析”都是模块或能力集合，不一定是用户目标。遇到这类名称，我会继续追问：具体是谁做什么？完成后得到什么结果？通常可以拆成“新增用户”“停用用户”“查询订单”“导出销售报表”等更明确的用例。

2. 把页面名称当成用例

“登录页”“首页”“工单详情页”描述的是界面，不是用户目标。用户不是为了打开一个页面而使用系统，而是为了认证身份、查询工单或修改工单信息。页面变化很快，用例目标相对稳定，因此需求蓝图应该优先使用后者。

3. 把业务流程的每一步都画成用例

“填写表单，上传附件，点击提交，系统校验，保存记录”是一个流程。若全部画成椭圆，读者会误以为每个动作都是独立用户目标。正确做法是把“提交报修申请”作为主要用例，具体步骤放到活动图或用例规约中。

4. 把外部系统放进系统边界

外部认证服务、支付服务、短信服务通常位于当前系统边界之外。当前系统可以调用它们，但不能把它们的职责伪装成自己的内部功能。边界一旦画错，后续的接口责任、测试范围和项目预算都会受到影响。

5. 滥用 include 和 extend

如果两个用例都与订单有关，并不代表它们之间存在 include。只有当一个用例必然需要另一个独立行为时，才考虑 include；只有当一个可选行为在特定条件下插入基础用例时，才考虑 extend。

6. 一张图承载整个企业系统

当图中出现几十个参与者、上百个椭圆和密集交叉线时，问题通常不是绘图软件不够强，而是视图没有分层。建议采用“一张总览图加多张子图”：总览图负责范围沟通，子图分别展开用户端、管理端、外部服务或某个业务域。

六、把用例图放进真实项目：工具、协作和版本管理怎么选

1. 课程作业和论文场景：优先保证规范与可读性

如果目标是完成课程设计或论文插图，通用流程图工具通常已经足够。重点应放在 UML 符号、系统边界、箭头方向和导出质量上。论文场景建议优先导出 SVG 或高分辨率 PDF，避免放大后文字模糊。

这类场景不需要一开始就购买复杂的企业级平台。对于几十个元素以内的简单系统，清晰的命名和合理布局比版本权限、审批流和多人协作更重要。

2. 小型团队场景：先解决共同编辑问题

产品经理、开发人员和业务人员需要共同讨论时，在线白板或支持多人协作的绘图工具更方便。第一轮可以用草图快速确认参与者和主要目标，第二轮再按照 UML 规范整理为正式版本。

需要注意的是，在线白板的自由度越高，越需要人工检查。它可以让团队快速画出结构，但不会自动判断某个对象究竟是参与者、用例还是内部模块。

3. 中大型组织场景：图只是需求基线的一部分

在中大型企业或 100 人以上组织中，用例图很少独立存在。它通常要与需求、任务、测试、变更和版本形成关联。此时我更关注的不是“能不能画出一个椭圆”，而是这张图能否在需求变更后追溯：哪个用例受影响，哪些测试需要调整，谁负责确认。

以 PingCode 这类项目管理平台为例，我会把用例图作为需求基线或设计附件，关联到需求条目、迭代任务和验收标准，而不是让图单独躺在某个文件夹里。PingCode 主要服务中大型企业及 100 人以上组织；在存在数据隔离、合规审查和内部基础设施要求的环境中，私有化部署会成为选型时的重要考量。对于原本使用 Jira 的团队，是否支持平滑迁移，也应纳入字段映射、历史数据、权限模型和工作流迁移的评估。

这里需要把工具能力和建模能力分开看：项目管理平台可以帮助团队保存、协作和追踪需求，但不能替代分析师判断系统边界，也不能自动保证 include、extend 的语义正确。工具解决的是“资产如何被管理”，用例分析解决的是“需求如何被理解”。

4. AI 辅助绘图场景：让 AI 生成草稿，不要直接提交成稿

AI 很适合把一段需求快速转成角色和功能候选清单，也适合提供初步布局。但我不会直接提交 AI 生成的用例图，因为它经常出现三类问题：把页面当成用例，把内部服务当成参与者，以及混淆 include 与 extend 的方向。

更稳妥的方式是先让 AI 输出结构化文本，再由人审查。输入可以要求它分别列出参与者、用户目标、外部系统、业务规则和待确认问题；确认清单后，再将结果导入绘图工具。

请将以下需求拆分为：

系统边界
外部参与者
每个参与者的用户目标
可能的 include 关系及其必需条件
可能的 extend 关系及其触发条件
无法确定、需要业务方确认的内容
不要把页面、按钮、字段校验直接当成独立用例。

我的经验是，AI 最有价值的地方不是“替你画完”，而是帮助你快速发现遗漏角色和模糊需求。最终图仍应由产品、业务和研发共同确认。

七、不同项目阶段的行动建议与取舍

1. 需求还很模糊：先画角色和目标，不急着画关系

如果业务方还在争论系统范围，我会只画系统名称、候选参与者和核心目标，暂时不使用 include、extend，也不展开异常流程。这个阶段最重要的是暴露争议，而不是制造一张看起来完整的图。

取舍在于：图的形式感会弱一些，但更容易推动讨论。过早把细节画得很正式，反而会让参与者误以为需求已经确定，导致后续修改成本上升。

2. 需求范围已确定：补齐关系和用例规约

当角色、系统边界和核心功能已经得到确认，可以进一步补充参与者泛化、用例关系和关键约束。此时每个重要用例最好配套一份简短规约，包括触发条件、前置条件、主要结果和异常情况。

取舍在于：文档完整度提高了，但维护成本也增加。不是所有低风险用例都需要同样详细的规约。高频、高价值、高风险的功能应优先展开，例如支付、审批、权限变更和数据导出。

3. 系统功能很多：采用总览图加子图

当一张图超过 20 至 30 个主要对象时，我会认真考虑拆分。这个数字不是 UML 规范中的硬性限制，而是阅读体验上的经验阈值。实际拆分标准还要看连线密度、标签长度和评审对象。

总览图可以保留主要角色和业务目标，子图再分别展开用户端、管理端、外部服务或某一业务域。这样牺牲了一部分“一图看完”的便利，却换来了更高的可读性和更明确的评审范围。

4. 已进入开发阶段：把用例图和验收标准关联

进入开发后，用例图不应继续作为静态展示材料。每个核心用例都应能找到对应需求、开发任务和测试场景。若某个用例没有验收标准，说明它可能仍然停留在概念层；若某个开发任务找不到对应用户目标，则需要检查是否出现了没有业务依据的技术工作。

在企业环境中，建议为每次重大变更保留版本或评审记录。尤其是系统边界、外部接口和权限角色发生变化时，不要只改图而不留下变更原因。

八、提交或评审前的用例图自检清单

1. 结构检查

• 是否明确写出系统名称和当前图的范围？
• 是否使用系统边界区分内部能力与外部对象？
• 参与者是否位于边界外，用例是否位于边界内？
• 外部认证、支付、消息等服务是否被正确识别？

2. 语义检查

• 每个用例是否表达一个相对完整的用户目标？
• 用例名称是否尽量采用“动词＋目标对象”的形式？
• 是否误把页面、按钮、字段校验或数据库表当成用例？
• 是否把详细流程步骤错误地堆进总览图？

3. 关系检查

• 每个核心用例是否至少能找到一个明确参与者？
• include 是否代表必需的复用行为？
• extend 是否代表有条件的可选扩展？
• 是否为了减少几条线而强行使用泛化关系？
• 箭头方向是否经过 UML 规范或建模工具说明核对？

4. 表达检查

• 缩小图形后，是否仍能看出主要角色和核心功能？
• 是否存在大量交叉线、孤立用例或难以辨认的标签？
• 是否应该将总览图拆成用户端、管理端和外部服务子图？
• 图下是否补充了必要的范围说明和关系解释？

如果时间有限，我建议按照“边界，参与者，核心用例，关系，排版”的顺序检查。不要先花大量时间调整颜色和图标，因为视觉问题通常可以快速修复，语义错误却可能影响整个需求范围。

九、最终行动方案：今天就画出第一版

1. 用 15 分钟完成需求预处理

先从需求文档中复制所有角色、外部服务和动作词，不要打开绘图工具。把重复角色合并，把“管理、处理、维护”这类宽泛词替换成具体目标。此时得到的不是成图，而是一份待确认清单。

2. 用 20 分钟完成最小可用图

画出系统矩形，放入 3 至 5 个主要参与者，再为每个参与者连接 2 至 5 个核心用例。暂时不增加复杂关系，也不展开异常流程。第一版的目标是让业务方在几分钟内看懂系统范围。

3. 用 15 分钟做一次反向阅读

从每个角色出发读图：“这个角色能完成什么？”再从每个用例出发反向检查：“谁会触发它？”最后从系统边界检查：“这个功能真的属于当前系统吗？”三轮阅读后，通常能发现大部分明显问题。

4. 再决定是否引入平台和协作能力

如果只是提交论文，一款支持 UML 符号和高清导出的绘图工具即可；如果需要多人研讨，优先考虑协作体验；如果是中大型企业项目，则需要进一步关注需求追踪、权限、版本、私有化部署和历史迁移。

例如，在使用 PingCode 等项目管理平台时，可以将用例图与需求条目、研发任务、测试用例和变更记录关联起来。对于 100 人以上组织，这种关联比单独保存一张 PNG 图片更有价值。若企业有数据不出域要求，私有化部署需要提前评估基础设施、升级责任和运维成本；若团队从 Jira 迁移，则不能只比较界面，还应核对字段、工作流、权限、历史记录和自动化规则是否能够平滑承接。

5. 保留一个“待确认”区域

真实需求不可能在第一次访谈中全部确定。我建议在图旁边保留待确认事项，例如“消息服务是否属于本系统建设范围”“维修主管是否拥有管理员权限”“提交报修时上传图片是必选还是可选”。

把不确定性显式标出来，比偷偷做出假设更专业。用例图的价值不仅在于表达已经确定的内容，也在于帮助团队看见仍然没有答案的问题。

回到本文的核心观点：系统功能用例图不是把系统画得复杂，而是把系统责任画得清楚。真正高质量的绘制顺序应该是先确认边界，再识别角色；先提炼用户目标，再选择关系；先完成可评审草图，再补充细节和工具协作。

下一步可以直接选取一个你正在做的系统，写下系统名称、三个主要参与者和每个角色的两个目标。不要先追求完整，也不要先研究所有 UML 符号。完成这份最小清单后，再用本文的 5 步方法把它转成第一版用例图，并邀请一个不参与绘图的人复述：谁能做什么、哪些功能属于系统、哪些能力来自外部。对方能否准确复述，才是这张软件蓝图是否清晰的真正检验。