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

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

为什么这么说？

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

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

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

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

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