主要涉及的文档是产品需求文档（PRD），内容有：
工具：markdown、Axure、visio、墨刀、xmind
写作前准备
梳理需求
原型设计
撰写文档
用例文档
http://www.woshipm.com/pd/80054.html
写作前准备
PRD是基于BRD、MRD的延续文档，主要用于产品设计和开发测试使用，因此阅读人群大多数是设计和技术人员。在这类人群中，设计师跟多依赖于原型进行交互或视觉设计，因此看这份文档的人就会偏向于技术人员。相对于技术人员，他们不太援助产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员跟多的关注界面，功能，交互，元素等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。
所以规划产品的第一步就是梳理出产品的信息结构，有了信息结构我们才能继续往下规划产品结构，并且信息结构是服务端技术人员创建数据库的依据，是数据机构的辅助文件。对于新产品或者新功能，没有人能够比产品经理更加清楚所需要的信息内容了，因此第一步我们就需要先将这些信息罗列出来，形成结构化。
梳理需求
上一节说到信息结构，罗列出产品的所有信息内容，现在我们就要依据信息结构开始规划产品的功能需求，绘制出产品结构图和用户流程图。首先我们要规划处产品的频道和子频道、子模块或子页面：
然后就是用户流程图，用于展现产品经理脑海中的比较抽象的产品逻辑，也就是产品经理对自己的产品想法进行梳理的一个过程：
这样做的目的是梳理产品逻辑，让我们清楚知道产品有几个频道，频道下面有没有子频道或者子页面，有无疏漏，可以对整个产品做一个鸟瞰式的查看。而且修改起来比文档或者原型方便很多。也易于给开发人员灌输一个整体框架。
原型设计
前两节帮助我们结构化梳理，接下来进行可行性推演，验证是否可行，花费多少资源，原型设计帮我们更加细致的考虑。
撰写文档
PRD文档没有标准的规范，也没有统一的模板，每个公司不一样，取决于团队要求和个人习惯。但是也有两项是必不可少的，那就是文件表示和修改记录。文档在撰写过程中，我们自行不断修改完善，但是如果正式交付给团队其它人员后，一旦有了修改，为了文档的同步，我们就需要标注出文档的修改内容，备注修改记录。关于标识和修改记录：
word文档
传统意义上的PRD文档，主要有四个部分组成：结构图、全局说明、频道功能、效果图。前面说过，这是给技术人员看的说明文档，所以最简单明了，用最少的文字交代清楚最好，大多数技术人员没有足够的耐心认真看完PRD文档。
1）结构图：
2）全局说明：主要讲解产品的全局性功能的说明，例如网站产品的页面编码、用户角色、移动产品的缓存机制、下载机制，这类全局性功能的说明，这里举一个例子：
状态的维持与恢复
当用户退出产品时（误操作、Home键、锁屏、自动关机），产品需要维持用户操作前的状态，当用户返回产品时仍可以恢复到之前状态，并继续使用。
维持状态包括流程操作、信息浏览、文本输入、文件下载。
锁屏状态时，如果用户在产品中有下载任务时，仍然保持下载。
3)频道功能：以频道为单位，页面为子项，分别描述产品的频道、页面及页面模块元素的功能需求(格式如下)。
示例格式
1、频道名：频道介绍及需求说明
2、页面1：页面介绍及需求说明
2.1、页面模块1：模块功能需求说明
2.1.1、页面模块1-元素1：功能说明
2.1.2、页面模块1-元素2：功能说明
2.2、页面模块2：模块功能需求说明
在撰写功能需求时，我们需要考虑用户的流程，例如一个“完成”按钮，我们需要描述他完成后，系统要不要给出反馈提示(反馈提示是什么样的形式反馈，内容显示成什么，有没有内容需要调取数据库)，或者要不要跳转页面(跳转到哪个页面，这个页面是其他频道页面，还是这个功能的子页面，如果是子页面就需要再描述这个子页面的模块及元素内容)。
4)效果图：效果图是由设计师完成的产品图，和实际开发完成的产品保真度一致。
用例文档
在产品和技术领域里都有UML的技能知识，而对于出品人月的UML则更多的是指用例图，也就是我们所说的用户流程图。
用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。
用例文档中有两个关联文件，分别是用例图和流程图。用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。
写用户文档的常用软件是Word，其中用例图和流程图的制作软件常用的是Visio，当然也有用Axure RP软件制作的，例如下面的第三步流程图就是用Axure RP制作的。
一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。
用例文档的大概组成部分如下：
1、修改记录：每次修改的备注记录，同PRD文档。
2、角色介绍：描述参与系统中的各个角色
3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。
用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。
1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。（如下图）
2、第二步是以用例图的方式注明角色在前后端的用例关系。（如下图）
3、第三步是以流程图的方式注明角色在各个功能环节的活动过程。（如下图：以活动报名为示例）
4、第四步则是以用例文档的方式将以上三步整合到一起，并撰写各个功能环节的用例描述。（如下图）
表格说明：
4.1、用例名：此功能环节的名称
4.2、用例编号：在此产品中该用例的编号
4.3、行为角色：参与或操作(执行)该功能的角色
4.4、简要说明：用最少的文字描述一下该用例的需求
4.5、前置条件：参与或操作(执行)此功能的前提条件
4.6、后置条件：执行完毕后的结果条件
4.7、流程图：该功能的角色活动过程(处理过程)图（第三步中的图）
上面示范的用例描述相对简单，也是最常用和基本的用例描述内容，当然也有稍微复杂一点的用例文档，文档中会详细描述使用场景、事件流和信息字段，也有一些用例文档还会插入产品界面效果图。
使用场景主要描述行为角色在不同情况下使用产品时，根据情况或问题给出相应的系统反馈。事件流类似流程图，只不过是通过文字的方式描述角色的活动过程。信息字段主要是描述用例中所用到的数据字段。
这些更多的描述内容取决于个人的习惯，最终目的都是为了描述清晰产品逻辑，因此我的原则就是用越少的文字描述清晰越多的需求说明。（毕竟这些文档是产品开发中的执行文档，文字不在多，表达清晰即可。）