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

第一章   引言

ü         使用两个以上用例模板，一个类似于散文形式，以流水帐的方式记录使用场景；一个采用比较正规的用例模板方式，将用例按照stakeholders分别描述。

ü         在新领域中发现需求。通过描述现有系统（包括已经使用某些信息化系统或者还未曾使用某些信息系统），分析出系统现有的用例。把用例作为一种抛砖引玉的工具。问一个问题：“如果使用某些新技术，是否可以更好的达到目标？” 使用“深入浅出”的方法。

l             首先创建一个广义的高层模型，把想象中的系统描述出来，然后与先前的领域专家一起讨论这个系统。

l             接着，深入用例细节。考虑此用例的其它场景。在一个已经有骨架的用例上再进行修改就比较简单。

l             通过该用例再深入其它用例。

ü         把用例当成需求来编写。

l             用例确实是需求。

l             用例不是需求的全部，大概三分之一。用例不详细描述外部接口，数据格式，业务规则和复杂公式。

l             外部接口。也就是用户界面，采用c/s或者b/s，界面如何布局。

l             业务规则。一些能够用用例描述之外的规则，比如公文流转中，每一步处理步骤的处理策略。

l             复杂公式。比如实现2PC协议的软件，就需要对算法进行详细描述。

ü         用例作为项目的连接结构，是需求的中心。

ü         用例的增值点。

l             用例可以对系统的目标进行描述。将用例整理成一个列表，项目相关人员可以对项目的费用和复杂性进行初步估算。讨论系统功能开发优先级以及如何组织开发小组。

l             用例对异常情况的把握。

ü         用例编写的精确度。

l             执行者和目标

l             用例概述和主成功场景

l             失败情况。列举出所有可能的失败情况先，不要急于写处理方案。

l             失败情况处理。棘手，复杂，但是如果处理好，可以让系统更加清晰。

ü         在编写用例之前，可以采用一个叙述对用户使用的功能进行描述，是非正式的，以具体某个人为操作的。

 

 

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

ü         交互是复合的。在用例的交互描述中，某一步骤可以展开成另一个子用例，某个用例也可以折叠成上层用例的某一个步骤。

ü         用例聚集场景。

l             用例聚集了某个目标下，所有的场景，成功的，失败的。

l             有些场景描述成功的，有些描述失败的

l             每个场景是对一个条件集合和一个结果的直接描述

l             用例包含场景，场景执行步骤包含子用例

l             场景中的步骤不关心子用例里面的场景，只关心该用例是否成功

ü         项目相关人员和利益模型。列出所有项目相关人员和他们的利益，并用这个列表检查以确保用例中没有内容被遗漏。（没有实际经历，待体验）

 

第三章   范围

ü         功能范围

l             一个好的工具――“in/out list”。分成3列，一列放任意内容，一列“内”，一列“外”。内，表示系统内实现的；外，表示系统外实现的。采用讨论的方式，界定系统的边界。

l             工具二――执行者目标列表，actor-goal list。

执行者

任务级目标

优先级

触发事件（Opt）

业务优先级（Opt）

开发复杂度（Opt）

开发优先级（Opt）

 

l             工具三――用例简述，use case briefs.

执行者

目标

简述

 

 

ü         设计范围

l             设计范围的示例。业务用例――BS，分为黑色的BS（将整个企业作为一个整体）和白色的BS（讨论的企业内部部门和人员）；系统用例――SS，分为黑色SS和白色SS；构件用例――CS，对被设计系统的子系统或者构件的描述。