有效的用例编写规则

　　第一章 什么是高质量的用例

　　1.1 为什么要使用用例

　　用例提供了一种用于构建故事的半形式框架;

　　在每个用例和所有描述层次中，用例都描述了错误情况的系统需求;

　　虽然本质上是一种功能分解技术，但用例已经成为面向对象软件开发的一个流行元素;

　　用例提供了可以在其上处理其他项目信息的骨架：

　　项目经理根据用例进行估计和发布进度;

　　数据及业务规则制定人员可以把自己的需求和所需用例联系起来;

　　用户界面设计人员可以进行设计，并将其与相关用例联系起来;

　　测试人员可以根据用例中描述的成功和失败情况构建测试场景(测试用例);

　　1.2 编写用例容易出现的问题

　　用户界面太多，用户界面应属于设计范畴，鼠标、按键等内容不应出现在用例中;

　　较低目标层次上的用例太多，无法展示系统将会给其最终用户提供什么功能;

　　使用用例表示非行为信息，性能需求、业务规则等不要在用例中描述;

　　太冗长，最好在3~9步;

　　目标实现不完整，尤其是错误处理;

　　句子片断，主、谓、宾尽量完整;

　　1.3 为什么使用用例模式语言

　　描述了用例的质量标志及其编写过程，提供了能够经受时间考验的用例改进建议;在评审用例初稿和改进其质量的过程中，这个工具能起到很大作用。

　　1.4 什么是模式

　　模式是质量标志和策略;

　　1.5 使用模式语言时错误观念

　　模式提供了一个关于其自身和模式内容的完整方法;只起补充作用

　　使用模式肯定会成功;

　　模式为老问题提供了新的解决方案;只是经常出现的问题的通用可靠方案

　　模式适用于所有情况;仅是处于某种上下文中的问题的解决方案

　　1.6 模式组织

　　1.7 用例的读者和编写者

　　有两组不同的认阅读和使用用例：(1)最终用户或业务专家;(2)程序员。

　　用例编写组必须包括：

　　至少一位具有编程背景的认，以获得描述所要求的准确性和精度;

　　至少一位熟知业务规则的认;

　　至少一位熟知在实际中如何使用系统的认;

　　第二章 团队

　　2.1 SmallWritingTeam

　　原因：

　　用例要求具有不同观点和专业知识的人编写;

　　将一大组人聚集在一起是困难的;

　　理论上，在用例上投入的人越多，就能越快的完成用例编写工作;

　　大的团队会变得低效;

　　大型编写团队可能会通过集体讨论的形式开发用例，添加许多不必要的特性;

　　所以：

　　一个由2人或3人组成的团队足够小，容易交流和达成一致;

　　可以使用几个SmallWritingTeam，但应当制定一位用例设计师，以保证所有用例与愿景一致。

　　最终目的是使过程保持在可管理状态，大的团队将在管理上投入更多的精力。

原文转自：http://www.uml.org.cn/Test/200705175.asp