最初接触到“用例”这个概念的时候是在《统一建模语言UML》课上，当时对这些概念很是不以为然，导致在学习过程中学的一塌糊涂。然而最终还是应了那句老话：“出来混，总是要还的”。在软件需求分析和软件设计模式等课程上我们再一次遇到了这些概念，所以也让我理解了一个事情，就是软件工程是名副其实的一个工程性专业，而不是跟着工科大部队仿着其他工科专业一样在自己名字后面强加“工程”两个字。为什么要说这是一个名副其实的工程性专业呢？想要完成一个软件，从需求分析到实际开发再到最后的运行维护，无论这个软件项目是大还是小，都要经过这样一个像工业流水线一样的流程。而在这个流程中，需要用到我们学过或正在学习的所有课程内容，比如软件需求分析，比如统一建模语言。所以这也让我重新审视自己，有没有对哪门课有过轻视的态度，让我理解软件工程专业课程体系的设置是很有深度的。想到建民哥在一次课上提到的一个设想，就是在一个大型项目上安排所有的教学课程，在开发项目的过程中让所有课程都以这一个项目来实施教学，这样能让学生对工程的概念体会的更加到位，也能让学生认识到所有课程的实际用途。这个设想是很有实践价值的，奈何以现在的教育体制和教学模式，这个设想暂时无法实践，那我们也只能是坚守自己的本心，以端正的态度去面对每一节软件工程专业课。
最近在阅读《编写有效用例》，以此作为软件需求分析课外阅读资料，所以有机会重新面对“用例”这个概念。在阅读了前三章之后突然意识到之前对“用例”这个概念的理解太狭隘了。从高层次的角度上来看，用例实际上就是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用更具体的语言来解释用例，就是用例描述了在不同的条件下，系统对某一项目相关人员的请求所做出的响应。从表现形式上来看，用例可以用流程图程序设计语言或者UML图来表示，但是理解了用例的本质之后，其实文本形式也可以作为对用例的描述，甚至可以说文本形式就是用例最根本的表达。用例不仅可以来记录需求分析，也能够作为项目组内相互讨论的范本，还可以用于记录最终的设计成果。
软件开发在软件工程中占有很大的比重，但是软件工程的最终落脚点还是在与人的交流上，因为软件是为人服务的。那么用例的编写也是一样，不管采用哪一种表现形式，最终的目的是要实现更高效的交流。作为一名软件工程专业的学生，学会编写一个好的用例是非常重要的。首先要做的就是理解用例中的三大概念元素：范围、主执行者和层次。范围是说真正被讨论的系统是什么，软件需求课程上老师一直在强调系统的边界，说的也是这个概念。主执行者是说谁有要实现的目标？也就是说系统中的某个功能是为谁服务的。最后是层次，一个系统在目标上需要有高低不同的层次。
其实说了这么多，用例和需求有着千丝万缕的关系，理解了用例，也就理解了需求。所以这也激发起我对这本书的阅读兴趣，让我决定要继续认真的把这本书阅读完，并做好阅读笔记。以上就是我在阅读了《编写有效用例》前几章的大致收获了。