市场需求文件（MRD）简介、框架、模板

MRD指Market Requirements Document即市场需求文档

主要功能：是描述什么样的功能和特点的产品可以在市场上取得成功

        目标市场分析

        目标用户分析 

        竞争对手分析

        产品需求概况

        通过哪些功能来实现商业目标

        功能性需求和非功能性需求

        需求的优先级

主要是给产品、运营、研发等业务线上的人看的，在需求被一致认可后，来商量该怎么做、如何做、什么时候做

BRD：Business RequirementsDocument，商业需求文档产品生命周期中最早的文档，内容涉及市场分析、销售策略、盈利预测等，通常是和老板过的PPT，比较短小精炼，没有产品细节

主要是产品、运营、研发等的管理层。要讲清为什么有这个需求，需求的边界和业务目标，所需资源等。

PRD：ProductRequirementsDocument，产品需求文档。进一步细化，是PM写的最多的内容，也就是传统意义上的需求分析，主要内容有功能使用的具体描述。

给单个职能单位看，沟通非常具体的实施方案

先有BRD，决策是否要开始一个产品。再有MRD，决策如何开始一个产品（when、how）。最后是PRD，决定要开始的产品具体是什么样的（what）。

BRD比较笼统的说是我们要做某件事，并说明做这件事的好处，相当于抛出一个论题。MRD相当于用论点支持我们的论题，具体论述我们该通过什么样的方式来达到我们的商业目的，在一系列分析以后，拿出可行性办法，输出指导性的文档。PRD则是具体的论据，如何具体实施产品方案。

MRD主要就是围绕当前市场、用户、竞品、自身产品四个因素做分析，得出相关结论

市场需求文档（MRD）

文档说明

市场分析

用户分析

竞品分析

产品分析

包括 文档基本信息 和 版本修改记录 。

文档基本信息包括产品需求名称、文档创建日期、创建人／联系方式、部门／职位。

版本修改记录包括日期、版本、修改人、修改内容、备注，一般以表格的形式出现

包括市场问题现状、目标市场分析、市场分析结论

A市场问题现状

现有市场存在问题才有机会，有机会才有可能去做。

就互联网而言可以从以下（不限于）几方面来选择性表述：

用户方面（例如：用户需求没有得到充分满足）

产品方面（例如：产品设计体验差）

技术方面（例如：图像识别技术存在难点）

运营方面（例如：缺乏必要的市场曝光）

商业模式方面（例如：有更有效的商业技巧）

B目标市场分析

很多行业的市场都很大，选择其中最有机会最可能成功从市场。例如互联网金融市场，互联网金融市场里又细分为互联网保险市场、p2p等，p2p里又分为专门做车贷、房贷的，每一个都各自成为一个市场，组合在一块是个大市场

目标市场分析的三个角度：市场规模、市场特征、发展趋势

市场规模大不大，鱼塘里的鱼够不够多，值不值得我们卷起裤子下去捞　相关的数据和分析报告可以从易观智库、企鹅智酷、比达咨询等数据网站获取

市场特征是指市场现状

发展趋势相关行业的最新政策消息、各种智库的相关数据和分析报告

市场分析结论综合上述的分析内容，得到一个比较有市场商业价值的结论，否则这个文档就没有存在的意义。结论得出选择这个市场会带来多大收益，能有多大把握，证明该市场有价值，值得去做。

 目标用户群体

 用户画像构建

 用户使用场景

 用户动机目标

A目标用户群体

年龄

性别/地域/学历

经济条件

生活习惯

B用户画像构建

用户画像既不能太粗，也不能太细，需要具有代表性

  a用户信息：昵称、年龄、性别、收入、职业、居住地

  b用户特征：性格、爱好、技能、习惯

C用户使用场景

用户使用场景就是描述用户在某个环境下完成了某个任务的故事。类似小学记叙文三要素：时间、地点、人物、事件。最终要明确用户在什么场景下会想起你的产品，又在什么场景下使用你的产品

D用户动机目标

分析用户动机的时候，要区分表面动机和本质目标。例如，想吃米线是表面动机，填饱肚子是本质目标。

 竞品对象

 竞品基本情况

 竞品优缺点分析

A竞品对象

寻找竞争对手的关键是要找全找准，不要把眼光局限在同行中

直接竞争对手

