这个学期的好几门课程都会用到UML用例图的相关知识，可见用例的重要性。用例图作为软件开发需求分析阶段的主要表现形式，有很多值得去学习和研究的内容。这本书通过对具体的一些用例的分析，介绍了一些编写有效用例的方法和技巧。这本书分为“用例体部分”、“经常讨论的主题”、“对忙于编写用例的人的提示”几个部分，单从名称来看便知这是具有丰富的软件开发经验的人对各种开发案例的总结归纳，可以从中学到很多细节性的知识。
首先， 用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约，描述了系统对某一项目相关人员的请求做出的响应。根据执行者的不同请求系统将执行不同的行为序列，每一个行为序列称为场景，用例正是多个不同场景的集合。根本来说，用例是以简单文本形式呈现的。根据记录对象的不同，被讨论的系统可以指组织本身或者计算机程序；读懂一个用例很简单，但要写出一个好的用力就会很难了。首先要明确三个概念：范围、主执行者、层次；老师上课时也一直强调必须先明确范围，因为它基本是作为顶层数据流图的，只有首先确定范围才可能继续后续工作，否则整个项目就会不断被扩张。
人们在大多数情况下没有时间去把用例写得正式、完整、漂亮，而只是尽可能将其写的充分，这就足够了。而且有时候用例要给非专业人员来看，他们会对系统有直接的操作或某种关联，所以要将用例做得更加通俗易懂。用例是用来讨论未来系统的需求问题，而不是需求描述，作为系统的功能性需求，它会将系统设计文档化。根据不同的情况和场景，用例编写可能会很规范，也可能会比较随意。用例确实是需求但也不是所有的需求，因为它只是所有需求文档中的一部分。人们只要写出一段用例，就能通过少量的编写节省大量的时间，还要坚持作错误处理。
“执行者和目标”和“项目相关人员和利益”是考虑执行者之间交互行为的两个部分。有的执行者是具有目标的，当一个请求产生时，可能会需要一个辅助执行者来帮助完成与系统之间的交互。而当目标失败时，系统也需要具备修复的能力。交互过程是一个十分复杂的过程，现实生活中它绝对不会始终按照一个特定的序列运行，所以用例需要考虑各方面因素，使用例尽可能地完整。一个项目必然会有很多利益相关者，而一些重要的利益相关者因为与系统运作联系不甚紧密，开发人员往往会容易把他们忽略，所以要尽可能考虑到所有利益相关者，避免犯严重的错误。
系统用例“范围”的确定是十分关键的一环，也是很不容易把握的。其中，功能范围是指系统要提供的服务，设计范围和功能范围的确定需要考虑项目相关人员和执行者的相关业务以及他们同系统之间的交互。用例开始执行通常是主执行者触发的，辅助执行者是为了将系统与外部接口相连。三个目标层次的定义更加方便了对于目标功能和作用的界定，用户目标是用户使用系统目标，相当于基本业务过程；概要层次包含多个用户目标，它可以显示用户目标的运行语境，显示相关目标的生命周期顺序，并为最底层用例提供一个人目录表；子功能层次的目标是指那些在实现用户目标时可能会用到的目标。可以用图标来突出目标层次，使整个用例更加清晰明了。
用例的前置条件声明了启动该用例之前系统必须满足的条件，一个典型的例子就是“用户登录并通过了身份验证”，说明通过身份验证之后用户才可以进入系统进行相关操作，而系统也不会再对用户身份进行检查。最小保证是系统向项目相关人员做出的最低承诺，比方说只有收到付款之后才可以启动订单。另外，为失败的事务处理做日志并不是一个显而易见的需求而是至关重要的，对于失败的记录可以解决许多纷争，由中可见，用例的编写时日志记录以及错误处理的重要性。成功保证说明了用例成功结束之后项目相关人员的哪些利益得到了满足，这通常是最小保证的添加内容。触发事件则是指启动用例的事件，例如使用ATM机的触发事件就是插入银行卡。