需求分析工具：用例（user case）

用例是捕获系统功能需求的技能。用例描述系统用户和系统本身的典型交互，这样就提供了系统如何被使用的说明。

用例的定义：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。对用例（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的原则
用例是短文。
用例可以是一个场景，包括动作和互交。
用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。
用例里不要有系统设计。
用例里不要有界面设计。
用例里不要有特性列表。
用例里不要有测试。
用例应该描述行为需求。
用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。
用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。

用户故事和用例的关系
用例和用户故事的概念非常相似。用例就像是用稍多一点细节描述的用户故事。一旦在当前迭代中要实现该用户故事，这种详尽细节就是合适的。
许多方法使用系统特性（极限编程把它们叫做用户故事）来帮助描述需求。一个常见的问题是特性如何与用例关联。
在计划一个迭代项目时，特性是堆砌系统的好办法，每一个迭代交付许多特性。用例提供执行者如何使用系统的叙述。因此，虽然两种技术都描述需求，但它们的目的不同。
虽然你可以直接描述特性，但许多人发现这样做很有帮助：先开发用例，然后生成特性列表。特性可能是整个用例、用例中的场景、用例中的步骤或一些行为谈何，例如为你的资产评估添加另一个折旧方法，这在用例叙述中展示不出来。通常，特性比用例有更细的粒度。