用例图用例命名与粒度：一个用例写多大才合理？
从“目标导向命名”到“粒度拆分边界”，用一套可执行的检查清单，帮你把用例图写得清晰、可评审、可落地。
很多用例图画到一半会“变形”：
- 用例名字像功能列表（“新增/删除/修改/查询”），但看不出用户目标
- 一个用例塞进十几个步骤，评审时争论不休
- 颗粒太碎：同一张图里一堆小圆圈，阅读成本爆炸
- 颗粒太粗：只剩“管理XX”，细节全靠口头补充
本质上是两件事没定清楚：用例怎么命名，以及一个用例的粒度（范围）该多大。
下面给你一套可直接拿去评审/落图的规则。
1. 先统一一个前提：用例图表达的是“目标”，不是“按钮”
用例（Use Case）更接近“某个参与者为了达成一个业务目标，与系统交互并获得结果”的描述。
- “按钮/页面/接口”属于实现层
- “目标/结果/价值”属于用例层
所以命名和粒度判断，都应该围绕 “是否能说清楚：谁，为了什么，得到什么结果”。
2. 用例命名：用“动词 + 业务对象 + 结果（可选）”
推荐的命名模板：
动词（完成某事） + 业务对象（谁/什么） + 结果/约束（可选）
例子（更像用例）：
- 提交报销申请
- 审批报销申请
- 查询报销进度
- 导出报销明细（按月份）
不推荐（更像功能点/技术点）：
- 报销新增/删除/修改/查询
- 报销管理
- 报销接口调用
- 报销页面
2.1 什么时候可以用“管理XX”？
只有当你在这张图的目标就是概览一个后台模块，并且读者默认接受“管理”包含多个子目标时，才勉强可用。
更稳妥的做法：把“管理XX”拆成 2~5 个主要目标型用例，比如：
- 创建商品
- 上架商品
- 调整库存
- 维护价格
- 查看商品表现
读者一眼能明白系统能做什么，而不是猜“管理”到底包含哪些动作。
2.2 避免“CRUD四连”的写法
如果你发现一张图里密密麻麻都是：新增/删除/修改/查询，通常意味着你在画“数据库表的维护”，而不是“用户目标”。
替代思路：把动作收敛到“业务关键动作”。
举例：
- 会员信息维护（过粗）
- 修改会员联系方式（过细）
更常用的颗粒：
- 维护会员资料（可以）
- 重置会员登录方式（可以）
关键是：评审时能对齐：为什么要做、做完的判定是什么。
3. 粒度判断的核心：一个用例要能“闭环”
判断一个用例是否“够大/太大”，最实用的标准是 闭环：
- 有明确的开始条件（触发点）
- 有明确的结束条件（成功结果/失败结果）
- 对参与者有可感知的价值
如果一个“用例”结束时，参与者还得再做一堆步骤才能得到结果，那它可能太碎； 如果一个“用例”内部包含多个独立目标，那它可能太粗。
3.1 用“成功判定”来测粒度
给你的用例补一句“成功的标准是什么”。
- 提交报销申请：成功 = 申请进入“待审批”，申请单号生成
- 审批报销申请：成功 = 状态变为“已批准/已拒绝”，并记录审批意见
- 生成月度报表：成功 = 报表生成并可下载/可查看
如果你很难写出成功判定，说明用例边界没想清楚。
4. 什么时候拆分：用 4 条“拆分信号”
出现以下任一信号，考虑拆分：
- 一个用例里有多个不同的参与者目标
- 例如“处理订单”同时包含“买家下单”“商家发货”“财务对账”，目标不同，应拆。
- 分支路径相互独立且复杂
- 例如“申请请假”里包含“病假/年假/事假/加班调休”，且规则差异大，可以拆成“申请病假/申请年假…”，或把规则放到扩展流程（extend）。
- 可复用的子目标反复出现
- 例如多个用例都需要“验证身份”“生成验证码”“校验库存”。这种更适合抽成被包含用例（include）。
- 用例名开始变成“并且/同时/以及”
- 名称里出现“并且”，往往意味着多个目标被塞进一个圆。
拆分后，你的图会更易读：主用例保留主目标，细节通过 include/extend 表达。
5. 什么时候合并：用 3 条“合并信号”
相反，如果出现以下情况，考虑合并：
- 用例之间只是界面入口不同，但目标相同
- 例如“从订单页取消订单”和“从消息里取消订单”，本质是同一目标。
- 用例之间差异只在少量参数
- 例如“导出日报/导出周报/导出月报”，可合并为“导出报表”，把时间范围做成条件。
- 图面过于拥挤，读者要放大才能读
- 这不是美观问题，是信息结构问题。先合并同类项，再用分组/包（package）或分图呈现。
6. 用 include / extend 控制“主线”与“可选项”
当粒度拿不准时，常见的做法是把“主线”稳住，再把可选项挂出去。
- include：主用例执行时“必然会发生”的子用例（复用）
- 例：提交报销申请 include 校验申请信息
- extend：在特定条件下“可能发生”的扩展
- 例：提交报销申请 extend 补充附件（当金额超过阈值）
这能让你的主用例保持目标闭环，而不会被细节拖垮。
如果你想快速把一套需求转换成“主用例 + include/extend”的结构，可以直接用这个生成器把需求文本转成草稿，然后你再按项目规则微调：
也可以在团队评审前，把你现有用例清单粘进去，让它按“目标命名模板”帮你做一次改写建议：
7. 评审清单：5 分钟快速过一遍
把下面清单打印出来贴在评审会议上会很有用：
- 用例名是否以“目标”命名，而不是页面/按钮/接口？
- 是否能为每个用例写出一句“成功判定”？
- 一个用例是否只服务一个主要参与者目标？
- 重复出现的步骤是否用 include 抽取？可选分支是否用 extend 表达？
- 这张图是否仍然可读（不靠放大、不靠口头补充才能理解）？
8. 一个快速示例：把“订单管理”改成可落地的用例
原始（过粗）：
- 订单管理
改写（更清晰）：
- 买家下单
- 买家支付订单
- 买家取消订单（extend：超时自动取消）
- 商家发货
- 买家确认收货
- 买家申请退款（include：提交退货信息；extend：上传凭证）
用例图不需要把每个字段、每个按钮都画出来；它要做的是让所有人对齐“我们到底要让用户完成什么”。
如果你正在卡在“粒度到底该怎么拆”的问题上，可以先按本文的拆分/合并信号过一遍，然后用一句话写出每个用例的成功判定。做完这两步，80% 的粒度争议会自然消失。