1 分析對象
如果問題能夠在需求階段予以解決，后續的整個項目的進度和質量將會好很多。
1.1 需求分析的對象
- 產品需求說明書
- 交互原型
- UE圖
一般在進入需求評審之前，要求PM將這些文檔提前發出來，提前了解該需求，帶著問題參加需求評審無疑是最高效的
2 如何梳理需求
2.1 需求來源
- 市場調研
- 數據埋點
- 用戶吐槽
我們為什么要做這個需求，這是一個why的過程。這也是需要一些數據來支撐這個需求的必要性。我們可以通過目標用戶的市場調研，通過已有客戶的使用的數據埋點統計，以及用戶的吐槽來搜集這些需求，然后根據這些數據的頻度和產品的規劃結合，確定該需求的優先級
2.2 需求注入的使用場景
往往PM在設計一個需求的時候，可能存在對需求理解的偏差，或者在設計的過程中設計的模型與用戶的實際場景會有一定的差距。我們就需要去還原這個真實的業務場景，看這個設計是否是用戶這個場景的功能模型。
2.3 需求邊界
- 正常業務流程
- 異常業務流程
往往PM設計的需求只會去描述正常的業務邏輯，而在實際使用過程中，各種分支和場景是多條路徑的，我們要想到各種異常的操作可能，要么在產品設計上加以規避，要么在程序設計上予以處理
2.4 摳字眼
需求的描述往往是文字話的表述，而中國的語言是多樣話的。我們就需要一個個的字去扣，比如說我要老公去買個蘋果。那去哪里買，買什么樣的蘋果，這些就要我們在分析時進行拷問
2.5 NLP，按照程序性思維分解
我們在梳理需求的時候，要將語言文字轉化為程序邏輯的過程思考，這樣你會發現一些判斷、邊界的問題
2.6 交叉邏輯，影響點
往往產品不斷的迭代，相互之間的交叉會越來越多，這時候就要關注是否對其他部分存在影響
針對移動端，還需要考慮對老的版本是否會有兼容
2.7 UI風格是否一致 風格、交互
這個往往是我們不太注重的地方，產品也是品牌樹立的一部分，整個系統的樣式是否統一、交互是否一致
2.8 結合當前的技術框架的可行性
當然了，需求設計的很好，但是也得結合目前的產品技術架構和產品架構進行思考，是否與目前的產品架構是一致的。還是整個底層都要重新來過，這是需要考慮時間成本的
3 工具
3.1 流程線框圖
我們在梳理需求的時候，業務流程比較長，涉及到的職能角色比較多，數據鏈長，我們需要借助工具來幫我們進行梳理，如采用visio等建模工具
3.2 思維導圖
當然，業務點比較多，在梳理的時候通過思維導圖擴散的模式來梳理也是很有必要的
4 沉淀
4.1 評審前的問題搜集
需求的梳理過程中，會發現有很多的疑問，一定要立即記錄下來，反復2-3次這樣的梳理，然后與PM進行溝通，并記錄溝通完成的結論
4.2 會議紀要
而在評審過程中，其他同學都會有他們自己角度的一些問題，這時候要認真的去記錄，然后回顧，也是對自己的需求梳理方法的一個完善的過程
