用例的目的

用例之所以被广泛采用的主要原因是，用例详细地描述了系统被使用时的行为细节，使得用户能够明白新系统到底是什么样的。

增值作用：1.对系统目标的描述，并被收集整理成一个列表。这个列表声明了系统可以做什么，揭示了系统的范围以及创建系统的目的。它成为项目相关人员之间互相交流的一个工具。

2.对异常情况处理的描述。此时用例编写者集中讨论主成功场景中可能发生的所有异常情况，并组织成一个列表，同时开始记录系统相应的应对措施。通过该表，开发小组能够发现一些开发人员自己工需求提供方以前没有考虑到的意外情况。

在编写错误处理文档时，经常能够发现新的项目相关人员、系统、目标和业务规则。而当我们考虑异常情况处理方法时，总是要和业务专家聚在一起，或通过电话来商量以决定系统在此种情况下该如何运作。

  如果没有这此离散的用例步骤和对失败情况所作的集中讨论，那么许多错误情况就不能在程序员编写代码段之前被发现。如果错误在程序员编写代码时才被发现，这对于发现新的功能和业务规则来说就太晚了。那里，业务专家通常已经走了，时间也已经十分紧迫，因此，程序员就只能想当然地按自己的想法编写代码，而不再去努力寻求更理想的解决办法。

  人们只写出一段用例，就能通过少量的编写而节省大量的时间，并从用例中获得好处。人们只要坚持作错误处理，就能通过早期发现那些难以捉摸的需求而节省大量的时间。

  根据所需精力的多少和每个阶段后的停顿，我们将编写用例所需的的工作时划分为四个精确度等级：

1）执行者和目标：列出系统所支持的执行者及其目标。审查这个列表的正确性和完整性。划分目标的优先级，并将其分配到各个小组和不同的发布版本中。至此，可获得具有初级精确度的功能需求。

2）用例概述和主成功场景：对于所选出的需要进一步细化的用例，勾画出其主成功场景。审查这些草图以确保系统能够真正表过我们所关心的项目相关人员的利益。这达到了功能需求的二级精确度。与下面两级不同，这些内容是相当容易被勾画出来的。

3）失败情况：完成主成功场景，并集中讨论所有可能发生的失败情况。在想出系统如何处理这些失败情况的办法之前，首先拟定一个完整的失败情况列表。设想出系统处理失败情况的方案要比仅仅列出这些失败情况需要更多的精力。如果一个开始就立即着手写失败情况处理方案，则常常会在列出所有的失败情况之前就耗尽了所有的精力。

4）失败情况处理。写出系统应该如何对这些失败情况作出反应。这经常是棘手的、累人的工作，但同时也是令人惊喜的工作。说它令人惊喜是因为多数情况下，在编写失败情况处理方案的过程中，对于一个模糊的业务规则的疑问会得到澄清，或者一个失败处理会突然展示出系统需要支持的新执行者和新目标。

  多数项目都时间紧迫、精力有限。因此，合理安排用例编写精确度应该是一个项目优先考虑的事情。极力建议大家按上述顺序进行工作。

  用例编写者的工作就是把故事编写得情节连贯、条理清楚，以使读者可以很舒适地在故事情节中切换、穿梭。