另一方面，处理例外是一个灰色的区域。假设您有了带有七个区域的输入屏幕，它们中的所有都有不同的限制。您有一个日期区域，一个邮政编码，一个输入区域，以及等等。每一个检查可能会在单独的流程中得到描述，因此被计算成可能不止一个事务。您可以选择的是，提供一个通用的流程。它预假设有一个可以容易处理的例外种类的框架。在这种情况下，您应该将该流程计算成一个事务。
使用当作环形路线的用例事务，可以在用例中随处可见。因为一个用例配置至少有一个基本流程，它也至少应该有一个事务。没有事务的流程是没有意义的，因为系统在没有刺激源时什么都不会做，用户在没有弄清系统的反应之前也不会提供任何刺激源。
几乎一直都会有描述处理例外的流程（因此，“例外的流程”）。每一个例外流程都至少含有一个事务。这点也适用于一个可选择的流程；对于每一个可选择的流程都应该有至少一个流程。很可能您需要查看基本流程，以查看可选择流程中事务的刺激源；这取决于处理用例的特定指定原则。
它给了您一个任何用例配置中用例事务最小数量的指示：流程中至少应该有以下数量的事务。
显示和计算
如果您拥有识别用例事务的能力，您是否需要对它们平等的重视？我们的策略是显示它们中的，每一个与事务（如果可以应用的话），但是有些时候并不计算它们的权重。我们的策略要比直接忽略它们更加直接。如果需要的话，调整原始的估算也十分的容易。
通过这种方式，您就能够看出框架的价值。如果用例计算十个事务的话，但是它们中只有三个值得处理，另外三个遵循框架，该用例是普通的而不是复杂的。
许多系统步骤可以是一个新的用例
是不是没有办法解释一个用例业务暗含的系统步骤与只有一步系统步骤之间的差异？您的直觉告诉您构建6个系统步骤要比构建1个需要更大的努力。实际上，我们完全赞成。但是，您不应该试着通过计算系统步骤，而应该通过隔离另外系统步骤涉及到的功能性，来解决这些小问题。如果您拥有大量的功能性，那么可能它就是用例本身。注意不要将任何堆积的功能发展成“用例”的状态。这将会是功能性降级。但是应用如下的规则：后续的用例必须拥有一个清晰的目标，这符合至少一个投资者的利益（并不一定与用户相似）。
一个范例可以是用例“产生年平均”。在这个用例的过程中，会生成一些报告，代表一个特定投资者的利益。生成每一个报告的过程中，会涉及到一些系统步骤。为每一个报告定义单独的用例，能够帮助您找到合适的投资者，而不用打扰其他的投资者。通过这种方式，我们就能够提供更加保险的估算了。
批任务
如果用例使用在缺乏用户交流的情况之下（在这方面我们有较好的经验），那么您怎样将业务的概念转化成一个环形路线。坦白来说，在这里它并不适用。您需要其他的方式来估算这种用例的权重。而且，这是由专家估算来完成的。表2显示了它们是怎样在扩展卡中显示的。
参考文献
[1] Jacobson,Ivar 等，Object-Oriented Software Engineering. A Use Case Driven Approach, 修订版，Addison-Wesley 1993.
[2] Cockburn,Alistair,Writing Effective Use Cases,Addison-Wesley,2001.
[3] Ribu, Kirsten,“Estimating Object-Oriented Software Projects with Use Cases”,MSc Thesis Oslo 2001
[4]?vergaard, Gunnar 和 Karin Palmkvist,Use Cases: Patter