编写有校用例——阅读笔记2

第九章：技术和数据的变化

扩展说明了系统所完成的目标是不同的，但有时需要表达“有多种不同的方法来完成相同目标”。系统所完成的目标是相同的，但怎样做可能不同，通常是因为技术的变化或输入数据的不同，应该将这些变化写到“技术和数据变化”列表中，而不是写到扩展部分中。

 

第十章：连接用例

扩展用例是指可能在两个用例之间需要另外一种连接，这种连接很像扩展机制。扩展用例从一个条件开始，在基用例中该条件可能满足的地方呗引用。应将所有的条件都放到模板的触发事件部分中。扩展用例的使用情况有两种：一是当有很多的用户可能使用的异步服务或中断服务的时候，并且这些服务不应该影响基用例。一是为一个已经锁定的需求文档编写附加文档的时候。

 

第十一章：用例格式

单列文字；步骤编号；没有条件语句；扩展部分的编号规则是数字和字母的结合。

五种项目类型的标准：1了解需求，甚至包括用例根本不在最后的需求文档中使用的情况2业务过程建模3设计和量化系统需求4在一个短期、高强度的项目中编写功能需求5在一个长期。大型项目中，在增量式开发时编写详细的功能需求。

用例格式有多种，但是主要目的和内容不变。具体格式可以根据项目开发需要来选用。

 

第二部分：经常讨论的主题

 

第十二章：什么时候才算完成

当满足1已经命名了与系统相关的全部主执行者及其用户目标。2捕获了系统的全部触发事件，既包括用例触发事件也包括扩展条件。3编写了所有用户目标用例以及必要的概要用例和子功能用例。4每个用例描述足够清晰。5投资方确认用例集覆盖了他们所有的需求。

 

第十三章：扩展到多个用例

简单描述每个用例，也就是说给每个用例单独命名是很重要的，特别是为评估。规划和跟踪提供了便利。还有就是每个用例的简介。创建用例簇，按执行者，概要用例，开发组和版本号，主题域等分类。

 

第十四章：CRUD和参数化用例

CRUD是指基于数据库操作的小用例。它们是独立的，但是它们打乱了整个用例集，使需要跟踪的用例成倍增加。参数化用例是针对相似用例建立的一种通用搜索机制，由其他人进行调用。步骤有1用户指定待搜索对象2系统搜索、产生可能匹配的对象列表3用户选择或重新排序结果列表或重新搜索4系统找到或没有找到的对象。

 

第十五章：业务过程建模

仔细识别组织中的核心业务应弄清楚1，在组织行为中的项目相关人员2该组织必须满足其需求的外部主执行者3该组织必须响应的触发事件4该组织提供的服务以及对项目相关人员的成功结果。业务过程设计可以采用业务黑盒进行描述。在建模过程中，保持系统核心目的不变，但可以根据实际需要重新定义适合新技术的业务过程进行技术革新和响应边界条件的更改。连接业务用例和系统用例。

 

第十六章：遗漏的需求

利用“精度”级别对数据需求进行分类，如信息别名，域列表或数据描述，域的细节和域校检。从用例到其他需求的交叉链接的过程中寻找遗漏的需求。