前几天有朋友问我需求文档应该如何写作？需要注意点什么？其实需求文档在每个公司和每个人的产出的都可能是不一样的，基本上没有固定的格式，如果简明扼要的概括就是需求文档把你这个需求描述清楚你想要什么就可以了。

需求文档注定是给所有人看的，它就是产品的定义。

• 文档围观的人包括：你的老板（如果产品够大，还会需要老板的老板），设计师，工程师，测试工程师。有时还应该包括产品前端：如运营，销售，甚至市场部同事。
• 在通过各方的评审和签字后，一般来说，这个文档就是一锤定音的事。若有更改，就是需求变更了。
• 所以，在需求文档撰写前和撰写中，对产品方向和用户的把握要足够强，从产品目的，到每个链接的含义，都需要准确地定义。基本上，当你开始写文档时，应该万事俱备。一边想一边写，那说明你还没有想明白这个产品是怎么回事。
• 在有些公司，需求文档会包括产品的最终设计界面。即在文档提交给大家围观前，产品界面已经确定完毕。

需求文档写作的一些建议

• 格式无所谓。用WORD的多，HTML，在线文档都成，我还见过PPT写的！
• 产品定义部分一定要详细描述。按功能模块写，跨功能的定义用流程和关系来描述。多站在用户的角度上，去定义用户任务，用户流程，页面逻辑关系等。
• 使用准确的用语，注意边界情况。比如，一个文本框最多输入多少个字符？是阿拉伯数字还是皆可？超过字数会怎么样？
• 多画图。把原型包括进去，或者把产品界面包括进去，不然就画出来。否则除了你，没多少看得懂。

比如现比较推崇的Agile敏捷开发，会更强短平快，削弱文档的沟通而加强团队的直接交流，简化流程，快速反馈，快速迭代等等。这种情况下，需求文档会极大简化，咱就不在这探讨了。

比较正规的文档目录

1. 文档信息，版本记录，责任人等
2. 项目背景，产品目的
3. 文档约定（采用的标准，通用名词等）
4. 可行性分析
   • 前期调研
   • 产品预期
   • 对其他产品的影响
5. 产品定义功能详述（文档主体部分）
   • 功能模块
   • 用例
   • 用户流程
   • 数据需求
   • 业务规则流程
6. 产品非功能需求
   • 对性能的需求
   • 安全性需求等
7. 产品风险或潜在问题

这种文档现在更多的出现在软件行业和严谨开发行业，对于互联网而言已经慢慢简化了需求文档的冗余程度，只要这个文档能很清晰的把这个产品描述清楚就好。

如：微博上有好友推荐关系，需求文档中可以描述为

向用户A 推荐 用户B 为他有共同爱好的人，那么他们需要有>10个共同关注的人；
向用户A 推荐 用户C 为他可能感兴趣的人，那么他们需要有共通过的粉丝>10人；

　　这两句话描述了微博用户推荐机制产品经理需要给开发产出的需求描述，也经常遇到会有开发问“他们之间怎么关联在一起”“这两个表不在一个数据库“等问题，如果产品经理是开发转型能提供解决方案并且时间很充裕可以协助一下，但大多数产品经理也许不会开发，所以这些问题开发要自己想办法解决，不要凡事遇到问题就找产品经理。产品经理也是人，不是神；