需求文档的唯一检验标准是：把它交给一个没参加过沟通的开发，他能不能据此做出功能、并自己判断做对没有。下面七个章节，就是围绕这个标准展开的。
一、功能清单：按角色写，不要按页面写
按页面写容易漏——页面可以少一个，角色能做的事少一件业务就跑不通。写法上，一个角色一组清单。
示例：【部门主管】① 查看本部门全部报销单 ② 审批/驳回（驳回需填原因）③ 导出本部门月度汇总 ④ 查看本部门成员的额度使用情况
二、业务流程与状态流转
把每个单据的状态画成一条线，写清谁能把状态从 A 改到 B、改的时候必须填什么。这一节写清了，权限和逻辑就自动定了。
草稿 → 已提交 → 审批中 → 已通过 → 已归档
↘ 已驳回 → 可重新提交三、数据字段与字典
- 字段清单：名称、类型、长度、是否必填、是否唯一、默认值
- 枚举字段要给出全部可选值（如单据类型：采购/报销/借款/还款）
- 金额字段注明精度与是否含税；数量字段注明单位
四、权限矩阵
| 功能 | 管理员 | 主管 | 员工 |
|---|---|---|---|
| 查看全部数据 | ✔ | 仅本部门 | 仅本人 |
| 审批单据 | ✔ | ✔ | — |
| 查看成本价字段 | ✔ | — | — |
| 导出数据 | ✔ | ✔（本部门） | — |
五、接口与外部系统
列清要对接哪些系统、由谁提供接口、有没有现成文档、测试环境的账号什么时候给。外部接口的交付时间往往不在你控制内，必须写进计划并留缓冲。
六、非功能需求
- 并发规模：同时在线多少人，峰值集中在什么时段
- 响应要求：常用页面打开时间、报表生成时间
- 兼容范围：浏览器版本、手机型号、微信版本
- 可用性：允许的停机窗口、备份频率与恢复目标
七、验收标准
这一节最容易被省略，代价最大。逐条写：做什么操作 → 期望看到什么结果。验收时照着念一遍就行，不需要现场争论。
八、常见问题
没人会写怎么办？
不用写文档体。先把上面七个标题抄下来，每节用大白话往里填，填不出来的地方就是要跟开发方补沟通的地方。
需求文档签了字还能改吗？
能，但要走变更单。见本栏目《软件定制开发第一步》。