用户故事、用例、任务故事和需求陈述是记录软件应执行内容的四种方式。它们常被呈现为竞争对手，但实际上它们在不同细节层次上回答不同的问题。用户故事询问谁想要什么以及为什么。用例逐步描述交互过程，包括出错情况。任务故事从用户所处的情况开始。需求陈述规定系统必须遵守的规则。
本指南比较了这四种方式，展示了同一功能用每种方式编写的示例，并解释了何时使用哪种。关于编写故事的基础知识，请参阅我们的中心指南 如何编写用户故事.
快速对比
| 用户故事 | 用例 | 任务故事 | 需求陈述 | |
|---|---|---|---|---|
| 格式 | 作为一个 [用户]，我想要 [动作]，以便 [收益] | 参与者、目标、前置条件、主要成功场景、扩展、后置条件 | 当 [情况] 时，我想要 [动机]，以便 [预期结果] | 系统应 [行为或约束] |
| 以……为中心 | 一类用户及其目标 | 参与者与系统之间的交互 | 情况和动机，而非用户画像 | 系统的行为或质量 |
| 长度 | 一句话加上验收标准 | 半页到几页 | 一句话 | 每个需求一句话，文档中包含多个需求 |
| 起源 | 极限编程；格式来自 Connextra（2001 年） | Ivar Jacobson（1980 年代末）；Alistair Cockburn 的目标导向风格（2000 年） | Paul Adams 在 Intercom；由 Alan Klement 开发（2013 年） | 传统需求工程（现为 ISO/IEC/IEEE 29148） |
| 最适合 | 敏捷待办事项列表与冲刺规划 | 复杂流程、集成、受监管或合同约束的工作 | 探索与设计，尤其是针对处于相同情境下的多样化用户 | 非功能性需求、合规性、固定范围合同 |
| 不擅长 | 展示完整流程及边界情况 | 速度；在快速迭代中难以保持同步 | 自行进行规划与估算 | 解释原因；容易写出无法测试的列表 |
用户故事
用户故事是对某项功能能力的简短描述，从希望获得该能力的人的视角出发。常见的格式“作为一个[用户类型]，我想要[动作]，以便[收益]”源自 2001 年 Connextra 团队，并通过 Mike Cohn 的著作《User Stories Applied》广泛传播。用户故事起源于极限编程（Extreme Programming），在那里它们被刻意保持简短：Ron Jeffries 将每个故事描述为一张卡片、一次对话和一个确认（3C原则）。卡片并非规格说明；细节在对话中达成一致，而验收标准则用于确认这些细节。
优势：故事足够小，可在一个冲刺中估算并完成，非技术利益相关者易于阅读，且始终关注价值（“以便”部分）。Mike Cohn 在 用户故事在需求方面的优势.
中阐述了其优势。局限：单个故事的待办事项列表无法展示它们如何组合成一个流程，且该格式容易忽略错误情况。团队通过 用户故事地图 解决第一个问题，通过编写良好的验收标准解决第二个问题（参见我们的 用户故事模板).
用例
用例描述了参与者（人或另一个系统）如何通过一系列步骤使用系统以达成目标，同时包含该序列可能分支或失败的方式。Ivar Jacobson 在 20 世纪 80 年代末引入了用例，Alistair Cockburn 的著作《Writing Effective Use Cases》（2000 年）确立了大多数团队今天使用的以目标为导向的纯文本风格（Cockburn 的网站).
完整的用例通常包括：
- 主要参与者：谁发起交互。
- 目标与范围：参与者想要什么以及正在描述哪个系统。
- 前置条件：必须已经为真的条件。
- 触发器：什么启动用例。
- 主要成功场景：一切顺利时的编号步骤。
- 扩展：替代路径和失败路径，每个都关联到其分支发生的步骤。
- 后置条件或保证：成功和失败结束时为真的状态。
优势：扩展部分迫使您思考出错的情况，且完整流程在一个地方可见，这对集成、支付和任何受审计的场景很有价值。局限：用例编写和更新耗时较长，且一个用例通常太大，无法在一个冲刺中构建。
用例已适应敏捷工作。在 Use-Case 2.0中，Jacobson 及其同事将每个用例拆分为“切片”，每个切片小到足以规划和测试，其作用与用户故事非常相似。
任务故事（待办任务）
任务故事用人物画像替代情境：“当[情境]时，我想要[动机]，以便[预期结果]。”这一想法最初由 Paul Adams 在 Intercom 博客上提出，并由 Alan Klement 发展，他在 2013 年的一篇 Intercom 客座文章中进行了阐述， 使用任务故事设计功能。它将通常与 Clayton Christensen 相关的“待办任务”思维应用于功能设计。
支持任务故事的论点是，“作为一个忙碌的家长”包含了团队无法测试的假设，而情境（“当我准备出门并意识到忘记订购杂货时”）解释了紧迫性、约束条件以及用户感觉“完成”的状态。处于相同情境下的两个非常不同的人物画像往往需要相同的东西。
优势：任务故事在探索和设计阶段表现良好，使团队专注于上下文，并为客户访谈产生更好的问题。局限：它们对谁被允许做什么说得很少，这对权限和角色很重要，且大多数团队仍将其转化为用户故事或任务以进行规划。
需求陈述
传统格式是编号陈述：“系统在五次登录尝试失败后锁定账户。”需求规范仍然是受监管行业、政府招标和固定价格合同的规范，当前编写它们的国际标准是 ISO/IEC/IEEE 29148。
敏捷团队也会使用需求陈述，主要用于非功能性需求（性能、安全性、可用性、可访问性），这些需求通常适用于多个用户故事。它们通常只需记录一次，例如在“完成定义”或简短的质量属性页面中，而不是在每个故事里重复。
同一功能用三种方式表述
功能：在合租费用分摊应用中，某人支付了一笔费用，并与其他人分摊成本。
作为用户故事
作为一名支付了共同消费款项的合租室友，我希望将费用分摊给相关的人，以便每个人的余额都能显示他们欠我的金额。
- 我可以选择哪些群成员分摊费用；默认情况下包含我自己。
- 默认分摊方式为均分；我可以切换为精确金额或百分比。
- 应用不会保存各部分之和不等于总额的分摊方案，并会提示差额是多少。
- 费用保存后，每个人的余额会立即更新，并收到通知。
作为用例
用例：分摊费用。主要参与者：付款人。前置条件：付款人已登录，且属于至少包含另一名成员的群组。触发条件：付款人选择“添加费用”。
- 付款人输入金额、描述和日期。
- 系统显示群成员，并默认选中付款人。
- 付款人选择分摊费用的成员。
- 系统建议均分方案，并显示每人的份额。
- 付款人确认。
- 系统保存费用，更新所有余额，并通知所选成员。
- 4a. 付款人切换为精确金额或百分比：系统会在每次输入数值时重新计算。
- 5a. 各份额之和不等于总额：系统阻止保存并显示差额。
- 6a. 设备离线：系统在本地保存费用，标记为待处理，并在重新联网后同步。
- 成功后的后置条件：费用被记录一次，且所有余额均反映该费用。失败时：余额无任何变化。
作为任务故事
当我刚在收银台支付了一笔部分属于室友的费用时，我希望在忘记金额之前记录下来，以便无需催促他人即可收回款项。
作为需求陈述
- REQ-1：系统应允许群成员记录包含金额、描述、日期和付款人的费用。
- REQ-2：系统应允许付款人将费用均分、按精确金额或按百分比分摊。
- REQ-3：系统应拒绝各部分之和不等于总额的分摊方案。
- REQ-4：系统应在保存后两秒内更新所有受影响的余额。
看看每个版本揭示了什么。用户故事最容易估算和规划。用例是唯一提出离线场景并说明保存失败时必须满足条件的版本。任务故事揭示了真正的约束，即收银台前的速度；它暗示第一个屏幕应只询问金额，而其他版本都不会提出这一点。需求陈述增加了故事中隐含的可衡量性能目标。
你应该使用哪一种？
| 情境 | 从以下开始 | 原因 |
|---|---|---|
| 早期探索、访谈、决定构建什么 | 任务故事 | 它们让团队保持对用户情境的关注，并提出更好的访谈问题 |
| 敏捷产品待办列表、冲刺规划 | 带有验收标准的用户故事 | 小、可估算，且所有人都能阅读 |
| 复杂流程、集成、资金流动 | 先写用例，再将其拆分为故事 | 扩展部分在故障路径成为缺陷之前将其暴露出来 |
| 受监管的产品、公开招标、固定价格合同 | 需求陈述，通常可追溯至用例 | 审计人员和合同需要编号的、可验证的陈述 |
| 性能、安全性、可访问性目标 | 需求陈述或完成定义 | 它们适用于多个故事，而非单一故事 |
| 由小团队开发的 MVP | 用户故事的故事地图，并为风险最高的流程编写一个用例 | 足够的结构以快速确定范围并构建 |
可以将它们结合使用吗？
可以，大多数成熟的团队都会这样做。一个可行的顺序如下：
- 在研究阶段使用任务故事，以捕捉真实用户的情境和动机。
- 将由此产生的能力排列在 故事地图 上，作为用户故事，并选择第一个发布切片。
- 对于失败代价高昂的一两个流程（如支付、注册、数据同步），编写轻量级用例以发现扩展点，然后将每个扩展点转化为独立的故事或验收标准。
- 将横切需求（性能、安全性、可访问性、合规性）记录一次，作为编号陈述或包含在完成定义中。
经验法则：只编写团队安全构建正确产品所需的最少内容。三人 MVP 团队不需要需求文档，而银行集成不应仅依赖单句描述。
常见错误
- 将用例编写为用户界面脚本（“用户点击蓝色按钮”），这将需求与即将变更的设计绑定在一起。
- 编写没有“以便”的用户故事，导致团队无法提出更简单的解决方案。
- 将任务故事当作伪装的画像（“当我是一个忙碌的妈妈……”）；情境应是一个时刻，而非一种身份。
- 将长长的需求列表复制到待办事项列表中，每行作为一个故事，这会产生没有用户且没有价值的故事。
- 在同一个待办事项列表中使用不同格式，且未就哪个是事实来源达成一致。
常见问题
用户故事和用例的主要区别是什么？
用户故事是一句话描述谁想要某种能力以及为什么，用于规划和优先排序工作。用例是参与者与系统之间交互的逐步描述，包括替代路径和失败路径。故事更小、细节更少；用例展示完整流程。
用户故事是需求吗？
它是一种轻量级的方式来捕捉需求，但不是完整的规范。细节存在于对话和验收标准中。非功能需求（如性能和安全）通常单独记录。
敏捷团队仍然使用用例吗？
是的，主要用于复杂或高风险流程。Ivar Jacobson 及其同事提出的 Use-Case 2.0 将用例拆分为可像用户故事一样规划的切片，因此两者可以共存于同一个待办事项列表中。
任务故事和用户故事的区别是什么？
用户故事从用户类型开始（“作为一个……”）。任务故事从情境开始（“当……”），并关注动机和预期结果。任务故事源于待办事项思维，在发现和设计中最为有用。
一个用例可以变成多个用户故事吗？
可以。主要成功场景通常变成一个或两个故事，每个重要的扩展点变成独立的故事或验收标准。这是一种可靠的方法，可以在不丢失边缘情况的情况下拆分大型功能。
用例和测试用例的区别是什么？
用例描述系统应如何行为以满足参与者的目标。测试用例通过特定输入和预期结果检查该行为中的某一条具体路径。一个用例通常会产生多个测试用例。
不确定您的产品需要多少规范？我们帮助创始人将想法转化为范围明确的待办事项列表，然后通过短周期冲刺进行构建。查看 我们的月度开发计划.