间接竞争对手

例如：摩拜单车的直接竞争对手包括ofo、小蓝单车……；间接竞争对手包括滴滴、地铁、公交……

B竞品基本情况

 背景历史

 市场现状

 目标用户

 运作/商业模式

 运营推广策略

C竞品优缺点分析

竞品的优点能否继承，缺点能否规避，判断是否有机会超越竞品

 产品定位

 产品核心目标

 产品结构

 产品路线图

产品功能性需求

 产品非功能性需求

A产品定位

一句话描述你的产品是做什么的，我们用什么样的产品满足用户或用户市场。

B产品核心目标

产品帮助目标用户解决什么问题。

解决核心目标的工作优先级是最高的，明确产品目标有助于整个团队专注不迷失。

C产品结构

为了满足用户需求、完成产品目标，需要哪些方面的物料准备。

D产品路线图（roadmap）

产品路线图是产品成长中的每个任务节点组合而成，是以任务为导向的时间节点图。将目标拆分，在不同阶段完成不同的功能。Roadmap的形式非常多，可以是甘特图，也可以是泳道图。无论用那种形式的路线图，必不可少的元素就是时间、任务，必要的时候科技增加子任务和里程碑。

E产品功能性需求

一个产品的重点功能罗列。这里需要主要，MRD只能做功能罗列，不讲具体功能实现逻辑和方法。

F产品非功能性需求

 性能需求

 安全需求

 扩展性需求

 兼容性需求

 运营市场需求

1.不同的公司、项目要求是不一样的，在敏捷开发的时代，即使是PRD也并非必需品，更何况是MRD，但这并不代表着MRD的内容就不用思考。

类似MRD的内容的思考一定会而且一定要有，只不过不再通过文档的形式表现，敏捷项目对制作MRD文档这一步骤省略的目的在于提高效率，但类似MRD的思考一定存在。

2.BRD／MRD／PRD哪个更重要？如果少做，可以少做哪个？

BRD肯定是最重要的，因为要说服老板或投资人投入，MRD是最有可能被省略的，因为一线员工往往更关注具体怎么做（PRD）。

3.一般谁来写MRD？

产品实习生、产品助理、基层产品经理一般是不写MRD的，更多的是PRD，只有高级产品经理、产品总监才会主要写BRD和MRD。

4.MRD的重点内容是什么？

重点内容：目标市场分析、目标用户分析、竞品优缺点分析、产品功能性需求。

总之MRD要重点论证出为什么要做和要做什么。

6. MRD一般写多少，用什么文档格式写？

MRD的内容很多，如果都详细写的话，甚至可以出本书了，这种情况下，写的人累，看的人也累，因此实际工作中往往根据需要进行缩减，格式上更建议PPT，重点突出。（详细叙述用word，突出重点用PPT）

本节课重点讲解了MRD的结构可内容，所谓的模板仅供大家参考。在实践的工作中，切忌照本宣科、生搬硬套，要根据自身所在公司的情况，酌情增减内容，重点内容多写，次要内容可以少写甚至不写，把握住用户问题和产品机会这个重要的目标来组织我们的MRD，要突出MRD的作用，而不要为了走形式，让MRD成为一纸空文。

撰写自家产品的MRD文档？

模板：

公司名-产品名-MRD-版本号

**公司 版权所有

版本记录

1、产品需求名称

2、目标市场分析

2.1 目标市场：

2.2 市场规模：

2.3 市场特征：

2.4 发展趋势：

3、目标用户分析

3.1 用户分析：

3.2 用户画像：

3.3 使用场景：

3.4 用户动机总结：

4 竞品分析

4.1 直接竞品

4.2 间接竞品

4.3 竞品的模式分析

竞品的商业模式。

竞品目标用户。

竞品运营、营销、推广策略。

技术分析。

市场份额。

5、产品需求概况

5.1 产品定位

5.2 产品核心目标

5.3 产品的结构图

5.4 产品路线图

5.5 产品的功能性需求

5.6 非功能性需求

总结：

什么是PRD?

prd文档是指产品需求文档，而产品需求文档是将商业需求文档和市场需求文档用更加专业的语言进行描述；prd的主要使用对象包括开发、测试、项目经理、交互设计师、运营及其他业务人员。

该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。

广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。

产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。

