03 - 需求打磨：业务问题 → 可验收的交付标准
需求没写清楚 = 项目失败的最大原因。一份合格的需求 = 谁 + 要什么 + 为什么 + 验收标准——少一个就出问题。
一句话
需求打磨 = 把"模糊的业务诉求"翻译成"开发能直接动手的验收标准"——核心动作是"评审三遍"：业务视角、技术视角、用户体验视角。
需求的 5 大特征
合格需求必须满足：
| 特征 | 解释 | 反例 |
|---|---|---|
| 可验收 | 有明确验收标准 | "做好用户体验"（不可验收） |
| 可估算 | 能估出大致工作量 | "简单加一下"（不可估算） |
| 可独立 | 一个需求能独立交付 | "支持多种支付"（太大） |
| 有业务价值 | 能说清为谁解决什么问题 | "加个配置项"（价值模糊） |
| 优先级明确 | 知道什么时候做 | "看情况"（无优先级） |
需求金字塔（INCOSE C04）
┌─────────────────────┐
│ 业务需求 (Business) │ 为什么做这个
└──────────┬──────────┘
↓
┌──────────────────────────────┐
│ 利益相关者需求 (Stakeholder) │ 谁需要什么
└──────────────┬───────────────┘
↓
┌────────────────────────────────┐
│ 系统需求 (System Requirements) │ 系统要做什么
└──────────────┬─────────────────┘
↓
┌──────────────────────────────────┐
│ 软件需求 (Software Requirements) │ 软件怎么实现
└──────────────────────────────────┘例子（用户退款）
业务需求：
提升用户退款体验，减少客服工作量，预计可降低客服成本 20%。
利益相关者需求：
用户：希望 3 天内收到退款，能看到进度。 客服：希望减少 50% 的退款咨询量。 财务：希望自动对账，不要人工核对。
系统需求：
- 用户可发起退款申请
- 3 天内自动到账
- 状态可查（5 个状态：申请/审核中/退款中/完成/失败）
- 客服后台能看到所有退款记录
软件需求：
- 接口：POST /refunds（申请）、GET /refunds/{id}（查询）
- 数据库表：refunds（id, user_id, amount, status, created_at）
- 状态机：申请 → 审核中 → 退款中 → 完成/失败
- 自动任务：每 5 分钟检查待退款订单
用户故事模板
最经典：
作为 [角色]
我想要 [功能]
以便于 [业务价值]完整版（推荐）：
【故事 ID】: US-2026-Q3-001
【标题】: 用户自助发起退款申请
【史诗】: EPIC-2026-Q3-支付优化
【估算】: 5 人天
【角色】
作为 已在 APP 完成支付的注册用户
【需求】
我希望 通过订单详情页申请退款
以便于 不用联系客服就能快速拿回钱
【业务背景】
- 当前退款流程：用户 → 客服 → 财务 → 用户（平均 5 天）
- 痛点：客服 30% 工作量在退款咨询
- 目标：自助率 80%，3 天到账率 95%
【验收标准】
GIVEN 用户已支付订单
WHEN 在订单详情页点击"申请退款"
THEN 系统显示退款金额选择（默认全款）
GIVEN 用户选择了退款金额
WHEN 提交申请且订单仍在 7 天内
THEN 系统创建退款记录，状态"审核中"
AND 显示预计 3 天内到账
GIVEN 退款申请已创建
WHEN 财务审核通过
THEN 系统自动发起退款
AND 用户收到通知
AND 状态变为"退款中"
GIVEN 退款已发起
WHEN 银行到账成功
THEN 状态变为"完成"
AND 用户收到到账通知
【不在范围内】
- 商家主动退款（另一个故事）
- 跨境退款（Q4 考虑）
【依赖】
- 依赖 US-2026-Q3-005（支付通道退款 API 对接）
【设计稿】
[链接到 Figma]
【技术风险】
1. 部分银行退款接口支持不全（需要 fallback 到手动）
2. 退款金额不能超过原订单金额（已确定）需求评审 3 视角
每条需求必须经 3 个视角评审——任何 1 个反对就要改需求：
视角 1：产品视角（业务价值）
问：
- 这解决了谁的具体问题？
- 不做有什么后果？
- 投入产出比合理吗？
- 优先级对吗？
视角 2：技术视角（可行性）
问：
- 现有系统能支撑吗？
- 要不要改架构？
- 工作量估算合理吗？
- 有没有隐藏依赖？
视角 3：测试/QA 视角（可测性）
问：
- 验收标准能转化成测试用例吗？
- 边界条件覆盖了吗？
- 异常路径清晰吗？
- 上线后怎么监控？
验收标准（AC）的写作
好的 AC 满足 SMART 原则：
- Specific（具体）——不模糊
- Measurable（可衡量）——有量化指标
- Achievable（可达成）——技术上能做到
- Relevant（相关）——对应业务价值
- Time-bound（有时限）——有截止日
反例：
AC1: 退款速度要快
AC2: 用户体验要好
AC3: 系统要稳定正例（Gherkin Given/When/Then）：
GIVEN 用户的订单已完成支付且未超过 7 天
WHEN 用户点击"申请退款"
THEN 在 1 秒内弹出退款金额选择对话框
AND 默认选中"全额退款"
AND 显示预计到账时间需求拆分（INVEST 原则）
好的子需求满足 INVEST：
| 字母 | 含义 | 反例 |
|---|---|---|
| I - Independent | 独立 | "做 A 和 B"（应拆） |
| N - Negotiable | 可协商 | 必须有 X 接口（不可协商的是约束不是需求） |
| V - Valuable | 有价值 | "重构 X 函数"（应给业务价值） |
| E - Estimable | 可估算 | "支持 AI"（不可估算） |
| S - Small | 小 | "建一个商城"（太大） |
| T - Testable | 可测 | "性能要好"（不可测） |
需求变更管理
变更不可避免，但要可追踪：
变更请求模板：
【变更请求】: CR-2026-Q3-001
【原因】: 法务要求增加实名认证字段
【影响范围】:
- 涉及故事：US-2026-Q3-001, US-2026-Q3-002
- 新增工作量：3 人天
- 推迟其他故事：US-2026-Q3-003 推迟到 Q4
【优先级】: 高（合规要求）
【决策】: 产品总负责人 ___ 日期 ___反模式：口头变更 = 没变更。所有变更必须有书面记录。
需求工具栈
小团队：
- Notion / 飞书文档（需求池 + Roadmap + 用户故事）
- GitHub Issues / Plane（任务卡片化）
- Figma（设计稿）
中大型团队：
- Jira（用户故事 + 验收标准 + 链接）
- Confluence（需求文档 + RFC）
- ProductBoard（需求优先级）
- Figma（设计稿）+ Zeplin（设计交付）
需求的 10 个反模式
1. 解决方案当需求
❌ "加一个二维码支付"（这是方案） ✅ "用户希望快速支付"（这是需求）→ 再讨论方案
2. 不写验收标准
❌ "做一个退款功能" ✅ "退款功能满足：3 天到账、状态可查、用户收到通知"
3. 验收标准用主观词
❌ "界面要美观"、"性能要好"、"体验要流畅" ✅ "页面加载 < 1 秒"、"首屏 < 3 秒"、"错误率 < 0.1%"
4. 一个用户故事包含多个功能
❌ "作为用户，我想要注册和登录"（应拆为 2 个故事）
5. 不写"不在范围"
每个故事明确"这个不做"——避免范围蔓延。
6. 估算时不用"人天"而用"小/中/大"
T-shirt 估算（S/M/L）适合前期粗估，但 Jira/Plane 里要换算成具体故事点（Fibonacci 1/2/3/5/8/13）或人天。
7. 业务方单方面写需求，技术只能接受
双向写作：技术参与需求评审，提出隐藏成本。
8. 需求文档锁死版，不迭代
需求是活文档——每次评审都更新。
9. 验收标准全是"正常路径"
必须包含异常路径：
- 网络失败怎么办？
- 重复点击怎么办？
- 并发请求怎么办？
- 数据缺失怎么办？
10. 验收时只看 demo
真实测试：在测试环境用真实数据走一遍，比 demo 更有说服力。
需求评审会议
会前：
- 提前 24 小时发需求文档（让大家有阅读时间）
- 明确议程：哪些需求要讨论（不要全过）
会中：
- 不超过 90 分钟
- 每个需求过 3 个视角
- 决策（接受 / 改动 / 拒绝）当场出
会后：
- 当天更新需求文档
- 同步到任务系统
进入下一章
需求评审通过后，下一步：
- 04 架构与设计——把需求翻译成系统方案
作者：基于 INCOSE C04 (Requirements) + IDDD L2-L4 (业务建模) 综合 最后更新：2026-06-28