刚好这阵子也在写产品需求文档，在知乎看到这样一个问题，转过来，以此共勉。
需求文档注定是给所有人看的，它就是产品的定义。
- 文档围观的人包括：你的老板（如果产品够大，还会需要老板的老板），设计师，工程师，测试工程师。有时还应该包括产品前端：如运营，销售，甚至市场部同事。
- 在通过各方的评审和签字后，一般来说，这个文档就是一锤定音的事。若有更改，就是需求变更了。
- 所以，在需求文档撰写前和撰写中，对产品方向和用户的把握要足够强，从产品目的，到每个链接的含义，都需要准确地定义。基本上，当你开始写文档时，应该万事俱备。一边想一边写，那说明你还没有想明白这个产品是怎么回事。
- 在有些公司，需求文档会包括产品的最终设计界面。即在文档提交给大家围观前，产品界面已经确定完毕。
需求文档写作的一些建议
- 格式无所谓。用WORD的多，HTML，在线文档都成，我还见过PPT写的！
- 产品定义部分一定要详细描述。按功能模块写，跨功能的定义用流程和关系来描述。多站在用户的角度上，去定义用户任务，用户流程，页面逻辑关系等。
- 使用准确的用语，注意边界情况。比如，一个文本框最多输入多少个字符？是阿拉伯数字还是皆可？超过字数会怎么样？
- 多画图。把原型包括进去，或者把产品界面包括进去，不然就画出来。否则除了你，没多少看得懂。
一个需求文档，一些通用部分是必须要包括进去的，我总结了一个示例。
当然， 很多时候有可能是创业公司，或是小版本快速上线，要求会宽泛得多得多。
比如现比较推崇的Agile敏捷开发，会更强短平快，削弱文档的沟通而加强团队的直接交流，简化流程，快速反馈，快速迭代等等。这种情况下，需求文档会极大简化，咱就不在这探讨了。
----------------------------------------------------------------------------------------------
- 文档信息，版本记录，责任人等
- 项目背景，产品目的
- 文档约定（采用的标准，通用名词等）
- 可行性分析
- 前期调研
- 产品预期
- 对其他产品的影响
- 产品定义功能详述（文档主体部分）
- 功能模块
- 用例
- 用户流程
- 数据需求
- 业务规则流程
- 产品非功能需求
- 对性能的需求
- 安全性需求等
- 产品风险或潜在问题
知乎：http://www.zhihu.com/question/19586231?rf=20503715