《编写有效用例》读书笔记（一）

第一章：引言

      用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例描述了在不同的条件下，系统对某一项目相关人员的请求所作出的响应。根据执行者作出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列称之为一个场景，一个用例是多个不同场景的集合。用例能够在项目组中激发对项目系统的讨论。编写一个好的用例需要掌握范围，主执行者，层次三个概念。用例可用于描述一个业务工作过程；集中讨论未来系统的需求问题，而不是需求描述；作为系统的功能性需求；将系统设计结果文档化；应用广泛。编写准确的需求需要理解技巧，质量，标准三项。用例确实是需求，但不是所有的需求。用例作为行为需求只是需求的一部分。合理安排精力，不要在刚开始写用例的时候就深入到每个细节，否则就不能及时有效的在主题层面上考虑问题。 

 

第一部分：用例体部分

第二章：用例是规范行为的契约

      被讨论系统是在不同项目相关人员间制定契约的一种机制，用例构成了契约中的行为部分。首先从仅从捕获执行者之间的交互行为的角度来考察一个用例。第一部分成为执行者和目标概念模型，第二部分称为项目相关人员和利益概念模型。执行者具有目标，目标可能会失败，交互是复合的，用例聚集场景。执行者和目标模型解释了如何编写用例中的句子，但是没有涉及如何描述所讨论系统的内部行为方面的内容。所以执行者和目标模型需要基于“用例是具有利益的项目相关人员之间的契约”来进一步被扩展。

 

第三章：范围

      范围用来描述项目开发人员负责的设计工作的边界，以便与应由其他人负责的设计工作或已经完成的实际工作相区别。明确范围很困难，我们可以使用用来跟踪和管理范围讨论的“内/外”列表，可以控制普通会议的讨论范围，也可以控制项目的需求。功能范围是指系统要提供的服务，它最终应该被用例所捕获。在识别用例的同事也在决定项目的功能范围。可以使用“执行者-目标”列表和“用例简述”辅助。设计范围是开发人员负责设计和讨论的系统的集合，包括硬件系统和软件系统，它是集合的边界。

 

第四章：项目相关人员和执行者

     项目相关人员是指契约的参与者，是对用例的行为具有特定利益的人或物。执行者是指任何具有行为的事物，可以是人，公司或组织，程序或系统。执行者的范围有系统的项目相关人员，用例的主执行者，被设计系统本身，用例的辅助执行者，内部执行者-所讨论的系统内的构件。

 

第五章：三个命名的目标层次

     用户目标是主执行者努力使工作得以完成的目标，或是用户使用系统的目标，相当于业务过程工程中的“基本业务过程”。概要层次目标包含多个用户目标，在描述系统时可以显示用户目标运行的语境，相关目标的生命周期顺序和为低层用例提供一个目录表。子功能层析的目标是指那些在实现用户目标时可能会被用到的目标，只有迫不得已时才把它们包含进来以增强可读性。目标层次注意1，把较多的精力投入到对海平面的用例的考察上，他们是重要的用例。2，编写一些最外层用例来为其他用例提供语境。3，不要在“是否把系统需求规格说明语句中你最喜欢的那个搓洗用作用例的标题”上面小题大做。利用图表来突出目标层次。通过找出用户目标和对每个用例执行3到100步的原则来找出正确的目标层。

 

第六章：前置条件、触发事件和保证

     用例的前置条件声明了启动该用例之前系统必须满足的条件。通常前置条件是指该条件已经通过其他用例的执行进行了设置。触发事件指明了启动用例的事件。保证分为最小保证-系统向项目相关人员做出的最低承诺，尤其是在主执行者的目标不能被满足的情况下。成功保证-说明了用例成功结束后项目相关人员的哪些利益得到了满足，用例可以通过执行主场景获得成功，也可以通过执行可选路径获得成功，是最小保证的添加内容。

 

第七章：场景和步骤

     人们通常通过构件一个场景来描述和解释用例。如果一个场景中主执行者完成了目标，所有项目相关人员利益都被满足，就被称为是主成功场景。主成功场景和所有场景扩展都苦役包含在由一下元素组成的结构中：场景执行的条件，完成的目标，执行步骤集，结束条件，作为场景片段的可能的扩展集。每个场景或片段被描述为由不同的执行者完成目标的活动序列。执行步骤是对用例的补充，并且都有统一的语法形式。应该使用简单的语法，明确地写出用例和主执行者，从俯视的角度来编写用例，显示过程向前推移，显示执行者的意图而不是动作，包含“合理”的活动集，确认，可选择地提及时间限制，习惯用语和编号等。

 

第八章：扩展

     在编写主政工场景的基础上，进行扩展来对因为特别跳进而出现行为分支的每个地方，写出分支的条件以及处理分支的步骤。大多数扩展以重新与主成功场景汇合而结束。扩展的步骤是寻找扩展条件，集中讨论所有可能的失败和可选择的过程，使扩展列表合理化，逐层合并失败。最后在扩展中创建出新的用例。

 

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

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

 

第十章：连接用例

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

 

第十一章：用例格式

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

五种项目类型的标准：

1了解需求，甚至包括用例根本不在最后的需求文档中使用的情况

2业务过程建模

3设计和量化系统需求

4在一个短期、高强度的项目中编写功能需求

5在一个长期。大型项目中，在增量式开发时编写详细的功能需求。

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

 

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

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

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

 

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

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

 

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

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

 

第十五章：业务过程建模

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

 

第十六章：遗漏的需求

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

 

参考：https://www.cnblogs.com/15732115368zhm/p/5024520.html

　　    https://www.cnblogs.com/caojuansh/p/12768592.html