软件项目开发全流程 · 第 7 课 · 需求分析与管理：验收标准、优先级与基线
1、需求拿到手 ≠ 需求清楚
第 6 课结束，你手里是一堆用户故事。但如果直接开工，结局通常是：开发做完了，用户说"这不是我要的"。
问题出在"用户故事只是个标题"。一条"作为管理员，我想要能管理用户，以便控制权限"——里面至少藏着 20 个没回答的问题：谁能加？能删吗？删了数据怎么办？批量吗？要审批吗？
本课解决四件事：
- 怎么把模糊故事变成可验证的需求？
- 一堆需求，怎么排优先级？
- 需求会变，怎么管理变更而不失控？
- 怎么证明"这个功能对应哪个需求"，即可追溯？
2、需求的三分类
拿到需求先贴标签，三类需求的处理方式完全不同：
| 类型 | 说明 | 例子 |
|---|---|---|
| 功能需求 | 系统做什么 | 用户能创建任务并指派给成员 |
| 非功能需求 | 系统做得怎么样（质量属性） | 列表加载 < 1 秒；支持 500 并发；数据每日备份 |
| 约束 | 不可协商的外部限制 | 必须部署在国内；必须用公司统一 SSO；预算 ≤ 10 万 |
非功能需求最容易被忽略，也最容易致命。 "要快"不是需求——必须量化成指标 + 条件 + 验收方式：
在 1 万条任务的账号下，任务列表首屏加载时间 ≤ 1.5 秒（P95）。
3、验收标准：可验证才算需求
验收标准（Acceptance Criteria，AC） 是"做完怎么算过"的书面约定。两种主流写法：
写法一：清单式
- 可输入标题（必填，≤ 80 字）
- 可指派 1 名成员，也可不指派
- 保存后出现在列表首位
- 标题为空时保存按钮置灰写法二：Given-When-Then（场景式，推荐用于有分支的逻辑）
场景：指派任务给不存在的成员
假如 我在指派输入框输入了系统中不存在的名字
当 我点击保存
那么 提示"该成员不存在"，且不创建任务AC 的三条铁律：
- 可观察：验证人不用猜，看结果就能判断。
- 可否定：能明确说"没通过"。
- 覆盖异常分支：只写正常路径的 AC 是半成品，边界、错误、权限必须写。
需求完成的定义（DoR，Definition of Ready）：一条故事要进入迭代，至少得有——清晰的价值描述、可测的 AC、估算过大小、依赖已识别、无阻塞疑问。宁可推迟进迭代，也不要带着疑问开工。
4、优先级：不是"都要"，而是"先要什么"
需求永远多于资源。排序方法有三把常用尺子：
① MoSCoW
- Must have：没有它产品不成立（MVP 必备）
- Should have：很重要，但可以临时用替代方案绕过
- Could have：锦上添花
- Won't have（this time）：明确这次不做——写下来很重要，它是对干系人的承诺
② Kano 模型
| 类型 | 特征 | 例子 |
|---|---|---|
| 基本型 | 没有会被骂，有了不会被夸 | 登录能用 |
| 期望型 | 越多越满意，线性 | 加载速度 |
| 兴奋型 | 没有无所谓，有了惊艳 | 智能任务提醒 |
先补齐基本型，再投期望型，兴奋型用来做差异化亮点。
③ WSJF（加权最短作业优先，SAFe 常用）
WSJF = 延迟成本 / 工作量
延迟成本 = 业务价值 + 时间紧迫性 + 风险降低/机会成本它回答的是"先做哪个收益/成本比最高"——不是"哪个最重要"。
排序的关键不是选哪种方法，而是标准公开、同一套尺子、集体确认。暗箱排序必然引发扯皮。
5、待办列表（Backlog）与梳理会
敏捷团队把需求装进产品待办列表（Product Backlog）：一个按优先级排序、持续更新的清单。
- Top 部分：细、小、准备好开工（满足 DoR）
- Bottom 部分：粗、大、只是方向（史诗或一句话）
- 越靠上越细，这叫渐进明细（Progressive Elaboration）——避免在不确定的需求上过度设计。
梳理会（Backlog Refinement）：每个迭代花 1 小时左右，团队和产品负责人一起把下几个迭代要做的故事"拆小 + 补 AC + 重新排序"。
拆小是硬功夫，因为"小"才好估、好验、好回滚。常见拆法见第 6 课（按流程/规则/角色/数据拆）。
6、需求基线与可追溯矩阵
需求基线（Baseline）：某个时点冻结并获批准的需求版本。它的作用不是"不许改"，而是"改动必须走变更流程"——让变更可见、可评估、可追溯。
可追溯矩阵（RTM, Requirements Traceability Matrix）：
| 需求 ID | 用户故事 | 设计文档 | 代码/模块 | 测试用例 | 状态 |
|---|---|---|---|---|---|
| R-001 | 创建任务 | 设计 §3.2 | task/api.rs | TC-012~015 | 已验收 |
| R-002 | 任务提醒 | 设计 §4.1 | notify/ | TC-020 | 开发中 |
它回答四个致命问题：
- 这个需求有没有被实现？（没实现 = 漏做）
- 这段代码是为哪个需求写的？（没来源 = 镀金，白干）
- 这个需求有没有测试覆盖？（没覆盖 = 裸奔）
- 改这个需求，会波及哪些代码和用例？（没矩阵 = 靠猜）
7、变更控制与范围蔓延
需求变更是常态，失控的变更才致命。区别就在一句话：变更有没有被评估和记录。
变更流程（轻量版）：
- 提出变更（谁、为什么、期望什么）
- 评估影响（工作量、工期、风险、影响的需求/用例）
- 决策（接受 / 拒绝 / 延后 / 换出：等量砍掉其它需求）
- 更新基线、待办列表、RTM
- 通知干系人
范围蔓延（Scope Creep）的三个典型信号：
- "顺手再加个小功能吧"——每次都说"小"，总账是工期翻倍。
- "这个也必须要"——但没人愿意砍掉别的。
- 需求文档版本号天天涨，但没有一次影响评估。
MVP 的纪律：范围只进不出，项目必死。"要加 X，就得砍 Y" 这句话要敢当着干系人说出口。
8、动手实验 🎯
任务：把第 6 课的 8~12 条故事整理成受管理的需求池。
- 给每条故事补 3~5 条验收标准，至少含 1 条异常/边界场景（用 Given-When-Then 写）。
- 把需求按 功能 / 非功能 / 约束 分类；把所有"要快、要好用"改写成可量化指标。
- 用 MoSCoW + WSJF 双尺子排一次序：先标 M/S/C/W，再算一遍"延迟成本÷工作量"，看两套结果是否冲突并说明理由。
- 建一张 RTM 小表（哪怕只有 10 行），把需求 → 测试用例先连起来（测试用例可先留空但要有编号）。
- 模拟一次变更："客户要求增加'任务批量导入'"，写一份变更影响评估（工作量、工期、要换出什么）。
- 写一份 DoR 检查清单（5~7 条），以后所有故事进迭代前必须过。
做完这步，你的需求池就具备了"可排序、可验收、可追溯、可变更"四个特征。
9、今天你带走的三句话
- 验收标准是需求的另一半：没有 AC 的故事只是标题；好 AC 必须可观察、可否定、覆盖异常。
- 优先级要有公开的尺子（MoSCoW / Kano / WSJF），并且敢于写下"这次不做"。
- 范围只进不出，项目必死——要加需求，就得等量换出，且必须有变更影响评估。
下一课我们离开"文字需求"，进入原型与 UI/UX 设计——把需求画成用户一眼就能评判的东西。