敏捷開發與項目管理實戰之敏捷需求分析(2)

　　區分知識層與操作層的具體實現往往可以采用系統參數化(如通過配置文件實現參數化)。比如，為了防止一個系統被惡意登錄。很多系統可能會在多次登錄失敗后，將相關的登錄賬號鎖住。但具體的登錄失敗次數應該是可以在系統運行過程中動態調整，因為這是個操作層的問題。

　　可見，區分需求的知識層和操作層可以使交付的系統更具可用性，減少系統的不必要的改動量，節約團隊資源。

　　分析復雜需求

　　對于一個所覆蓋的業務場景背景比較多的需求，有一些人傾向于同時對多個場景進行理解和分析。但這樣做的結果往往是容易把本不該放在一起考慮的問題放在了一起討論，影響了思維的清晰性和條理性，最后反而妨礙了需求的正確理解和做進一步分析。其實，對于這種需求可以采用"分而治之"的策略進行分析。先將各個業務場景繪制成決策樹上的分支，然后單獨對決策樹上的各個分支逐一進行理解和分析。再在次基礎上，綜合分析各個分支。

　　決策樹不僅可以清晰、直觀地展現這些業務場景，便于個人理解需求和進行團體討、分析需求。而且，決策樹因畫法簡單，便于在白紙和白板上手工繪制。

　　例如，有這樣一個需求：用戶可以通過發短信的方式利用自己手機賬戶的余額為其它手機賬戶充值。實現該功能時要求滿足如下條件：

　　用戶及余額接收方的賬戶類型必須都是預付費

　　若充值金額超過 200 元，則用戶的手機號必須在大額充值白名單中。否則，不允許充值。

　　充值手續費為充值金額的 0.5%。手續費不足 1 元按 1 元算。

　　如果充值后，用戶賬戶余額不足 30 元，則不允許充值。

　　若充值失敗或者不滿足充值條件，則短信通知用戶未充值成功及其原因。

　　這樣一個邏輯分支稍微復雜的需求，可以手工畫出相應的決策樹。使得我們可以清晰得表示它，

　　便于理解需求和團隊討論需求。如圖 1 所示。

　　圖 1. 決策樹

　　若一個需求涉及先前迭代中已經實現的多個模塊的修改。則可以用投石問路的策略，先對其中一個模塊相關的需求進行分析，再根據對這個模塊的分析中所獲得的知識及發現的問題繼續對其它模塊涉及的需求進行分析。這樣可以降低分析的難度提供分析的效率。

原文轉自：http://www.ibm.com/developerworks/cn/rational/r-cn-agilerequirementanalysis/index.html