如何做好一份高质量的产品需求，作者从完整、具体、准确、友好四个方面出发，分析做好产品需求所需要具备的要点，希望通过阅读本篇文章，能对你有所帮助。
交付高质量的产品需求：
一份高质量的产品需求，应该是具备以下重要特性：完整、具体、准确、友好。
一、完整
产品需求的完整性，包括标配需求，分支流程、异常流程的闭环；包括功能逻辑的齐全；包括不同的业务场景；包括上下游联系关系影响的说明；包括附件资料；包括非功能性需求…
1. 分支、异常流程业务流程中涉及有分支流程，需说明每种分支流程的走向、流程节点的具体规则、不应出现有去无回、断头路的情况；涉及有异常流程，同样需需说明异常流程的触发条件、走向、异常流程节点的具体业务规则。
比如在常见的OA审批流程中，就存在以下容易被忽略的流程状况：
- 提交OA申请后，没有撤销申请的步骤，以及撤销申请后是否可修改再次提交申请。
- 审批人超时未审批 流程该怎么走，超24小时未审、超48小时未审 流程如何处理。
- 审批人驳回OA申请，是否可以直接修改原申请内容 再次提交申请。
- 申请人职级不同，审批层级不同的情况，这种多级审批流程如何定义和说明。
- 审批流程结束后，是否有需要 回写的数据、或需要更新的状态。
2. 列举完整的业务场景对于业务场景众多、且复杂的需求，需列举出所有相关的业务场景，以及每种情况对应的业务规则和逻辑、或处理方案。
这点上，就比较考验产品同学的业务熟悉程度、以及业务分析能力了。
在以下购物车的示例中，在提交订单时，就需考虑各种业务场景下的逻辑处理：
- 商品已下架。
- 商品无库存。
- 商品被删除。
- 商品不在配送区域内。
- 商品属于不同的商家（涉及需拆单）。
- 商品属于不同的仓库（涉及需拆单）。
- 包含需冷链运输的商品（涉及需拆单）。
- …
3. 上下游相关联的逻辑修改某项功能点（尤其涉及到基础数据变更的情况），需列举出上下游相关的修改点，或通知下游系统变更的影响以及可能需要做哪些修改；包括相关模块的功能点、对外接口、权限规则、数据报表、数据的导入导出等。
- 比如：客户信息中 客户类型的枚举值由5个变成了3个，在统计报表中原来根据5个客户类型统计数据的逻辑，就需要做同步的变更。
- 再比如：客户信息中 渠道类型由1个字段拆成了2个字段，对外接口中读取渠道类型的逻辑，需要指明是否需要调整。
4. 原有的规则和逻辑涉及需要描述原有功能逻辑的需求，产品同学普遍的会写：与原有逻辑保持一致、或翻看原有逻辑，同时又不指明原有逻辑是怎样的，或在哪个地方以查看。如果是新同学遇到这种情况，就不知所措，要开始怼人了。
对于业务逻辑复杂的中后台系统，并且是经历1-100的迭代过程，更需要注意描述清楚原功能的逻辑和规则，或者指明在哪个文档、文档的哪个部分可以查看现。如原有逻辑已找不到有文档记录，可能就需要提前找技术同学翻查代码，以核验原有逻辑的正确性。
5. 提供联系关系的附件资料- 导入、导出模板文件：涉及导入、导出数据的系统功能，需提供导入、导出数据的模板文件。
- 初始化的数据：功能上线后需立即展示初始数据的需求，应提供初始化的数据源文件。
- 消息、短信模板：如需发送短信，需提供短信模板，包括短信签名。如需给用户发送即时消息，需提供消息模板文件，包括发送人、消息模板内容。 同时指明，短信或消息模板中的变量，以及变量的取值规则。
- 产品提示文案：固定的提示文案，如有变量，需指明变量如何取值。
6. 非功能性需求- 权限需求：所有功能权限、数据权限点的权限分配规则，涉及数据接口的，还需说明接口范围的权限要求。
- 安全需求：说明哪些字段或数据需配置为监控字段，即默认展示位***，点击再查看明文。对于业务复杂的后台系统，可能还需再深入一步，指明哪些级别或类型的用户可直接看明文、哪些需点击再看明文、哪些只能看到***。 安全类与权限类的需求，关联度比较高，有时需结合在一起，尤其是重业务、重流程的B端产品，需单独列为一份产品需求来对待。
如以下示例：
- 数据需求：如果涉及存量数据的处理(比如加字段），需描述存量数据的处理方案；描述哪些功能项需做数据埋点。
- 兼容性需求： 不同移动端系统（Android、iOS等）及其版本、手机及其型号的兼容性；新老数据接口的兼容性等；不同浏览器及其版本的兼容性。
- 性能需求：系统并发量的要求；页面打开速度、响应速度的要求。
二、具体
交付给技术、测试同学的需求，一定是具体可编码的、可执行测试验证的。
很多时候产品同学以为是清楚的描述了，实际上会包括潜在的多个选项指明不清、或与且的关系、多个操作入口该修改哪些地方、以及边界性的问题等。
在曾经团队中出现过如斯产品需求：
满足状态在跟进中、最后跟进时间在7天内的客户需由销售管理层手动分配销售经理。
在该需求描述中就存在不够清晰，具体的问题：
- 满足的2个条件是且、仍是或的关系。
- 跟进中的客户有跟进中-未拜访、跟进中-已拜访2个状态，那 跟进中 该如何判定，只包括其中一个状态，仍是2个状态都包括。
- 最后跟进时间在7天内，是否包括7天。
再比如以下需求：
替换销售经理时，不能填写自己的姓名。
实际上替换销售经理的操作入口有N个，并且有的特殊地方其逻辑是不同的，最好把替换的入口列举出来的，不然技术同学容易做漏、测试同学容易测漏、上线后也便于自己验收。
另外不能填写自的姓名该怎么判断，可编码的详细描述应该是不能填写当前操作用户的姓名。
三、准确
同样的文字描述加上标点符号、或断句不同，其表达出来的意思就可能有多种。需求的准确性主要指需求的描述应该是唯一确定、理解上没有歧义的。
类似时间/日期相关的描述，应具体说明是哪个时间段，精确到日期仍是时分秒；涉及连续多个且、或的逻辑判断，需明确描述“或者”， “并且”的判断规则。对于理解可能有歧义，又很难文字描述逻辑需求，加以释义说明、或示例说明。
团队曾经做过一个增值服务相关的费用：不加时效费。
从字面上脑回路不同的人就有不同的理解：
- 不加 “时效费”，不加上 货物运输时效的费用，即是要减去相应的费用。
- “不加时效” 费，不加 货物运输时效 的一种费用。
比如以下产品需求：
营业额均值取值规则：取当前时间前3个月客户的营业额之和的均值。
当前时间前3个月的理解：
假如当前时间为2020-10-10 10:00，则当前时间前三个月含义可能有2种：
- 自然月份： 2020-07-01 00:00:00 到 2020-09-30 23:59:59？
- 非自然月份：2020-07-10 00:00:00 到 2020-10-09 23:59:59？
前3个月营业额之和均值的理解：
假如3个月中有1个月的营业额为0，则取均值时除以2、仍是除以3？或者是再往前多取一个月的营业额？
四、友好
产品需求描述清楚、准确了，最后展示给用户（技术、测试同学）时，也需漂亮的颜值，友好的展示形式。
需求文档需设置好文档结构图，标明清晰文档的结构、层次，难易理解的逻辑给予示例说明，大段文字的空行、格式、间隔等，也都是需要考虑的因素。能用图形、表格的尽量使用图表展示，避免大坨的文字堆积。
比如以下示例中的格式、符号问题：
在申请信息页面要增加 结算方式、客户分值2个新的字段，以下团队成员给出的文字描述，就没太注意文字的格式、标点符号等展示细节：
更友好的展示应该是：
- 结算方式：取客户后台->财务信息->结算信息中的结算方式字段。
- 客户分值：取客户后台->基础信息->基本信息中的客户分值字段。
再比如以下的文档结构图示例，右边设置了文档结构图的文档就更便于阅读：
五、另外
清晰明了的产品需求， 能有效提高产研的效率，节省团队的沟通成本，也能体现出产品同学的专业度，赢取团队的信任。
但也并无意味着沟通的减少，产研整个过程的产品、技术、测试同学之间积极、及时性、无障碍的沟通始终是不可缺少的，在项目跟进过程中，产品同学大部分的时间其实都会花在沟通上。
沟通是门大学问，也是一生的学问。
本文由 @天晴一把刀 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
如何做好一份高质量的产品需求，作者从完整、具体、准确、友好四个方面出发，分析做好产品需求所需要具备的要点，希望通过阅读本篇文章，能对你有所帮助。
交付高质量的产品需求：
一份高质量的产品需求，应该是具备以下重要特性：完整、具体、准确、友好。
一、完整
产品需求的完整性，包括标配需求，分支流程、异常流程的闭环；包括功能逻辑的齐全；包括不同的业务场景；包括上下游联系关系影响的说明；包括附件资料；包括非功能性需求…
1. 分支、异常流程业务流程中涉及有分支流程，需说明每种分支流程的走向、流程节点的具体规则、不应出现有去无回、断头路的情况；涉及有异常流程，同样需需说明异常流程的触发条件、走向、异常流程节点的具体业务规则。
比如在常见的OA审批流程中，就存在以下容易被忽略的流程状况：
- 提交OA申请后，没有撤销申请的步骤，以及撤销申请后是否可修改再次提交申请。
- 审批人超时未审批 流程该怎么走，超24小时未审、超48小时未审 流程如何处理。
- 审批人驳回OA申请，是否可以直接修改原申请内容 再次提交申请。
- 申请人职级不同，审批层级不同的情况，这种多级审批流程如何定义和说明。
- 审批流程结束后，是否有需要 回写的数据、或需要更新的状态。
2. 列举完整的业务场景对于业务场景众多、且复杂的需求，需列举出所有相关的业务场景，以及每种情况对应的业务规则和逻辑、或处理方案。
这点上，就比较考验产品同学的业务熟悉程度、以及业务分析能力了。
在以下购物车的示例中，在提交订单时，就需考虑各种业务场景下的逻辑处理：
- 商品已下架。
- 商品无库存。
- 商品被删除。
- 商品不在配送区域内。
- 商品属于不同的商家（涉及需拆单）。
- 商品属于不同的仓库（涉及需拆单）。
- 包含需冷链运输的商品（涉及需拆单）。
- …
3. 上下游相关联的逻辑修改某项功能点（尤其涉及到基础数据变更的情况），需列举出上下游相关的修改点，或通知下游系统变更的影响以及可能需要做哪些修改；包括相关模块的功能点、对外接口、权限规则、数据报表、数据的导入导出等。
- 比如：客户信息中 客户类型的枚举值由5个变成了3个，在统计报表中原来根据5个客户类型统计数据的逻辑，就需要做同步的变更。
- 再比如：客户信息中 渠道类型由1个字段拆成了2个字段，对外接口中读取渠道类型的逻辑，需要指明是否需要调整。
4. 原有的规则和逻辑涉及需要描述原有功能逻辑的需求，产品同学普遍的会写：与原有逻辑保持一致、或翻看原有逻辑，同时又不指明原有逻辑是怎样的，或在哪个地方以查看。如果是新同学遇到这种情况，就不知所措，要开始怼人了。
对于业务逻辑复杂的中后台系统，并且是经历1-100的迭代过程，更需要注意描述清楚原功能的逻辑和规则，或者指明在哪个文档、文档的哪个部分可以查看现。如原有逻辑已找不到有文档记录，可能就需要提前找技术同学翻查代码，以核验原有逻辑的正确性。
5. 提供联系关系的附件资料- 导入、导出模板文件：涉及导入、导出数据的系统功能，需提供导入、导出数据的模板文件。
- 初始化的数据：功能上线后需立即展示初始数据的需求，应提供初始化的数据源文件。
- 消息、短信模板：如需发送短信，需提供短信模板，包括短信签名。如需给用户发送即时消息，需提供消息模板文件，包括发送人、消息模板内容。 同时指明，短信或消息模板中的变量，以及变量的取值规则。
- 产品提示文案：固定的提示文案，如有变量，需指明变量如何取值。
6. 非功能性需求- 权限需求：所有功能权限、数据权限点的权限分配规则，涉及数据接口的，还需说明接口范围的权限要求。
- 安全需求：说明哪些字段或数据需配置为监控字段，即默认展示位***，点击再查看明文。对于业务复杂的后台系统，可能还需再深入一步，指明哪些级别或类型的用户可直接看明文、哪些需点击再看明文、哪些只能看到***。 安全类与权限类的需求，关联度比较高，有时需结合在一起，尤其是重业务、重流程的B端产品，需单独列为一份产品需求来对待。
如以下示例：
如何做好一份高质量的产品需求，作者从完整、具体、准确、友好四个方面出发，分析做好产品需求所需要具备的要点，希望通过阅读本篇文章，能对你有所帮助。
交付高质量的产品需求：
一份高质量的产品需求，应该是具备以下重要特性：完整、具体、准确、友好。
一、完整
产品需求的完整性，包括标配需求，分支流程、异常流程的闭环；包括功能逻辑的齐全；包括不同的业务场景；包括上下游联系关系影响的说明；包括附件资料；包括非功能性需求…
1. 分支、异常流程业务流程中涉及有分支流程，需说明每种分支流程的走向、流程节点的具体规则、不应出现有去无回、断头路的情况；涉及有异常流程，同样需需说明异常流程的触发条件、走向、异常流程节点的具体业务规则。
比如在常见的OA审批流程中，就存在以下容易被忽略的流程状况：
- 提交OA申请后，没有撤销申请的步骤，以及撤销申请后是否可修改再次提交申请。
- 审批人超时未审批 流程该怎么走，超24小时未审、超48小时未审 流程如何处理。
- 审批人驳回OA申请，是否可以直接修改原申请内容 再次提交申请。
- 申请人职级不同，审批层级不同的情况，这种多级审批流程如何定义和说明。
- 审批流程结束后，是否有需要 回写的数据、或需要更新的状态。
2. 列举完整的业务场景对于业务场景众多、且复杂的需求，需列举出所有相关的业务场景，以及每种情况对应的业务规则和逻辑、或处理方案。
这点上，就比较考验产品同学的业务熟悉程度、以及业务分析能力了。
在以下购物车的示例中，在提交订单时，就需考虑各种业务场景下的逻辑处理：
- 商品已下架。
- 商品无库存。
- 商品被删除。
- 商品不在配送区域内。
- 商品属于不同的商家（涉及需拆单）。
- 商品属于不同的仓库（涉及需拆单）。
- 包含需冷链运输的商品（涉及需拆单）。
- …
3. 上下游相关联的逻辑修改某项功能点（尤其涉及到基础数据变更的情况），需列举出上下游相关的修改点，或通知下游系统变更的影响以及可能需要做哪些修改；包括相关模块的功能点、对外接口、权限规则、数据报表、数据的导入导出等。
- 比如：客户信息中 客户类型的枚举值由5个变成了3个，在统计报表中原来根据5个客户类型统计数据的逻辑，就需要做同步的变更。
- 再比如：客户信息中 渠道类型由1个字段拆成了2个字段，对外接口中读取渠道类型的逻辑，需要指明是否需要调整。
4. 原有的规则和逻辑涉及需要描述原有功能逻辑的需求，产品同学普遍的会写：与原有逻辑保持一致、或翻看原有逻辑，同时又不指明原有逻辑是怎样的，或在哪个地方以查看。如果是新同学遇到这种情况，就不知所措，要开始怼人了。
对于业务逻辑复杂的中后台系统，并且是经历1-100的迭代过程，更需要注意描述清楚原功能的逻辑和规则，或者指明在哪个文档、文档的哪个部分可以查看现。如原有逻辑已找不到有文档记录，可能就需要提前找技术同学翻查代码，以核验原有逻辑的正确性。
5. 提供联系关系的附件资料- 导入、导出模板文件：涉及导入、导出数据的系统功能，需提供导入、导出数据的模板文件。
- 初始化的数据：功能上线后需立即展示初始数据的需求，应提供初始化的数据源文件。
- 消息、短信模板：如需发送短信，需提供短信模板，包括短信签名。如需给用户发送即时消息，需提供消息模板文件，包括发送人、消息模板内容。 同时指明，短信或消息模板中的变量，以及变量的取值规则。
- 产品提示文案：固定的提示文案，如有变量，需指明变量如何取值。
6. 非功能性需求- 权限需求：所有功能权限、数据权限点的权限分配规则，涉及数据接口的，还需说明接口范围的权限要求。
- 安全需求：说明哪些字段或数据需配置为监控字段，即默认展示位***，点击再查看明文。对于业务复杂的后台系统，可能还需再深入一步，指明哪些级别或类型的用户可直接看明文、哪些需点击再看明文、哪些只能看到***。 安全类与权限类的需求，关联度比较高，有时需结合在一起，尤其是重业务、重流程的B端产品，需单独列为一份产品需求来对待。
如以下示例：
