A. 如何撰写PRD文档
prd文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
开发工具推荐 ：
Rational Rose★★★★－－熟悉项目发生的相关业务行为。
visio 2007★★★★－－将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一
mind manager★★★－－把项目条目化，条理化，目录结构具体规定好。
Axure★★★－－前台结构布局，合理规范的将系统脱去朦胧的华纱。
Word★★★★★--穿针织网，把需求综合起来，整理成最终的产品需求文档。
也就是用以上任意一种软件都可以打开，不过应该有版本要求。
B. 简单介绍下PRD、Visio、Axure这几个软件的功能
PRD产品需求文档(Proct Requirement Document，PRD)的英文简称。是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。 [编辑本段]文档作用 该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。 [编辑本段]文档意义 该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。 [编辑本段]文档撰写 在该文档中，基点依然是MRD中的内容，只是把重心放在了“产品需求”上，而产品需求本身实在MRD中有所体现的，区别就是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。
这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。
文档核心：
该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。
在一些国外的公司，是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing & Proct Requirements Document”。 [编辑本段]错误认识 1）PRD无原始数据（MRD为体现载体）支持，只是个人经验、部门要求或者领导指示进行撰写。
2）在PRD中，只重视“产品功能”的描述，而缺乏对产品其它指标项的说明。在一个完整的PRD中，一共需要对产品的10个产品需求项指标进行说明，分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其它要求”。
3）照搬国外的PRD模板，来源于何处，不知道，将去向何处，也不知道，无头无尾，一个被割裂的文档。 VISIO概述 Microsoft Office Visio 2007 是微软公司出品的一款的软件，它有助于 IT 和商务专业人员轻松地可视化、分析和交流复杂信息。它能够将难以理解的复杂文本和表格转换为一目了然的 Visio 图表。该软件通过创建与数据相关的 Visio 图表（而不使用静态图片）来显示数据，这些图表易于刷新，并能够显着提高生产率。使用 Office Visio 2007 中的各种图表可了解、操作和共享企业内组织系统、资源和流程的有关信息。 Axureaxure 概述Axure RP 能帮助网站需求设计者，快捷而简便的创建基于网站构架图的带注释页面示意图、操作流程图、以及交互设计，并可自动生成用于演示的网页文件和规格文件，以提供演示与开发。
C. PRD文件用什么软件可以编辑
把后缀名直接改成JPG
D. 产品经理应该怎么写BRD、MRD、PRD（需求文档）呢
因为内容较多，我就简要说一下写作目录
BRD文档
01 BRD说明
概念：BRD文档是产品生命周期中最早的文档，是我们产品定义阶段的汇总。
用于：说明市场分析，销售策略，盈利预测，产品构思等。
目的：说服领导及同事为此项目提供资源支持。
02 BRD撰写
撰写结构：方案背景、产品规划、运营规划、收益&成本、盈利模式、风险&对策
整体结构梳理如下：
1. 方案背景
描述背景的所有的数据最好注明数据来源。可以通过上市公司财报，艾瑞咨询，或一些知名网站的采访文章来获取数据，甚至是内部人士的消息，都是重要的参考来源。
基于整个行业，描述以下内容：
(1)行业背景和现状
(2)商业价值/市场规模(开辟新市场的情况下)
(3)用户需求
(4)盈利模式
(5)发展趋势
(6)竞争对手发展情况
2. 产品规划
产品规划主要是包括对于产品的定位、产品的核心目标、产品的结构和迭代路线进行一个整体的呈现。这部分内容可以借鉴产品的迭代更新文件(如果有的话)，主要是基于当前产品的规划，描述以下内容：
(1)产品定位
(2)核心目标
(3)产品结构
(4)产品路线
3. 运营规划
完整的运营规划，包括内容运营，用户运营，社区运营，活动运营，产品运营五个方面，但是并不是所有的产品都会占据所有的运营方式，每个产品的运营涉及的部分不一定一样，侧重点也不一样。
(1)内容运营
(2)用户运营
(3)社区运营
(4)活动运营
(5)产品运营
4. 盈利模式
简单的说，就是介绍产品将通过怎样的模式、渠道来获得收益
5. 收益与成本
6. 风险与对策
SWOT分析：优势、劣势、机会、威胁;(SWOT就不多叙述了，网站内有详细的介绍哦)
MRD文档
1、概述:包含两个点，背景和目标。
2、市场概述:描述一下你们要做的是什么市场。
2.1市场特征
从全局说说目前市场个竞品的产品定位。
2.1.1市场问题
列举市场痛点，用户在需求产生后，遇到的各个环节的问题，目前市场是如何满足的，以及那些需求点尚未得到满足?或满足不够有深度挖掘的空间。
2.1.2市场机会
根据市场的问题，分析问题，是否还有机会做这个市场?根据市场凸显的问题，举例出几种解决方案，逐一举例。
2.2市场趋势
可预见的估测评估未来市场的发展，可能会出现那种情况?出现巨头垄断?还是三足鼎立?垂直细分?020线上线下结合等等。
2.3市场细分
举例市场都有哪些细分?和这些细分相对应的产品都有哪些?
2.4市场壁垒
要切入市场，有哪些难题，有什么壁垒?
成熟壁垒。市场已经非常成熟，品牌体验已经深入人心，不细分切入几乎没用胜算。
资金壁垒。市场处于初期红海或者到了火拼时代如以前的百团大战、打车、拼车、外卖市场等。一种就是起动需要大量的资金，如京东的自建物料。
技术壁垒。如人工智能、搜索这些需要高精尖技术人才，才能实现的。
垄断壁垒。例如医疗、电信、支付等，需要国家批准的。
2.5市场紧迫性
基于市场发展的趋势，项目的启动是否需要一些特殊的需求?
3.用户需求分析:详细说明用户需求的动机。
3.1用户类型细分
说明用户群体的细分维度，对用户进行分解，可通过典型用户、类型特征特征等进行描述。不同需求用户，对产品的关注点不同。
3.2用户场景
用户发生需求的场景，和不同场景的特征。比如睡觉时、坐地铁坐公交时、开车时等等。
4、竞品分析
直接竞品
间接竞品
竞品模式分析
PRD文档
一、PRD文档头
文档名称、作者或则撰写人、文档编写日期、版本纪录、目录。
二、PRD文档内容结构
PRD文档内容结构包括：概述、产品需求说明、产品流程说明、产品结构和功能说明、其他产品需求、上线需求说明。如果需要的话有相关文档，附件说明。
1、概述
从大的方向，讲讲项目的相关背景、有什么目标、有没有竞品对像?而阶段性计划是什么?传递做这个需求的目的是什么?要达到什么样的目标?要达到这个目标阶段性计划是什么?
2、产品需求
落到具体的地方，产品有哪些需求?增加了哪些需求?调整了什么?取消了什么?需不需要其他资源的配合?有什么影响?，从这几个地方说清楚。
3、产品流程说明
讲清楚每个逻辑点，每个地方应该怎么走?应该做什么样的判断?如果进行这个操作返回给用户什么内容?用户触发之后得到什么内容?
4、产品结构说明
根据产品的内在逻辑，分解、细化需求，将需求细化说明。
5、其他产品需求
涉及到其他产品的产品线时，需要协同多个产品线进行多方面考虑。协同调整，避免出现遗漏，出现不必要的偏差。
6、相关文档
如果一个项目分解成多个团队。多个需求文档协同合作。如一个UGC社区，有PC端社区，有APP端社区。
7、上线需求
测试通过的需求，具体的上线时间，具体一些特殊的流程需求等。
8、其他需求、附件
作为需求的一种补充，对一些需求进行补充说明，或者需要的文件说明等
欢迎来起点学院学习更多产品文档写作方法
E. PRD格式的文件用什么软件制作编辑啊
Foxit Pdf Editor 2.0 build 1011 汉化版 PDF文件编辑软件
这个大小仅有2M不到的软件可以简单地实现PDF的阅读和创建修改工作.不过扩展功能什么的就不多了,并且不支持中文,而这可以通过安装中文包实现.
F. prd，prd文档用什么软件做
我用的摹客iDoc，感觉是为产品经理量身打造的文档工具，支持在线撰写或上传本地文档。
文档可以和Mockplus、Axure的原型图和Sketch、Adobe XD、PS的设计稿互相引用，相互论证。也支持自动生成历史版本，可随时追溯和查看。完成后可以直接生成链接分享给同事，同事可以在上面选中文字评论，审阅很方便，哪里有问题也可以随时查看修改。
G. 用axure原型中用什么写prd
1、我自己画的工具，参考了网上的部分信息
2、使用图片，思维导图等工具来实现
H. 如何快速写好基于AxureRP原型的PRD文档
大公司才会有交互设计师这个岗位，也就才会有交互设计稿这种文档产出，一般的公司都是只有产品设计师、需求分析师、商务分析师或者产品经理这样的岗位，这个岗位基本会包办了从需求收集，需求分析，需求设计，原型设计，编写PRD这样的一个过程，所以说小公司比较锻炼人，会练就全能的本事。编写PRD文档是个较为苦命的工作项，具体的编写要求参见《如何书写好的产品需求文档PRD》，这份文档将会作为产品的指导性文档，告诉开发、测试产品的需求点，实现的要求，验证的逻辑，运营人员也需要参考，以获知当前产品所能达到的功能层次。写文档的时候事无巨细吧，人家会嫌你写的太繁琐了；写的太简单吧，人家又会嫌你没说清楚该说的；开始使用敏捷模式要求文档弱化了，但其实只是在过需求的时候不需要提前先把PRD写好，事后还是得补的；写文档耗掉的时间多了，人家会说能否除掉一半，功能需求都确认好了，你只是将它描述出来为什么要用掉那么多的时间？凡此种种，都让做产品的我们感觉命怎么这么苦，因此开拓一种写PRD的新思路新方法是相当有必要的。现在都讲究用工具来辅助，工具用的好，确实能事半功倍，那要是工具用的不好呢？那就只能自求多福了。原型设计软件的主要功能还是用来做原型，那是否原型演示完了之后就没有用了呢？这个我想有点工作经验的人都不会这么认为，当然我们还是可以发挥一下原型的剩余价值的。大家都知道，如果一份文档里面可以图文结合，所描述的东西更能吸引到人去阅读，也更能帮助别人理解。AxureRP所设计的原型支持HTML格式的浏览，相较于其他原型设计软件直接产出图片，AxureRP的原型即可以直接导出成图片格式，也可以通过在浏览过程当中用截图软件来截图的方式使用，当然后一种方式更为繁琐，后面说明为什么直接生成图片反而不方便。 使用AxureRP自带的文档生成功能去生成PRD文档这点我在之前写AxureRP使用教程的时候有提到过，AxureRP是支持通过即定的word模板格式来导出生成文档的，可以参考《AxureRP教程–生成规格说明书》。不过使用这个功能对自身的要求是比较高的：1、要对AxureRP所提供的注释功能非常熟悉，其默认提供的注释字段是国际通用的，并不适合中国国情，要根据产品和项目的需求进行修改和自定义。要了解组件注释和页面注释的使用方式，以及这些注释会出现在文档的什么位置等；2、要在做原型设计的时候就做好注释的录入，每个组件的交互，前置触发条件，后置反馈事件，以及每个页面的功能说明等，这是一项细致活，挺耗时间的，和快速原型设计的要求不大相符；且万一在确认需求的过程当中需要修改的，这个维护量也比较大；3、要熟悉word的格式排版设置，用AxureRP默认提供的word模板生成出来的PRD文档，估计不符合大多数公司的文档编写要求，如果没有要求的则可以直接使用，否则就得自己倒腾一个word模板出来，这个对word的功底要求较高，再就是还得熟悉AxureRP里面模板导入的机制和模板使用机制；4、综上所述，这个功能虽然很强大但实际应用的较少，其实比较鸡肋，个人是已经放弃了，有兴趣的朋友可以深入研究一下，到时分享一下； 基于AxureRP原型的PRD文档编写这个方式其实就是截图，然后用截图+文字的形式来书写PRD文档，有人就说了，图片制作软件那么多，为什么非得用AxureRP来做原型，还得截图呀，这里有个已经使用AxureRP的前提：1、AxureRP提倡快速原型设计法，可以大大减少原型设计的时间，这是选择使用AxureRP的一个原因；2、AxureRP支持HTML格式的浏览，极大的方便了原型的演示效果，可以很清楚地告诉演示对象每个页面的跳转，每个按钮的操作效果，每个连接点击结果等，这是选择使用AxureRP第二个原因； 当然AxureRP的优点不止于此，原因可能很多，但主要的是这两个方面，这两个前提决定了我们当前都是使用AxureRP来做原型设计的，然后再讨论如果在已经使用AxureRP的情况再来优化截图写PRD的方法，否则就没法进行下去了。1、为什么是HTML格式页面的截图而不是直接导出图片？这个从操作层面上来讲，导出图片的模式操作流程如下：导出为图片>>>打开word>>>选择插入菜单>>>选择插入图片>>>搜寻图片所在文件夹>>>选择图片>>>点击按钮完成插入图片操作；或者是下面这种方式：导出为图片>>>打开图片所在文件夹>>>选择插入图片并打开>>>复制图片>>>打开word>>>粘贴图片完成插入图片操作；这个比上面的省一个步骤；从HTML页面截图的模式操作流程如下：打开对象所在HTML页面>>>用截图工具截图>>>复制所截图片>>>打开word>>>粘贴图片完成插入图片操作；对比一下就知道，用截图的方式所需的操作步骤是最少的，也就是最能节省时间的，这里推荐一个截图工具：Snagit（下载地址），可以对所截的图进行一些简单的编辑，比如画个圈圈提示一下，画点箭头什么的。2、基于AxureRP原型截图这种方式更能适应需求变化。大家都知道AxureRP是支持单个页面的修改单个页面重新生成原型的，不需要整体原型重新生成一遍，这样某个地方修改了，只要重新生成一下原型，然后再截图修改即可，而导出图片的方式AxureRP只支持导出主页和导出全部页面两种方式；3、截图工具的辅助功能，上面也提到了，可以对图片做一些必要的处理； 这是截图+文字的模式，有了截图之后，编写描述文字应该就方便很多了，避免出现大段的文字。另外PRD编写一般都是有格式要求的，有些内容不能用工具来解决，一般一份PRD文档要包含以下这些内容：1、概述部分：简单介绍一下产品的背景，产品的价值或者愿景，产品的简单介绍，一些预估的风险点，干系人，名词解释等等；2、业务需求描述部分：定义好目标用户群体，业务流程图，业务架构图，脑图等等的介绍；3、功能需求描述部分：这部分才是用到上面所述方法的点，每个功能点都可以用那样的方式描述；4、非功能需求描述部分：与产品相关的一些辅助功能，性能要求、易用性要求等等；5、接口描述部分：与外部有相关接口的需要在这个部分描述；6、附录部分：培训信息、参考资料等，还可以有运营计划等等；完整的PRD文档中，最多的部分就是对功能需求的分解描述，AxureRP可以很好的支撑这个部分的全部内容，另外其实AxureRP也有流程图、UML图的功能，业务流程图、业务架构图等都可以在AxureRP里面实现出来。基本上我自己目前就采用的是如上的方式来编写PRD文档，在原型已经设计好并演示确认了的情况下，编写PRD文档一般都比较快速，30页到50页之间的文档，如果时间利用充分的话，可以在1天到1天半之内搞定。产品经理都是很忙的，时间挤挤总会有的，要在有限的时间内做更多的事，一是要充分利用工具，二是要发掘一些新的方法，双管齐下，应该就可以找到适合自己的Style！作者博客：IT民工（若无特别注明，雷锋网文章皆为原创，转载请注明出处)
移动互联网创业和创新 雷科技
汇聚全球面向未来的创新科技产品 爱搞机
玩智能手机就上爱搞机 超好玩
推荐超好玩的移动游戏
超好玩的推荐移动游戏 左林右狸
雷锋网创始人林军、笨狸二人转
负责八卦和无厘头，绝不卖萌！
I. .PRD格式的文件用什么工具打开
一种图片格式
这是转换器
可以转成BMP JPG之类的
http://www.onlinedown.net/soft/21413.htm
J. 如何写出好的PRD
首先，先了解清楚PRD的阅读对象，使用者。
PRD的模版中一般有如下信息：
PRD预期的读者包括：产品、开发、测试人员及相应的负责人和用户方代表。产品、开发、测试人员会从中了解到本次需求的背景和详细要求，以及每个需求点未来的优化方向或对用户的价值。而用户方代表则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求，是否符合以及是否都覆盖到了自己的预期。因此PRD也是产品经理同相关角色确认开发任务的重要依据。当所有角色认可了PRD中的内容后，这份PRD将作为后续开发、测试、需求验证的依据。
其次，一个完整的PRD还应该具备的要素有
1、文档的命名和编号
文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆。
2、文档的版本历史
包括，编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版本(或第几次修改，一次修改一般为一个版本)，章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观的了解原因。日期是指需求文档修改的时间，修改人是指需求内容的修改者。
3、目录
不需要自己新建，文档完成后直接更新模版中的目录即可。目录是用来了解文档结构的
4、引言
这部分的内容有：产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明
产品概述：解释说明该产品研发的背景以及核心功能。
预期读者：文档的使用对象
成功的定义和判断标准：旨在说明产品的目标
参考资料：PRD的参考资料
名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。
5、需求概述
需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等
需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。
用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明。
运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。
设计和实现上的限制：比如控件的开发环境、接口的调用方式等等
项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等等
产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。
6.功能需求
功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：
简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。
场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件
使用者说明：对产品使用者做出说明，可融入简要说明中。
前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。
后置条件：操作后引发的后续处理。
主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明(这是非常重要的)。
推荐一个方法：“用例”，在面向对象的软件设计模型中，用例是一个被阐述的内容，用例是对功能使用场景的解释。用例很条理的介绍了每个功能的前置、后置条件，主流程介绍，帮助开发、测试等角色快速的了解产品功能。
7、可选方案
列出所有可以选择的达到该产品目标的方案要点(主要思路)，给各方案适当的评价，并推荐最优方案(在功能需求中描述的)。你在做这个产品规划时一定有很多的备选方案，别放弃这些方案，永远没有过时的idea，只有最适合时机的idea。所以可以写出几个可选方案，或许是你下期产品改版一个方向。记住，多思考方案是永不为过的
8、效益成本分析
通过这一点上能看出产品经理必须是个全才，不仅要具备行业知识，还需要有财务知识。一个产品的成本衡量一般包括三个方面：效益预测、产品技术成本和其他成本支出。
9、整合需求
产品整合能力是产品经理很重要的一个能力，业务合作通常是不可避免的，将隶属于两个不同来源的业务功能做整合也是常见需求，比如系统登陆使用公司的域用户登陆，或者付款使用财付通、支付宝付款，解决好整合需求也是体现产品经理核心竞争力的一大重要表现。
10、BETA测试需求
很多产品在正式上线前都有BETA版本或者内测版本，或者叫灰度版本，目的是在测试产品的一些核心功能或者性能。这部份内容不是必须的，但如果需要，需要给出在此阶段要实现的目标或测试、衡量标准。
11、非功能性需求
一般情况下非功能性需求包括以下几个部分：产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。这些信息构成了产品上线的完整内容，也很好的体现了产品经理的综合素质。
12、运营计划
产品上线后如何运营，目标受众是什么，建议的推广策略、问题反馈途径、风险监控、亮点宣传等等，以及与运营人员的协作方式。作为产品的设计人员不是开发完产品就能画句号的，让产品用起来、用得好，有口碑更为重要，所以非常建议运营计划的制定上有产品设计人员的参与。