例子：补充“预约汽车”用例
假设我们的系统是一个网站程序。当客户需要的时候，我们会为他们提供私人在线预约汽车服务。我们要为这个实现的具体情况来细化我们的用例，不过不要过多的涉及到设计阶段的工作。
这是预约汽车用例的更详细的描述，还是侧重于做什么，而不是侧重于怎么做：
用例：预约汽车(补充)
这个用例从顾客进入我们的预约汽车网站开始。
系统提示顾客输入希望的租借和归还汽车的时间、地点，顾客输入以上信息。 系统还提供给顾客一个选项，来选择汽车的种类，如微型汽车、SUV、标准汽车，等等。顾客可以限定在一个或多个种类中搜索汽车。默认值是搜索所有种类的汽车。如果顾客参加了我们的有奖租赁汽车活动，他可以在网页上一个单独的地方输入他的有奖活动的编号。如果他填写了这个编号，系统会访问顾客的档案， 来预先获取相关的信息。
如果顾客要继续进行预约，系统在下一个网页上，列出从数据库中找到的所有符合条件(时间地点)的汽车，提供每辆汽车的基本费率，根据顾客的租用历史情况还可以打一点折扣。如果顾客需要汽车的更详细的信息，系统从数据库中查找该信息，并将其显示给顾客。
如果顾客选定了一辆要预约的汽车，系统在一个新的网页中让顾客填写个人信息(姓名、电话、用于确认的电子邮件、信用卡发行商，等等)。如果系统中已经有该顾客的档案，则调出系统中的相应信息显示在页面上。有些信息是必填项，另外一些则是选填项(如电子邮件)。用户需要填写所有的必填项。系统还提供各种保护产品的信息(如汽车损伤保险、乘客险等)和单日的价格，并询问顾客是否购买，顾客做选择。
如果顾客表示“接受这个预约”，系统在网页上显示这次预约的概要信息(汽车型号、日期、时间、选用的保护产品及其费用、费用总额等等)，让顾客确认。如果顾客填写了电子邮件，系统会发送一封确认信到顾客的电子邮件地址。
当确认信息出现在顾客面前时，这个用例就结束了。
在这个经过补充的用例描述中，我们清晰的描述了一个基于浏览器的程序的行为，描述了很多对顾客来说不可见的行为。但是并没有提供设计级别的信息。
我们需要为每个用例提供类似的详细信息吗?
不需要。但是请记住，补充细节，并不是指实现的具体细节。我们的目标是为了能够有足够的信息来理解系统中的分析类，并与你的顾客或分析人员就所有用例的业务流程达成一致。 如果你觉得补充一些细节对于找出系统中的分析类有所帮助，那么就加上它。
注意：把握这个细节的尺度会比较困难。需要时间和一些练习。多上手练习，向别人多询问，还要记住当你无法决定的时候，应该稍微偏向抽象一点的描述。增加一些没有写上去的内容比较容易做到，但是要从很多杂乱的描述中找到有用的信息可就难的多了。
为什么还要先写出比较抽象的用例呢?为什么不直接把用例补充的比较详细?
这是因为抽象的用例是系统行为的最通用的描述(不过多的描述系统内部行为)。如果你还要开发一套客户端/服务器版本的预约汽车的用例会怎么样呢?如果你从详细的用例(基于浏览器的系统用例)，每次改变你的实现平台的时候，你都得重写整个用例。这个通用的描述与技术无关，特别是当你还没有、或是无法确定系统的具体环境的时候，它的价值就得到了体现。另外，通用描述用例能够让你的业务分析人员能够只看到系统如何工作的内容，而不是看到包含很多他们难以理解的技术细节的内容。
用例分析第三步：为用例行为找出分析类
文章来源于领测软件测试网 https://www.ltesting.net/
