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