第一章 引言
1、用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应。
举个例子：某人在ATM机提款，这个本身就可以看作一个用例，只是它的层次比较高，细分下去，人可以在ATM上做什么？粗略一想，就有几条：
(1)查询余额(2)提款(3)转帐(4)存款，
这四点都可以独立成为一个用例，而且执行者都是人，简单来说，用例就是描述执行者和系统之间的交互的集合。
2、从根本上说，用例是文本形式；他们是作为人与人之间，尤其是没有受过专门培训的人员之间互相交流的一种手段。因此，简单的文本通常是编写用例的首选形式。
“用例”这两个字就和用例图联系在一起，就是一个小人，一个椭圆，中间有线连接那种图，其实用例图只是用例的图形化表示，用例真正的内容体现在它的文本描述中，而且描述的语言和平时人们日常写作的语言一样。
3、编写用例必须掌握的三个概念：
(1) 范围(scope)：真正被讨论的系统是什么？
(2) 主执行者(primary actor)：谁有要实现的目标？
(3) 层次(level)：目标的层次是高还是低？
范围很重要，有个可能一个用例只是一个项目的一小块功能交互，只有明确好范围，才能真正把握需求，但这个还需开发方与客户不断的沟通才能确定。主执行者与项目管理的项目干系人有些联系，很多用例主执行者就是项目干系人中的一员。
4、只有一个用例模板是不够的。至少要有两个用例模板：一个是非正式的（或称随意的），在要求不严的项目中使用；另一个是完整正式的，在要求严格的项目中使用。
无论正式还是非正式，只要能使客户和开发人员能建立有效的沟通途径，就是好用例，只是有时候一些项目要求比较严格，文档写的也比较正式而已。
5、如果把用例作为需求来编写，请谨记以下两点：
(1) 用例确实是需求。不必将用例转变成行为需求的其他形式。
(2) 用例不是所有的需求。用例不详细地描述外部接口、数据格式、业务规则和复杂公式。
需求包含用例，用例属于需求的一部分，这恰恰反应了：“用例不是万能的....”，
6、用例仅仅是行为需求，并且是所有的行为需求。
总结：第一章主要是为用例定位，以及怎么样在不同的环境和时间安排下编写用例，使其达到最好的效果。
第二章 用例是规范行为的契约
这一章主要说明的问题：“具有目标的执行者之间的交互”和“具有利益的项目相关人员之间的契约”
1、首先，仅从捕获(具有某种目标的)执行者之间的交互行为的角度来考察一个用例，然后可以进一步扩充讨论的内容，直到用例能被用作项目相关人员间协调各自利益的契约。
这里说明了一个很重要的问题，就是获取用例是有过程的，第一步就是根据执行者的目标来捕获需求，然后第二步才是关心具体交互所牵涉到的利益。
2、为了实现其职责，系统制定出一些子目标。系统可以内部实现一些子目标，但其他子目标需要借助‘辅助执行者’（supporting actor）来实现。这些辅助执行者可以是打印子系统，也可以是其他组织，如合作单位或政府代理等。
用例的执行者并不都是人
3、执行者可以是单个人员、组织或者计算机。执行者和目标概念模型可以用来描述由人、公司和计算机组成的混合系统；也可以用来描述一个软件系统。
4、强调目标失败和失败反应是用例通常能够进行良好的系统行为描述和出色的功能需求描述的原因之一。
5、活动序列很适合于描述发生在过去的交互过程，因为“过去”是已经完全确定的。要描述发生在将来的交互过程，需要有一个所有可能出现的活动序列组合的集合。
6、用例包含了到达一个目标可能出现的所有场景的集合，为了更加完善，需要加入一下内容：
(1)与同一个主执行者的同一个目标有关的所有交互过程。
(2)用例由触发事件启动后开始执行，直到目标被实现或者被取消而结束，系统通过本次交互完成它的职责。
7、用例，做为规范行为的契约，捕获了与满足项目相关人员利益相关的所有行为，并且仅限于此。
为了满足项目相关人员的利益，需要描述三种行为：
（1）两个执行者之间的交互（为了促进一个目标），交互过程中可能会有信息的往返传递
（2）确认（为了维护某一项目相关人员的利益所进行的确认）
（3）内部状态变化（代表项目相关人员）
这个现在我还是不太明白，可能要看第四章才会有更深的体会
8、列出所有的项目相关人员和他们的利益，并用这个列表仔细的检查以确保用例体中没有任何内容被遗漏。然而，这个微小的改动却能对用例的质量产生重大的影响。