第4章 需求拆解方法：用户故事与用例
需求拆解是将模糊的业务诉求转化为可执行开发任务的关键步骤。未经拆解的需求往往存在边界模糊、粒度不均、验收困难三大问题。本章围绕 Epic → User Story 的纵向拆解链路、用例图的结构化表达以及验收条件的标准化书写，提供可直接套用的方法框架与交付物模板。
4.1 为什么需要需求拆解
在一次电商后台重构项目中，业务方提出“优化支付流程”。该描述过于宏观，开发团队无法评估工作量，测试团队无法设计用例，上线后也无法衡量是否“优化到位”。拆解的核心价值在于：
- 对齐颗粒度：让每个需求单元可在 2–5 日内完成开发与验证。
- 暴露隐含假设：拆解过程中倒逼产品经理澄清边界条件与异常分支。
- 建立验收基线：每个故事都有明确的“完成定义”，避免扯皮。
4.2 Epic → Feature → User Story 层次体系
标准的拆解结构分为三层，每层对应不同的管理粒度与受众：
| 层级 | 英文 | 描述粒度 | 典型生命周期 | 管理者 |
|---|---|---|---|---|
| 史诗 | Epic | 一个完整的产品能力域，如“多币种支付” | 1–3 个季度 | 产品总监 / 高级产品经理 |
| 特性 | Feature | Epic 内的功能模块，如“汇率实时换算” | 2–6 周 | 产品经理 |
| 用户故事 | User Story | 单个用户操作场景，如“用户查看订单时看到实时汇率” | 1–5 天 | 产品经理 + 开发 |
拆解原则：每个 User Story 必须满足 INVEST——独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimable）、小型（Small）、可测试（Testable）。
4.3 用户故事三要素与 INVEST 原则
一个完整的 User Story 由卡片（Card）、对话（Conversation）、确认（Confirmation）三要素构成。卡片用于记录，对话用于澄清，确认用于验收。
标准模板：
**标题**：用户查看订单实时汇率
**角色**：作为 跨境电商买家
**功能**：我希望 在订单详情页看到所选币种的实时汇率
**价值**：以便 我准确知晓最终支付金额，避免汇率波动超出预算INVEST 验真检查表：
- I（Independent）：该故事是否可以独立开发与上线？不依赖 US-2 即可发布。
- N（Negotiable）：实现方式是否留有协商空间？界面位置、刷新频率可讨论。
- V（Valuable）：用户或业务能否感知到价值？买家能提前算账，减少投诉。
- S（Small）：工作量是否小于 3 人天？前端展示 + 接口调用，约 2 人天。
- T（Testable）：是否有明确的验收条件？见下方验收条件示例。
4.4 用例图核心要素
用例图（Use Case Diagram）从系统边界出发，展示参与者（Actor）与用例（Use Case）之间的关系。它补充了 User Story 缺失的全局交互视图，尤其适合表达多角色、多权限的复杂场景。
| 要素 | UML 符号 | 说明 | 示例 |
|---|---|---|---|
| 系统边界 | 矩形框 + 系统名称 | 划定待建系统的范围 | “跨境电商支付平台” |
| 参与者 | 火柴人图标 | 与系统交互的人或外部系统 | 买家、卖家、银行网关 |
| 用例 | 椭圆 + 用例名称 | 系统提供的完整服务 | “查询汇率”、“发起支付” |
| 关系 | 连线 + 箭头 / 虚线 | 关联、包含（<<include>>）、扩展（<<extend>>） | “支付”包含“验证余额” |
用例图与 User Story 的映射关系：
- 一个用例通常对应 1–3 个 User Story（主流程 + 异常分支）。
- 参与者直接对应 User Story 中的“角色”。
- 包含关系提示需要提取公共子故事，例如“用户登录”作为多个用例的公共前置。
4.5 验收条件书写：Given-When-Then
验收条件（Acceptance Criteria）是 User Story 的“完成定义”。Given-When-Then 结构是业界最通用的书写范式：
- Given：前置条件与初始化状态。
- When：用户触发操作。
- Then：系统响应与预期结果。
以 US-1“实时汇率查询”为例：
Scenario 1：成功查询汇率
Given 买家已登录并打开订单详情页
When 页面加载汇率模块
Then 系统调用汇率接口并展示“1 USD = 7.24 CNY”
And 汇率更新时间显示在数值下方
Scenario 2：汇率接口超时
Given 买家已登录并打开订单详情页
When 汇率接口 5 秒内未返回
Then 页面展示“汇率加载中，请稍后”
And 每 3 秒自动重试，最多重试 3 次
Scenario 3：汇率数据异常（返回负数）
Given 买家已登录并打开订单详情页
When 汇率接口返回 -1
Then 页面展示“汇率暂时不可用”
And 系统记录告警日志并通知运维验收条件书写三原则：
- 可执行：QA 能直接基于写好的条件编写测试用例，无需额外解释。
- 覆盖分支：至少包含主流程（Happy Path）+ 1 个异常分支 + 1 个边界条件。
- 无实现细节：不要写“调用汇率接口 v2”，应写“系统获取最新汇率”。
4.6 从用户访谈中提炼 User Story
用户访谈是需求拆解的源头输入。将访谈录音/笔记转化为 User Story 的四步法：
| 步骤 | 动作 | 输出 | 示例 |
|---|---|---|---|
| 1. 定位角色 | 从访谈中识别“谁在使用” | 参与者列表 | 跨境买家、客服、财务 |
| 2. 提取目标 | 用户反复提到的“痛点/期望” | 业务目标清单 | “我想知道最后要付多少人民币” |
| 3. 撰写卡片 | 按“角色-功能-价值”写成 User Story | 故事卡片草稿 | 作为买家，我希望在订单页看到实时汇率…… |
| 4. 补充约束 | 从对话中提取非功能约束 | 验收条件 + 指标 | 汇率刷新延迟 < 3s |
4.7 本章交付物模板
以下三个模板可作为第 4 章标准化输出物，直接复制到 PRD 对应章节中使用。
模板 A：User Story 卡片
| 字段 | 内容 |
|---------------|-----------------------------------------------------------|
| 故事编号 | US-2025-001 |
| 关联 Epic | 多币种支付 |
| 关联 Feature | 汇率服务 |
| 角色 | 作为 跨境电商买家 |
| 功能 | 我希望 在订单详情页查看实时汇率 |
| 价值 | 以便 准确预估最终支付金额 |
| 验收条件 | 见下方 Scenario 1-3 |
| 预估工时 | 2 人天 |
| 优先级 | P1 |模板 B：用例图核对清单
□ 系统边界矩形已绘制，命名与 PRD 一致
□ 所有参与者已识别（含外部系统）
□ 每个用例对应至少一个用户目标
□ 包含关系（<<include>>）仅用于公共子流程
□ 扩展关系（<<extend>>）用于可选或异常分支模板 C：验收条件检查表
□ 主流程（Happy Path）已覆盖
□ 至少 1 个异常分支（网络超时/数据异常/权限不足）
□ 至少 1 个边界条件（空值/极限值/并发冲突）
□ 每个条件可独立测试
□ 包含量化指标（耗时/成功率/容量）本章核心交付物清单
| 交付物 | 格式 | 关联章节 | 评审要点 |
|---|---|---|---|
| Epic → Feature → User Story 拆解列表 | 表格 / 思维导图 | 4.2 | 每个 Feature 下至少 2 个 User Story |
| User Story 卡片（含 INVEST 标记） | 卡片模板 | 4.3 | 独立、可测试、有价值 |
| 用例图（含边界、参与者、用例、关系） | UML 图 | 4.4 | 每个用例映射到至少 1 个 User Story |
| 验收条件（Given-When-Then） | 文本 + 表格 | 4.5 | 覆盖主流程 + 异常 + 边界 |
| 从用户访谈到 User Story 的映射记录 | 四步法表格 | 4.6 | 原始访谈内容可追溯 |
完成上述交付物后，需求拆解阶段即可关闭。评审时重点关注：每一层是否对齐业务目标？每个 User Story 的验收条件是否可执行？是否存在未拆解的 Epic 残留？ 确认无误后进入第 5 章——需求优先级排序与工作量估算。