作为PM，要知道的四类产品文档

前言：作为一名刚入职不久的产品小白来说，写文档是逃避不了的事情，并且写文档也是最快能够了解产品的方式之一了，当然了，写多少、写什么还是要取决于公司的业务。

---

1.简单介绍四种文档

产品文档不仅是说作为产品经理对当前这个产品有多了解，更重要的是为了让设计和开发部门更加有效的理解产品的功能框架，所以产品的需求文档是非常重要的。接下来就简单的介绍下PRD、BRD、MRD、FSD 这四种文档

• PRD (Product Requirements Document，产品需求文档)：PRD是对产品功能的进一步细化，是PD新人写的最多的文档。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体需求。
• BRD(Business Requirements Documents，商业需求文档)：这是产品生命周期中最早的文档，其内容涉及市场分析、销售策略、盈利预测等，通常是给大BOSS展示的PPT，也就比较短小精悍、没有过多的产品细节，有点类似于创业者的商业计划，主要是为了获得认可、争取资源
• MRD(Market Requirements Documents，市场需求文档)：在获得大BOSS支持后，产品开始进入实施阶段，也就是开始写MRD了，要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分为哪几块，功能的优先级等。而且在实际工作中，PD在这个阶段常见的产出物有产品的Feature List、业务逻辑图等，这是从商业目标到技术实现的关键转化文档
• FSD(Functional Specifications Document，功能详细说明)：比较像经常写的用例文档，经常包含在PRD中，从这开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定、比如网页上的某表格中的数字格式等。并且硬件系统的设计、数据库设计、表结构设计等工作需要架构师或者系统分析师来编写

---

2.对PRD简单分析

对于PRD应该说相对于其他三种文档算是最为常见的了，通常一个项目会有一份或者多份PRD，每一份PRD会包含逻辑相关的若干功能点，这些相关需求在“需求打包”的环节已经被识别出来，也就是产品需求列表里的若干行。如下是从网上当的PRD文档结构模板，大致如此：

对于以上章节模块简单介绍如下：

1. 修订历史：每次修订的日期，版本号、说明和作者，便于以后追溯
2. 项目概述：项目背景、意义、目的、目标等
3. 功能范围：给出PRD的业务逻辑图，描述系统中角色的职责、与周边系统的关系、全局的商业规划等
4. 用户范围：对本PRD设计的角色，系统做出简单的说明
5. 词汇表：对PRD设计的专有词汇、术语、缩写等做出说明
6. 非功能需求：如性能需求、数据监控需求等
7. 其他说明：此处可以任意发挥

总体说明之后是用例文档部分，首先要对PRD中所有用例进行说明、然后说明各个用例之间关系、一般有类图、用例图、状态图等几种表示方法，其中用例图最为关键，这块内容我会在之后的博客中进行介绍；然后是用例的正文，由一个个用例组成、这部分也就是常说的用例文档 UC ,那么什么是UC呢？

---

3.用例文档，UC

UC是需求人员写给开发人员看的一种最基本的文档，理想状态下，一个UC代表了产品需求列表里的一行，但实际上并不绝对，也可能多个UC满足一个产品需求，或者一个UC涉及到多个产品需求，在此对部分专业名称简单介绍一下：

• UC（USER CASE，需求评审）：是PRD评审、UC评审、Demo评审的统称，在需求完成以后，是PD说给开发、测试听并给出评价或批准的过程
• TC（TEST CASE，测试评审）：在TC编写完成，测试开始执行之前，由测试人员把对需求的理解以TC的形式说给PD、开发听。
• PD（产品设计、需求分析师）：PD（product designer/product director）：产品设计或产品负责人，多见于互联网等以产品为中心的行业。
• PM（产品经理或项目经理 product manager/project manager）：前者多见于互联网、快消（貌似是宝洁最先提出产品经理的概念）等行业；后者的应用可能更广泛，像工程单位也用“项目总（经理）”的叫法。

简单的附上UC模板如下：

由于UC一般只用来描述功能需求，他不便于描述诸如产品扩展性、系统容量、人员培养等非功能需求，所以一般把非功能需求部分都写在PRD的总体说明里