才成立。尽管一些书写用例的方法将它描述成叙述用例事务的另一种方法，但毕竟它不是标准的方式。
用例事务不是一个“刺激源”
有些作者建议“用户运行的刺激源的存在性就是定义事务的部分”。尽管一次事务总是从一个刺激源开始（就是用户进行了一项触发系统反应的操作），刺激源本身并不是完整的事务。假设您拥有一个以下的用例描述：
用户选择一个 X.
…
（n）用户提交。
…
现在还不清楚系统是否对步骤（1）和（n）中刺激源作出了反应，或者系统是否对步骤（1）或者步骤（n）分别作出。因此，两个刺激源可以组成一个或者两个事务。它并不取决于刺激源，而是取决于刺激源和回应的组合。
用例事务并不是一个数据库活动
在 Web 上进行的许多次讨论中，您可以找到定义为“一系列要么完全执行，要么一点也不执行的活动”的用例事务。该定义听起来像是数据库管理系统中的一个事务性机理，如果它没有正常运行的话该步骤可以返回。在我们的经验中，这不是在一个用例描述中将一片内容与另一片内容隔离起来的方法。它也行会激发一个想法，也就是事务在一定程度上与数据库中的读写操作相关。但是，在一个环形路线中，系统根本不用查询数据库也是可能的。这个过程中数据库也行根本不会涉及到，或者数据来自系统以外。因此得出用例事务一定会与数据库中的事务联系起来的结论是不合适的。
用例事务不是一个系统步骤
用例事务中的系统可能会在一步完成。表面上，我们可能会得出用例事务只是一个系统步骤。但是，一个系统步骤并不是描述用例事务的一个较好的基础，因为它取决于对您计算的多少步骤的描述。而且，系统本身并没有多少涉及到Actor与系统之间的联系。换句话说，您的估算应该基于“环形的”事务，而不是系统步骤。
范例：复杂的用户界面
用例事务的“环形路线”方法，在估算用户界面复杂性方面显示出其价值。一个范例就是工作入口项目，在这个项目中可以设计出一个工作设计机器。在基于用例模型（Survey）的早期估算中，工作搜索界面被认为是简单的；用户可以从一系列的下拉菜单中选择搜索项，然后进行选择。但是，在用于产生用例描述的用户界面中，如果系统可以对已作出的选择进行回应，并更改后续下拉菜单中内容的话，那么可以预见应用的可用性会得到提高。换句话说，本来应该是一个的事务现在变成了两个。
这里是用例配置的第一个草稿：
该段文字扩展如下：
这里您可以看到两个“环形路线”。将用例配置当作证明，查看调整初始估算后的合理性变得容易起来。
将用例事务保持在一定的层次上
如果用例事务是一个紧跟系统回应的刺激源，那么它十分能够计算成一个事务？例如，如果我从我的键盘上敲入一个“K”，那么这就是一个刺激源，然后系统会通过在屏幕上显示一个能组成“K”的像素点来回应这个刺激源。所以，我们以前推荐的定义是不是太狭隘了？
不，不是这样的。它显示您理解用例事务时，应该与用例事务本身被理解保持同一个层次。现在，您可能对输入字母这种操作不感兴趣，当字母出现在屏幕上的，您就会觉得这是理所当然的；您不需要在系统中构建什么东西来产生结果。但是，如果您的内容是描述键盘模型与图形化反应器，这样一个用例事务是十分合理的。
怎样计算事务
既然您已经看到了决定什么是以及什么不是用例事务的清晰解释，让我们检查在用例中计算事务的一些挑战。如上面所述，用例的权重是由它所包含的用例事务的数量所决定的，但是，什么时候系统对刺激源的反应会计算成不同的？
使用用例事务与流程
让我们通过检查上面介绍过的工作入口的搜索流程开始。如果用户在寻找一个“Java”类型的工作，他选择了 Java,然后系统会在数据库中搜索这种类型的所有工作。当用户寻找一个“.Net”类型的工作，它选择了.Net。然后系统会搜索数据库来找到该类型的所有工作。这两种是不是不同的事务？当然不是。用例配置本身是抽象的或者通用的，在这个意义上您不要对不同的搜索项期待不同的流程。这只不过是安装过程中的一点不同。但是，您可以对一个使用预定义类型或者自由格式文本的搜索期待不同的流程。