Aaron之无主题空间

皆主题,此谓无主题。
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

杂话用例建模【6】:异常流程的价值

Posted on 2009-07-30 20:24  Aaron  阅读(575)  评论(0编辑  收藏  举报

有人认为,Use Case的描述中,主成功流程的价值是最大的,异常流程则不然(起码是“不那么大”)。

Actor来说,主成功场景往往(也只是“往往”哦)是最有价值的。但是对于需求分析师来说,对于捕获需求这个活动来说,真正有价值的是异常流程。

为什么这么说?

因为异常流程里隐匿了很多通常不能“一下子”就能看到的需求。这部分需求可能只占系统的20%,却可能需要我们花80%的功夫去发现。仍然用绝大部分应用都可能用到的“登录”来说明:“登录“是一个很容易想到的场景,只要你想要使用受保护的功能则必须登录;而“找回密码”则相对不那么容易被发现。只有当我们在分析“登录”的异常情况时,才会发现:密码错了怎么办?密码忘了怎么办?

所以,其实异常流程会帮需求分析师发现新的场景和业务规则,这些场景和业务规则如果没有被发现则我们的需求是严重缺损的。而这些缺损带到开发阶段就会耗费较高的成本来弥补。

大家一定有过这样的体验:需求很快做好了,横看竖看都觉得什么都明白了;但是到开发的时候,问题就来了:如果申请被拒绝了怎么办?如果用户重复提交申请怎么办?等等诸如此类。有的异常流程甚至到测试的时候才被发现。

要处理这类问题就头疼了:可能需要更改一条业务规则或增加一条新的业务规则,但这条新规则可能与现有的其他业务规则有冲突……当这样的情况越来越多的时候,就全乱套了!而有的可能需要需求方、业务专家参与解决,这个时候需求方和业务专家可能已经不在项目组了。即便能找到,可是这个时候所有人对当时的场景都忘得一干二净了,想要重新讨论何其之难?

所以我们一定要避免这种做得很不透彻的需求分析。在描述Use Case的时候要尽力发掘出可能存在的异常情况,尽早发现所有存在的需要需求方或业务专家解释的问题。如果没有了对异常流程的挖掘和描述,则Use Case聊胜于无!