运行时期和建立时期的需求比较
一个重要的因数要记住，就是系统的赞助者是大过用户团体的。系统中有许多的风险承担者，Use Cases仅仅捕获其中一些风险承担者的需要，具体说，Use Cases仅仅捕获系统运行时期的需求而忽略做为系统开发组织的风险承担者的需求，开发组织最有兴趣的是对建立时期需求的描述。
运行时期需求包括：系统范围、用户组织对产品的期望和目标、Use Cases、其它非功能性需求。
建立时期需求包括：减少开发成本、较少的变更处理、现存组件的重用。
建立时期的需求可以部分的由Use Cases把握。但许多方面是需要由开发组织的处理的。
l 项目范围和目标：项目必须提交什么。（和系统范围的区别是它提交的是所有项目的东西）
l 增长性和变更请求：这些可以在捕获为常规Use Cases格式中的“Change Cases”
l 开发负责人的约束：包括标准、习惯、工具、品质度量标准、品质保证原则、及品质保证的习惯。
Use Cases的适用性
Use Cases首先用于需要响应客观事件的系统。它们能用于提供了一个有很容易理解的目标的清楚的行为者的环境。当结果不可定义或不清晰时不能用Use Cases。意思是如果目标成功或目标失败不能有一个明确的定义，那么Use Cases不能用来捕获需求。
然而说到这，现在大部分对象方法都使用Use Cases。因为Use Cases被证明是捕获需求的非常有效的机制。
总结
Use Cases以一种可读的、可驳倒的格式捕获需求。Use Cases是系统客观必需机能的可驳倒的描述。
可驳倒的意思是当你说明Use Cases时期望从用户和开发者处获得关于Use Cases品质的反馈。
Use Cases并没有从一开始就就明确的定义，它主要的开发顺序如下：
1、 指出行为者（Actor）
2、 指出行为者的目标
3、 指出每一行为者：目标语句对的成功或失败的意思
4、 指出每一Use Case的主要的成功的情节
5、 在细化阶段，指出失败的条件及可恢复/不可恢复的情节
只有做到了第四步才能决定哪一些的东西在Use Case中逐步开发出来。
总而言之，Use Cases是非常有效的需求捕获技术，它能使需求变得容易回顾，并且避免在需求中有实现细节的偏好出现。
对照表：
中文 Scenario 情节 Internal structure 内部结构 Measurable 量化 Thread 线索
文章来源于领测软件测试网 https://www.ltesting.net/
