大多数需求文档写不好，是因为少了这 5 块

好用的需求文档，不是功能清单，而是一页纸的共同约定。

很多人写需求上来就是“我要个商城”，这其实是方案。真正该写的，是解决谁的什么问题、想达到什么效果。目标定错，后面全跑偏。

一份靠谱的需求书，得填满这5块：

目标：别写“做个系统”，要写清解决谁的问题。
用户与场景：谁用、在哪用、用多频繁，决定了怎么做。
功能分级：分出必须做、以后做和坚决不做，防超预算。
验收标准：别写“界面好看”，要写“几步完成、几秒加载”。
边界约束：提前说清不含啥、有啥合规要求，免得上线爆雷。

最常见的坑，就是把功能当目标。比如平铺一堆功能不分主次，或者满篇都是“好用”“稳定”这种没法测的词。不写清楚不含啥，增项扯皮的种子就埋下了。

作者给了一个万能模板，照着填空就行：

【项目目标】解决谁的什么问题，期望啥结果。
【核心用户与场景】主要给谁用，在什么设备上用。
【功能清单与优先级】必须做啥、以后做啥、坚决不做啥。
【验收标准】几步完成、多久响应、失败怎么提示。
【边界与约束】不含啥、合规要求、第三方依赖、性能预期。

有个客户本来想做教育小程序，啥都要。按这法子一梳理，砍掉一半非刚需功能，报价直接降了四成。

找外包前，先自己把这页纸填上。填不下去的地方，往往就是最容易翻车的地方。需求理透了再谈钱，比上线后返工便宜一百倍。