第2章 用户故事与用例的区别：粒度、格式、适用场景
在需求拆解与表达阶段，产品经理最常用两种需求描述技术：用户故事 (User Story) 和 用例 (Use Case)。两者都用于表达需求，但在粒度、格式和适用场景上存在显著差异。混淆使用会导致PRD结构混乱、开发团队理解偏差、验收标准模糊。
本章从用户场景与业务问题出发，围绕用户访谈后的需求拆解阶段，帮助你在撰写PRD时根据团队节奏、系统复杂度和交付目标，正确选择用户故事或用例进行方案表达，并为后续指标验证和验收条件编写打下基础。
2.1 三维度核心对比
下表从粒度、格式、适用场景三个维度直接对比，便于快速建立认知框架：
| 对比维度 | 用户故事 (User Story) | 用例 (Use Case) |
|---|---|---|
| 粒度 | 小：单用户、单需求、单场景；通常 1–3 天可开发完成 | 大：完整交互流程 + 多分支 + 多异常场景；通常 1–2 周或更长时间 |
| 格式 | 非结构化模板： "As a …, I want …, So that …" 可附加验收条件 (Acceptance Criteria) |
结构化模板： 用例名称、参与者、前置条件、基本流程、扩展流程、后置条件 |
| 适用场景 | 敏捷开发、产品探索、MVP 阶段、需求不确定时 | 复杂系统、合规性要求、需要详细文档、多团队协作 |
2.2 粒度差异详解
粒度直接决定了需求在PRD中的拆解深度和交付节奏：
- 用户故事 — 小粒度：聚焦单一用户的单一目标，一个故事通常对应一个完整的开发任务（含前后端）。例如："作为用户，我想用邮箱注册账号，以便快速体验系统。" 这个故事只覆盖注册主流程，不包含社交账号登录、邮箱验证失败等分支。
- 用例 — 大粒度：覆盖完整交互链路，包含正常流程、可选流程、异常流程、业务规则。例如："用户注册用例" 会包含邮箱注册、手机注册、第三方登录、验证码重发、注册失败处理等全部场景，通常需要 5–15 个步骤来描述。
需求拆解判断标准： 如果你需要 2–3 句话就能说清一个需求，并且开发预估在 3 天以内，用用户故事；如果你需要写满一页 A4 纸才能覆盖所有分支，并且涉及多角色、多系统交互，用用例。
2.3 格式差异详解
格式差异反映了两种方法对需求表达的不同哲学：用户故事强调价值沟通，用例强调行为描述。
用户故事标准模板：
As a [用户角色]
I want [功能/需求]
So that [业务价值]
示例：
As a 求职者
I want 在投递简历前看到岗位的薪资范围
So that 我可以判断该岗位是否符合我的期望用例标准模板：
用例名称：查看岗位薪资范围
参与者：求职者
前置条件：求职者已登录，且岗位详情页已加载
基本流程：
1. 求职者进入岗位详情页
2. 系统展示岗位基本信息，含薪资范围
3. 求职者确认薪资信息后决定是否投递
扩展流程：
2a. 薪资范围为"面议"时：
2a1. 系统不展示具体数字，显示"薪资面议"标签
2b. 薪资范围超出用户筛选区间时：
2b1. 系统在薪资区域显示"与您期望不符"提示
后置条件：求职者获得薪资信息，可继续投递或返回
关键认知： 用户故事的 "So that" 部分是核心价值主张，不能省略；用例的 "扩展流程" 是质量保障，不能只写基本路径。两者在需求拆解阶段互补，不是替代关系。
2.4 适用场景选择
在用户访谈后，需求拆解阶段需要根据以下因素判断使用哪种表达方式：
- 团队开发节奏： Scrum 团队 2 周 sprint → 用户故事；瀑布或混合团队 → 用例
- 需求确定性： 探索期、需求频繁变更 → 用户故事；合规审计、需求稳定 → 用例
- 系统复杂度： 前端展示类需求 → 用户故事；多系统交互、状态机、事务型需求 → 用例
- 受众： 与业务方快速对齐 → 用户故事；与开发、测试做详细评审 → 用例
常见误区： 切忌将用户故事写成"小用例"——给用户故事添加过多的前置条件、分支流程和后置条件，会使其失去"轻量沟通"的优势；反之，将用例强行压缩成用户故事格式，会导致关键异常路径丢失，验收时频繁遗漏场景。
2.5 在PRD中的协同使用
真正的产品需求文档往往不是"只用用户故事"或"只用用例"，而是根据需求的层次和类型混合使用。以下是在PRD中协同使用的推荐策略：
- Epic 层（大特性）：使用用例描述完整的业务流程和系统交互，确保架构级理解一致。
- Story 层（具体功能）：使用用户故事拆解用例中的每一个独立场景，分配给迭代开发。
- 验收条件：无论是用户故事还是用例，最终都要转化为可验证的验收条件，驱动测试与交付。
交付物模板建议： 在PRD中为每个功能模块先编写 1 个"用例概览"（含基本流程和关键扩展），再将其拆解为 3–8 个"用户故事"（每个故事附验收条件）。这样既保证了系统完整性，又适配了敏捷交付节奏。
掌握用户故事与用例的区别，是需求拆解阶段的"分水岭"能力。下一阶段将围绕验收条件编写，把本章选择的表达方式进一步转化为可度量、可测试的交付标准。