关于产品需求文档的各种D

一篇不错的文章 http://www.zhihu.com/question/19886426

 

BRD：BusinessRequirementsDocument，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。

MRD：Market RequirementsDocument，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有MindManager的思维图，Excel的Feature List等。

PRD：Product RequirementsDocument，产品需求文档。进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（usecase）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

 

另一篇 也不错 http://blog.lishibin.com/?p=926

关于各种需求文档的缩写

让我们看看产品文档的缩写都有哪些吧：

1. BRD

2. MRD

3. PRD

4. FSD

5. PSD

6. SRS

1. BRD – Business Requirements Document （商业需求文档）

“商业需求文档”即BRD，着重于定义项目的商业需求。也就是说BRD定义了一个或多个用户面对的问题，这些问题是有可能通过公司的产品解决的。完成定义之后BRD会提出一个解决方案，通常是一个新的产品或者是现有产品功能的改善。同时BRD还有可能包含了对商业模型的分析，例如利润预期，市场和竞争分析，销售/市场策略等等。BRD的作者通常是产品经理，产品市场经理或商业分析师，在一些小公司，这个文档可能会由公司高层，甚至是创始人来写。BRD的内容通常比较简短，1~3页的WORD文档，或者10页左右的PPT已经足够说明问题了。

举例：

让我们假设你的公司正在开发一个用户关系管理系统（CRM）。这个系统是协助其他公司的销售经理如何跟进产品销售过程，并分析得出关于销售的靠谱的预期的。那在这种情况下我们的BRD应该怎写呢：

A. 谁会面对这些问题？

• 世界五百强的销售经理。

B. 他们面对的时什么问题？

• 无法实时的查看交易进行状态；
• 无法分析出一个可信赖的销售预期。

C. 建议的解决方案是什么？

• 创建一个基于页面的系统，能够查看实时交易进行状态，并分析出一个可信赖的销售预期。

2.MRD – Market Requirements Document （市场需求文档）

MRD主要用处是定义市场需求，可能是针对一个新产品也可能是旧有产品的一个增强型的功能，与BRD不同的是，BRD是对于商业问题和解决问题的方法的简要定义，而MRD则更加的细节，他可能包括以下几点：

a. 解决这个商业问题的功能需求；

b. 市场和竞争对手分析；

c. 功能与非功能需求；（所谓非功能需求包括性能要求等–译者注）

d. 功能需求的优先级；

e. 需求用例。

写这个文档的人一般是产品经理，产品市场经理或者商业分析师。MRD文档一般会有5~25页，甚至更多，就像下面这个例子。

举例：

让我们紧接着上面那个CRM的例子继续，MRD会定义需求，对需求进行优先级排序，同时描述需求用例。需求主要包括功能需求和非功能需求两种：

A. 功能需求：

• 必须能够在IE（6.0版本以上）和FireFox（1.5版本以上）上工作；
• 必须使用SSL协议保证通信能够被加密；
• …
• 用户能通过交互界面输入以下字段的内容：用户名称、公司名称、联系方式、机会说明、销售额度等等。

B.非功能需求：

• 能够承担十万同时在线用户；
• 系统稳定性达到99.9%；
• …
• 拥有英、德、日三种语言的用户使用说明。

请查看这篇文章来获得更多关于MRD的内容。

注：很多公司都会把MRD和PRD混为一篇文档，这样的话这篇文档的长度可能会达到50页以上。

3. PRD – Product Requirements Document （产品需求文档）

产品需求文档关注于定义新产品的需求或者旧有产品的增强性功能。与MRD不同的是，MRD往往从市场需求角度描述产品的需求，而PRD更加关注产品本身的需求，会详细描述各种特性与功能的细节，PRD中还常常包括用户界面和用户流程。如果一家公司的MRD不包括各种特性与功能的细节需求和用户需求用例的话，这些内容就会由PRD来描述。PRD的撰写人经常是产品经理、商业分析师或者产品分析师。PRD文档的长度一般是20~50页，对于一些复杂一点的产品，文档长度会更长。

举例：

让我们继续上面的CRM项目，在这个项目中PRD文档应该包括的内容是：

• 登录界面应包括用户名、密码字段，还应该有“忘记密码？”提示文字链；
• “联系我们”界面应该让用户可以输入姓名、电话、Email…
• …
• “销售预测”界面在生成年度预测报告前，应该有5个步骤，每个步骤用户都会输入一些限定条件，每个步骤的详细说明如下：……

PRD文档除了上面描述的这些功能逻辑外，还应该包括一些详细的需求用例。

注：一些公司会把MRD和PRD合并成一篇文档，如果这样的话就应该包括这里描述的MRD和PRD两部分内容。

4. FSD – Functional Specifications Document 功能详细说明文档

功能详细说明文档从具体执行的角度定义产品的功能需求，FSD会对每一个界面和功能做出非常细节的定义说明，并能够直接交付技术人员进行开发。我们再来对比一下MRD、PRD还有FSD的不同，MRD是关注于市场需求的需求定义，PRD是关注于产品本身的需求定义，而FSD是关注于定义功能的细节设计，这个设计会以技术人员熟悉的格式撰写，并直接交付技术人员进行开发，FSD还包括确定的UI设计，界面各个部分细节都已经被确定。这篇文档通常由产品分析师、技术负责人或者项目经理来撰写，总之这个文档的作者一般都隶属于技术团队。这篇文档一般是无数页的word或者其他的文本文件格式文档。

5. PSD – Product Specifications Document 产品详细说明文档

产品详细说明文档不是一个很流行的说法，不过再一些公司里的确会存在这样的文档，其内容与上面所说的FSD再大体上是一致的。

6. SRS – Software Requirements Specification 软件需求说明

这也不是一个很常用的文档，只在一少部分公司里会存在，这篇文档的主要内容类似PRD或者FSD。