《项目名称》产品需求文档
时间：YYYY-MM-DD
文档修订记录
版本号 v1.1 v1.0
更新时间 yyyy-mm-dd 内容 1、 简要描述核心更新内容 2、 … 作者 xx xx yyyy-mm-dd 文档创建
目录
一、 概述......................................................... 4
1. 需求说明..................................................... 4 2. 产品结构..................................................... 4 3. 主业务流程................................................... 5 二、 名词释义..................................... 错误!未定义书签。 三、 功能性需求................................................... 5
1. 全局性交互或数据规则......................................... 5 2. 模块A ....................................................... 6 3. 模块B ....................................................... 7 四、 非功能性需求................................................. 7 五、 数据统计需求................................................. 8 六、 交付与上线................................................... 9
1. 交付说明..................................................... 9 2. 上线方案..................................................... 9
1.文档概述
1.1需求说明
项目名称、项目背景、以及原始需求，整体分为三个段落即可；
此处主要功能为帮助团队内的成员理解需求的出发点。
1.2产品功能结构
此处主要简述该产品或需求的完整主体结构,推荐使用脑图(Xmind或者MindManager等工具来绘制表达)；
不过该结构应当和后面的功能型需求或者非功能性需求说明目录结构保持统一。
1.3业务流程
对核心业务流程进行图示，常用流程图、泳道图（常用工具为visio）来表达。但注意，此处非详细的逻辑/交互流程，而是主要业务流程示意。
1.4名词术语
名词A：释义说明 名词B：释义说明
若该产品或需求文档内，存在部分全新定义的专有名词，或部分较少使用到的第三方用语，则提前单独附上释义。
2.功能性需求
2.1全局交互数据规则
1)交互
全局性的交互更多见于一些加载、网络、提醒情况下，某些特定的交互和场景下也可能存在特殊的全局性需求（如微信的悬浮窗功能）； 2)数据规则
全局性数据规则常见于最高优先级（相对）的数据，用于限制下级数据的下发，如黑名
单管理、用户状态等。
2.2模块1
1) 子模块1（内容/信息展示型）
a) 原型 b) 信息 c) 交互 d) 数据规则 e) 异常状态
2) 子模块2（功能/交互流程型）
a) 完整流程逻辑说明 b) 原型 c) 信息 d) 交互 e) 数据规则 f) 异常状态
※文档结构说明：
内容/信息展示型模块：指的是偏内容展示的模块，交互逻辑或较少甚至没有。该类型模块的需求主要是说明原型结构、数据规则。
功能/交互流程型模块：指的是包含连续性或较多判断的功能流程的模块，该类型模块除了常规的原型结构、数据规则，还包括一定量甚至大量的交互判断。因此附上完整的流程逻辑说明能有效的帮助相关人员理解该需求。
原型： 具体该模块的原型，若与实际设计图有变化（包括信息元素的变动或布局的较大变动），应替换为设计图截图或修改后的原型。
信息/显示规则：基于原型所见内容或规则需要，模块中会用到哪些信息，以及展示时候有哪些类型或限制，具体说明为：
信息展现形式：文字、图片、图标
信息展示内容：具体文案、图标的需求。同一信息如果存在不同类型或状态的说明，比如性别男、女；信息展示的规则限制，常见有：字数限制、行数限制、高度限制、宽度限制、缩放限制、颜色限制、格式限制、隐藏限制等
交互规则：交互的范围很广，常见的交互需求应包括以下内容，但可能很多交互情况的处理方式可以标准化，但在需求中仍需说明。具体应根据实际产品/需求而定。
交互操作：点击、加载（加载中、加载失败、加载超时）、滑动/拖动（左滑、右滑、上拉、下拉）、长按、双击、多点操作等
交互响应：变色/变暗/变量、区域响应、文字响应、动画响应、效果响应、文字显示 响应结果：指的是交互操作后的各种结果，某些情况下如果需求特殊的交互响应过程/动画，应特别说明
技术实现：专指特殊的交互动作/动画需求，应提前找到案例或与开发人员沟通，避免不具备可实现性。
数据规则：与“信息”的差异在于，信息更偏于直接显示的、以及落地到每一个文字/图标细节的元素，而数据规则是更整体化的规则说明。数据规则制定时，应首先确定好方向定位，再拟定初版规则并进行完善，同时数据规则的设定一般对技术依赖严重，因此需提前和技术沟通。（一般而言，数据规则至少包括数据如何获取、数据如何缓存两部分）
异常状态：异常状态常见包括加载失败、无数据、超时等，同时，部分特定场景下的产品/功能还有特别的异常状态，比如未获得相关权限、无相关设备、空间存储不够、文件丢失、文件格式不支持等。
2.3模块2
整体结构如模块1所述。
3.非功能性需求
非功能性需求基于不同类型的产品/项目，差异性可能较大，常见的类型包括： (1)性能需求。如大致响应时间需求、最大并发数要求等；
(2)兼容性需求。通常情况下，PC端网页要求对主流浏览器如IE、Chrome、360、QQ的兼容，H5网页要求对UC、QQ、微信、Safari等浏览器或客户端兼容，iOS APP要求兼容
iOS8\\9\\10\\11系统以及iphone5、5s、6s等以上设备，安卓APP要求兼容4.2/5.x/6.x/7.x/8.x/9.x等主流系统以及华为、小米、三星、oppo、vivo等设备；同时移动网络都要求兼容电信、移动、联通三大运营商基本网络类型等；
(3)网页的URL和TKD；
(4)大页面/模块的缓存规则（但如果部分模块的缓存规则是独立的，则应在具体模块的数据规则说明中直接说明）；
(5)纯文字/图片设计内容（比如设计礼物、表情等）；
(6)风险控制需求。部分业务有可能存在一定的风险，比如被刷注册、刷评论等，这类风险可提前在技术实现时做一定的兼容可控性。
4.数据统计需求
数据统计需求一般包括四部分，可根据实际项目时间或需求进行拆分，但数据统计和数据展示可独立进行：
1.基本数据统计 2.业务数据统计 3.事件行为统计 4.统计展示后台
※文档结构说明：
数据统计：数据统计有的可直接在服务器统计，有的则需要前端/客户端上报统计，有的还可以直接使用第三方统计工具，需根据实际情况区分。
数据展示后台：仅对于重要、核心数据，需单独建设数据展示后台，后台内容可包括： 核心行为的直接统计结果、完整逐条的详细数据列表 符合实际产品情况的数据筛选、过滤、排序等查看手段 折线图、柱状图、饼图等常见、直观的数据展示方式
5.交付与上线
5.1交付说明
针对涉及到的不同部门，整理对应的交付文档，以及安排交付。
交付核心：有明确文档以及交接人员。
5.2上线方案
为确保产品的最终效果，一个优秀的上线方案至少应从以下方面准备充分： 1) 历史数据或交叉业务处理 2) 技术支持 3) 运营方案 4) 推广策略
5) 数据和用户反馈跟踪
因篇幅问题不能全部显示，请点此查看更多更全内容