1.业务需求（business requirement）表示组织或客户高层次的目标
用户需求（user requirement）描述了用户能使用系统来做什么
功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
业务需求-房子的开发商 用户需求-买房人 功能需求-房子本身
业务需求：就是想要赚钱（业务方层面）
用户需求：买到的东西物有所值（用户层面）
功能需求：满足前面两个（产品层面）
业务需求和用户需求，经过需求分析的转化，变成产品的功能需求，才能实现需求
需求分析实例：
案例：用户自助寄件的需求
需求描述：目前很多城市的小区都已经有了快递柜，但快递柜主要是用于送件使用，而对于快递公司收件，用得比较少，某快递公司，就希望利用快递柜，来实现用户自助寄件的需求。
业务建设方：某快递公司
业务需求：用户自助寄件
用户需求就是在进行“自助寄件”的过程中，你尽量让我简单、易用，高效、快捷。
接下来，我们进行需求分析的转化
需求分析的转化，核心是两个点，一是对这个业务的场景进行充分的理解和认知，二是想明白业务场景中需求点，要通过何种方式来满足它。
业务场景细节的挖掘
细节做透（这是在需求分析转化中很重要的一项工作）
计费这个，我看到过菜鸟裹裹的自提柜寄件，选择格子的时候会提示用户这个格子的限重是多少，页面上的小提示内也说明了如果物品的重量超过了格子的限重，快递员小哥会拒收，我觉得这种相互之间的约定就挺好的，如果你希望你的快递被收走，那么就遵守规定，感觉比较可行。
特意看了几遍，想了一下这个寄件支付的问题。
1）寄件人在手机天下寄件信息完毕确认寄件，地图定位显示当前最近的位置去寄件
2）我查询了一下快递公司收费标准是以重量来算，你文章中说的以体积来算，假如用户寄件的物品很轻，但是体积大，那不是价格就很高了。这样用户使用率是不高的，还不如直接让快递公司上门取件。上面有朋友说在快递柜里面加一个称重的，我觉得是可行的。重量称出来，用户就可以直接支付.
（作者回应）关于柜子目前占用情况，我们可以做一个像我们网上支付电影院的选座位的界面，显示当前有哪些柜子是已经被占用，哪些柜子是空闲的。这里面有一个问题就是当用户的物品体积过大怎么办的问题，可以在手机填写信息时选择柜子的大小，这个体积用户是可以目测得。1. 对于计量收费的问题，其实并不需要考虑所有情况，当体积比较大的物件的时候，完全可以指引用户走快递员上门的方式； 自助 寄件只是提供了多一种寄件选择，针对的更多是小件、且周边有速递柜条件，用户刚好要出门等场景下来使用的； 它也并非就代替了原来的快递员上门的模式；2. 柜子的空闲占用情况，你说的参考选座位的模式，也是一种好的方式，差别在于，选座位，我要考虑的座位的视野好不好，是不是我喜欢的位置，柜子，其实只要有空闲能放的就好，不需要这么多考虑；
