需求分析篇｜从实例分析中理解业务需求、用户需求、功能需求的转化
本节试图从一个简单的“用户自助寄件”案例出发，分析业务需求、用户需求、功能需求之间的关系和差异，以及如何进行需求的分析和转化。
在产品的需求里面，经常有这三个概念：业务需求、用户需求、功能需求，但往往，我们很容易搞混，不清楚他们之间的关系和差异，我们先引用一下比较官方的解释：
业务需求（ Business requirement ） 表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。
用户需求（ user requirement ） 描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
功能需求（ functional requirement ） 规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求
这个解释其实还是蛮明确的，其实理解这三者的关键点，是要先认清楚每个需求针对的对象不一样：
- 业务需求———对应的是组织或者客户，实质就是业务的建设方；你也可以类比房地产市场的开发商；
- 用户需求———对应的是使用产品的用户；你也可以类比买房的人；
- 功能需求———对应的是产品，即产品要具备怎样的功能，才能满足相应的业务需求和用户需求；类比房地产市场，那就是房子本身。
类比成房地产三个角色后，你发现，开发商通常的诉求是想多赚钱，买房的人诉求是买到物有所值，甚至物超所值的房子；但不管二者怎么想，最终都是需要通过房子来实现，必须建设的房子的属性达到某个标准才能满足二者的诉求；
所以，这么一看，你就明白了，其实这三者之间的关系是：
即，业务需求和用户需求，只有经过需求分析的转化，变成产品的功能需求后，才能得到实现。
需求实例
接下来，我们用一个简单的实例来进行说明：
案例：用户自助寄件的需求
业务建设方：某快递公司
需求描述：目前很多城市的小区都已经有了快递柜，但快递柜主要是用于送件使用，而对于快递公司收件，用得比较少，某快递公司，就希望利用快递柜，来实现用户自助寄件的需求。
首先，我们来分析其业务需求
这个案例的业务建设方是：快递公司，其业务需求也很明确，就是： 用户自助寄件。
业务方之所以要建设这个需求，其目的是：希望利用快递柜，实现更高效的收件服务，减少人工上门收件的等待、低效、人力投入成本高等问题。
其次，我们来看用户需求
这个案例的用户，就是每一个要寄快递的人，那么他们的需求是什么了？
他们的需求，其实就是在进行“自助寄件”的过程中，你尽量让 我简单、易用，高效、快捷。
接下来，我们进行需求分析的转化
需求分析的转化，核心是两个点，一是对这个业务的场景进行充分的理解和认知，二是想明白业务场景中需求点，要通过何种方式来满足它。
业务需求是“用户自助寄件”，这个业务要实现，我们结合寄快递的实际场景，其实还是蛮容易就能想到，有3个关键环节：
- 用户要填写单据：即填写收发件人的相关信息；
- 用户要能找到周边的快递柜，并且能打开它；
- 还需要进行计量、支付快递费的问题
这三个环节，基本把这个业务的三个关键阶段说明出来了，它就是：填单——>找柜子放件——>支付。
然后，逐一对三个阶段进行具体的分析：
填单阶段：
- 业务方需求：必须收件人、联系电话、寄件人信息清楚、明确等等。
- 用户需求：能选的就选，能简单填写的就简单填。
转化为功能需求，你发现，无非是通过表单形式让用户把相关信息填上来，而为了满足用户需求，你肯定需要设计对收件人的记忆功能，让用户填写一次，后续每次只需要选择而已（相关的细节还很多，这里只做举例）。
找柜子放件阶段：
- 业务需求：把最方便最合适的柜子告诉用户，并确保用户能安全、准确的找到快递柜、放入快递件；
- 用户需求：我就想知道我要把快递件放到哪里，别让我多走；
这个业务需求和用户需求说起来简单，转化成功能需求时，其实里面还蛮多细节的：
- 位置服务肯定需要，一是为满足发现柜子的需求，二是也有导航的需求；
- 如何打开柜子呢？从我们的产品经验或者竞品参考来看，可以有扫描开启、验证码等方式；
- 如何保证用户去到快递柜，一定就有其空的柜子可以给他放了，这里面就涉及一个快递柜忙闲资源的管理；
所以，这里转化为功能需求时，你发现：有位置服务功能、扫描开启/验证码开启功能，柜子资源分配管理功能等；
支付阶段：
- 业务需求：根据收费标准，准确无误、及时收到用户快递费。
- 用户需求：支付方便。
- 功能需求：
- 如何来计量，由于是自助寄件，称重显然不合适，那么按体积是一种较简便的方式，而如何按体积了，其实根据可快递柜的柜子；
- 如何支付，这个还简单，可以使用比较常用的几种支付方式就好；
以上，都只是简单的需求分析和转化的过程，实际的需求过程中，我们经常讲需要结合业务场景、用户场景把一些关键细节挖掘出来，并能在产品设计时考虑进去，以给用户一个良好的体验。
业务场景细节的挖掘
比如：在上面的开启柜子的方式中，到底用扫描开启还是验证码的方式呢？
其实用“验证码开启”会更合适，因为会存在很多这样的场景，某个寄快递的人，刚好家里有人下楼，或者认识的邻居下楼，而快递柜就在小区门口，那么找人代劳一下放件是一种很正常的事情，那么这时候，使用验证码就是一种最合适、简便的方式。
又比如：某用户希望自己的快递能更快的被寄出去。
那么，如果在给用户呈现周边分布的快递柜的同时，还告诉用户，该快递柜的收件时间，目前快递员的分布位置，是不是能让用户更好的去选择呢。
这样的细节还很多，需要在实际分析中，更好的去理解用户场景、挖掘细节，并逐步的完善。
通过上面的分析，我们发现，只要你充分认清楚业务需求方的诉求、用户在执行具体任务时的诉求，并对产品的常规实现方式有了解的话，需求分析并不是一个多复杂的过程，就是这么一步步去推理、去转化的过程。
而要把每个细节做透，就必须在实际中多去磨练，在生活中多体验，学会场景化的思维方式。
作者：贝克曼，微信公众号：【贝克曼的产品修炼之路】。一名产品老兵，十年以上传统+互联网行业产品从业经历，专注于产品需求分析和企业转型咨询。
关键字：产品经理, 需求
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
