粗略浏览整本书，我对它第一印象并不是很好，不然也不会迟迟未看下去。然而，耐着性子学习，却发现我们所学习的软件工程的相关课程，万变不离其宗，整个系统是一致的。换句话说，一个系统做下来，并不是单单一门课就可以解决的事，其间蕴含了所有学习的或还未学习的内容。
用例这个概念曾在学习UML中有提及，当时用例的概念仅仅止步于“用客户或用户的语言和词汇来描述的系统的一个完整功能”。紧接着，学习的重点便是用例图和其他图的绘制。在UML中强调的是使用图绘的方式来描述用例之间的“关联关系”、“泛化关系”、“包含关系”、扩展关系”等。而此教材是一方面是从文字和图符来教我们如何写用例，另一方面教我们如何写一份具有可读性的用例。同样的，软件需求分析课程和这个也差不多，侧重点不同，却说的是同样的内容，
从第一章阅读至第三章内容，主要是从什么是用例，用例的用处，用例的意义和相关边界范围几个角度来介绍的。
于我而言，我一般都不太关系具体的概念知识，比起那些冗杂难懂的定义，我更倾向于了解这个东西究竟是干什么的、有什么用。
用例详细的描述了系统被使用时的行为细节，使得用户明白新系统到底是怎么样的。举个例子来说：(非正式版本)请求者发起请求，并把这个请求从给他的批准者。然后批准者首先检查预算中是否还有资金，然后核实货物的价格，接着完成提交请求，并将请求发送给买者……这一系列的活动，至到最后请求者得到相应的响应。这个完整的过程就可以称之为一个用例。
同时，用例描述了整个系统，并被冠以系统之名，并被整理成一个列表。这个列表申明了这个系统可以做什么，系统的范围是什么，创建系统的目的是什么。其次，用例某种程度上十分详尽的描述了异常情况的处理过程，让开发人员发现需求方或自己之前并没有考虑到的种种意外情况。对于这些意外情况的提前发现，能让程序员在编写代码以前就想好相应的解决方案，这时，咨询业务专家就是十分及时的，否则，程序员会十分想当然的编写代码，而不努力寻求更理想的解决办法。
用例这个东西，听起来很简单，但是真正写起来却很困难，不考虑写的是否有效，不考虑写的怎么样，就光考虑所有的情况有时就能逼疯我们这些初学者，这时候就需要一个系统使用叙述来热身并且需要合理安排自己的精力来做这些事。
范围这个概念在其他课程上，被听到的更多是“边界”、“系统边界”这些术语。概念上来说，范围一词来描述项目开发人员负责的设计工作的边界，以便于应由其他人负责的设计工作或已经完成的设计工作相区别。此处从功能范围、设计范围、最外层用例几个方面来讲述什么是范围，范围究竟是怎么样的。通过一些举例来告诉我们哪些是在范围内的，哪些属于临界点的，哪些不是范围内的。说实话，看着书上的例子我还能辨别什么事范围内的，但是一脱离课本，看一个新的系统，我还不确定自己所想是否正确，并且不会同比较通俗的语句来讲述，这个部分，暂且留着，以后再解决。