用例是捕获系统功能需求的技能。用例描述系统用户和系统本身的典型交互,这样提供了系统如何被使用的说明。
  用例的定义:在不展现一个系统或子系统内部结构的情况下,对系统或子系统的某个连贯的功能单元的定义和描述。对用例(use case)是通过共同用户目标绑定在一起的场景集合。场景(scenario)是描述用户和系统之间交互的序列。
  用例的格式:UML中用例的定义相当简略,UML里没有描述你应用如何捕获用例的内容。UML所描述的是用例图,展示用例之间的相互关系。但几乎用例所有的价值都在于它的内容,图的价值相当有限。
  书写用例的内容没有标准的方式,不同的格式适用于不同的情况。图9.1展示了常用的风格,一开始,你挑选场景之一作为主成功场景(main success scenario)。接着,你开始书写用例体,把主成功场景书写为编号的步骤序列,然后,你再书写其他场景作为扩展(extension),描述主成功场景上的变化,扩展可以继续扩展——直到用户达到目标,如3a——或失败,如6a。
  每个用例有一个主执行者,它调用系统来将会一个服务。主执行者是带有目标的执行者,且例会尝试满足它的目标。主执行者通常是(但不总是)用例的引发者。执行用例时,还有其他执行者和系统通信,这些称为辅助执行者。
  用例文本实例
  购买产品
  目标级别:海平面级
  主成功场景:

  1.顾客浏览目录并添加想要的条目
  2.顾客结账
  3.顾客填写送货信息(地址,第二天或第三天发货)
  4.系统提出包括送货在内的全部价格信息
  5.客户填写信用卡信息
  6.系统立即确认销售
  8.系统向顾客发确认电子邮件
  扩展:
  3a:顾客是固定顾客客
  1.系统显示当前的送货信息、价格信息以及票据信息
  2.用户可以接受或取消这些默认,返回到MSS的第6步
  6a:系统不准许信用卡购物
  1.客户可以输入信用卡信息或取消
  用例中的每个步骤是执行者和系统之间的交互元素。每个步骤应该是一个简单的陈述,清晰地展示谁执行该步骤。步骤应该展示执行者的意图,而不是执行者如何做的具体细节。因此,你不用在用例中描述用户界面。事实上,通常在设计用户界面之前书写用例。
  创建USE CASE的原则
  用例是短文。
  用例可以是一个场景,包括动作和互交。
  用例可以是一组场景,描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为,例如黑盒需求,业务流程,系统设计说明。
  用例里不要有系统设计。
  用例里不要有界面设计。
  用例里不要有特性列表。
  用例里不要有测试。
  用例应该描述行为需求。
  用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。
  用例的大价值不在于主场景,而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。
  用户故事和用例的关系
  用例和用户故事的概念非常相似。用例像是用稍多一点细节描述的用户故事。一旦在当前迭代中要实现该用户故事,这种详尽细节是合适的。
  许多方法使用系统特性(极限编程把它们叫做用户故事)来帮助描述需求。一个常见的问题是特性如何与用例关联。
  在计划一个迭代项目时,特性是堆砌系统的好办法,每一个迭代交付许多特性。用例提供执行者如何使用系统的叙述。因此,虽然两种技术都描述需求,但它们的目的不同。
  虽然你可以直接描述特性,但许多人发现这样做很有帮助:先开发用例,然后生成特性列表。特性可能是整个用例、用例中的场景、用例中的步骤或一些行为谈何,例如为你的资产评估添加另一个折旧方法,这在用例叙述中展示不出来。通常,特性比用例有更细的粒度。