明確細準的需求是做好產品的前提。
需求要根據實際情況，進行側重點的劃分。我平時遇到是將重點放在當需求出現時，如何更好的梳理需求，並正確的分析需求。首先我們應該將需求從「確認出現」，到「落實設計」中間的這樣乙個階段叫做「需求處理階段」。在需求處理階段大致分為3個階段 ：需求梳理、需求分析、需求放大。
一、需求梳理
1、建立自己的需求池
這個需求池可能是協作攻擊的乙個模組，也可能是你自己的一張**，無論是什麼，關鍵是你要在上面記錄你在工作中收集到的創意、想法、功能、優化，並做出乙個基本的優先順序判斷。
2、對需求進行判斷
我們可以從以下角度嘗試對需求做出一些合理化的期待：
響應資料變化期望，例如：某個你認為可以提公升使用者興趣的功能，其必然會在產品的開啟次數、dau、mau等等資料上產生變化；
效率的提公升，例如：某乙個流程的優化或者某乙個系統內部物件的重構所帶來的效率的提公升，當然這裡的效率可能指的是使用者在使用過程中的效率，同樣也可能是系統本身的運算效率；
資料的期望 和效率的提公升是我們在整理需求過程中的乙個判斷，同樣也是需求合理化的體現
3、需求的劃分
對於需求的劃分，你可以從多個維度來考慮，例如：乙個需求涉及的功能，究竟是新的模組化功能，還是單純在現有功能進行優化（長需求或短需求）；再例如：我們根據產品所在的不同階段，根據需求的**進行劃分，市場及運營的反饋的需求、客服反饋的問題、產品本身的優化等等
二、需求分析
1、對現有邏輯的影響
思考新需求對現有業務邏輯的影響，有些表面上的影響，當然你也同樣要考慮到一些潛在的影響，這同樣是你對需求評估的乙個重要標準。
2、需求與現有流程的對應及擴充套件
新的需求可能會涉及到新的流程、新的功能，當很多新東西出現的時候，我們同樣要在邏輯層面考慮到」可復用「，並且在設計中考慮到」擴充套件性「。
3、展現的豐富 +從」可用「到」易用「
對於一些針對使用者的前端優化需求，可能更多的我們要分析其真實的目的，不僅僅是在設計和互動上進行一次次的優化，很多時候我們更應該從」可用「到」易用「的角度出發去分析需求。
4、多部門配合，多角度規劃
很多時候乙個需求對應的功能不僅僅涉及到開發和技術，當實現之後更要市場、運營等等部門進行配合，所以在這之前你就要做到」心裡有數「，全面思考並給出合理化的建議和方案。
三、需求放大
需求的放大更針對一些新的功能，或者流程變動；對於一些簡單的優化我們直接進行 下面的設計可能更加的直接有效，當然這同樣是在你的細緻思考之後。
1、解構需求鏈條
針對一些流程性的東西，我們應該對其進行詳細的梳理和串聯，這時候一張大白紙，一支筆，按照流程寫下一些可能是你想到的所有的東西，這樣更有助於你快速的分析，接下來整理每個節點，整理並劃分你寫的東西，將其串聯起來，為接下來的分析做好準備。
2、尋找背後的邏輯
拆解細分需求背後的邏輯，對每乙個你整理的節點進行更詳細的分析，這時候你可以結合你剛剛所寫的所有和這個節點相關的資訊一起進行考慮，這也會讓你考慮的更加全面，舉個尋找背後邏輯的簡單例子：在我們設計使用者下訂單這樣乙個操作的時候，其實我們要考慮到訂單的整合、支付、交易以及連續的後置操作 等等，這也都可以屬於下訂單背後的邏輯。
3、對應使用者形態
解決需求的簡單處理步驟
為什麼要寫這篇簡短部落格？答案很簡單，最近在處理需求的時候走了不少彎路，浪費了大量的時間。因此也總結了幾點失誤 1 當接到需求的時候不要急著去做，先想清楚該如何去做。2 不要把所有的問題都想的過於複雜化，其實什麼算能力，並不是你會的有多少，而是如何才能恰到好處的解決自己的需求，達到自己的目的。3 遇...
各種需求的處理
功能性需求方面 將會以一張圖的形式體現出該專案將會實現的功能與各模組之間的關係 對於出錯處理方面 我們簡單的選擇了出錯即返回上一層的解決辦法 因為系統較為簡單 所以完全可以應付 介面需求方面就比較簡單 windows系統在聯網環境下通過瀏覽器登入即可 以上三點在最終的需求規格說明書中都會附有相應的圖...
做需求調研必須回答的三個問題
需求調研是資訊化專案得以成功的關鍵因素之一，沒有準確的需求調研，專案就像航行在茫茫大海中的一葉小舟失去前進方向 沒有明確的需求彙總，專案就好象在游泳比賽中失去了目標 沒有細緻的需求，專案就像身陷敵軍而找不到突破的方向。做好需求調研，首先要回答以下幾個問題。需求調研誰來做？需求調研應該由哪一方承擔？是...