19.12.16 痞M二点五-产品经理如何写PRD需求文档

今天用一份需求文档样例来讲述下产品经理如何全面系统的写一份完整的需求文档，文末有文档领取地址 有需要文档的可以自行领取 首先来讲述下需求文档的结构以及每个模块的目的，产品经理写文档要注意精准的把控业务需求，但是要更加精准的把控开发同学需求，这样才能写出一份便于团队开展的工作文档，废话不多说直接进入正题，一些产品背景什么的自行体会 主要介绍主要文档部分，以及书写规范
此文档＋AXURE源文件可关注微信公众号：痞M二点五 输入 1122 领取
一，产品目标：
讲述本次需求设计主要实现什么样的产品目标，有利于团队理解开发方向（此项很重要），不是冠冕堂皇的话，一句定输赢的部分，中华文字博大精深，所以通过文档文字来表述需求很多时候团队会造成理解偏差，一个目标可以让开发同学以及团队精准的实现需求，防止跑偏
二，产品结构
主要然团队了解你的产品都有些什么样的功能，如果有时间也可以列一份产品功能需求清单，有利于进行功能点拆分，进行排期计划

三：重点来了不像其它文章废话一堆看似很有道理但是发现自己没办法用，直接进入实操细节，主说常用功能书写，下文以具体某一产品进行实操举例，方便读者直接上手使用

全局说明

功能权限

登录状态：所有功能都可使用；
未登录状态：只可以查看附近图书馆自习室信息，可以查看课程信息，但不能学习课程。
会员用户在会员期限内可进行所有操作，所有资源对会员用户开放。
非会员用户只允许用户使用免费资源，但可直接花钱购买会员课程。

键盘说明

点击手机注册/手机登录输入框时弹出数字键盘；
点击其他输入框弹出字母键盘。

3.3 异常说明

打断后重新打开 APP：

点击空白区域或无网络情况：

3.4 常见操作

3.4.1 操作

• 下拉刷新；
• 上拉加载（列表结束/到达最底部）。

3.4.2 用户头像
用户头像链接到个人资料页，特殊情况在页面中另外说明。
3.4.3 Home键
按 home 键，程序改为后台运行，再次打开软件时，则回到按home键时的页面。
3.4.4 缓存机制
初始列表20条，每次加载20条。

注册功能 1) 载入注册页面时默认“手机号码输入框”获得输入焦点，并展开纯数字键盘。
2) 当“手机号码输入框”“验证码输入框”“密码输入框”“确认密码输入框”任一为空时，“注册”按钮为不可用状态，防止用户误操作。
3) 当“手机号码输入框”输入的是“非11位数字”或“第一个数字不是1时”点击“发送验证码”按钮，提示“请填写有效的手机号码”。
4) “手机号码输入框”、“验证码输入框”获得输入焦点时，自动切换到纯数字键盘。
5) “密码输入框”、“确认密码输入框”获得输入焦点时，自动切换到英文输入键盘。
6) 当“密码输入框”“确认密码输入框”输入的不一致时点击“注册”按钮提示“两次密码输入不一致，请重新输入”，并清空“密码输入框”“确认密码输入框”。优先级高于7）
7) 当“密码输入框”输入的密码少于六个字符时，“确认密码输入框”获得输入焦点提示“密码不能少于六位”。
8) 当“密码输入框”输入的密码少于六个字符时，点击“注册”按钮提示“密码不能少于六位”。
9) 当“验证码”错误时，点击“注册”按钮提示“请输入有效的验证码”。
10) 当“手机号码输入框”输入格式正确的手机号码已注册时点击“发送验证码”按钮，提示“该手机号码已注册”，自动跳转至登录页面并将之前填写的手机号码同步至登录页面的手机号码输入框。
11) 当注册成功时，点击“注册”按钮时提示“恭喜！注册成功!”并自动跳转至“XX”页面。 登录 1) 载入登录页面时默认“手机号码输入框”获得输入焦点，并展开纯数字键盘。
2) 当“手机号码输入框”“密码输入框”任一为空时，“登录”按钮为不可用状态，防止用户误操作。
3) 当密码错误时点击“登录”按钮提示“手机号码与密码不匹配”
4) 当手机号码输入框输入的是“非11位数字”或“第一个数字不是1时”，点击“登录”按钮提示“请填写有效的手机号码”，优先级高于 5） 。
5) “密码输入框”获得输入焦点时，自动切换到英文输入键盘。
6) 当网络异常时点击“登录”按钮提示“网络异常，请检查网络设置”。
当填写的正确格式的手机号码尚未注册时点击“登录”按钮提示“该手机号码尚未注册”，并自动跳转至注册页面，并将之前已填写的手机号码同步至注册页面的手机号码输入框。
忘记密码

前置条件：【登录页】点击【忘记密码】按钮。
功能需求：手机号、验证码、显示密码功能需求如上
1）下一步
当输入项中有一项或多项为空，【下一步】按钮为禁用状态；
当输入项全部输入后，按钮变为可用状态，点击后服务器端依次校验手机号和验证码，验证成功后跳转至右边界面；验证失败会有以下情况：
验证码：验证码错误，弹出窗口：“短信验证码输入错误”；
2）请输入密码：输入新密码
3）请再次确认密码：再次输入新密码
4）登陆：当输入项中有一项或多项为空，【登录】按钮为禁用状态；
当输入项全部输入后，按钮变为可用状态，点击后服务器端校验两次输入密码是否相同，验证成功后成功跳转至【首页】；验证失败会有以下情况：
验证码错误，弹出toast：“短信验证码输入错误”；
账户登录时弹出浮窗显示登录中状态，此时界面元素不可点击。登录成功跳转到【首页】，8秒内未完成登录则取消登录中状态，弹出toast：“当前网络不给力，请稍后再试”；
此外在AXURE中也可以做些详细表述 方便开发同学浏览例如

