敏捷开发与项目管理实战之敏捷需求分析(2)

　　区分知识层与操作层的具体实现往往可以采用系统参数化(如通过配置文件实现参数化)。比如，为了防止一个系统被恶意登录。很多系统可能会在多次登录失败后，将相关的登录账号锁住。但具体的登录失败次数应该是可以在系统运行过程中动态调整，因为这是个操作层的问题。

　　可见，区分需求的知识层和操作层可以使交付的系统更具可用性，减少系统的不必要的改动量，节约团队资源。

　　分析复杂需求

　　对于一个所覆盖的业务场景背景比较多的需求，有一些人倾向于同时对多个场景进行理解和分析。但这样做的结果往往是容易把本不该放在一起考虑的问题放在了一起讨论，影响了思维的清晰性和条理性，最后反而妨碍了需求的正确理解和做进一步分析。其实，对于这种需求可以采用"分而治之"的策略进行分析。先将各个业务场景绘制成决策树上的分支，然后单独对决策树上的各个分支逐一进行理解和分析。再在次基础上，综合分析各个分支。

　　决策树不仅可以清晰、直观地展现这些业务场景，便于个人理解需求和进行团体讨、分析需求。而且，决策树因画法简单，便于在白纸和白板上手工绘制。

　　例如，有这样一个需求：用户可以通过发短信的方式利用自己手机账户的余额为其它手机账户充值。实现该功能时要求满足如下条件：

　　用户及余额接收方的账户类型必须都是预付费

　　若充值金额超过 200 元，则用户的手机号必须在大额充值白名单中。否则，不允许充值。

　　充值手续费为充值金额的 0.5%。手续费不足 1 元按 1 元算。

　　如果充值后，用户账户余额不足 30 元，则不允许充值。

　　若充值失败或者不满足充值条件，则短信通知用户未充值成功及其原因。

　　这样一个逻辑分支稍微复杂的需求，可以手工画出相应的决策树。使得我们可以清晰得表示它，

　　便于理解需求和团队讨论需求。如图 1 所示。

　　图 1. 决策树

　　若一个需求涉及先前迭代中已经实现的多个模块的修改。则可以用投石问路的策略，先对其中一个模块相关的需求进行分析，再根据对这个模块的分析中所获得的知识及发现的问题继续对其它模块涉及的需求进行分析。这样可以降低分析的难度提供分析的效率。

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