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