如何写一篇挑不出毛病的需求文档.docxVIP

如何写一篇挑不出毛病的需求文档 前言 需求文档是产品经理的基本功，也是产品能力的体现，产品能力行不行看文档就能看出来。 我从实际工作+日常总结，整理了一些自己写PRD的方法，分享给各位，希望能对各位有用~ 一、原则与前提 在文章开始前，我们简单看下在什么时候用、谁去用，来明确需求文档的书写原则： 产品需求评审的时候看； 研发技术方案设计、敲代码的时候看； UI进行界面设计的时候看； 测试写测试用例、执行用例的时候看。 PRD 文档的目的就是让每个项目成员知道需求为什么做、要做什么、怎么做。 所以可以得到PRD的书写原则有： 有理有据：从项目成员知道为什么做； 全面、清晰、准确：让大家知道做什么、怎么做； 易读性：让大家方便快捷的理解文档内容。 明确了原则，还有2个前提：「需求类型、需求大小」 需求类型有：功能需求、接口需求、性能需求、策略需求、埋点需求、统计需求等等。 需求大小：可以是从0-1的大项目，包含上边的所有需求类型，还有就是日常迭代版本的小需求。 我们接下来文章内容都是基于以上原则与前提，接下来正文开始~ 二、需求文档用啥写 我们以终为始，先看需求文档的呈现方式。目前主要有以下2类： 1. Axure一体化需求文档 使用Axure将全部需求文档，最终通过Axure打包提供出去。好处是方便查看，看原型的基础上又能看文档说明。但有一种不是很“严肃”的感觉。 2. Word版 通过Word进行需求描述，并统一提供。容易留存，也比较正规，在阅读上以文字为主。 具体选择那种方式，可以先看公司要求。 像我之前有公司要求，必须用word，就算是有大量原型的，也只能把页面原型画好，然后再复制到word里，在word写需求内容。 如果没有要求，具体采用的方式可以看不同的需求类型： 如果只涉及到画原型的，可以使用Axure。 如果只有偏后端需求的，逻辑相关的需求，比如说是接口需求、算法需求，并不涉及到前端需求的，我们可以直接使用word写。 如果是做的大项目，同时有功能需求，又有接口需求、算法需求的，我建议都放在一起，比如说都用Axure写需求。 我之前做新项目的时候，同时提供了功能需求的axure文档+word版的接口需求，后来用例评审的时候，测试说不知道word版接口需求，之后我就统一写在axure里了。 三、需求文档包含哪些内容 需求有大有小，同样的需求文档也有大有小，小到直接一句话描述，大到上百个原型页面，好几万个字。 一句话的需求我们在这就不说了，我们说下正常的需求文档。 不论是使用Axure还是word，也不论需求大小是什么，PRD文档中一般需要包含以下内容： 1. 文档修改记录 需求文档在需求评审、研发、测试过程中一定会改的。 比如说加个限制，补充个遗漏的逻辑等等，不过我们一定要记录下修改内容，并及时更新需求文档、及时同步项目成员。 一般通过表格展示出以下内容： 修改内容：说清楚修改的哪个模块，哪个页面、哪个功能点。当然也可以分成修改模块、修改页面多个列。 修改原因：就是为啥要修改，比如说逻辑缺失需要补充等等。 修改人：谁改的。 修改日期：修改时间。 在使用Axure时，我们可以在文档修改记录中加上文本链接跳转，项目成员点击文字可直接进入到对应页面查看。 对于word，也是同样的，加个文档修改记录。 对于文档修改记录，不仅在PRD文档中可以用到，在写其它文档时都可以加上，比如操作手册。 2. 项目背景 or 需求背景 背景同样也是有大有小，对于新项目，则需要介绍下整个项目的大背景。对于每个需求，我们同样也可以简单说下需求背景。 参考格式如下： 当前的现状是什么，有哪些问题/痛点，这些问题导致了什么结果，为了解决这个问题，我们需要采取什么动作，达到什么目的，能够获取哪些收益，产生什么价值。 3. 名词解释 如果有专业名词，一定要写上。 在不同行业、不同公司、不同团队中都有专门的名词，项目成员是不明白一些名词的，这个时候一定要说明。 比如说抗菌药物DDD值，绝对的专业名词，不说一般没人知道。 另外在说名词解释的时候，尽量加上示例说明方便大家快速理解。 4. 流程图 当涉及跨角色、跨系统、跨模块、多判断逻辑时，我们一定要画出来，让各方更快地了解产品流程。 流程图同样有大有小： 包括整体产品业务流程图、单个模块的流程图、单个功能的流程图。 1）整体流程图 为了将这个产品的功能业务串起来，可以不用画的太详细，画出大的概览图，从大而全的角度将这个项目表达出来。 一般是在0-1的新项目中画，日常迭代的需求中不需要。 2）单个模块功能的流程图 当一个功能模块功能很多时，为了将模块内的功能串起来，说清楚单独模块的流程，这个就要画的细致一点。 当涉及到新的模块时一定要画。 3）单个功能的流程图 对于复杂的单个功能，涉及到的处理逻辑比较多时，我