需求分析

核心问题：如何将模糊的业务需求转化为清晰的技术需求？如何避免需求理解偏差？

1. 用户故事与验收标准

// 用户故事格式：As a [role], I want [feature], so that [benefit]
// 验收标准（AC）：Given-When-Then 格式

// 示例：购物车功能
// 用户故事：
// 作为一个注册用户，我想要将商品加入购物车，以便稍后统一结算。
//
// 验收标准：
// AC1: 用户可以将商品加入购物车
//   Given 用户已登录且商品有库存
//   When  用户点击"加入购物车"
//   Then  购物车数量增加，显示成功提示
//
// AC2: 同一商品重复添加时合并数量
//   Given 购物车中已有商品 A（数量 2）
//   When  用户再次将商品 A 加入购物车（数量 1）
//   Then  购物车中商品 A 数量变为 3
//
// AC3: 库存不足时提示用户
//   Given 商品当前可购买数量为 5，购物车中已有 4 件
//   When  用户尝试再添加 2 件
//   Then  拒绝本次添加，提示库存不足，并返回剩余可添加数量 1 件
//   注：「可购买数量」是业务定义的有效值，不必然等于数据库库存字段

验收标准要锁定业务结果，而非页面提示。购物车示例里，「不超卖」应落成一条可验证的业务不变量，即累计售出数量不得超过可售数量。边界条件（库存恰好耗尽、重复提交、并发下单）同样写进验收标准。至于库存何时预占、并发如何加锁，属于技术设计，不在需求阶段展开。需求分析只定义业务必须满足的约束，不决定实现方式。

2. 需求分解

// 大需求分解为小需求（INVEST 原则）
// I - Independent（独立的）
// N - Negotiable（可协商的）
// V - Valuable（有价值的）
// E - Estimable（可估算的）
// S - Small（小的）
// T - Testable（可测试的）

// 示例：将"订单系统"分解为独立的用户故事
// 1. 创建订单（基础功能）
// 2. 查看订单列表
// 3. 查看订单详情
// 4. 取消订单
// 5. 订单支付
// 6. 订单退款
// 7. 订单物流跟踪

需求分析的产物是澄清后的业务规则、边界与验收条件。如何把这些条目排进产品待办列表、估算故事点并承诺进 Sprint，见敏捷开发。澄清与迭代规划在开发中往复进行，并非严格的先后阶段。

3. 需求评审 Checklist

□ 需求目标是否明确？
□ 用户故事是否完整（角色-功能-价值）？
□ 验收标准是否清晰（Given-When-Then）？
□ 是否有边界条件和异常场景？
□ 是否有非功能需求（性能、安全）？
□ 涉及用户界面时，相关设计是否已明确？
□ 依赖的外部系统是否明确？
□ 技术可行性是否评估过？
□ 工期估算是否合理？

4. 需求变更管理

// 需求变更流程（按影响范围分层决策）
// 1. 提出变更请求（描述变更内容和原因）
// 2. 评估影响范围（工期、成本、风险）
// 3. 按影响范围决策
//    - 不改变 Sprint Goal 的细节澄清或范围调整，相关角色协商后更新 Backlog
//    - 影响 Sprint Goal、交付承诺或跨团队依赖，评估影响后协商调整，必要时重新规划
//    - 涉及合同、合规或正式变更控制，按项目约定的审批机制执行
// 4. 更新需求文档和 Sprint Backlog
// 5. 通知相关方

// 变更影响评估模板
/**
 * 变更名称：订单支持部分退款
 * 变更原因：用户反馈需要部分退款功能
 * 影响范围：
 *   - 后端：退款逻辑、金额计算
 *   - 前端：退款页面、退款记录
 *   - 测试：退款场景覆盖
 * 额外工期：3 天
 * 风险：与支付渠道的接口可能需要调整
 * 决策：同意变更，纳入下个 Sprint
 */

需求分析的核心：好的需求分析不是记录用户说什么，而是理解用户要什么。