于需求分類和排序，通過分析用戶滿意度與需求實現情況的關聯，找出兩者間的非線性關系。排序方式分為以下三種：
基本型需求：這類是最基礎的需求，比如手機里的打電話和短信功能
重點：這類需求解決后只能消除不滿，不能升高用戶滿意度
期望型需求：這類是用戶期待的需求。如果滿足這類需求，則會讓用戶高興；不滿足，則失望。一般情況下，用戶都會對一款產品有所期望，比如更多的內存、更快的處理速度等
重點：這類需求滿足的越多，用戶滿意度越高
興奮型需求：這類是用戶通常想不到的需求，擁有之后，會讓他們眼前一亮。如果用戶體驗還很不錯，則會引起自發傳播效應
重點：在解決前兩類需求后，可以分配資源做這部分
用戶滿意度與需求實現程度間的關聯，匯總如下圖所示：
優先級：基本型需求>期望型需求>興奮型需求
2.需求打包
經過前一階段的優先級排序工作，我們就可以在需求管理文檔中填入商業價值、開發量、性價比等內容，并按需求性價比從高到低排列
在日常工作中，我們是有相對固定的迭代周期，一般為2-4周迭代一次。當然，在項目開始初期，我們也曾有過一周迭代一次、更甚一周迭代兩次的時候，這時就會涉及到敏捷開發相關問題
有關敏捷開發的問題，在之后項目把控的文章會深入討論，這里只提一句：產品迭代上線的時間最好為周二至周四，因為如果在線上使用出現問題，也可以立即進行補救，不會導致占用周末時間來救火的情況
以相對固定的迭代周期為例，我們需要在階段迭代完成后，梳理出下一階段所要開發的需求內容。這里就需要參考性價比以及開發量了，要做到：先根據性價比決定優先順序，再疊加開發量累計到達迭代周期范圍
比如，我們是2周進行一次固定迭代，那么依次選擇性價比高的前幾位，并累加開發量直到滿足2周任務時間為止，則本次迭代內容就是上述這些
還有一點需要注意，那就是一定要預留一段應急的時間，一般情況下我們會有2-3天的富裕，防止突如其來的需求打亂原先制定的計劃。不過說實話，這是常態在所難免...
3.商業需求文檔BRD
最后來講一下有關BRD的內容，它的意義在于，在項目初期爭取開發資源時提供一臂之力。但事實上，除了大公司可能會需要，像一般的小公司都會忽視BRD的存在價值
如果身為產品經理的你，想提高自己的眼界，向更高層級進發，那么非常有必要對BRD的思維框架有所了解。可能不需要你會寫，但應該借鑒的是它所思考的方向和視角
網上有關BRD的模板千差萬別，但歸根結底還是從商業層面對未來要做的功能、實現的價值展開聯想，主要分為以下6方面內容：
項目背景
從行業或企業層面分析我們為什么做，行業分析參考PEST模型，企業自身分析參考SWOT模型、波特五力圖
商業價值
使用量化說明方式，具體能帶來什么
功能需求
圍繞做什么、做多少展開
非功能需求
交互、設計等除搭建功能以外的需求
資源評估
針對現有資源，評估各需求開發量，并合理分配
風險與對策
項目過程中可能出現的問題及其對策
BRD中需要的部分內容，也是需求打包過程中需要明確的，所以可以在需求打包前就把上述問題都想清楚
小結
本文針對需求優先級排序的知識點及流程方法進行了匯總，它是需求環節的中間步驟，起到了承上啟下的作用。在接下來的工作中，還需要對已確定迭代的需求進行功能轉化，經歷從表象需求到實際目標再到用戶價值觀最后轉化為產品功能的整體流程，這就是需求轉化
