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