都是在功能共享方面 避免理解偏差的有利方式，主要结构大同小异
（1）版本记录

1. 谁：该文档是谁编写的，便于快速找到对应的负责人员，同时，后期有助于在需求文档库中建档分类。
2. 时间：什么时间编写的该文档，旨在告知该功能是什么时间要开始做，便于后期溯源时，快速定位。
3. 事件：针对什么产品、什么功能做的规划，其实就是文档标题。
4. 版本号：便于记录产品不同版本的节点做了什么内容及调整，同时，针对不同的系统，有助于使用统一的版本号做管理。
5. 上线计划：依据上线计划倒推测试周期、开发周期、设计周期，从而给参与该项目的协同人员约定好时间，便于更好的把控项目进度。
6. 评审及修改：项目完成后的需求评审建议和结果，针对初稿内容做了哪些修改。此处一定要详细，后续调整内容时，评审建议和修改事项是很重要的可参考的细节点。

（2）版本说明

1. 项目背景：清楚地写出为什么要做该项目，谁要求做的。
2. 核心需求：为了解决什么冲突。
3. 预期目的：想达到什么结果，后续有什么进一步的规划。

详细的项目背景有助于所有参与人员快速地了解项目是怎么回事。
（3）设计规范
设计规范来源于产品经理对该产品的整体了解：在做完市场分析、行业分析、竞品机构分析、用户调研之后，针对自己要做的产品，产品经理会形成自己的整体构思和产品走向模型。
而这个构思就是需要表达给设计师的理念——要做一款什么样的产品，要达到什么效果。
关于设计理念的表达，不同的公司有很大的差别，以及整个行业对这块内容都没有统一的观点。
一种观点认为，产品经理只需要输出黑白灰原型图即可，其他的都交给设计师处理，给设计师足够的发挥空间；
另一种观点认为，设计师对要做的产品，不了解缘由，直接去设计会有偏差，最终交付的产品大部分都不符合；
还有种观点认为，要看设计师的水平再来决定，水平高的不需要产品经理说什么，都可以交付足够让人惊艳的设计，水平低的说再多，也做不出效果，而大部分公司都属于第二种情况。
综上所述，岗位不同、职位不同、个人认知的不同，以及最重要的信息接收到处理个人间都是有差异的，最终呈现在产品上的内容就会有很大的差异。
而规避这类问题，最好的方式还是沟通。充足且有效的沟通，确保产品经理与设计师间的已知信息达到一致，双方的理念、想法、建议等越碰撞越容易做出更好的产品。
主要对接的内容包含两个部分：

1. 信息与意向：传递产品信息，告知设计师关于该产品的设计原因、行业情况、要做的产品对标竞品是哪些，以后对产品的规划是什么、产品经理的意向是什么。
2. 基础设计理念：产品主题、整体色调、各样式的字号、色号、全局页面的建议等。

（4）功能列表
功能列表为产品经理在经过足够多的调研和分析，从汇总的产品需求池中筛选出的当前应处理需求列表。
功能列表的作用为便于相关人员全面了解产品的功能，从而评估项目周期、处理优先级等。
功能列表主要表述都做什么功能，哪些重要且紧急。列表参数包含：

1. 模块
2. 功能点
3. 功能点描述（详细）
4. 优先级（高、中、低）

（5）角色列表
角色列表为表述清楚该产品上线后，参与到该产品中的群体有哪些。列表参数包含：

1. 角色名称
2. 职责：在产品参与中的简要说明
3. 备注：特殊情形

（6）框架图
框架图为该产品包含什么内容：模块、功能。便于开发人员快速、便捷的了解产品全局。
框架图没必要做的很高大上，高大上固然很好，会让使用的人赏心悦目。但是，功能介绍简单易懂和开发人员能看懂、看明白更重要，千万不能舍本逐末。
（7）流程图
流程图分两个部分：

1. 整体流程图：整体流程为将产品各大模块之间的交互流程，一般做正向流程居多，辅助以部分判断流程和异常处理机制
2. 功能流程图：功能流程为涉及到具体的功能点的交互流程，包含：正向流程、规则、判断流程、异常流程。

（8）功能需求

功能需求为具体的各功能点，是需求文档的核心。主要是详细的分解各功能点，包含两个方面：

1. 前端：针对前端部分，页面如何来、页面元素、各功能点的规则、交互、跳转规则、非常规流程的页面元素、交互、跳转规则等等。
2. 后台部分：前端功能的实现，依靠后台的哪些逻辑和数据，是否需要做新功能模块、新功能模块的内容、数据的调用、存储、接口数据传值等等。

（9）非功能需求
非功能需求为用户常规操作产品时的极端情况，涉及很多内容，以下列举几个比较重要且常规规划中需要考虑的点：

1. 产品性能：产品对用户操作的响应、对群体操作的并发预防等。
2. 安全性：公司数据、用户信息的保密性处理，不同角色的权限设置、使用中的限制等。
3. 可靠性：用户操作中出现异常情况，是否可继续操作，遇到异常情况时数据或使用状态是否可被恢复等。
4. 拓展性：拓展性主要针对公司内部而言，产品完成后，无论是设计师、开发人员，还是测试人员，针对产品所做的工作，是否可以被复用到其他地方。用户在产品中的使用情况是否可被系统获取后用作不同维度的分析等。

   欢迎关注微信公众号痞M二点五输入 1122领取产品需求原文档** 发布于 2019-11-16