1、用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应。
从文字上看，比较难理解，举个比较经典的例子：某人在ATM机提款，这个本身就可以看作一个用例，只是它的层次比较高，细分下 去，人可以在ATM上做什么？粗略一想，就有几条：(1)查询余额(2)提款(3)转帐(4)存款，这四点都可以独立成为一个用例，而且执行者都是人，简 单来说，用例就是描述执行者和系统之间的交互的集合。
2、从根本上说，用例是文本形式；他们是作为人与人之间，尤其是没有受过专门培训的人员之间互相交流的一种手段。因此，简单的文本通常是编写用例的首选形式。
很多人一看到“用例”这两个字就和用例图联系在一起，就是一个小人，一个椭圆，中间有线连接那种图，其实用例图只是用例的图形化表示，用例真正的内容体现在它的文本描述中，而且描述的语言和平时人们日常写作的语言一样，一般有初中文化的人都看的懂。
3、编写用例必须掌握的三个概念：
(1) 范围(scope)：真正被讨论的系统是什么？
(2) 主执行者(primary actor)：谁有要实现的目标？
(3) 层次(level)：目标的层次是高还是低？
范围很重要，这个和项目管理里面的项目范围概念差不多，不过可能它的粒度小一点，有个可能一个用例只是一个项目的一小块功能交 互，只有明确好范围，才能真正把握需求，但这个还需开发方与客户不断的沟通才能确定。主执行者与项目管理的项目干系人有些联系，很多用例主执行者就是项目 干系人中的一员。
4、只有一个用例模板是不够的。至少要有两个用例模板：一个是非正式的（或称随意的），在要求不严的项目中使用；另一个是完整正式的，在要求严格的项目中使用。
无论正式还是非正式，只要能使客户和开发人员能建立有效的沟通途径，就是好用例，只是有时候一些项目要求比较严格，文档写的也比较正式而已。
5、如果把用例作为需求来编写，请谨记以下两点：
(1) 用例确实是需求。不必将用例转变成行为需求的其他形式。
(2) 用例不是所有的需求。用例不详细地描述外部接口、数据格式、业务规则和复杂公式。
需求包含用例，用例属于需求的一部分，这恰恰反应了：“用例不是万能的....”，下一句想必不用说都知道了吧，呵呵。
6、用例仅仅是行为需求，并且是所有的行为需求。
注意后半句
小结：这一章主要是为用例定位，以及怎么样在不同的环境和时间安排下编写用例，使其达到最好的效果。