能仅仅意味着订单已经经过验证并且交货已经排定日程。场景中的任务一个用例中的不同场景显示目标怎样成或败：成功的场景中目标达成，失败的场景中目标没有达成。这里边美妙的地方在于：目标总结了许多的系统使用意图，用户可以看见他们被期望臬使用系统。当然系统没有支持他们所有的目标时，用户也能立即察觉而不用等第一个原型开发出来，或者甚至糟糕到要等系统全部开发完才发现。用例应该多大一个有趣的话题是试图确定用例的大小。一种方法是将大小与用例的范围与意图联系起来。对于真正大的范围，一个用例不只描述一个单独的系统，而是描述一笔业务用到的所有系统。这种业务用例busi
essusecase将整个系统当作一个黑盒，并描述活动者与公司相关的目标。业务用例的场景不可以对公司的内部结构做任何假设。也就是说：用户应该向公司下订单，不是客户服务部。而对于系统开发来说，一个用例的范围限制为单个系统。这是用例更常见的形式，称为系统用例systemusecase，它们将系统当作黑盒。这些用例不能描述任何内部结构，并且只能使用问题域的语言。用例的另一个范围是系统内的子系统或构件的设计。这些实现级用例impleme
tatio
usecase将构件当作黑盒，活动者是与之有接口的构件。例如：可能用实现级用例说明某个应用程序对所使用的EMAIL构件的要求。按这样分级，关于用例大小的讨论是容易的。被设计项目item的范围界定总的大小overallsize。为了帮助系统设计者，每个用例应该只描述单一的没有大分枝的活动线索
fthread。违背这一约束，这在不精确或含混的准则中常常能见到，会使得把用例当作测试说明源材料的变得很难。作为系统用例的例子，“询问数据库库存是否偏低”就太小了，显然把实现细节与需求混起来了。对比之下，作为系统用例，“管理仓库”就太大了，因为它不可能作为单一的没有大分枝的活动线索来完成，而且从系统看，描述目标成功是很困难的。但它是个很好的分部门partsdepartme
t的业务用例。对于分部门来说，定义“管理仓库”目标的成功是可能的可能用库存清单变化、部门能力或运作成本等术语。业务用例的好处在于可用来将其它用例归类。“管理仓库”可用来组合所有与仓库管理相关的用例。用例的形式化定义用例是结果的提交者，该结果对特定活动者是可测量的。正如前面提到的，活动者可以是与要设计的系统进行交互的人或外部系统。对于一个用例有可以测量的结果的要求，是从单线索要求衍生的。做为可测量结果的一个方面，r