開始接觸需求工作時，在對用戶需求的溝通基礎上，多依據于做軟件開發的結構化思維方式來編寫需求文檔，這種方式易陷入實現細節的陷阱。如何在用戶需求和軟件需求之間找到平衡點，使得做出的產品即是用戶想要的又在技術可行和成本上性價比最高，甚至超出用戶期望，給用戶驚喜，開展需求工作時需認真考慮。業內談得比較多的‘六何法（what、why、when、who、where、how）’，在需求分析工作中同樣適用，可作為問題分析的基本習慣。下面談些自己的理解：

1、信息收集和初步分析：
 what：需求是什么，解決什么人的什么問題（用戶群體、用戶規模、業務場景、性能指標和組網）？
 why：背景是什么，為什么有這個需求（高層領導思路、團隊主動規劃需求、競品分析需求）？
 when：需求的市場時間（實驗室驗收、試運營和正式上線等各階段時間）？
 who：需求的用戶對象是誰（如：技術部門），是否與其他用戶對象（如：業務部、內容部、運維部門等）有關聯？
 where：哪里做（現場開發還是團隊本地開發）？
 how：怎么做（需求端做可行性分析、技術團隊負責實現）？
  需求端需要關注的幾個維度：
   1.關注需求的輸入
   2.關注需求的輸出
   3.關注中間的業務流程
   4.關注對歷史需求的影響
   5.關注需求的價值延生
   6.關注中間業務流程的數據回收

2、結合現有產品的情況做進一步分析：
 原則：樹葉—>樹枝—>樹干—>樹枝—>樹葉（樹X思路借鑒自《人人都是產品經理》）
 過程：首先，從樹葉—>樹枝—>樹干，其次，從樹干—>樹枝—>樹葉的過程。一方面不能漏掉提煉用戶需求的這個過程，目的是透過現象看本質，另一方面也不能停在本質上，試想如果做到“樹干”就結束，后端的執行人員可能還是不知道要做什么東西，所以要繼續把樹干再重新分解成樹枝、樹葉。總結成一句就是：自底向上的透過現象看本質以抓心核心，自頂向下的將需求逐步分解以指導研發。
  分析過程：
  1）從業務流程的角度，搭建需求框架。
  2）對各個功能需求逐步細化。
  3）將需求分析過程中的疑問形成訪談清單。
  4）與用戶溝通澄清，達成一致。
  5）根據澄清意見修訂需求。
  6）根據修訂后需求及全流程，重新梳理一遍。
  7）考慮和已有功能的關系及并行下的業務處理。
  8）考慮需求的外延（基于新業務規劃和運營數據分析），為后續迭代準備。
  9）考慮不同區域客戶或同一區域不同客戶的易用性需求。
  10）需求查漏補缺，形成閉環。 

讀后感：《項目經理應該知道的97件事》中關于“矛盾體的需求說明書”
      良好的需求具體描述了你正努力解決的問題，并描述了為何一定要解決這個特別的問題（即需求需要說明“做什么”和“為什么要做”），這會使程序員在開發過程中更靈活、更高效和更積極。編碼人員只有致力于解決問題并深入了解這個問題時，才會做出獨立的設計選擇。他們應只受限于他們已經選用的技術，而不受限于非編程人員制作的教條式的脆弱說明書。
      將你努力制作的東西與怎樣去制作它區分開來。然后，讓訓練有素的各個團隊成員根據他們自己在項目中的角色來做決定。
      倘若不分清用戶需求和軟件需求說明書的界線，就會導致錯誤的人在作決定。導致的結果無外乎兩種，要么是讓軟件開發人員來決定什么功能對客戶重要，要么是軟件項目經理來告知開發人員如何構建代碼。無論如何，都只會產出低劣的軟件產品。