项目验收时的争执，多数不是因为系统做错了，而是因为双方对"做完"的定义不一样。需求文档的作用就是在开工前把这个定义写清楚——写不清楚的，会在验收那天变成争议。
一、争议的根源：定义不清楚
"这个功能不好用""这不是我要的""当时不是说好了吗"——这些话在验收现场很常见。它们指向的其实是同一件事：需求文档里没有可判定的标准。写成"操作要方便""界面要友好""性能要流畅"，就只能靠感觉验收，而感觉永远无法达成一致。
二、必须回答的三个问题
- 做什么：有哪些功能、覆盖哪些角色、处理哪些数据
- 不做什么：明确排除项——这一条往往比第一条更重要
- 怎么算做完：每一项的验收标准，要能被观察和判定
明确排除项，是成本控制的关键
把"本期不做"的项目列出来并签字确认，可以在后期挡住大量"顺手加一个"的需求。写下来的边界，才是边界。
三、需求文档的最小结构
- 背景与目标：为什么要做，解决什么问题，成功的样子是什么
- 使用角色：谁在用，各自能看到什么、能做什么
- 业务流程：主流程 + 关键异常分支，最好配一张流程图
- 功能清单：按模块列出，每条一句话描述
- 数据与字段：关键字段的来源、规则、约束
- 非功能要求：性能、并发、兼容、安全、部署环境
- 排除项与待定项：本期不做的、暂不确定的，全部列明
- 验收标准与工期节点：逐条对应功能清单
结构不必复杂，但每一节都要落字。口头确认的内容，在文档里没有出现，就等于没有确认过。
四、验收标准怎么写才可用
三个要求：可观测、可复现、可判定。
| 写法 | 示例 | 可判定 |
|---|---|---|
| 模糊表述 | 列表加载要快 | 否 |
| 可判定 | 1000 条数据下，列表首屏加载不超过 2 秒 | 是 |
| 模糊表述 | 权限管理要灵活 | 否 |
| 可判定 | 支持按角色配置菜单、按钮级权限，变更后即时生效 | 是 |
五、变更怎么管
需求变更不可避免，重要的是让它"可见"。建议所有变更走同一张单子：
- 写清楚变更内容与原需求的差异
- 评估对工期、成本、已有功能的影响
- 双方确认后，更新需求文档版本号并留档
这样做的目的不是增加流程，而是让项目结束时，双方手上都有一份反映最终状态的文档。没有变更记录的文档，会在项目后期变成一份谁都不认的旧文件。
#需求文档#验收标准#变更管理#软件事业部
