CBAP50技术手册】#47 Use Cases & Scenarios（用例与场景）：BA（业务分析师）让需求“活起来”的剧本写作术

把需求演绎成系统与用户的真实互动剧本。

在一次项目需求评审会上，开发组沉默不语，业务方焦躁不安。写在文档里的需求，似乎谁都“看懂了”，但又好像“谁都没真正理解”。

直到我用一组 Use Cases & Scenarios 把冷冰冰的需求变成了一场场“用户剧本”，大家才终于“看见”了系统该如何运作，沟通顿时顺畅了。

Use Cases 和 Scenarios，就像是 BA 的“剧作笔”——把抽象需求，演绎成生动细节。

---

什么是 Use Cases & Scenarios？

不是 PPT 上那句“用户能登录系统”，也不是一句“管理员可以导出数据”就完事。

Use Cases 是：

• 从用户角度出发，描述系统如何支持他们完成某项任务
• 包括各方参与者、交互流程、触发条件、主线流程与异常流程
• 是功能需求的“行为剧本”

Scenarios 是：

• Use Case 的具体化版本
• 用真实语境和具体数据，展示某一个用户如何使用系统
• 通常包含具体输入、操作、结果和期望体验

Use Case 是“这一类事情怎么发生”，Scenario 是“某一天它是怎么发生的”。

---

我常用的 Use Case 模板

• Use Case 名称：如“用户提交订单”
• 参与者：用户、管理员、系统接口等
• 前置条件：如“用户已登录”
• 触发事件：点击“提交订单”按钮
• 主成功路径：系统验证库存 → 创建订单 → 发出确认邮件
• 扩展流程：如支付失败、库存不足、用户取消
• 后置条件：订单状态变更为“已创建”

Scenarios 示例：

• 张三登录后，把两件商品加入购物车，使用优惠券结账，系统提示“库存不足”，他删除一件后完成支付，订单号：#ORD1234。

---

我的 Use Cases & Scenarios 编写流程

1. 明确目标功能 用一句话描述：系统应该支持用户完成什么任务？
2. 识别所有角色 不只是“用户”，还可能有后台管理者、外部系统接口等。
3. 绘制交互流程 用活动图或流程图理清事件顺序，有助于发现遗漏路径。
4. 编写主线用例 聚焦“正常流程”，描述步骤清晰、语义准确。
5. 补充例外流程 各种“万一”都要想清楚，比如中断、失败、取消等。
6. 添加具体 Scenarios 以“一个用户的一次操作”视角，具体化流程，贴近真实语境。
7. 评审 & 验证 和开发、测试一起审视每条路径，验证是否可实现、是否可测试。

---

一个真实案例

在一次 HR 系统优化项目中，有个需求是“员工可以在线申请年假”。

初版需求很模糊，开发问：“到底怎么算余额？”

测试问：“如果申请的是节假日怎么办？”

业务说：“这个流程我们原来是线下审批的。”

我编写了 Use Case：

• 名称：员工申请年假
• 主路径：选择时间段 → 检查假期余额 → 提交申请 → 上级审批 → 通知人事
• 扩展流程：余额不足、选择非法日期、审批被拒绝

然后补了两个 Scenarios：

• 王丽申请 6 月 3-5 日年假，系统发现 6 月 5 日为端午节，提示“节假日不可申请”
• 李强申请 8 月 15-19 日年假，系统验证通过，自动发送审批通知给其主管

结果？开发知道该怎么做了，测试知道测试什么了，业务也“看见”了系统行为，沟通效率暴涨。

---

Use Cases & Scenarios 的价值

• 还原用户视角：不是功能堆砌，而是真正站在“怎么用”的角度
• 澄清业务流程：很多“你以为”的假设，都会在编写中暴露出来
• 桥接设计与开发：让设计、开发、测试都能围绕具体行为讨论
• 提前暴露边界问题：异常路径、角色权限、数据问题都能提前识别
• 增强可测试性：每一个 Scenario 都是天然的测试用例模板

---

我的经验建议

• 一口气写主路径，再补异常流程：避免流程混乱，层层加细节
• 把“用例”写给用户看，而不是写给系统看：用自然语言、用户视角
• 每个流程后都问一句“如果失败了呢？”
• Scenario 要“具体到人”：用具体人物、数据、动作构建故事，有画面感
• 善用模板 + 图示结合：让文档“有读者”，而不是“摆设”

---

最后的共勉

我们 BA 不是写代码的，但我们写的 Use Cases & Scenarios，

就是开发的“剧本”，测试的“脚本”，业务的“蓝本”。

用精致的剧本，带领整个团队看清未来该如何运作。

这是 BA 的剧作能力，也是沟通能力的巅峰体现。