需求|快速搞定B端需求，看这篇就够了( 三 )

2）可以从两个纬度四个象限进行划分，一个是紧急程度，一个是重要程度。按照优先级划分为重要紧急、不重要紧急、重要不紧急、不重要不紧急。
如果产品在0-1阶段，那根据KANO模型的基本型需求>期望型需求>兴奋型需求来判断，如果产品在1-N的迭代期，根据，产品价值大实现成本低>产品价值大实现成本高>产品价值小实现成本低>产品价值小实现成本高来判断（图来自网络）。

文章插图
六、需求文档的输出功能需求整理输出产品方案，做需求文档输出时，为了全面考虑产品方案的逻辑完整性和流程的完整性，可用以下三个点来自查自检。
1. 功能触发的前提1）前置条件：触发该流程的前提条件，如领取优惠券的前置条件为“注册且登录账号”，甚至还有其他比如是否是新用户等等。
2）数据来源：流程中数据来源，如审核功能中：审核人员审批下级发起的审核单。审核人员的操作流程中，下部发起审核产生审批单就是审核人员的操作流程中的数据来源；数据来源通常是在发生数据流转的场景下需要进行说明。
3）角色及权限：即用户在系统中承担的作用的抽象，是否已经把功能抽象到权限中去，这样可针对权限的设置来分配某些角色可以用，某些角色不可以用。
2. 操作流程1）事件：主要是指功能的交互规则及逻辑判断。
这个模块用来说明用户和系统之间发生的交互。交互规则是泛指的交互规则，包含功能的页面布局、触发功能的动作及触发后的交互效果；逻辑判断则是指当用户在前端发生行为，系统对用户行为进行识别、判断并返回相应的动作的过程。
2）触发反馈：指用户与系统完成交互后，用户和系统会得到什么样的反馈及产生什么样的数据和结果。
【需求|快速搞定B端需求，看这篇就够了】3）异常处理：是对主流程补充，我们尽可能全的罗列并写清楚异常流程时，可以有效避免在产品设计时的场景遗漏。异常流程的梳理建议是参考测试同事的正反例原则。
3. 通用说明1）数据埋点：埋点就不多进行赘述，但不管是采用第三方系统还是自己的埋点体系，都要做好数据分类，后续提取数据时能减少很多功夫。
2）数据需求：主要为业务方和产品经理在使用和运营提供决策依据，在设计产品方案时一定要规划相对的监控数据指标，以便于后续运营和迭代时有数据进行支撑。
3）数据字典：不要出现这个数据在这是姓名，到另外一个页面成为了用户名这样的事情。以上，是我对B端产品（项目）的理解，后续会对业务需求、管理需求、用户需求分别分析一下。
本文由 @pm老潘原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议