📄 一句话概括
需求定义是设计的原料采集：把「用户要什么、系统用来干什么」一条条写清楚——表结构是从需求里长出来的，不是拍脑袋定的。
📝 本节和前面几节的关系
5-1 流程里「需求定义」排在设计之前，本节展开它。从这里到 5-9 是一条链：需求 → 实体 → 关系 → E-R 图 → 模型——每一节都是上一节的加工品，最后 5-16~5-19 用书评网站把整条链走一遍。
一、需求定义回答三个问题
- 谁用：哪些角色要用这个系统（5-2 的角色）
- 干什么：每类角色要完成什么操作（录入、查询、统计……）
- 保什么：要存哪些数据、保留多久、谁有权动
二、怎么采集：听、看、追
| 方法 | 做法 |
|---|---|
| 听 | 访谈用户：现在怎么干、哪里最烦 |
| 看 | 看现用表格/单据——它们就是事实上的「数据模型」 |
| 追 | 追问异常流：改分怎么改？退课怎么退？——异常流程才是设计难点 |
第三条最容易被漏：正常流程谁都答得上来，「成绩登错了怎么办」一问，才知道需要「修改人、修改时间」两列。
三、产出：一份清单
需求定义的交付物是一张功能/数据清单，例如书评网站（本章贯穿案例的预告）：
- 用户能注册、登录、写书评、打分
- 每本书有多条评论
- 能查某书平均分、某用户的全部评论
- ……（5-16 从这张清单正式开工）
四、动手 Demo：把一句抱怨翻译成需求
用户说：「每次找哪个班谁没交作业都要翻聊天记录。」 翻译：需要作业提交记录表（谁、哪科、哪次、交没交、何时交）+ 查询功能（按班/科目/次号筛未交名单）。 一句抱怨 → 两行需求——这就是需求定义的日常。
五、30 秒实验
给「班级成绩管理」追三个异常流问题：成绩登错怎么改？学生转学记录留不留？期末报表谁出？——每问一次，清单就多一两行。
六、常见误区
- 「需求由开发人员想象」：需求只属于用户；开发者负责翻译不负责发明
- 「需求写完就定了」：需求会进化，但每版都要留档——将来改表时的依据就是它
自测三问
1. 需求定义回答哪三个问题？（谁用/干什么/保什么） 2. 三种采集方法？（听访谈/看现用表格/追异常流） 3. 为什么异常流程最关键？（正常流程人人会答，设计难点全在异常）- ☐ 下一节（5-5 实体、属性-思考需要保存的数据）
相关笔记
- 引入的缺点、引入的目的-探讨是否应当引入数据库 —— 上一节：要不要上
- 实体、属性-思考需要保存的数据 —— 下一节：需求变实体
- 🗄️ 数据库基础 · 索引 —— 全课路线图