产品需求文档分很多种，这里我只说一种让程序员看起来舒服的需求文档格式吧：
作为程序员，在需求文档当中，最关注的内容是哪几种呢？
1、流程：包括业务流程和基本流程；
2、数据：包括输入数据和展示数据；
3、事件流：特别是分支事件流和例外事件流，感觉很多需求文档中，缺少了这部分；
那么，文档的模板是怎么样的呢？
1、需求说明：主要阐述为什么要做这个需求；
2、业务流程：最好使用VISIO来绘制，画出整个业务的流程图，特别是其中所要涉及的判定，分支等，都要画出来，越详细越好；
3、基本流程：继续使用VISIO，画出基本流程即可，一般来说都是业务流程中的最主要部分，但是可以加入更多的细节；
4、分支事件流：VISIO，各种分支事件的详细流程，越详细越好；
5、例外事件流：这里要使用表格，示例如下：主要是系统判定和对应的提示；6、输入数据：用户可以输入数据的字段，已经相应的定义，包括是否必填，字段长度，录入方式，对应规则等；
7、显示数据：页面显示给用户的数据，对应的字段，取数规则，对应规则等;
8、补充说明；这个需求文档模板，更倾向于传统的软件模板，而不是网络上比较流行的AXURE文档。
我很少会写传统意义上的产品需求文档；甚至，我连word都很少用。用惯了Axure的任意布局方式，再用word感觉非常别扭，尤其是在添加图片时，简直感到捉急。当然，这不是我不用word写需求文档的根本原因。简单来谈一下，为什么软件开发项目中，需要需求文档这么个东西？在稍微大一点的开发团队中，产品经理未必能向所有开发人员，传达具体的产品开发需求。这时就需要一份文档来供所有的项目参与人员阅读。而产品经理又常常爱拍脑袋、容易变卦，所以文档也是开发人员约束产品经理的一项武器。在产品上线前的测试环节，测试人员也同样会拿产品需求文档来验收产品质量。当团队进入新人时，文档也可以让新人更快地了解产品。总的来说，产品需求文档有三个核心作用：
1.传达产品开发需求；
2.保证各部门沟通有理有据，
3.产品质量控制有具体标准
由此可见，产品需求文档是必不可少的。那一份好的需求文档，就应该能准确传达出产品的开发需求。那么产品需求文档该用什么方式写，才能更好地传达出产品开发需求呢？就我所见，行业大多产品经理都是用Word+Axure原型的方式组成产品需求文档。那这种方式，是否真的能方便地表达出产品需求？我问了很多程序猿，他们在开发时，一般都是看着效果图和原型图写代码，只有在遇到问题时，才会查看word文档。也就是说，开发需要一边写代码，一边看效果图，一边看原型，还要时不时查看文档。而且，大多数程序猿都不会逐字逐句去读产品经理的长篇大论。那产品经理写word真的合适吗？这样的用户体验真的好吗？花费大量时间写word真的有价值吗？在Axure画原型的同时，我们为什么不能直接在旁边标注呢？这样岂不是方便快捷很多吗？其实，当下流行一种直接在原型图上标注的需求文档撰写方式。在新版的Axure8中，也已经推荐了原型加标注的需求文档样式。Axure8新增了一组部件—不干贴，就是方便产品设计人员进行功能标注。这份需求文档是我打磨一年，所产出的。目的就是希望打造出一份易于团队协作的产品需求文档。之所以不贴出源文件的下载链接，也是希望其他产品人看到后，可以有所启发，从而做出合适自己团队的需求文档。不发任何原文件或HTML文件。
在我看来产品经理产出一份需求文档，首先是要过需求审核的。而PM在审核之前的工作应该是，拿出你的数据和你思考的结论。
1、我们前一个版本的数据表现如何（一份数据表格），这是对前一段各位工作的反馈，也是树立新的工作目标。
1+、在数据的基础之上，我们哪些数据的表现不尽如人意，我们要做什么样的功能才能改善现状？
2、你为什么认为用户有这个需求（用户访谈文稿/用户反馈摘抄，竞品分析，市场调研、BOSS拍脑袋等），说服项目组成员，认为这个功能是解决用户需求的最佳方案。
3、详细解释功能实现的逻辑：包括使用流程（流程图），数据流通（脑图），需要配合的部门，可以调用到的资源等。
4、基本的场景假设，包括正常使用场景，异常使用以及无法使用等。
当以上四点都敲定以后（无论PM一人兼职UX/UE还是分值），再由具体人员，一起讨论实现细节问题，并给出时间排期。在此之后，才有高保真原型图，虽然程序研发的时候可能会按照高保真原型图进行，但是这个前提是程序的脑袋里面已经被你输出的价值观占据了，而PM价值产出应该是在需求评审时候的逻辑输出。
