我们收到过两页的需求，也收到过八十页的需求。两页的项目最后做得很顺，八十页的反而返工最多。差别不在长度，在于有没有回答开发团队真正关心的问题。
需求文档要回答的六个问题
1. 为什么做（目标） 一句话说清系统上线后要改变什么："让销售在手机上就能查库存和下单，不再打电话问仓库。"目标决定了后面所有取舍。
2. 谁在用（角色） 列出所有会接触系统的人：销售、仓库、财务、客户、管理员。每个角色一句话描述他们最常做的事。
3. 怎么用（流程） 用文字或流程图描述主流程，从触发到结束。不要试图穷尽所有分支，先把最常见的路径写清楚，再补充例外情况。
4. 有什么（字段） 把现在用的 Excel 表头、纸质单据、微信群里的信息抄下来，这就是最真实的字段清单。标注哪些是必填、哪些有固定选项。
5. 怎么算做完（验收标准） 每个功能写一到两条可验证的标准："销售提交订单后，仓库端 10 秒内能看到新订单。"验收标准越具体，扯皮越少。
6. 先做什么（优先级） 把需求分成三档：没有就不能上线、有了更好、以后再说。第一档控制在能 4–8 周做完的范围。
三个常见误区
- 写界面而不是写业务：不必描述按钮颜色与位置，把业务规则写清楚，界面交给设计。
- 把"现在怎么做"当成"应该怎么做"：先描述现状，再单独列出希望改变的地方。
- 一次性写完再沟通：写完目标与角色就可以先聊一次，剩下的部分在沟通中一起完善。
给一个模板
把上面六个问题作为六个标题，每个标题下面用列表回答，两到四页就足够。剩下的细节，在原型阶段会自然浮现。