Tfifthe1. 为什么你需要用例图？
刚接手一个新项目时，最头疼的就是需求模糊不清。产品经理说"我们要做个电商平台"，开发团队问"具体要哪些功能"，得到的回答往往是"就和淘宝差不多"。这时候，用例图就像是一把手术刀，能精准地解剖出系统的核心功能和用户交互。
我去年负责过一个社区团购项目，最初的需求文档只有三页PPT。通过和业务方反复沟通，我们用一周时间画出了完整的用例图，不仅明确了"团长管理"、"商品上下架"、"订单核销"等23个核心功能，还发现了5个被遗漏的重要场景。这份可视化文档后来成为整个项目的需求基准。
用例图之所以被称为"对话蓝图"，是因为它能：
- 可视化用户与系统的对话流程
- 标准化不同角色对需求的理解
- 结构化碎片化的功能需求
- 验证需求是否完整覆盖业务场景
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 用例图核心三要素详解
2.1 参与者（Actor）：谁在和系统对话？
参与者不一定是人。我做过一个物流系统，主要的参与者包括：
- 快递员（人类用户）
- 第三方地图API（外部系统）
- 智能快递柜（物联网设备）
识别参与者时要注意：
- 角色而非职位：用"购物者"而不是"张三"
- 外部性：财务系统的"银行接口"算参与者，但"支付模块"不算
- 主次区分：核心用户标实线，次要用户标虚线
plantuml复制@startuml
left to right direction
actor 顾客 as C
actor 银行系统 as B #LightGray
@enduml
2.2 用例（Use Case）：系统能做什么？
好的用例命名应该是"动词+宾语"结构。比如：
- ✔️ "提交订单"（不要写成"订单提交"）
- ✔️ "查询物流"（避免"物流查询"）
常见错误：
- 把功能点拆得太细："点击按钮"这种不算用例
- 混淆业务目标和技术实现："调用API"是实现细节
我习惯给每个用例加备注说明：
code复制用例：团长审核
触发条件：新团长提交申请
前置条件：用户具有管理员权限
基本流程：
1. 系统显示待审核列表
2. 管理员查看资料
3. 通过/驳回申请
异常流程：
- 资料不全时提示补充