《编写有效用例》读书笔记2
第二部分
讲的是经常讨论的主题。
第12章：什么时候才算完成
当满足如下要求时，才算完成任务：
已经命名了与系统相关的全部主执行者及其用户目标。
捕获了系统的全部触发条件，既包括用例触发条件，也包括扩展条件。
编写了所有用户目标用例及其必要的概要用例和子功能用例
每个用例描述足够清晰。
投资方确认用例集覆盖了他们所有用例表示的需求
第13章：扩展到多个用例
在对大量用例进行处理时，可以采用两种行之有效的技术：对每个用例简单说明，或者把用例分为多个簇。
现有四种常用且有效的分簇技术：
按执行者分类、按概要用例分类、按开发组和版本号分类、按主题域分类
第14章：CRUD和参数化用例
到目前为止，对如何组织创建一个实体，检索一个实体，更新一个实体以及删除一个实体这类用例，一直没有一致的意见。我们把这些基于数据库操作的小用例称为CRUD用例。
在提取系统用例时，偶尔会遇到这种情况：一些用例大致相同。对于这些用例，可能只由一个开发组建立一种通用搜索机制，而由其他人员进行调用。
第15章：业务过程建模
本书所讲内容既可用于软件系统设计，也可用于业务过程设计。对于任何系统，包括向外界用户提供服务同时保护其他用户利益的业务系统，用力都可以进行描述。
第16章：遗漏的需求
编写执行者的目的，是仅用别名来表达需要传递的数据细节。就如客户信息用名字和地址表示一样，这固然是一个好的建议。然而，对程序员来说，这没有提供软件开发所必须的详细信息。
用例只是需求文档的行为需求，它们不包括系统性能需求、业务规则、用户界面设计、数据描述、有限状态机行为、优先级以及其它相关信息。
利用“精度”级别对数据需求进行分类，同样有利于合理安排你的精力，通常把数据需求分为三个精度级别：
信息别名，域列表或数据描述，域的细节和域校验
第17章：用例在整个过程中的作用
用例为管理者指明应提交给用户的系统功能。用例的标题指明主执行者的需求，同时系统也必须支持这些需求，而用例描述则说明系统需要什么功能以及将提供什么服务。
第18章：用例概述和极端编程
第19章：错误改正
在编写用例时，最常见的错误是遗漏句子主语，假定用户借口及目标编写过于详细等。