確定
確定需求往往是承接需求調研而來，目的是搞清楚產品部門究竟要解決的是什麼問題，有時候業務部門會要求你能為他們做到些什麼，但這種要求往往過於含糊，你還需要再和他們多了解一些信息，才有可能真正了解他們希望得到是什麼，避免發生買個MBP回來只為裝了winxp玩掃雷這樣的杯具……
在確定環節中，這只完成了一半的工作；接下來我們需要知道對應這個需求，會有哪些角色來使用，我們需要能夠對這些角色涉及到的不同需求做出細分。這也是需要和業務/需求部門溝通好的。
分解：
分解的意義在於把大問題化解為小問題，變成一個個可控的模塊，注意這裡是說的可控是指你可以通過一定的約束條件和已知存在的變量來實現對問題的描述。經常看到的所謂需求拆解只不過是把業務部門的需求換個描述方式，這種糊弄人的做法要不得，山寨，害人害己。
大問題變成了小問題，我們就可以來討論如何去實現了。
至於該如何把大的需求拆解，這裡提供兩種思路：
要記得，在需求被拆解後的每一個問題有些是對應固定的角色的，而一些則是可認為是無所謂角色區分的共性問題，還有一些問題的處理結果會影響他角色。務須能分清楚來對待。
分解階段另一件重要的事情就是完成流程圖的設計，對應產品人員要做的是業務流程圖，如果有核心開發人員也參與了前期的需求討論分析，可以建議他們同步展開架構流程的思考。
在繪制流程圖的時候需要盡可能標明其中的裡程碑功能，大約需要哪些功能支撐、需要設計多少個頁面或頻道、組件，對應的管理後台需要有哪些對應的調用。這時候也需要一並帶著整理。我的實踐經驗是，可以先做完流程圖，然後把後面的這些問題帶進去思考，一方面尋找答案，一方面也可以完善你的流程圖。
如果能夠一路堅持走下來，基本上可以做到很完整地了解自己要解決些什麼問題了。這時候你面對的就不再是一個總的需求，而是一個個細節的問題。接下來要做的就是對各個問題進行評估，
評估；
如果我們把分解理解為找問題，那麼評估就是為解決問題做准備。
鑒於我們在分解問題的時候，其實已經涉及了一部分評估的工作，這裡不妨更深一層。例如，你打算使用多少個頁面、會有多少個功能點出現。這些經過分析提煉後的內容可以用PRD或者低保真原型的方式展現給相關的開發人員和業務部門。
不過評估最重要的工作並不是要窮列出來究竟需要做哪些工作，而是需要對這些即將展開的工作做出排序，同時你可能必須捨棄一些原本精心構思的內容。
對工作的排序是產品自己無法完成的，需要盡可能和開發部門配合。開發人員對於業務需求有著自己的一套理解，同時由於涉及到很多實現細節的問題，也需要在達到共識的基礎上才能繼續推動。
因此，在真正展開具體的產品設計工作之前，需要能和開發人員進行溝通，盡可能做到以下幾點：我們需要多少個功能點來支撐這個產品或滿足需求；這些功能點都是可以在規定項目時間內開發完成的嗎；開發人員對於自己要做的事情有足夠的判斷，知道哪些應該先做，哪些要後置；對於暫時無法實現的功能，是退回給需求方，還是產品重新構思或者延至2.0版本完成，需要說明清楚。
對於沒有技術背景的產品，這時候很容易陷入被動，你可能會被技術提出的各種“不好實現”攪得心煩意亂。為了避免這種情況，你最好能找到一個能和你順暢溝通的技術經理，很多問題其實並不需要你親自上陣的。
決策：
在經過了前面幾輪重重的折磨，才是產品人員真正發揮創意的時候，你將左右會有怎樣的表現，你擁有整個產品開發的決策權。別人可以提意見，但是最終你才是那個決定事情該怎麼做的人。
制定項目計劃，針對每個細分功能拿出具體的實現策略，給出產出物的交付時間，繪制原型圖和PRD文檔。從產品整體框架到頁面布局、頻道功能再到按鈕的位置，彈出層的設計。設計的創意才在這裡真正迸發，你所有知道的界面設計、導航架構、交互形式的知識和才能都會在這裡得到淋漓盡致的體現。
暫且撇下你的設計創意不表，如何把評估階段的成果應用好是我們是否能順利進入決策階段的關鍵。總會有一些功能被砍掉，也有一些新功能提出來，原本想好的某些流程也可能要重新調整。在決策階段，你需要有做減法的魄力和決心，拋棄一些東西，適當做一些讓步，但是要能保證產品的核心功能不被閹割。對於核心功能，任何為了減輕工作量或者無法實現而要求繞道而行的借口都是可恥的；如果你有有充分的理由相信產品的核心功能，那就一定要堅持到底。
寫在最後的話：
至此，我們通過確定、分解、評估和決策把需求分析階段要做的事情做了一個梳理，也為後面的設計和開發開了一個好頭。當然你仍然會面臨業務部門的需求變更，設計或者開發人員在某個功能或表現形式上跟你死磕的局面，這時候你仍然可以應用這四個步驟來解決具體的問題，但是在實現上需要做一些變通，項目一旦進入到開發編碼階段，時間會非常緊湊，你能做的就是根據新提出來的想法迅速協調好利益相關部門，在開會之前你就能要准備好幾套方案，否則會議就會變成一種折磨：低效，浪費時間，不解決問題。