11.1什么是PRD文档
-产品需求文档向上是对MRD内容的继承与发展，向下则是要把MRD文档里的各种理论要求技术化，向研发部门与设计部门说明产品的功能和性能要求。-PRD文档是产品文档中最底层最细致的文档，所以写作的时候要细致耐心。
11.2三大文档的区别与用途
-BRD：这么做有好处，说明好处在哪里-MRD：通过BRD明确了这个事情值得做后，描述应该怎么做，并说明这么做的原因
-PRD：获得了授权，而且已经确定了要走的路线，剩下的就是打造装备。
BRD>MRD>PRD是一个逐步论证并得出结果的过程，是产品进来思维升华的过程，是这三个文档三位一体的过程。
11.3PRD文档面向的对象
-研发人员-由于研发人员本身专注功能的实现与性能，所以他们相对对其它诸如运营、市场、设计等表现相对不关心，对产品更多的了解来至于产品经理的产品宣讲。
-设计人员
-设计人员本身更多的会关注于产品的调性与原型图，所以对PRD文档的需求是相对较弱的。
所以PRD文档需要用最平铺直叙最简单的话，把问题说的一清二楚。
11.4PRD文档的几种表现方式
-根据实际情况，能满足把问题讲清楚的几种方式-文字模式（word）
-原型图模式
-图片模式
-影像模式
11.5Axure原型图描述功能
11.6Axure说明导出成Word文档
11.7常见PRD文档包含内容
-文档说明-产品说明
-全局功能说明
-详细功能说明
11.7.1文档说明
-产品版本号-版本号（1.26）1
-重大调整升级
-产品结构功能等有调整
-子版本号（1.26）2
-在原有基础上对局部功能进行升级或调整
-修正版本号（1.26）6
-局部小范围优化与Bug修复
-一般是动功能性的东西
-版本号的命名原则
-归零原则：前一个数字增加一位，后面都归零
-收费原则：子版本号和修正版本号的变化，一般看做版本内升级，只有版本号变化则加收费用
11.7.2历史修订
-编号-版本号
-修订章节
-修订原因
-修订日期
-修订人
-历史修订的作用
-对修改前后进行比较
-有利于维护和管理PRD
-修订人
-修订日期
-方便查阅，可以只看修订部分
11.7.3名词术语表
-将一些产品里不容易理解，容易混淆，或者缩写的词汇在开篇进行统一的列表说明，有利于阅读。
11.8PRD文档包含的内容
-产品说明-包含：
-产品信息结构
-信息结构图是只按照产品进来思路中的产品表现信息来整理产品的一种示意图
-信息结构能帮助我们整理产品结构，同事是研发人员建立数据库的参数
-产品结构图
-产品结构体是按照产品的逻辑与表现方式，结构化的表现产品构造的一种示意图
-通过这个产品结构图，我们大致就能将之前抽象的逻辑形象化的表现出来，也便于文档阅读者理解我们的产品思路
-用户使用流程图
-用户使用流程图用于表述用户在使用产品过程中的行为走向
-通过用户行为串联信息结构与产品结构，阅读者通过阅读用户使用流程，能更好的理解产品经理设计的用户行为。
11.9信息结构图-案列-产品100主贴与回复贴信息结构信息分析
（页面-微观）主题
发帖人
时间
内容
回帖人
时间
内容
喜欢内容
喜欢数量
11.10产品结构图-案例-产品100网站产品结构图
（宏观，模块功能）首页-版块频道-必答版块-主题详情页
版块信息-置顶帖列表-主贴列表-登录用户基本信息-热门话题
11.11产品用户使用流程图
使用操作说11.12全局功能说明
全局性的东西要说清楚，不要放在子类里。全局功能说明分类：
-UI
-交互
-等等
先加载页面，不需要加载的项目。
11.13详细功能需求描述
整体说明完成后，我们就开始对各个需求版块进行详细的需求描述-根据实际需求的表述顺序
-按功能逻辑来表述
-按产品结构来表述
产品逻辑表述需求
-产品名称
-产品流向
-产品流向页面
-页面结构
-结构元素
11.14UML>用例文档>用例图与状态图
UML常见的说明图类型-用例图-表述
-状态图
-时序图
-结构图
-等
11.15什么是用例图
用例-用例就是一种描述系统功能需求的方法
用例图
-用例图表述的是系统的外部参与者与系统之间的关系，由参与者与用例组成的示意图
-用例图的组成要素
-参与者
-用例
-关联线
-方框
11.16用例说明
用例编号界面描述
流程图
扩展流程
11.17详细功能需求描述的基本结构
-产品的整体用例图-功能板块1需求
-功能板块1的子功能1
-功能板块1的子功能1的元素1说明（用例描述）
-功能板块1的子功能1的元素2说明（用例描述）
-功能板块2需求（用例文档）
11.18详细需求说明原则
-MECE原则：相互独立，完全穷尽。也就是对于一个重大的议题，能够做大不重叠、不遗漏的分类，而且能够藉此有效把握问题的核心，并解决问题的方法。-MECE知识一种思考方式，当PRD文档撰写交付研发以后，其实多少还是会存在没有考虑到位或者需求调整的情况，所以：
-撰写PRD文档前一定要保证考虑到位了，产品结构本身短期内部会有重大改动
-需求分类与表述方式要参考MECE原则
-这样即便是在交付后，出现调整或需要优化的地方，也不会出现重构的情况
-需求撰写，更多的是考验耐心、思路、经验，但产品架构的确定等更是考验一个产品进来对产品的规划与把握能力
-不要害怕，不要迷信
11.19优秀的PRD文档应该具备的特点
-正确：确保文档中表述与产品经理的思路是对应且正确的-无歧义：文档的表述方便阅读理解，不会产生歧义
-完备：MECE原则尽量保证对产品功能需求表述的系统完整
-一致：文档中用词用语一致，对于同一事物的表述应该一样，避免混用同义词
-具有优先级：产品的功能需求是有先后主次的，对于一次性规划叫多功能的PRD，应该注明功能性需求的先后主次
-可验证：对功能性的描述，是可以进行测试的，而不是无法测试，无法定性的东西
-可修改：PRD文档便于后期的修改与升级
-可追踪：每个功能性需求的来源应该是清楚明白的
产品需求文档是产品经理的第一核心文档，产品需求文档一定要写的清楚明白，该文档是产品经理从0到1打造产品的过程，后续的研发团队也是根据该文档进行产品研发的，一旦产品的架构出错了后期改动就得付出巨大的代价。
单纯的文档在表述上可能更严谨一些，但是给用研发团队时理解起来就比较耗费时间了，一般都需要以原型图的方式给出，对细节方面不太懂得地方再去查找文档中具体的文字描述，这样才能以最快的方式让研发团队进入到对应的开发阶段。