需求分析文档和需求描述文档。
简单来谈一下，为什么软件开发项目中，需要需求文档这么个东西？在稍微大一点的开发团队中，产品经理未必能向所有开发人员，传达具体的产品开发需求。这时就需要一份文档来供所有的项目参与人员阅读。而产品经理又常常爱拍脑袋、容易变卦，所以文档也是开发人员约束产品经理的一项武器。在产品上线前的测试环节，测试人员也同样会拿产品需求文档来验收产品质量。当团队进入新人时，文档也可以让新人更快地了解产品。
总的来说，产品需求文档有三个核心作用：
传达产品开发需求；
保证各部门沟通有理有据
产品质量控制有具体标准
行业大多产品经理都是用Word+Axure原型的方式组成产品需求文档。那这种方式，是否真的能方便地表达出产品需求？我问了很多程序猿，他们在开发时，一般都是看着效果图和原型图写代码，只有在遇到问题时，才会查看word文档。也就是说，开发需要一边写代码，一边看效果图，一边看原型，还要时不时查看文档。而且，大多数程序猿都不会逐字逐句去读产品经理的长篇大论。那产品经理写word真的合适吗？这样的用户体验真的好吗？花费大量时间写word真的有价值吗？在Axure画原型的同时，我们为什么不能直接在旁边标注呢？这样岂不是方便快捷很多吗？
其实，当下流行一种直接在原型图上标注的需求文档撰写方式。在新版的Axure8中，也已经推荐了原型加标注的需求文档样式。Axure8新增了一组部件—不干贴，就是方便产品设计人员进行功能标注。
后端产品需要表达复杂的逻辑，必须画各种流程图，用严谨的语言描述各种规则，而用到axure的时候基本只是简单的后台配置页面。后端产品必须是word和visio的重度用户，axure只是补充。
认识功能这是我强调的另一个概念，对于产品经理而言，这是一个分水岭：认识功能。其实有许多产品经理认识需求，但却不认识功能。这并不是一个值得提倡的趋势，需求的来源我们可以理解成分析阶段的产物，也是一种想法，思考的表现，但却终要功能来实现。互联网产品经理本身有很大的局限性质，我们的想发必须依赖功能才得以实现，而这些功能都受到编程语言的限制，那就表示，功能是有限的需求是什么呢？用户将内容从A产品里分享到朋友圈里，如果他的微信好友访问了他分享出去的内容，那在A产品里能够记录并通知用户：你的微信好友xxx ，访问了你分享的这是一个需求，也是我所做过的一个需求，实际的效果非常好，我们不需要将用户的微信好友转移到A产品里，就能实现简单的熟人互动。怎么实现呢？Word版本的需求文档，大多是以描述需求为主，就像这个案例一样，这个描述里有多少个功能，都有哪些功能，我们都是不知道的。
在撰写的过程中，会反复思考需求如何实现的，并且向开发询问，进行技术调研，经过了这一系列的过程，最终写出来的需求文档，就会极大的规避遗漏掉的需求，以及会变更的需求。
积累需求库当我们进入这个行业后，会逐渐的发现，功能的复用度很高。我所了解的 设计师有一些开源的素材，开发也会有封装好的SDK，可以直接使用。产品经理也可以，我们的需求文档也可以积累下来，也是可以被复用的。图中是一个功能模块的需求文档，我们会发现很多产品里使用到发布时间的，都会有一些相同的表现结果。那么这部分的需求文档就可以复用到多个项目中。随着这样的模块化需求越来越多，我们自身就会积累非常高效的需求库。怎么做呢？这只需要我们单独再建一张EXCEL，将每个版本的需求，按照一定的规律进行集合就好了。Excel的需求文档，由于是对功能进行定义，也就是说从功能的角度来写，这就导致复用性非常高，不牵扯到业务逻辑，需求场景，功能就是功能。
久而久之，就会让我们发现其实不同的需求所用到的功能很多都是相同的。不论我们做什么样的项目，图片还是那个图片，输入框还是输入框。这时，我们再写一份需求文档，大概只需要1-2小时，从我们的需求库，提取出相应需求就可以了。需求库的形成，会有几个典型好处对功能的认识可积累下来极高的复用性能逐渐完善需求，减少遗漏有时候，我们会反复在同一个类型的需求里反相同的错误，就拿统计数字来讲吧。统计数字现在经常被使用，像是点赞数，评论数，关注数，粉丝数，照片数，阅读数等等，非常多的地方使用到了统计数。我们可能在第一次写统计数字的需求时，会漏掉单位转换，没关系，我们将这个遗漏掉的需求，以需求变更的形式，记录下来。第二次写的时候，我们会直接复用这块的需求，可能还会漏掉四舍五入，同样的，还是用需求变更的方式记录下来。到后续的第三次，第四次，直到我们不需要再补充了，直到不会再因为该类型的需求，增加需求变更记录了，我们的需求库就成熟了。
产品经理产出一份需求文档，首先是要过需求审核的。而PM在审核之前的工作应该是，拿出你的数据和你思考的结论。1、我们前一个版本的数据表现如何（一份数据表格），这是对前一段各位工作的反馈，也是树立新的工作目标。1+、在数据的基础之上，我们哪些数据的表现不尽如人意，我们要做什么样的功能才能改善现状？2、你为什么认为用户有这个需求（用户访谈文稿/用户反馈摘抄，竞品分析，市场调研、BOSS拍脑袋等），说服项目组成员，认为这个功能是解决用户需求的最佳方案。3、详细解释功能实现的逻辑：包括使用流程（流程图），数据流通（脑图），需要配合的部门，可以调用到的资源等。4、基本的场景假设，包括正常使用场景，异常使用以及无法使用等。当以上四点都敲定以后（无论PM一人兼职UX/UE还是分值），再由具体人员，一起讨论实现细节问题，并给出时间排期。在此之后，才有高保真原型图，虽然程序研发的时候可能会按照高保真原型图进行，但是这个前提是程序的脑袋里面已经被你输出的价值观占据了，而PM价值产出应该是在需求评审时候的逻辑输出。
需求分析文档和需求描述文档。
作者：PulpCore
链接：https://www.zhihu.com/question/29213027/answer/67569732
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
作者：枯叶
链接：https://www.zhihu.com/question/29213027/answer/183150712
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
作者：臻龙
链接：https://www.zhihu.com/question/29213027/answer/66180329
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
