业务用例与系统用例
取决于被讨论系统的不同，在业务用例和系统用例之间可能存在着巨大的差异。一个是描述用户的业务，而另一个描述的是用户同系统的交互活动。然而，这两种类型的用例之间的区别也可以变得模糊。例如，在一个软件开发项目中，系统就是业务。当您开发和测试一个特定的系统功能的时候，很容易就会忘记最终的用户很可能不会用您所采用的方法使用该系统，甚至都不会拥有同样的需要。
为了理解业务用例和系统用例之间的区别，想象一下软件开发团队已经承担了一项软件应用程序开发任务，并且要保证其在全球各种不同地区的环境下都可以同样出色的运作。为了确保该应用程序达到这些要求，该团队就必须遵循一套最小化的全球规则。1 这些规则在一套规范中被严格定义，不能随意被更改。开发团队需要针对这些规则来审核自己的代码，目前这些工作必须由手工来完成。一位程序师（审核员）必须打开源文件来查找同指定规则相矛盾的地方。
该组织收到一份执行决定，要建造一种能够使这些全球性规则（及其他规范）得到自动分析的工具，并且集合一支团队来开展这一项目。目标就是将业务用例中手工操作的那部分替换为软件应用程序（即系统）。这一手工过程非常耗费时间且容易出现错误。并不是所有的程序师都能够同样好的理解这一全球性的规则，许多人很可能没有注意到这之间存在的矛盾之处。另外，团队成员在持续的工作压力下变得越来越快的生产产品。一个可以核查全球化规则的自动化的系统将降低忽视某条规范的风险，并节省大量的时间。
在这个特定情节中，业务用例“在核查之前复审每一份源文件”可以被看作：
对于工作区内的每一份源文件：
打开源文件。
逐行阅读代码（注：需要深入的代码知识）。
如果您发现了一个可以的方法，就请参考包含这一规则的网页（注：非常耗费时间）。
如果可能的话，通过修改代码解决该问题（对于开发者的业务用例）。
对于测试者来说可选的流程：如果您不能正确地解决这个问题，就请将发现的问题记录在Word文档中并提交给开发人员。
打开下一份源文件并重复上面的步骤。
正如您所看到的，这是一套冗长的流程，但却是实现自动控制的一个非常好的候选方案。
系统用例的价值
一旦您定义了用户的“就是这样”的流程和目标，您就能够指定那些用户活动的部分是一个自动控制的系统所能提供的。尽管它们仍然包含着用户的活动，系统用例却是以系统为中心的，来描述用户同系统交互的过程。然而，请注意系统用例应当在业务流程的背景下被定义。最终，我们的目标是帮助用户处理业务问题。
这里就是在我们虚构的项目中，团队是如何定义基础系统用例的，假设用户就是团队的一个成员：
前提：全球性的规则在IDE的复审特性的代码中被授权使用。
在IDE中打开代码复审工具。
（步骤之打开工具）。
运行一个代码复审。
主流程——点击按钮“Run”。
（在新区域内列出可选流程的详细描述）。
复审自动化复审的结果（发现的问题）。
对于每一个发现的问题，解决之：
主流程：提交缺陷。
（在新区域内列出可选流程的详细描述）。
如果您不能够修正这一代码，则提交缺陷。
（步骤之缺陷提交）。
一个包含以上这些步骤地简短的文档将提供充分的信息，使得读者了解到最终产品应该是什么样子，它将如何帮助客户处理他们的业务，等等。即使这一信息没有被明确的说清楚。
下面是拥有系统用例而带来的一些显而易见的好处：
即使没有一个代码被分类为“代码复审完毕，等待测试”，测试人员也能够针对上面描述的功能制定出一份测试方案。
另外，正是基于这一点，文档编写者可以针对代码复审创建并且（或者）添加文档中的结构。
开发管理者在此之后可以使开发进度更加优化，以便使得第一份开发构造将至少满足该用例的主要流程。
用例促进了项目的开发，并且使得全体团队成员在项目伊始就忙碌起来。如果您仍然没有将您的工作关注到用例上，那么请给它们一次机会。您所付出的努力将是值得的。
确定系统用例适当的详细程度
在每一个用例步骤中应该包含多少信息呢？
我更偏爱于取得系统用例并将其根据业务用例分类，并且同样通过一组步骤将大量的用户交互活动分类。该组步骤解释了该步骤的目的，并且可以在某些细节在实现过程中改变的情况下保持不变。这种方法使得文档更加易懂，它将系统用例和业务用例联系起来，并且如果产品执行变化时它允许用例可以被容易的修正。
例如，在上述系统用例中的简单的步骤“运行代码复审”中，向细心的读者传递了一个非常有价值的信息，包括：
代码复审被结合在IDE中。
代码复审必须在使用中，或者“运行”。
代码复审提供了一个关于违背某套有效性标准的问题清单。
某些问题可以被迅速的修正。
代码复审将获得迅速的修正。
回页首
确保有效的测试
一旦用例被适当的设置并且开发团队就他们所扮演的角色达成共识，这些用例就成为方案中其他部分的基础。实际上，这是最好的利用它们所提供功能的方法。
工程团队建造一个开发方案，其中至少要包括：一份将要被建造的组建的清单，以及每一个组建的时间期限。清楚的描绘主用例的特性需求和实际工作特性的组件必要性之间的关系是非常重要的。
识别这些核心组件并且定义它们的用例是非常关键的步骤，它使得应用程序功能性的早期测试变成可能。如果该核心组件能够在开发周期的初期被完成，那么测试人员就能够开始为基本的规则集合撰写测试脚本并且确认该工具功能的有效性。
在我们的例子中，系统用例“运行代码复审”使得测试人员能够为该核心功能制定能够测试计划，甚至可以在代码被编写出来之间就实现这一点。测试人员还可以为主流程和可选项目创建一套手工测试脚本。
