用例与用户故事
一、用例（Use Case）：参与者、主成功场景与扩展
用例描述的是「谁在什么情况下与系统交互、完成什么目标、步骤是什么、异常怎么处理」。它把「用户能做什么」变成可执行、可测试的场景，适合做需求分析、设计讨论和测试用例来源。
一个用例通常包含：参与者（Actor）——谁在用（用户、管理员、外部系统）；目标——要达成什么；前置条件——进入该用例前系统应处于什么状态；主成功场景（Main Success Scenario）——一步步走完的正常流程；扩展（Extensions）——分支、异常、可选路径（如「若库存不足则…」「若用户取消则…」）。
- 用户进入结算页，系统展示购物车项、配送方式与金额。
- 用户选择配送方式与收货地址，点击「提交订单」。
- 系统校验库存、生成订单、跳转支付页。
- 用户完成支付，系统更新订单状态为「已支付」。
- 2a. 若某商品库存不足：系统提示并标出该商品，不提交。
- 3a. 若用户取消支付或超时：订单保持「待支付」，15 分钟后释放库存。
用例不必一次写尽所有分支，但主流程和常见异常要写清，这样设计、开发、测试都有据可依。多个用例之间可以有「包含」「扩展」关系（例如「提交订单」包含「计算运费」），复杂系统时用用例图梳理参与者与用例的关系（下一部分设计会讲到 UML 用例图）。
二、用户故事：格式与 INVEST 原则
用户故事（User Story）是敏捷里常用的需求表述方式，通常是一句简短描述，格式为：「作为 [角色]，我想要 [能力/功能]，以便 [价值/目的]。」（As a… I want… So that…）它强调「谁、要什么、为什么」，便于和用户沟通、也便于拆成小粒度的开发项。
一条好的用户故事还会配上验收标准（AC）：在什么条件下、完成什么操作、得到什么结果。故事本身是「占位符」，AC 才是可测试的细节。
INVEST是衡量用户故事质量的六条原则的缩写，用来检查故事是否适合进入开发与排期：
用例和用户故事可以配合用：用例把「场景与步骤」写清楚，用户故事把「价值与迭代粒度」拎出来；同一个用例可以拆成多条用户故事（例如「提交订单」拆成「选配送」「确认地址」「支付」等），每条故事带自己的 AC。
三、从需求到可开发条目的拆解
高层需求（如「用户能下单」「支持多门店」）往往太大，不能直接丢给开发「做这一条」。需要拆解成可在一个迭代内完成、可单独验收的用户故事或任务。拆解时注意：粒度——一条故事最好几天内能做完、能交付；价值——拆完的每条仍应对用户或业务有价值；依赖——尽量减少故事之间的强依赖，否则排期会卡在一起。
拆完后，每条故事应有验收标准，并可以估点或估工时，再按优先级放进 Backlog，供迭代选取。
四、Backlog 管理入门
Product Backlog是产品待办列表——所有已知的、按优先级排序的需求（通常以用户故事或类似条目形式存在）。它由产品负责人（Product Owner）维护，条目会不断增删改、优先级会调整。Sprint Backlog是当前迭代选出来要做的那一批条目，迭代内尽量不随意加新需求，保证「本迭代就做这些」。
Backlog 管理常见实践：优先级排序——重要的、紧急的在上方；Refinement（细化）——定期把即将要做的条目细化（补 AC、估点、拆得太大的再拆小），避免迭代开始时才发现「故事太大或说不清」；透明与可见——所有人能看到 Backlog 和当前迭代内容，便于对齐。
一句话： 用例把「谁、在什么条件下、做什么步骤、异常怎么处理」写清楚，适合做需求分析与测试依据；用户故事用「作为…我想要…以便…」表达价值与粒度，配合 INVEST 与验收标准。需求要拆成可开发、可验收的条目再进 Backlog；Backlog 按优先级排序、定期 Refinement，当前迭代的条目构成 Sprint Backlog。
五、小结
用例包含参与者、前置条件、主成功场景与扩展（异常/分支），把「用户能做什么」变成可执行、可测试的场景。用户故事格式为「作为 [角色] 我想要 [能力] 以便 [价值]」，配合验收标准；INVEST 六条（独立、可协商、有价值、可估算、足够小、可测试）帮助写好故事。从需求到可开发条目要做拆解：粒度合适、带 AC、可估点，再按优先级放入 Backlog。Backlog 管理：Product Backlog 为全部待办、按优先级排序并持续 Refinement；Sprint Backlog 为本迭代选出的条目。下一章我们进入设计与建模：软件设计基础——抽象、模块化与接口。