【題記】作為一只“冠冕堂皇”的產品狗，總是少不了在各種情形下（包括，拉出業務主流程就行、2個小時之內、不考慮技術實現等等）被要求產出各種規格、版本、形式的需求文檔，那么也就少不了將文檔提交給業務的上下游環節，或者在各種正式和非正式的場合進行各種名目的評審，那么也就免不了擔心就著需求被人指指點點，在眾人面前因為各種小細節的遺漏、邏輯的模糊被挑戰。雖然，在考慮問題的時候難免在細節上可能會出現遺漏，這也是需求評審的重要意義之一，但是，對于自己需求的自我檢查，能夠更好地家加強自己的信心，也能夠在業務上下游環節樹立自己更美好、更專業的產品狗形象。

事實上，每次在需求提交前進行一次需求文檔的梳理有助于自己對于需求整體和細節的把握，能夠在一定程度上通過情景再造詳實需求細節，也便于加強自己對于需求的熟悉程度，以在需求評審時能夠快速、敏銳的闡述自己產品設計的出發點和對于業務實現及客戶體驗的考量。那么，問題來了——需求檢查從何做起，要怎么開始？

【其實，方法很簡單】進行需求檢查的方法，實際上和我們在進行產品設計的方法是一致的，即“可用性”檢查的方法，也就是通過設定：用戶在特定條件下完成指定任務。從這個角度來解釋需求文檔，就是，用戶在特定條件下完成指定任務的實現指南；繼續延伸下來，對于需求文檔的檢查，就是對于用戶、特定條件和指定任務的逐層分解后進行業務流程的演進，進而通過任務完成的過程檢查各節點在需求中的映射，發現邏輯遺漏或者流程細節中的缺失。

【示例】以我們常見和經常使用的移動購物APP為例，在完成主要的業務流程和結構功能的構建之后，在進行需求檢查時，對用戶、特定條件和指定任務進行逐層的拆解，我們可以得到以下內容：

用 ?????戶： 按照用戶類型進行拆解得到：游客、注冊用戶、第三方賬戶登錄用戶

? ? ? ? ? ? ? ? ? 按照用戶級別進行拆解得到：普通用戶、VIP用戶

? ? ? ? ? ? ? ? ? 按照用戶角色進行拆解得到：操作用戶、管理員用戶

? ? ? ? ? ? ? ? ? 按照用戶狀態進行拆解得到：新建用戶、歷史用戶

特定條件： 按照登錄狀態進行拆解得到：登錄狀態、未登錄狀態

? ? ? ? ? ? ? ? ?按照網絡狀態進行拆解得到：在線狀態（WI-FI、3G）、離線狀態

? ? ? ? ? ? ? ? ?按照數據狀態進行拆解得到：空白狀態、存量歷史數據狀態（A/B，一條/多條）

? ? ? ? ? ? ? ? ?按照預設條件是否滿足進行拆解：滿足狀態（條件1/2）、不滿足狀態（原因1/2）

指定任務：指定任務按照業務流程的節點進行拆解和定義。

? ? ? ? ? ? ? ? 各個流程節點的任務都可以歸結為“表單記錄”式操作：增、刪、改、查

? ? ? ? ? ? ? ? ?按照指定任務為查看商品詳情進行拆解得到：查看新商品、查看購物車/訂單商品

? ? ? ? ? ? ? ? ?按照指定任務為收藏商品進行拆解得到：收藏新商品、二次收藏商品

以上拆解并非是完整展示，而且在拆解之后所要進行的更為重要的步驟是交叉組合，將拆解得到的內容組合后還原成”可用性“檢查的內容模式：不同的用戶在不同的特定條件下完成不同指定任務的實現指南。只要通過逐層的拆解和組合，就能夠在構建完成的主業務流程需求的主干上，不斷的細化、豐富、完善需求內容。隨著拆分的細致程度的不斷提升，檢查的深入程度也會不斷的加深，相應的需求的質量也會得到不斷的強化，也將實現我們之前所討論的目的：一步到位，拒絕別人對你的需求說三道四。