简书APPPRD文档规范写法及内容概述

不同公司、不同团队或产品对PRD文档的要求不同，不同PM的撰写风格也各有所异，本文力求全面而简洁，仅做简要概括。
这样写prd,哎哟不错哦

简书，在我看来长这样
本文“简书”移动端为例，按照上图的总结写一份简单的PRD文档框架，希望能帮助同为“简书”用户的大家更好地理解。（PM菜鸟一枚，简书新用户，重文档轻分析）。

简书APP版本信息表示意图

1、版本信息
2、文档说明

2.1 文档简介

本文档主要描述简书APP的功能需求点及其设计，目的在于清晰地定义各模块的需求细节及逻辑流程。

2.2 文档读者

本文档主要面向以下读者：简书APP项目的研发人员、测试人员、产品经理、市场运营人员、管理人员等。

2.3 专业术语

可在此提前交代一些专业术语以方便后文理解（通常以表格形式），也可见附录8.4

目录（略）

3、产品简介

3.1 产品定位

简书致力于提供最好的分享体验，为写作者打造最优秀的写作软件 ，为阅读者打造最优雅的阅读社区。“交流故事，沟通想法”是简书的slogan。

3.2 产品特色

简单优雅的设计、良好的交流氛围、丰富的文章主题、Mardown富文本等特色功能

3.3 用户分析

主要用户为喜欢分享交流、爱生活拥有文艺气息的年轻人，喜爱文字并想在喧嚣网络中沉淀文字的读写人。

4、产品架构

4.1 产品结构图

此文仅述主要模块，应展开至最小用户可见单元。
简书APP产品结构图

4.2 信息结构图

信息结构以信息为维度，比如用户信息，用户文章信息，用户行为信息等，与产品结构可对应分析，不再陈述。

4.3 总体流程图

总体流程可说明产品的基本的用户行为路径，有助产品理解。
简书APP总体流程图

5、详细功能说明

5.1 功能列表

功能列表作为功能需求说明的总览，可分模块描述。
简书APP功能列表示意图

前置条件：使用该功能的前提条件、逻辑关系说明。有时候也可以说明路径，就是我们常用的面包屑；后置条件：发生这个用例之后的结果，会产生哪些影像，必须达到什么要求；用例图：表达功能在表现层的逻辑图，可以是传统意义上的用例图，或者是简化版的原型图、流程图。（关于用例图这块还有些疑问，最近也在学习，之后再把学习结果整理出来）权限要求：用户权限、数据权限、功能权限，这里也牵涉到一个三户模型的概念，当我们设计权限的时候，可以根据三户模型去设计；界面原型：把这个用例相关的产品原型图贴出来，也可以说明一下画图工具。

业务规则单独提一下，这是用例描述里面最关键的一部分。可以从页面布局、操作逻辑（规则）、交互状态（操作说明）等几个方面去描述这个用例。具体内容可以包括：流程图、操作逻辑（基本事件流、异常事件流）、接口说明（请求数据接口、调用功能接口、需要开放的接口、对应接口中的字段）、数据状态说明（多状态流转说明）、交互状态说明（点击效果、指向地址、打开方式、刷新方式）等。
业务规则是我们产品经理需要主要思考的内容，涵盖的内容比较多，我在学习过程中没有找到专门去说明业务规则该怎么写的文章，初步的感觉就是需要注意的东西太多了，不然一步就是一个坑，等再学习一段时间再把业务规则这部分的学习结果整理出来。
5.2 原型界面

每一个模块功能的需求说明都应该包含详细的原型界面图及流程图，此作简单示意图（重置密码）。
简书APP重置密码原型示意图

5.3 用例流程
简书APP重置密码流程图

6、非功能性需求
6.1 性能需求

1、前端内容展现应保证用户在WIFI及移动网络下阅读体验流畅；

2、万级用户在线时后台信息处理稳定且快速等等。

6.2 系统需求

兼容Andriod、IOS各系统版本（包括最新版本）

6.3 运营需求

用户/内容管理系统开发、用户数据分析系统开发等

7、项目规划

有的项目或产品并不包含该部分，但通常要交代产品的风险分析及应对策略。

8、附录

大量的相关参考文档可放置附录，以避免篇幅过长影响阅读。通常包括原型/UI文档、MRD/BRD文档、技术文档、专业术语。

其他

其他，说白了就是因为需求文档模板并不能涵盖所有方面，经常会出现一些其他需要说明的内容，但是又不知道放在哪里合适，所以就放在其他里好了。

这部分我放了三块内容，首先是“其他接口”，就是对其它系统产生“字段、业务流程”进行说明，以及本次产品或业务，对前后台那些非主流程模块产生影响。

“系统风险评估”要说明的是当前设计的功能存在哪些缺陷、注意事项与后期的功能拓展如何解决这些问题。

“其他需求”是对一些非核心的功能点进行详情描述。如：一些需过滤的关键字、新增某个栏目字段。