于需求分类和排序，通过分析用户满意度与需求实现情况的关联，找出两者间的非线性关系。排序方式分为以下三种：
基本型需求：这类是最基础的需求，比如手机里的打电话和短信功能
重点：这类需求解决后只能消除不满，不能升高用户满意度
期望型需求：这类是用户期待的需求。如果满足这类需求，则会让用户高兴；不满足，则失望。一般情况下，用户都会对一款产品有所期望，比如更多的内存、更快的处理速度等
重点：这类需求满足的越多，用户满意度越高
兴奋型需求：这类是用户通常想不到的需求，拥有之后，会让他们眼前一亮。如果用户体验还很不错，则会引起自发传播效应
重点：在解决前两类需求后，可以分配资源做这部分
用户满意度与需求实现程度间的关联，汇总如下图所示：
优先级：基本型需求>期望型需求>兴奋型需求
2.需求打包
经过前一阶段的优先级排序工作，我们就可以在需求管理文档中填入商业价值、开发量、性价比等内容，并按需求性价比从高到低排列
在日常工作中，我们是有相对固定的迭代周期，一般为2-4周迭代一次。当然，在项目开始初期，我们也曾有过一周迭代一次、更甚一周迭代两次的时候，这时就会涉及到敏捷开发相关问题
有关敏捷开发的问题，在之后项目把控的文章会深入讨论，这里只提一句：产品迭代上线的时间最好为周二至周四，因为如果在线上使用出现问题，也可以立即进行补救，不会导致占用周末时间来救火的情况
以相对固定的迭代周期为例，我们需要在阶段迭代完成后，梳理出下一阶段所要开发的需求内容。这里就需要参考性价比以及开发量了，要做到：先根据性价比决定优先顺序，再叠加开发量累计到达迭代周期范围
比如，我们是2周进行一次固定迭代，那么依次选择性价比高的前几位，并累加开发量直到满足2周任务时间为止，则本次迭代内容就是上述这些
还有一点需要注意，那就是一定要预留一段应急的时间，一般情况下我们会有2-3天的富裕，防止突如其来的需求打乱原先制定的计划。不过说实话，这是常态在所难免...
3.商业需求文档BRD
最后来讲一下有关BRD的内容，它的意义在于，在项目初期争取开发资源时提供一臂之力。但事实上，除了大公司可能会需要，像一般的小公司都会忽视BRD的存在价值
如果身为产品经理的你，想提高自己的眼界，向更高层级进发，那么非常有必要对BRD的思维框架有所了解。可能不需要你会写，但应该借鉴的是它所思考的方向和视角
网上有关BRD的模板千差万别，但归根结底还是从商业层面对未来要做的功能、实现的价值展开联想，主要分为以下6方面内容：
项目背景
从行业或企业层面分析我们为什么做，行业分析参考PEST模型，企业自身分析参考SWOT模型、波特五力图
商业价值
使用量化说明方式，具体能带来什么
功能需求
围绕做什么、做多少展开
非功能需求
交互、设计等除搭建功能以外的需求
资源评估
针对现有资源，评估各需求开发量，并合理分配
风险与对策
项目过程中可能出现的问题及其对策
BRD中需要的部分内容，也是需求打包过程中需要明确的，所以可以在需求打包前就把上述问题都想清楚
小结
本文针对需求优先级排序的知识点及流程方法进行了汇总，它是需求环节的中间步骤，起到了承上启下的作用。在接下来的工作中，还需要对已确定迭代的需求进行功能转化，经历从表象需求到实际目标再到用户价值观最后转化为产品功能的整体流程，这就是需求转化
