第十一章作为本书的第一部分的最后一个章节，提供了几种可供选择的用例格式。第一种是完整正式的用例格式，首先是单列文字，其次没有条件语句，最后便是扩展的部分的编号规则是数字和字母的组合。我个人在看了本书之后，比较喜欢这种格式，其原因一是从前看到后看习惯了，另一个原因就是扩展部分的编号规则更能让我接受。
在看了几个格式后，不禁好奇，怎么会有这么多种的模板来参照，如此不严谨的确不像是我们这类工程类的文档的要求，往后看才知道，原来影响用例书写格式的因素很多，从社会文化到理解层次到项目人员的相关要求到经验到覆盖面到复杂度均有影响。除此之外，在不同的需求分析阶段，对用例的要求也不尽相同，从需求了解用例模板，到业务过程建模用例到确定系统需求用例规模到短期高效的项目用例，这些因所处的时间段的不同也有所不同。
用例的格式的最终选择，可以用这么一句话来代替“因时制宜，看个人喜好”。
由第十二章进入新的部分，本书开始讨论一些经常讨论的主题。第二部分大多内容简单，不那么系统，而是针对一个小问题开始讲述的，因此，接下来，我就要踩西瓜皮喽！
看着王老师讲了快一个学期的软件需求分析，还感觉老师还没开始的我，看到第十二章的题目简直如遇知音啊！真的啊，“什么时候才算完成”，究竟需求分析的前期要做到什么时候，什么时候才能解决，才算完成工作？本书给我们了一个明确的定义：1)已经命名了与系统相关的全部执行者以及用户目标2）捕获了系统的全部触发条件3）编写了所有用户目标用例以及必要的概要用例和子功能用例4）每个用例的描述都足够清晰5）投资方确认用例集覆盖了他们的所有需求。其实，看完这五个要求，总觉得这些要求存而不存，一点都没有定量化的给出要求，太过概念，而无始发意义。
在之前编写老师所给的项目的用例时，就觉得，有的用例单写在一个里面觉得这个用例太过丰满，而单独挑出来写，又太多贫瘠，这里就讲到了一个有效的方法：“对每个用例进行简单说明，或者把用例分为多个簇”。说实话，这篇的内容并没有给出实例，具体的实施并不是像理论如此简单。
在软工的学习过程中，CRUD是一个经常说到的一个词汇，即增删查改，当然在基于数据库的操作的小用例称为CRUD用例。在这里的细节处理主要体现在可选数据流里分成了四五个部分分别对应了CRUD相关的操作。