表现形式

一般企业内部的PRD文档选择wiki系统或word文档。wiki在协同和保密方面会有优势，而且能够记录修改文档的每一次变更。而word在阅读修改方面比较有优势，一般使用Word加SVN的方式来管理更新文档。这个可根据每个企业的管理规范来选择那种方法更合适。

主要构成

一份基础的PRD文档主要由三部分组成

　　①引言

　　引言部分主要包括：需求背景、需求目的、需求概要、涉及范围、全局规则和名词说明，交互原型地址等。引言部分的写作目的是让阅读者快速理解需求背景和概要。如果是公司内部文档，引言部分可以从简写作。

　　②业务建模

　　建模的目的是为了帮助阅读对象更好的理解需要开发的需求，常用的模型种类包括：用例图、实体图、状态图、流程图等。常用的建模语言如UML。UML具体的建模方法请戳这里。

　　③ 业务模块

　　业务模块包含具体页面的元素、用例规则，以及相关的原型，流程图。业务模块的描述是整个文档最核心的部分，下面博主用案例来描述一下业务模块的编写方法。

　　4.案例介绍：旅行箱–目的地攻略(应用商店搜索“旅行箱”)

　　需求的目标是在APP中展示相关国家/城市的旅游资讯内容，如下图所示：

　　那么我们在第一部分的引言中可以写下简单的需求描述：

　　1. 目的地攻略以城市/国家为单位，展示八个栏目下的文章列表。

　　2. 初期运营指标为编辑所有涉及城市的归属国家攻略内容，相关城市暂不编辑;APP前台默认显示国家内容卡片，城市内容卡片无数据时隐藏。

　　3. 运营系统提供内容生成对应的触屏网页，App读取和下载对应网页内容;

　　为了帮开发者迅速了解需求结构，我们需要建一个简单的流程图帮助开发理解功能：

　　相对复杂的运营系统，我们可以补充相关用例图和实体关系图：

　　引言和建模部分是为了帮助开发和测试人员快速理解需求，具体的页面和用例规则还需要通过第三部分的业务模块来描述，这里我们节选案例中的文章列表页来描述：

　　文章列表页共包含一个页面，四个用例

　　那我们的描述结构就为：

　　1. 文章卡片页面元素

　　2. 收藏文章用例

　　3. 分享文章用例

　　4. 查看文章列表

　　5. 查看文章(太简单可不描述)

　　文章卡片的页面元素描述：

　　(收藏)用例的描述为

　　业务模块的描述一般是原型图+数据元素+用例描述，这样可以在原型图的基础上加上对应元素属性的描述，并通过动作描写的方式表达用例规则和各种流程。这样的写作方式不仅可以向不同对象传达产品经理的意图，而且可以帮助产品经理自己梳理需求的逻辑和各种异常流程。