以上的脑图可以说明一切，我就简单解释下好了。
1. 背景和意义，说明你做这件事情的目的和潜在的收益。
对于不一定能做成的产品来说，这一块儿可以算是“吸引投资”的最重要的因素。你是否能说服别人开发你的产品，并且证明你的产品对公司是由意义的，决定了这个产品是否能上线。所以，各种最好是能使用各种量化数据。
没有这个产品之前，用户的痛点是什么？公司的痛点是什么?客户的痛点是什么？有多痛？产品如何解决这些痛点？上线后能减少多少痛苦？如何评估这些痛苦的减轻？
2. 功能概述，简述你解决问题的方法。
你的产品有哪些功能？这些功能的优先级排序是怎样的？（如果超过预定排期，可以砍掉或者合并一些优先级低的功能）
使用你产品的有哪些人？这些人的权限有什么不同？产品在使用过程中分为哪几种状态？这些状态时如何触发的？
你的产品结构是怎样的？如何导航以防止用户不迷路？
如何测试你的这些功能？（帮QA节省人力了，呵呵）
3. 功能细分，逐一细数产品的功能。
在每个功能里，页面都是怎样的？有什么文案提示？操作有什么边界限制？各种正常与异常的触发方式是什么？
这个功能对某些特定需求的用户，正确和错误的案例分别是什么？用户错误了，如何引导他们回归正途？
4. 其他需求
你的产品对安全性有什么额外要求？对浏览器有什么要求？当原型和文档发生冲突时，当和原系统发生冲突时，以哪个为准？
你产品对空间和机器性能有什么要求？
5. 附录
对于一些比较多的内容，比如每个表单的选项，各种状态的文案、日志需要记录哪些信息，数据库需要记录哪些信息等等。可以通过附录的方式展现。
如果你是PM-RD，你还可以简单设计一下数据库，做一个总体设计：）
商业主要考虑成本/收益，适用于商业产品；产品主要侧重于产品的定位和目的，所有需求都围绕产品；功能是产品组成产品的力度，是产品需求文档在某一个阶段 升级的细分；in all，无论是什么文档，都是形式。只要能完成对研发、测试、乃至老板、运营团队的沟通、设计备案的功能就行~不一定要拘泥于形式。我是觉得需求文档应该详细些，保证完备性和可传承性，但它不具备沟通需的简洁性，所以需要PPT和原型来配合沟通~~