今日一句话：把"要做什么"写清楚，写到任何人看了都知道该写哪些代码。
一、先讲业务：需求为什么要写清楚
今日目标
| # | 目标 | 验收方式 |
|---|---|---|
| 1 | 能说出需求的 3 个层次（业务/用户/功能），并各举一例 | 口述 |
| 2 | 能说出"需求"和"技术方案"的区别 | 口述 |
| 3 | 能画出含 4 个参与者的用例图，说出用例粒度怎么把握 | 交图 |
| 4 | 能按模板写出含扩展场景的用例描述 | 交 8 个用例 |
| 5 | 能说出扩展场景与代码里 if 分支的对应关系 |
口述 + |
需求错误的代价曲线
| 阶段发现需求错误 | 修复成本倍数 |
|---|---|
| 需求阶段发现 | 1x |
| 设计阶段发现 | 5x |
| 编码阶段发现 | 10x |
| 测试阶段发现 | 20x |
| 上线后才发现 | 100x+ |
需求的三个层次（重点）
| 层次 | 谁提的 | 长什么样 | 例子 |
|---|---|---|---|
| 业务需求 | 老板/甲方 | 一句话，说目标和价值 | "要让新闻发布从两天缩短到两小时" |
| 用户需求 | 最终使用的人 | 从用户视角描述要做什么 | "我要能在线写稿并看到审核进度" |
| 功能需求 | 产品经理/我们 | 具体到系统要提供什么功能 | "稿件提交后状态从 0 变为 1，并给编辑发站内通知" |
判断标准只有一个：这条需求，能不能直接写代码、能不能验收？能，才算功能需求。
需求追溯链
看图口诀：上一环写不清，下一环全是猜。
① 业务需求 → ② 用户需求 → ③ 功能需求（能写代码了）
④ 用例（图 + 描述）→ ⑤ 代码（Day06 起）→ ⑥ 验收（D38）
红色虚线：需求要改，必须回头改"功能需求"，再往下传 ------ 别在代码里偷偷补，那样文档和代码就成了"两张皮"。二、需求从哪来：需求获取与分类
课程目标
能说出需求的3个层次，并把一句"甲方的话"翻译成功能需求。
能说出4种需求获取方法，并说出本实训用哪几种。
能完成一次"访谈记者"的模拟，产出大于等于8个回答。
能整理出大于等于20条带优先级的需求清单。
| 方法 | 怎么做 | 适合场景 | |
|---|---|---|---|
| 访谈 | 一对一问用户 | 用户少、需求深 | |
| 问卷调查 | 发问卷统计 | 用户多、需求浅 | |
| 观察 | 看用户现在怎么干活 | 有现存流程可观摩 | |
| 竞品分析 | 看别人怎么做 | 有成熟同类产品 |