编写有效用例-笔记
用例由触发事件启动后开始执行，直到目标被实现或被取消而结束。
主执行者有一个目标，系统应该帮助主执行者实现这个目标。一些场景描述了目标被实现的情况；而另一些场景以目标被取消为结束。
每一个场景都包含一系列的执行步骤，以表明动作和交互过程是如何被一步步展开的。
用例把所有的场景聚焦到一起，显示了一个目标获得成功或遭遇失败的所有可能的途径。
原则：
一些场景成功结束；一些场景则以失败告终
用例将所有场景聚集到一起，无论是成功的场景还是失败的场景
每一个场景是对一个条件集合和一个结果的直接描述
用例包含场景，场景中的执行步骤中又会包含子用例
场景中 步骤不关心子用例具体用到了什么，而只关心子用例最终是成功还是失败。
项目相关人员和利益 概念模型，模型中“项目相关人员和利益”部分指明了哪些内容需要被包括在用例之中，哪些内容不需要。
主执行者通用是在场的，也不是总在场。其他项目相关人员不在场 称为 幕后执行者，系统执行动作来满足这些幕后执行都 利益，包括收集信息、执行确认检查以及更新日志等
要认真完成一个用例，有必要列出所有的项目相关人员，然后根据用例中的操作命名他们的利益，声明如果用例成功完成将对每一个项目相关人员意味着什么以及靠什么来保证他们能从系统中得到他们所希望得到的利益。把这些摘清楚之后，就可以开始编写用例中的执行步骤，确保从用例被触发开始直到结束期间所有这些不同的利益都能得到满足。如此，就能知道编写用例时从哪里开始到哪里结束，以及用例中应包含什么，不应包含什么。
为了满足项目相关人员的利益，需要描述三种行为：
1 两个执行者之间的交互 --为了促进一个目标
2 确认--为了保护项目相关人员
3 内部状态变化--代表项目相关人员
列出所有的项目相关人员和他们的利益，并用这个一表进行仔细的检查以确保用例中没有任何内容被遗漏
图形模型
用例描述了具有利益项目相关人员之间行为的契约。我们按照被选中的项目相着人员的操作目标来对期行为进行组织。这里“被选中的项目相关人员”是指那些想要系统帮他们做些事情的人，我们称其为 主执行者。用例名是主执行者的目标，它包含描写契约中相应部分所需的所有行为。
系统有责任通过执行一系列动作来满足意见一致的项目相关人员的一致利益。系统要执行的动作是下面三类之一：
1 两个执行都之间的交互，交互过程中可能会有信息的往返传递。
2 为了维护某一项目相关人员的利益所进行的确认。
3 一次内部状态变化，也是为了维护或增进某一项目相关人员的某一利益。
场景由执行步骤组成。在成功场景中，项目相关人员的民有一致利益都通过系统有责任实现的服务而得到满足。在失败场景中，那些利益都根据系统的承诺而得到保护。当项目相关人员的所有利益都得到满足呀得到保护时，场景就结束了。
项目相关人员具有利益。执行都具有行为。主执行都也是项目相关人员。
面向目标的行为由职责、目标、动作组成
私有动作是指那些增进或保护了项目相关人员利益的行为。
交互将执行者间的动作连接起来。
范围：描述项目开发人员负责的设计工作 边界
内、外列有： 三列：主题、 内、外 标识
执行者-目标 列表:列举了系统支持的所有用户目标，展示了系统功能方面的内容。只包括系统真正支持的服务。：执行者、任务目标、优先级、触发事件。他的重点在项目 规划和内容上。
执行者-目标列表在描述系统行为方面精确度是最低的，但它对从整体上把握系统很有帮助。
用例简述：是对用例行为所作的一个包含2-6句话的描述，它仅提及了最重要的活动和失败情况。它提示读者用例中正在发生什么事情，对估计工作复杂度很有用。
可以将用例简述做成一个表格，或作为执行者-目标列表的扩充，或在初稿中直接将期作为用例体的一部分。
功能范围：指系统要提供的服务，它最终应被用例所捕获。
设计范围：是系统的区域，它是开发人员负责设计和讨论的系统的集合，包括硬件系统和软件系统 ；它是集合的边界。
执行者，动作中的个体。有时在一个用例中，它指一个个体。有时，它指担当某个给定角色的一类个体的通称。
只有一个执行者列表对设计者来说是没有多少帮助的，设计者必须知道用户具有什么技能，然后才能保证设计出的系统行为和用户界面能够满足最终用户的要求。 执行都概况表： 名称、概况-背景和技能
辅助执行都是指为被设计系统提供服务的外部执行者。它可以是一个高速打印机、一个网络服务 或是必须进行一些调查然后把调查结果反馈给我们的人
识别辅助执行者的目的是为了识别系统将要使用的外部接口以及这些接口间所采用 协议。
目标层次
用户目标：蓝色 海平面，它是主执行都努力使工作得以完成的目标，或是用户使用系统的目标。它相当于业务过程工程中的 基本业务过程。在多数情况下，用户目标应通过一个、一次处理完成测试
颜色梯度是从白色、到蓝色、再到靛青色，再到黑色。更大范围 更高层次的目标 是白色的。更小范围、更低层次的目标是靛青色的。黑色表明目标层次太低，以致为它编写一个用例将是不合适的。
用户目标才是需要被编写的重要目标。海平面波浪与用户目标相对应。云朵或风筝表示高于海平面；鱼或蛤表示低于海平面。
系统的价值是通过它对海平面目标的支持来判断的。
系统所支持的用户目标列表就是关于系统功能的一个最短的概述，这是进行优先级划分、发布、分组、评估和开发的基础。
概要层次
概要层次目标 包含多个用户目标：
显示用户目标运行的语境；
显示相关目标的生命周期顺序
为低层用例提供一个目录表
概要用例在颜色梯度上是白色的。白色用例包含白色、蓝色，偶尔甚至会有靛青色的执行步骤。
概要用例通常需要执行几个小时、几天、几个星期、几个月、甚至几年。
最外层用例过程描述
1 以一个用户目标作为开始
2 提问 这个目标对主执行者AA提供什么服务？
3 找出最外层设计范围S，使得AA在S这外：公司、组合软件系统、被设计的具体软件系统
4 找出最终执行者在设计范围中的所有用户目标
5 找出执行都对系统具有的概要目标
6 为执行者对系统S的目标编写概要层用例。
即使在规模最大的系统中，通常也仅有4-5个这样的最高层用例。它们概括了3-4个最终主执行者的利益。
对公司而言：客户
对组合软件系统而言：市场部
对软件系统本身而言：安全部
这些最外层用例对于在总体上将工作联系起来很有帮助。然而，最外层用例不能为开发组提供被创建系统的功能需求--那些内容包含在用户目标用例中。
子功能层次：目标是指那些在实现用户目标时可能会被用到的目标。只有当迫不得已时才把它们包含进来--需要它们是因为可读性方面的考虑，或者因为有许多其他目标用到它们。
目标层次总结：
把较多的精力投入到对海平面用例的考查上，它们是重要的用例。
编写一些最外层用例来为其他用例提供语境。
不要在 是否把系统需要规格说明语句中你最喜欢的那个措辞用作用例的标题 上面小题大做。
利用图标来突出目标层次：
高度概括 用例 标以云朵 或 加号
将概要用例标以风筝 或 加号
将用户目标用例标以波浪 或感叹号 或 什么也不添加
将子功能用例标以小鱼。或 减号
对于一些子功能是不必编写用例的。使用蛤图标
找出用户目标：主执行者真正想要的是什么? 执行者为什么做这件事？ 答案可能就是执行者的目标
提升和降低目标层次：
用例中的交互步骤描述了一个过程是如何完成的；用例名称表明了该过程的意义所在。在决定一个交互步骤处于哪一个目标层次上才合适时，可以用这种 如何做/为什么做 的关系。
为了提升一个或几个交互步骤 目标层次，思考这样一个问题，“执行者为什么做这件事？”，答案可能就是较高一层的目标。
前置条件
用例的前置条件声明了启动该用例之前系统必须满足的条件。通用，前置条件是指该条件已经通过其他用例的执行进行了设置。
借助高层用例来体现低层用例间的相互关系。
最小保证
最小保证是系统向项目相关人员作出的最低承诺，尤其是在主执行者的目标不能被满足的情况下。多数情况下，两个或更多的项目相关人员必须在最小保证中被提及。例如 可以有用户、提供系统的公司，还可能有政府管理部门
不必在最小保证中不厌其烦地列举出用例的所有失败情况。失败情况多种多样。所有 失败条件和处理方案都已在扩展区进行了描述。在模板中加入最小保证的目的是为了声明系统的承诺。
最常见的最小保证是：系统将其执行进度情况记入日志。
最小保证被写成一些简单的断言形式，无论用例如何被执行，这些断言最终都应为真。它表明每一个项目相关人员的利益都得到了满足。
最小保证：只有收到付款以后才启动订单。
最小保证：如果没有捕获到最小信息，那么不完整 请求就被丢弃，不对这个请求进行任何记录。如果最小信息被捕获，那么不完整的请求就被保存并记入日志。
在目标遭遇失败的情况下，项目相关人员认可他们的利益得到了保护，这是最小保证是否成功、失败的测标准。
成功保证
成功保证说明了用例成功结束后项目相关人员的哪些利益得到了满足，用例可以通过执行主场景获得成功，也可以通过执行可选路径获得成功。
成功保证通常是作为最小保证的添加内容：最小保证被满足后，并且一些附加条件为真；附加条件中至少包括用例标题中声明的目标
成功保证被编写为 一组简单的断言，这些断言应用于用例成功运行结束时，以表明每个项目相关人员的利益都得到了满足。
找出成功保证 最好方法是问这样一个问题，“在用例成功结束时，什么事会使项目相关人员感到不高兴呢？” 这个问题通常很容易回答。然后写出答案的反面回答。
触发事件
触发事件指明了启动用例 事件。
主成功场景
我们首先编写一个自顶向下的描述，这个描述中包含一个容易理解的相当典型的场景，在该场景中，主执行者完成了目标，所有项目相关人员 利益都被满足了。这个场景就是主成功场景。其他成功场景和所有错误的处理，都会在主成功场景的扩展中进行描述。
主成功场景和所有场景扩展都可以包含在由以下元素组成的结构中：
场景执行的条件：对于主成功场景，条件就是前置条件加上触发事件。对于扩展场景，条令不是扩展条件
完成的目标：对于主成功场景，目标就是用例的名称，也就是满足项目相关人员的利益。对于一个扩展场景，目标是完成用例目标，或者是在处理扩展场景后重亲进入主成功场景。
执行步骤集：这些活动构成了场景的主体。在每一个场景和场景片段中，这些活动都遵循相同 规则。
结束条件：主成功场景结束时完成的目标。一个场景的片段可能随着目标的完成或放弃而结束。
作为场景片段的、可能的扩展集：主成功场景的扩展写在用例模板中 扩展部分。扩展场景的扩展可以嵌入到扩展体中，或者写在扩展体里面，或者就写在扩展体的后面
下面的任何一步都要描述：
1 两个执行者之间的交互（顾客输入地址）
2 为了保护项目相关人员利益的确认过程（密码确认）
3 满足项目相关人员利益的内部变化（系统从余额中扣除一定数量的金额）
执行步骤
执行步骤是对用例的补充，并且都有统一的语法形式，在一个简单活动中，执行者完成任务或向另外的执行者发送信息。
用户输入名称和地址
在任何时候，用户可以要求退款
系统确认名称和账号都存在
系统根据费用更新用户的余额
由于步骤通常一个紧接着下一个，因此时间限制常被忽略。
在写执行步骤时，经常会有很多小的不同。然而一旦你选择了一种编写方式，就要在每个步骤中都坚持使用相同的风格。
准则
准则1：使用简单的语法
主语 谓语动词 直接宾语 前置短语
准则2：明确地写出“谁控制球”
在同一个场景中使用相同 结构。在每一个步骤中，一个执行者 控制球 。这个执行者就是句子的主语--第一个执行者，它或许是句子中 第一个词或者是第二个词。“足球”是执行者与执行者之间传递的信息和数据。
控制球的执行者会做以下三件事之一：自己踢球，将球传给别人，或者 将球上 泥擦掉。大多数情况下，在步骤结束的时候，另外一个执行者控制足球。问问自己，在句子结束的时候，谁控制足球？ 不论什么时候，这个问题都应该有明确的答案。
准则3：从俯视的角度来编写用例
例：用户插入卡并输入密码
系统从账号余额中扣除一定数量。
准则4:显示过程向前推移
每一个步骤完成的是与用例目标的高或低相关。在一个概要或白色用例中，一个步骤可能完整地完成一个用户目标。在子功能用例中，一个步骤可能只完成少部分的工作。
将一些小 步骤合并，可以使用例的可读性更好，更加清晰，而且保持了原有 基本信息。少于9个步骤
为了找到具有较高层次目标的步骤，可以提出这样的问题：为什么执行者要做这件事情？，可能需要多次地部这个问题才能得到满意的答案，而这个问题的答案可能就是步骤实现的目标。
用户按下tab键
为什么用户要按下tab键呢？是为了将焦点移到地址框中
为什么要将焦点移到地址框呢？因为在系统开始工作前，要输入用户名和地址。
因此一个清楚地描述过程向前移动的主动语态句子是：用户输入用户名和地址
准则5：显示执行者的意图而不是动作
允许用例中只描述用户执行的意图。对具体动作的描述属于设计的任务，而不应该出现在功能需求文档中。
在需求文档中，我们只关心界面所要达到的意图，即它表达用户的意图，总结在执行者之间传递的信息。
通常情况下，当一些连续步骤的数据都在同一方向上运动时，就可以将这些步骤合并成一个步骤。
准则6：包含“合理”的活动集
可以把每个部分作为一个单独的执行步骤，也可以用不同的方式合并其中的几个部分。
准则7：“确认”而不是“检查是否”
我们使用 问为什么 的技术来找到一个更好的短语。为什么系统要检查条件？答案：是为了确认、验证或确保某些事情 ，这些都是很好的可以表示目标的动词。
系统验证了密码正确
当看到 如图。。。就。。。这样的句子 用“验证”来代替 “检查”
系统确认密码正确
系统向用户提供有效的操作
用例描述了一个成功的场景。在扩展部分 寻找 密码无效 的扩展。
准则8：可选择地提及时间限制
准则9：习惯用语：“用户让系统A与系统B交互”
用户命令系统从系统B获取基本数据。
准则10：习惯用语：“循环执行步骤X到Y，直到条件满足”
如果只有一个步骤需要重复，可以将表达重复执行的短语放在步骤描述中：
用户选择了一个或多个产品
如果多个步骤需要重复，可以把表达重复执行折语句放在这些步骤的前面或者后面。
在表达重复的语句前面我们不需要加上序号，也不需要用任何句子来说明这是一个表达重复 的语句。 步骤X到Y可以循环执行
编号或不编号
步骤编号使步骤更清晰，并在扩展部分给出引用的位置。编号的维护是困难的。
扩展：
将主成功场景从开始到结束，按照时间的顺序写出来，然后在每个分支点写出场景的扩展。
扩展通常是这样的，在主成功场景下，对于因为特别条件而出现行为分支的每个地方，写出分支的条件以及处理分支的步骤。大多数扩展以重新与主成功场景汇合而结束。
扩展实质上是一个从主用例中被拆分的用例。扩展开始于一个与它相关的条件。它包含了一个执行步骤的序列，该序列描述了在这个条件下发生了什么。扩展以完成或放弃扩展目标作为结束。
1 集中讨论，发现能够想到的每种可能
2 根据准则，评估、删除以及合并所有建议
3 详细讨论，并找到处理每一种情况的方法。
扩展条件：就是在一些条件下系统会完成不同的动作。包括成功和失败两种条件。
集中讨论所有可能的情况，这些情况中的场景可能失败，或通过其他方式获得成功。仔细考虑下面所有的条目：
1 一种可选择的成功路径（职员使用便捷的代码）
2 主执行者操作错误（无效密码）
3 主执行者无任何操作 （等待密码超时）
4 系统确认 这个短语的每一次出现，都暗示了将会有一个处理系统失败的扩展（无效的账号）
5 从辅助执行者那里得到不恰当的响应或没有响应（响应超时）
6 作为正常功能的一部分，检测所设计系统的内部错误，并处理（现金分配阻塞）
7 必须处理不期望和异常的内部错误，并产生一个外部可见的结果（发现崩溃 事务日志）
8 必须检测系统关键性能的失败（回答没有在5秒内完成）
准则 11 ： 用“检测到什么”的方式来编写条件
应该写出系统检测什么，而不仅仅写出发生了什么。等待用户输入密码的时间超时或密码输入的时间超时
扩展条件经常是一个描述系统检测到了什么的短语。有时也可以用一个句子。
无效密码：
网络崩溃：
顾客没有响应（超时）：
现金不适当地投放：
如果你使用编号的步骤，那么在条件被检测出的地方也要写出步骤的编号，并在编号后面加上一个字母。顺序和字母是无关的。
扩展条件列表尽可能的短，是所有的而且公是必须由系统处理的情况。
在集中讨论之后，应该产生一个短小和简单 主成功场景以及一个需要考虑的、长长的条件列表。仔细考虑列表，清除那些系统不需要处理的笨人合并那些对系统来说等价的条件。请使用下面两个标准：
1 系统必须能够检测到条件。
2 系统必须完成条件的检测。
在删除那些不可检测的条件前，尝试一下它们是否可以变为可测的条件。删除“用户忘记插入卡”等条件，因为系统不能检测到这个条件。可以将不可测的条件“用户忘记密码”改写为系统可测的条件“密码输入超时”。
合并等价条件 “卡不可读或不是ATM 卡”
逐层合并失败
准则12：条件处理的缩排方式
当使用编号方式时，应该缩排 那些指明如何处理条件 执行步骤，并在字母后重亲从编号1开始。2a1 或 .1
从扩展中创建新用例，以下两种情况下，可以为扩展创建新用例：
1 扩展在多个地方使用。将扩展转变为用例意味着它可以在同一个地方被跟踪和维护。
2 扩展使得用例难以阅读。两页左右的用例和三级缩排是可读性的极限
扩展说明了系统完成的目标是不同的
技术和数据变化 列表：系统所完成的目标是相同的，方法不同。
用银行卡、眼扫描、指纹来识别
技术和数据变化列表不包含步骤
连接用例
子用例：一个执行步骤可以是一个简单的步骤或者另外一个用例的名称。
加下划线（超链接）或楷体字的活动表示调用了别外一个用例，该用例扩展了活动的描述。
扩展用例：只有在必须的情况下才创建扩展用例，因为这些用例不容易理解、维护
最常见的一种情况是当有很多的用户可能使用的异步服务或中断服务的时候，并且这些服务不应该影响基用例。
另外一种情况是为一个已经锁定的需求文档编写附加文档的时候：
在你参加的项目中，开发过程是一个迭代的过程，并且有多个结束点。你有一个基准需求作为一个结束点。在一个后来的结束点上，你扩展了一个基准用例，增加了新功能或附加功能。但你不能影响基准用例。
如果触发事件包括了基用例应负责的事件，即基用例知道什么时候、在哪里、为什么第二个用例应该开始，那么基用例应包括、调用、引用别外一个用例。
如果触发包括了第二个用例应负责 事件，即第二个用例知道什么时候、在哪里、为什么它应该开始，那么第二个用例应扩展基用例。
当基用例调用第二个用例时，基用例指定第二个用例在什么时候和什么地方执行。被引用的用例不包含基用例的名称。当第二个用例扩展基用例时，基用例不用指定，实际上也不用知道关于扩展用例的任何事情。扩展用例指定它所中断的用例，并且决定在什么情况下执行用例。
用例格式
完整正式的用例格式：
1 单列文字（不是一个表格）
2 步骤编号
3 没有条件语句
4 扩展部分的编号规则是数字和字母的组保
用例24 完整正式的用例模板《名字》
<用例名应该是一个用主动语态动词短语来表示的用例目标>
使用语境：<目标较长的描述，如果需要，还包括触发条件>
范围：<设计范围，在设计时将系统作为一个墨盒来考虑>
级别：<概要、用户目标、子功能三者之一>
主执行者：<主执行者的角色名称或主执行者的描述>
项目相关人员和利益：<用例中的项目相关人员和关键利益的列表>
前置条件：<我们民希望的，周围环境已经达到的状态>
最小保证：<在所有退出操作前，如何保证得到必须信息>
触发事件：<什么引发了用例，可能是时间事件>
主成功场景：
<在这里写出从触发事件到目标完成以及清除的步骤>
<步骤编号#><动作描述>
扩展：
<在这里写出扩展，每次写一个扩展，每一个扩展都指向主场景中的特定步骤>
<被改变步骤><条件>:<动作或子用例>
技术和数据变化列表：
<在这里写出场景中因技术或数据变化而引起的可能分支>
<步骤或变化编号#><变化列表>
相关信息：
<项目民需要的所有附加信息>
通常，在适当的目标级别中，直到将文档减少到3到9个步骤时，人们才会发现文档简单清晰
双列表格式: 用户 系统
五种项目类型的标准
1 了解需求 ，甚至包括用例根本不在最后的需求文档中使用 情况
2 业务过程建模
3 设计和量化系统需求
4 在一个短期、高强度的项目中编写功能需求
5 在一个长期、大型项目中，在增量式开发开始时编写详细的功能需求。
不要使用 公司、系统 这样不明确的词，而是使用它们实际的名称。
需求了解用例模板 黑盒
范围：acura
级别：海平面
使用语境:
主执行者
项目相关人员和利益：
前置条件：
触发事件：
主成功场景：
发生频率：
未解决问题：填写一些好想法
业务过程用例模板 概要
范围：myco操作
级别：概要
使用语境：在操作语境中关于目标的文字描述
主执行者：所有主执行者
项目相关人员和利益：适当的人和物
最小保证：所有保证
成功保证：所有保证
前置条件：在用例被触发前必须具备什么条件
触发事件：可以是任何事件
主成功场景：
1 动作步骤
2
扩展：
1a.扩展条件
1a1.动作步骤
发生频率：所有时刻
未解决问题：
这个模板是用于重新设计新软件的业务或过程。阅读这些用例的人往往是一些高层人员、部门经理、高级执行官，因此尽量使这些用例可读性强，减少细节 内容。步骤的编号突出了活动的时间顺序。一定要在扩展中描述错误的处理，这样才能揭示重要的业务规则。
确定系统需求用例规模模板
范围：acura
级别：概要
使用语境：在这里填写前置条件或正常用途的条件
主执行者：任何人 在这里用几句话来描述执行者如何在主成功场景中成功地完成工作
在这里用几句话来描述可选的路径和处理
发生频率：多久
未解决问题：在这里填写一些好想法
当为估计系统大小和结构而分析需求时，使用这个模板。以后，可以细化需求直到完成一个完整的用例。
高强度项目用例模板
范围：acura
级别：用户目标
使用语境：
主执行者：
项目相关人员和利益：
最小保证和成功保证：
前置条件：
触发事件：
主成功场景：
用来描述执行者在主成功场景中完成目标的一段文字
扩展：
用来描述民有可选的路径和处理的一段文字
发生频率：
未解决问题：
详细功能需求用例
用例名称
范围：acura
级别：用户目标
使用语境
主执行者
项目相关人员和利益：
最小保证：
成功保证：
前置条件：
触发事件：
主成功场景：
1.
2
扩展：
1a.
1a1.
发生频率：
未解决问题：
当收集行为需求，并且需要完整正式的用例格式中的所有信息时，可以使用上述模板
不要为应该在项目中采用哪种格式而烦恼，只需要选择一种既适合于编写者又适合于读者的格式。
当满足如下要求时，才算完成任务：
1 已经命名了与系统相关的全部主执行者及其用户目标
2 捕获了系统的全部触发条件，既包括用例触发条件，也包括扩展条件
3 编写了所有用户目标用例以及必要的概要用例和子功能用例
4 每个用例描述足够清晰，使得：
投资方确认他们能够区分这个用例是或不是实际上要提交的用例。
用户确认用例表达了他们的要求，或者能接受这些用例作为系统的行为
开发人员确认可以实现所有用例表示的功能
5 投资方确认用例集覆盖了他们所有的需求。
全部主执行者及其用户目标：
通过全部主执行者及其用户目标，可以确定系统的实现范围。有必要采用集体讨论的方式对主执行者及其目标列表进行多次检查。
全部触发条件：这些触发条件表示系统边界的微调。系统必须对它们进行响应。
有一个方法可以对系统触发条件进行重新检查，即通过识别系统中所有具有生命周期的元素并重新审查它们的生命周期，寻找所有改变它们状态的事件。
概要用例和子功能用例：
概要用例建立了用户目标用例的环境。所有这些用例如何组装在一起
子功能用例为用户目标用例提供支持。只有被多个其他用例调用或者分离一个复杂行为时，子功能用例才有存在 必要。
用例确认：只有投资方和应用专家阅读这些用例并认为用例表达了他们所有的需求；系统开发人员阅读这些用例并认为他们能够根据用例描述开发符合需求的系统时，才能认为这些用例合格。
在对大量用例时行处理时，可以采用两种行之有效的技术：对每个用例进行简单说明，或者把用例分为多个簇
简单描述每个用例--低精度表示
好的用例名字集合便于操作整个用例集，特别是为评估、规划和跟踪提供了便利。可以把所有的用例名放入一张电子表格中，利用电子表格功能对其分类、排序、统计各种用例特性。
第二级精度是每个用例的简介，即用两句到三句话对每个用例进行概括。简介也可以放入电子表格或表单中，有利于审查。另外用例简介也可以作为系统和项目组织工作的概述。
当需要从整体上浏览用例集时，这种粗略的描述方法就显得非常有用。
创建用例簇
分簇技术：
按执行者分类：最容易想到的方法是对用例集按它们所属 主执行者分簇。
按概要用例分类：
按开发组和版要号分类：对用例集按负责开发设计工作的开发组和版本号进行分簇，有利于简化项目跟踪工作 。
按主题域分类：容易弄清某个主题所涉及的领域。
CRUD -create retrieve update delete
参数化用例：公共行为被局部化，只需编写一次
业务过程建模
核心业务：弄清楚
1 在组织行为中 项目相关人员
2 该组织必须满足其需求的外部主执行者
3 该组织必须响应的触发事件。
4 该组织提供的服务，以及对项目相关人员的成功结果。
在这个阶段，可以充分利用当前的新技术，创建新资源组和新过程。用白盒用例对系统文档化。这些用例展示了人与各部门之间的交互作用，以及这些作用所产生的组织外部可见行为。考虑系统失败及异常处理等情况。在此过账中可以选择使用新技术，或不使用新技术来满足系统需求。
为了减少混乱，应该在用例模板中写明用例范围及级别
在同一时间不是所有用例都能交付。但是，每次交付都必须包括一个完整场景。用例说明了用户需要实现什么，并列出了所涉及的很多场景。
交付的规划和设计必须与最张用户使用的功能集保持一致，这些功能应是来自用例的完整场景。同时，功能测试者要对用例兼容性进行测试。
从用例到任务或特征列表
一个保持良好交流的开发组，可以通过用例制定软件设计任务。保证用例到设计任务的映射，以及保持映射 及时性
遗漏的需求
用例只是需求文档 行为需求，它们不包括系统性能需求、业务规则、用户界面设计、数据描述、有限状态机行为、优先级以及其他相关信息。
这些信息中，下列信息可以作为用例相关信息附在用例上：
用例优先级、期望的发生频率、性能要求、交付日期、次要执行者、业务规则、未解决的问题
在许多情况下，一张简单电子表或表单就能很好地捕获相关信息。请多 人在项目开始处，用一张电子表格来概括用例信息全貌，并在表格最左端标明用例名，然后在其他各列中填充如下信息：
主执行者、触发条件、交付优先级、复杂度评估、可能的版本、性能要求、完成状态、其他
数据需求的精度
信息别名
域列表或数据描述
域的细节和域校检
可通过超文本链接把用例和数据需求细节进行分离，并建立从用例以相关域列表的链接。
域列表：
方法一：为每一个别名保留一个单独条目，用域的细节及相关检验条件对这个条目不断进行细化。
方法二：把别名信息放在一个域列有中，当需要对信息做进一步细化时，不能在原条目中进行扩展，而必须为每一域重新创建单独条目。
域的细节和域校验：
必须把域的细节和域校验放入第三级精度中。
用例不是进行扩展的地方
相关信息必须与用例建立连接
域的详细说明可能随时间改变，应独立于用例详细说明
用例在项目组织中的作用：
用例为管理者指明应提交给用户的系统功能。用例的标题指明主执行者的需求，同时系统也必须支持这些需求，而用例描述则说明系统需要什么功能以及将提供什么服务。
通用用例标题进行组织
在早期项目开始中，通常创建一张用例表，表格中第一、二栏分别写上用例名和用例主执行者，第三栏由投资方填写每个业务过程用例的优先级，第四栏写上由开发组评估的实现功能的困难和复杂度。
首先由投资方对每个用例优先级进行评估，由开发组估算开发费用。投资方看到费用后，对优先级进行调整。也可以不进行调整。
好处：用例表清晰显示系统对整个业务的价值。
用例名列表为基于优先级的工作和时间表提供了依据。
跨版本处理用例
可以使用高亮方式表明先实现的部分，许多项目都以这种方式进行开发。
交付完整场景
在同一时间不是所有用例都能交付。但是，每次交付都必须包括一个完整场景。交付的软件必须包含其中一些完整的场景，否则就不要交付这些功能。
交付的规则和设计必须与最终用户使用的功能集保持一致，这些功能应是来自用例 完整场景。同时，功能测试者要对用例兼容性进行测试。
在任何情况下，用例都是按不同的组织模式划分整个系统，而不是对象。
在开发组中，应指派有丰富经验的员工来创建用户友好的界面。他们首先要阅读用例，创立一个系统界面表示方式，该表示方式应保持用例的步骤，同时尽量减少用户的工作。由用户和程序设计人员进行审核。
用例编写人员发现这种方式非常有用，可以假定正在对屏幕输入数据或填充表格，然后去发现需要输入什么信息，以及输入数据时是否要受某种顺序限制。确保这些表示方式是作为应用专家审查任务的指示，而不是作为需求的一部分。
描述用户界面设计不是编写需求文档，但随着开发的进程，使用用户界面设计实例来扩展需求文档是很有用处的。这些设计信息从文字和可视化两方面解释系统的行为，因此增加了需求文档的可理解性。
用户界面设计可分为 高 中 低 三个精度级别：
用户界面的低精度描述是一种屏幕导航图，用状态图或有限状态机进行描述。每种状态是用户将会遇到的屏幕名称，有限状态机显示了什么用户事件导致从一种屏幕状态向另一种屏幕状态转移。
中精度描述可看成一幅画或缩小的屏幕快照。把这些放到有例结尾处，以便读者能查阅指定的设计。
高精度描述列出每个屏幕所有的域类型、长度及有效性验证机制，它们不属于需求文档。
从用例到测试用例
用例为系统提供了现成的功能测试描述，在需求阶段用例就会为测试组提供一套测试方案。最好的情况是测试组也能够帮助编写用例。
在正规的开发组中，测试组应把用例分成多个测试集，并编写计划来确定触发不同路径的每个测试设置。然后，构造用于测试这些设置的测试用例。此外还将设计不同数据来测试不同数据组合。最后还将设计系统执行性能和负载测试。最后两项测试任务不能直接从用例派生出来。
分工合作过程
1 制定一份粗略的系统功能图：
对系统采用的叙述方式达成共识 开发组
对应用领域达成共识，并集中讨论系统主执行者和系统目标 开发组
编写系统描述 个人
收集各种系统描述 开发组
第一阶段工作完成，团队应向每个投资方发送一份系统叙述，它显示新系统草图低精度，应该包括如下各项：
系统构想陈述
列出哪些在领域中和哪些不在领域中 包括功能和设计范围
在执行环境中的系统草图
关键的主执行者列表
项目相关人员及其相关利益列表
最重要的用户目标列表
系统描述集 至少半页
2 制定详细的用例视图
集中研讨用例编写 开发组 采用分组方法构造所有主执行者和用户目标列表。
对用例编写格式达成共识 开发组 编写用例样本，开发组讨论用例编写级别和风格、用例模板、项目相关人员及其利益、最小保证等 。形成初步的用例编写标准。
编写用例 个人： 花费几天或数周时间，各小组独自或成对编写用例，然后在小组内传阅，不断改进直到正确。然后编写概要用例。
审核用例 个人：编写者把用例发送给系统开发人员和系统应用专家进行审核。员确定用例是否包含实现所需要的各种细节，数据描述和用户界面设计除外，应用专家应确定系统需求是否确实如此，以及业务过账是否真正以这种方式工作。
审核用例 开发组：软件设计人员、业务专家、应用专家、用户界面设计人员都参加审核 。编写者应确保每一步都可理解的、正确的，并且足够详细便于实现。所有这些工作可能通过正式审核、非正式审核、用户审核及开发人员审核来进行。
在完成用例编写时：
1 指定所有扩展条件
2 仔细考虑业务策略与失败处理的联系。
3 验证对项目相关人员利益的保护
4 验证用例是否公描述了实际需要的所有需求
5 确保每个用例对用户和应用专家是可读的，以及开发人员清楚地知道所要实现的系统。
错误改正：
1 没有系统
2 没有主执行者
3 过多的用户接口细节
4 过低的目标级别
5 目标和内容不符
对每个用例的提示
1 每个用例都是一篇散文，既要采用单调的写作方式，又要富有完美的表达能力。
2 使用例易于阅读
1 让问题短小，切题。
2 从头开始，用一条主线贯穿始终。顶部是一些对全局有重要意义的用例。从这里分离出用户目标和最张的子功能用例。
3 用动词短语来给用例命名，这些动词表明了用例所要达到的目的。
4 从触发事件开始一直继续，直到目标实现或者被取消，并且系统完成所有与这次事务处理有关的记录。
5 用完整的主动语态句子来描述所要完成的子目标。
6 确保每步中执行者及其意图是可见的
7 突出失败条件，并使恢复动作是可读的。最好是不必为每个步骤编号，人们就能清楚地知道下一步该做什么。
8 将可选的行为放在扩展部分，而不是用例主体的条件语句中
9 只在非常必要的情况下生成扩展用例。
3 仅用一种句型，在编写用例的每个执行步骤时，只采用一种句型。
现在时态的句子
在主动高不成低不就中用主动动词
描述执行者成功到达的目标，这些目标推动了整个过程的前进
扩展的条件部分用冒号代替句点作为条件的结束。
4 “包含" 子用例
5 谁控制球 ，应该按从上向下 角度，以观察和记录景物的方式来编写用例。或者是以剧本宣布哪个演员将要出场的方式来编写用例。
6 正确地得到目标层：
由一个人 在一个地方 一次完成
执行者 完成操作 就可以离开
执行者在完成许多工作后可以要求XX
大部分用例在主成功场景中有3到9个步骤。合并多于步骤
7 不考虑GUI 确定你所定的每一步恰好抓住了执行者的真实意图，而不仅仅是操作用户界面的动作。
8 两个结局 ：成功和失败
当一个执行步骤调用一个子用例时，被调用的用例可能成功或者失败。如果是在主成功场景中调用，则将失败处理话扩展中。如果调用来自一个扩展，则将成功和失败的处理均放在同一个扩展中
9 项目相关人员需要的保证
10 前置条件：用例的可运行条件
11 对用例进行通过、失败测试
对用列集 提示
12 一个不断展开的故事：将复杂的定作部分移到它自己的用例中，或者将简单的子用例合并到调用它的用例中。
13 业务范围和系统范围
业务用例的设计范围是业务运作，它所涉及的执行者在组织外部，完成与组织相关的目标。业务用例通常不涉及技术,因为它只涉及如何进行业务动作。
系统用例的设计范围就是要设计的计算机系统。它所涉及的执行者完成与计算机系统相关的目标，它涉及到技术问题。
业务用例通用以白盒方式来编写，它描述公司中个人和部门之间 相互作用。而系统用例通常以黑盒方式来编写。因为大多数业务用例的目标是描述公司现在和未来的设计，而系统用例的的目标是为一个新设计形成需求，所以这样做通常是合适的。业务用例描述了业务的内部情形，而系统用例描述了计算机系统外的情形。
14 核心价值和变化
核心价值：所基于的目标 ：用例围绕主执行者的目标和各种不同执行者所要实现的子目标，包括所讨论的系统。用例的每句话都描述了一个要实现折子目标。
从系统外部的观察角度：通过用例来描述执行动作。
可读性：用例或任何规格说明最终都是供人们阅读的。如果人们读不懂它们，那么用例就没有达到它的核心目标。可以通过牺牲 些精确性甚至准确性。
用于多个目标：用例是一种行为描述形式，在项目的不同时间可能用于不同的目标。
黑盒需求：作为功能规格说明时，所讨论的系统通常被看作是黑盒。
在主成功场景之后的选择路径：在主成功场景后放置选择过程 初衷是想保持这个创建最易读用例的方式。
不要太费精力：
适当的改变：
编号的步骤与简单的分段
非正式与完整正式。
15 用例集中的质量问题
对整个用例集只有三个有关质量的问题：
每个用例都是来源于最高层到最低层目标的展开吧？
对每个主执行者在最外层的设计范围内都可能存在一个与设置语境相关的、最高层的用例吗？
对于项目相关人员和用户 这就是所要开发的全部内容吗？
处理用例的提示
16 用例只是整个需求收集工作中的一小部分。这综合症是这项工作的重点，在连接数据定义、业务规则、用户接口设计、业务领域模型等 中起着核心作用。然而它们并非需求的全部，仅仅是其中的行为部分。
17 首先向广度上努力
首先从广度上而不是从深度上，做到逐步精确。工作随着细化，逐步加大
主执行者：把收集所有的主执行者作为了解整个系统的第一步，尽量简明 。
目标：列出所有主执行者的目标可能是你在一个视图中了解整个系统目标的最后一次机会，花费足够多的时间和精力，尽可能完整和正确地列出这张表格。
主成功场景：通常简短而明了。它指明了系统所要交付的内容。
失败、扩展条件：在考虑怎样处理扩展条件之前，应先找到它们。这是一个靠集体研讨的活动。
恢复步骤：编写者被迫要去面对一些经常被忽略的业务规则问题，因此这是用例编写过程中最艰难的部分。
数据域：相同的开发人员常常被派去将数据名扩展为域列表
数据域详述和检测：尽管这些详述和检查超出了用例体系的范围，但是最后必须完成它们的编写工作
18 12步秘诀
1 寻找系统的边界--语境图 输入、输出表格
2 集体研讨并列出主执行者--执行者简介表
3 集体研讨并列出主执行者对系统的目标 执行者-目标列表
4 编写覆盖以上各项的最外层概要级用例
5 重新考虑和修订具有战略意义的用例，通过增加、删减来合并目标。
6 选取一个用例进行展开，或者写一段叙述来熟悉材料。
7 将项目相关人员、利益、前置条件和保证填入表中，再对它们检查两次。
8 编写主成功场景，对比利益和保证来检查它。
9 集体研讨并列出可能的失败条件和可选的成功条件。
10 写出在每个扩展中执行者和系统应该做什么。
11 列出所有需要自己空间的子用例。
12 从顶部开始重新调整用例。适当地增加、删减和合并用例，再次检查完整性、可读性和失败条件。
19 认识错误的代价
降低用例质量所带来的开销取决于系统和项目。一些项目在写需求文档时不需要质量保证，因为它们已经在用户和开发者之间进行了很好的交流。
应用专家和开发人员的交流超好，那么由于用例模板省略部分所带来的损失就越少。人们可以进行简单的讨论，然后直接解决问题。
如果将系统功能正确地写下来是很重要的，那么你需要密切注意项目相关人员及其利益、前置条件和最低保证。
20 短小而可读的文档，意味着人们在阅读中会有很多疑问，于是就会提问。从那些问题中就能发现遗漏的信息。
提高组内交流的质量对每个项目都有好处。
21 处理失败情况
用例 的一个很有价值的地方就是定义了所有的扩展条件。
22 前期和后期的工作标题
在项目的开始，要收集系统需要满足的所有目标，并将它们放入一个可读的结构中。将精力集中于工作标题或是受系统影响的社会角色，可以使你进行有效的集中讨论，并且给目标命名时就有一个良好的开端。
可以使用工作标题来描述不同工作技术和工作风格。标题信息也可以体现用户界面的设计。
23 执行者扮演角色
执行者 是指使用该系统的人的工作标题，也指使用系统时那个人所扮演的角色
重要的部分是目标，它表明了系统将要做什么。在系统生命周期里可能会协调和重新安排是谁完成系统目标。
24 大 图画恶作剧
用例图 可以被用作：
用例的目录表。
系统的语境图，显示执行者寻求他们可变的重叠的目标，也可能是系统得出了辅助执行者。
一幅大图画 可以显示高层用例和低层用例的关系。
用例的基本形式是文本，因此那些椭圆只是文本的补充。
26 使用标题和简介的项目计划
用例计划表：将执行者和目标填入表中最左边的两列，在接下来的几列中依次填入所需的下列信息：业务价值、复杂度、实现、开发组、完整性、性能需求和外部接口 等 。
交付部分用例：在一个特殊版本中经常会只交付一部分用例。应该在项目计划表中注明在第一个版本中哪些用例要交付，在最终版 本中哪些用例需要全部交付。
心得：测试用例：写大纲 测试内容、测试点
每个测试用例前要写主要步骤
