编写了那么多的用例，那用例到底是干嘛的？用例为管理者指明应提交给用户的系统功能。用例的标题指明主执行者的需求，同时系统也必须支持这些需求，而用例描述则说明了系统需要什么功能以及将提供什么服务。
在一开始接触用例的时候，UML课程中提及过用例的优先级以及用例版本号等其他细节，对于这些信息的汇总可以称为规划表，而规划表在项目开发过程中，可以非常容易的对这张表进行审核和操作。另外，可以对每个用例进行评估，指定用例开发组，以及对每个用例，每个版本的工作进行跟踪。
在编写用例的过程中，出错是非常正常的，而发现错误和会改正错误的这一步时非常正常的。那么，哪里会经常出问题？怎么修改？这是一个很重要的环节，十九章就给出了当用例缺少系统、主执行者、过多的用户接口、过低的目标级别等问题出现的时候，相对应的解决办法。
虽然本书第二部分内容不多章节也少，但是都对编写用例经常会遇到的问题，提供了相应的解决办法和理论依据。由于大多例子都是依附于案例的，全都搬到笔记里并不适合，因此，只留下了一些理论的依据和缘由，并未展开详细讲解。
由此，很快的进入了本书的第三部分“对忙于编写用例的人的提示”。看到标题应该就可以猜到这部分是给“光干活不注意细节的人”的人看的。哈哈，比如我。上次写一分课后作业，写了好半天，回头一翻，竟然还写错内容了!真真是白白忙活。编写用例也是一样的，与其花很多时间捉摸研究，不如，先跳出来好好看看，看看自己可能会遇到的问题，再进入其中研究相关问题。
在一开始学用例的时候，我们第一个接触的便是用例图，后面才是使用的语言描述，我们总觉得，学工科的东西，表述的越简单越好，但是，用例却应该是一篇散文，易于阅读，但是又要富有美感。那么多人在学习，肯定不是所有的人都喜欢阅读的，所以，让别人能够看得下去，第一个点就是让问题短小而切题，并且从头开始，用一条主线贯穿始终。跟写作文一样，用例是是要起因经过结果的，并且遵循主旨。而且，为了让问题短小精悍，就要使用动词短语来命名用例，然后从触发事件开始，至到目标实现或者被取消，用例才可能结束。其余的相关的细节过多，就不一一阐述了，但是，不说不代表重要，所有的细节都是重点。顶层的散文故事，只是一部分，而后续需要不断展开的故事，就像写故事背景一般，故事的开始不仅仅是一个开始，还是一个又一个的故事。而且写故事的时候不能跑题，一定要记得自己原有的业务范围和业务边界，尽管这个边界某种程度上来说十分的模糊，但是却又不得不去区分。