第五章 用例
5.1 CompelteSingleGole
不适当的目标，会使编写人员不能确定什么时候一个用例结束，什么时候另一个用例开始。
原因：
太大的用例可能会因细节过多占去涉众的大部分精力；
大的用例限制重用；
过小的用例仅能描述某些价值实现的一部分；
所以：
编写每个用例，用来描述一个完整而且定义良好的目标。
初速目标的特性为：
? 它与一个定义良好的参与者相关；
? 它对参与者或参与者代表的涉众是有价值的；
? 它与在这一级别上为系统确定的其他目标一致；
? 避免与具体的借口细节联系到一起，而编写出完成目标片断的用例；
5.2 VerbPhraseName
没有意义的普通名称不会使读者有什么期望，也不会提供一个方便的参考点。
原因：
名称为读者确定了基调和关联，并能够为编写人员提供一个焦点；
适当的用例名称能够使读者看到大的概貌，并且对整个用例集有效；
所以：
用一个代表主参与者目标的主动动词短语来命名用例。
5.3 ScenarioPlusFragments（主场景+分支片断）
读者必须能够非常轻松的阅读具体的场景或他们感兴趣的故事；否则，他们可能会变的沮丧，或遗漏重要的信息。
原因:
一个有趣的用例需要捕获主成功场景的分支；
将每个分支编写为一个完整的故事将会模糊故事变体之间的差别；
将每个变体分离出来也会使编写人员的工作变得非常困难；
需要清晰的确定主成功场景；
所以：
将成功的故事情节编写为简单场景，不考虑任何可能的失败。在该场景下面，放上展示会发生什么情况的故事片断。
5.4 ExhaustiveAlternatives
用例可以有很多分支，遗漏一些分支意味着开发人员会误解系统的行为，这样的系统是不完善的。
原因：
开发人员需要知道如何处理错误；
进度压力限制了开发人员可以识别各种变化的时间；
拥有关于变化的信息有助于开发人员构建一个健壮的设计；
所以：
必须捕获在用例中处理的所有分支和失败情况。
5.5 Adornments
在用例中包含非功能需求很难快就会将用例搞乱并模糊用例。
原因：
用例的目的是清晰的表达系统的功能需求；
不应该遗漏有助于理解用例或对开发人员来说有价值的信息；
所以：
在用例模板的场景文本之外创建额外的区域，来容纳对关联用例有用的补充信息；
用例和其他补充需求紧紧相扣，例如：性能需求、用户界面说明、约束条件、业务规则、数据字典等。
5.6 PreciseAndReadable
对非技术性读者来说太复杂，或对开发人员来说太不精确的用例是不完善的，很可能或导致构建不良且不适当的系统。
原因：
对涉众和开发人员来说，用例应该是可读的；
开发人员有一种添加细节和解决方案的倾向；
非技术性涉众可能会遗漏一些必要的考虑；
为客户和开发人员提供不同的需求文档集合是很糟糕的；
所以：
用例需要足够可读，以便使涉众可以阅读和作出评估；
用例需要足够精确，以便开发人员可以理解他们正在构建的系统。