关于产品需求文档的各种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。


你可能感兴趣的:(crm,文档,UseCase,Dreamweaver,产品,技术人)