什么样的系统需要进行非功能性需求分析

用户需求一般分为功能性需求和非功能性需求。

非功能性分析是对功能性分析的补充。

如性能分析。用户界面要求分析。或其他特殊要求分析。

什么是非功能性测试？

非功能测试是一种用于检查软件应用程序的非功能方面（性能，可用性，可靠性等）的测试。它旨在根据功能测试从未解决的非功能参数来测试系统的准备情况。

非功能测试的主要包括:

1、可靠性。软件使用者期望软件能够无误运行。可靠性是度量软件如何在主流情形和非预期情形下维持它的功能，有时也包括软件出错时的自恢复能力。例如，自动定时保存现行文件的功能就可以归类到可靠性。

2、可用性。如果用户不明白应该如何使用，那么，即使是零差错的软件也会变得毫无用处。可用性测量的是用户学习和控制软件以达到用户需求的容易程度。进行可用性研究、重视顾客反馈意见和对错误信息和交互内容的检查都能提高可用性。

3、可维护性。可维护性描述了修改软件而不引入新错误所需的工作量。产品代码和测试代码都必须具备高度的可维护性。团队成员对代码的熟悉程度、产品的可测性和复杂度都对可维护性有影响。

4、可移植性。可移植性指一种计算机上的软件转置到其它计算机上的能力。软件移植是实现功能的等价联系，而不是等同联系。从狭义上讲，是指可移植软件应独立于计算机的硬件环境；从广义上讲，可移植软件还应独立于计算机的软件，即高级的标准化的软件，它的功能与机器系统结构无关，可跨越很多机器界限。

如何获取和分析非功能性需求

基于以上分析，本系统没有明显的质量属性冲突。 第三步：确定这些质量属性的优先级。 这个优先级是根据各个质量属性对系统的影响程度来定性判断的。一般来讲，影响安全生产的要素要高优先级考虑，其次是影响企业经营的要素，最后考虑哪些支持性的要素。因此，该案例的软件质量优先级排序如下：1.安全性2.持续可用性3.易用性4.可维护性5.可扩展性、可移植性、可重用性、可测试性。 第四步：筛选关键的软件质量属性。 一个系统关键的软件质量属性和质量目标不可能太多，一般视系统的规模从2-5个不等。因此，该案例的关键软件质量属性可以选择前三个：1.安全性2.持续可用性3.易用性。 （二）获取和分析软件约束的过程如下： 第一步，获取约束。可以从以下4个方面获取软件约束。 （1）来自业务环境的约束，如：与其他系统集成、预算限制、上线时间紧等 （2）来自使用环境的约束，如：用户群特征（知识水平、语言能力、操作习惯等），系统运行环境（干扰、网络质量、移动性等） （3）来自构建（开发）环境的约束，如：开发人员的素质（技术水平、学习能力、）、团队分布等 （4）来自当前技术环境的约束，如：技术平台、中间件、编程语言等等。 第二步，分析约束，发现功能性需求和软件质量属性。 案例：某公司欲开发一个全球农产品C2C电子商务项目，主要功能是提供一个便捷、快速的交易流程。投资5000万用于初期开发系统、运营和市场营销。先期估算买卖会员一年内可以到达20万，以后计划每年确保50%的会员增长率。该系统拟采用支付宝和快钱进行第三方结算。目前这两家公司向其他客户提供Web服务接口。承接方希望在年度内完成开发，因为他们下一年要被一家外资公司执行收购。 第一步，获取约束 业务环境存在哪些约束？投资方投资额限制、会员增长率、第三方系统集成要求 。 使用环境存在哪些约束？全球农民或农场主为系统的使用者，隐含一个设计约束：系统操作简单。有些农村地区网络质量差，带宽小。 构建环境存在哪些约束？系统开发商有对开发时间的限制。 技术环境存在哪些约束？可能以Web服务方式集成。 第二步，分析约束，发现功能性需求和软件质量属性。 直接的设计约束：以Web服务方式集成，开发周期，多语言版本等等。 可引出功能需求：“主要功能是提供一个便捷、快速的交易流程”，并且，全球农民或农场主为系统的使用者，这就要求系统能够进行产品快速搜索和产品比价。 可引出质量需求：“有些农村地区网络质量差，带宽小。”在网络环境差的条件下保证系统的可用性等。