我的需求文档里一般包含四块：项目背景、项目目标、需求概述和需求详细描述，必要的时候可以带上项目风险（说明此次版本可能带来的问题或考虑不够完善的地方）和业务流程图（对某些复杂功能/逻辑的分解）。
产品需求文档主要是要把需求的逻辑表达清楚没歧义，对各个细节描述清晰，各输入输出项（涉及到表单/数据的输入输出）、业务流程（功能的交互步骤和数据的流转）、计算规则（某些特定须计算的规则）、判断逻辑 （业务流程中出现的一些判断逻辑及各种判断下的反馈情况，账号的权限范围也属于这种）和一些特殊情况（如是否支持横屏啊之类的）都要写清楚，如果实在记不住太多，每次写需求文档时都会这里漏个流程那里漏个判断的，可以整理一份适合自己的需求文档自查清单，每次写完后从头到尾对照一遍。当然不能事无巨细都通通一股脑写进去，不然开发和测试的朋友会看的很辛苦，小心被打…
举一个活生生的反例，上周写文档时有一个计算规则比较想当然了，要算“累计阅读时长”，阅读时长嘛就是阅读时长嘛，一句话就带过了，然后在需求评审时就比较惨了，该如何统计这个阅读时长？直接用定时器吗？还是使用本地时间？用定时器比用本地时间相比既复杂又低效，但如果用本地时间，那用户直接修改手机上的时间给不给累计阅读时长？还有用户如果一直停留在当前阅读页还给不给算阅读时长？…后面对这个功能的计算规则讨论了好久，最终评审会上也没确定下来。所以说，做好细节是多么的重要！/(ㄒoㄒ)/~~
产品需求文档的准确和详细可以有效减少需求评审时的花费的时间，也能让参会人员更清楚地了解需求。
