用例技术（1）-一些基础概念

词汇缩写

SuD——System under Disscussion：被讨论系统

用例历史

20世纪60年代：Ivar Jacobson在爱立信工作提出了用例的概念。
20世纪80年代：引入到面向对象编程领域。
1994年：建立了actor和目标概念模型，从而把用例中难以理解的事情解释清楚，并且为如何编写用例提供了指导。
1995年开始：actor和goal目标模型正式使用。
从1994年到1999年：用例的概念基本保持了稳定，后续又产生了项目相关人员（stakeholder）和利益（interest）模型。

用例和UML的关系

平时所说的统一建模语言对这些概念没有任何影响，因为用例的概念早于UML产生，UML正式创建是在1994年）。
由于UML的快速发展，很多人会误认为用例是图形的形式，其实从根本上来说用例是文本的，简单的文本形式是编写用例的首选形式。

用例的概念

用例是涉众就系统行为达成的契约,它描述了在不同条件下，系统对某一项目相关人员的请求做出响应时，发生的系统行为，其中主执行者
指的提出请求的项目相关人员，根据执行者做出的请求，和请求涉及的条件，系统将执行不同的行为序列，每一行为序列称为一个场景，一个用例时多个场景的集合。

用例的组成部分

执行者（actor）：谁有要完成的目标，具有相关行为的人或物。
涉众（stakeholder）：对SuD有特定兴趣的人或物。
主执行者（Primary actor）：激发与SuD的一次交互活动，从而达到某一目标的人或物。
用例（user case）：规定SuD行为的协议。
范围（scope）：界定SuD
前置条件和保证（precondition and guarantee）：在用例执行之前和之后必须满足的条件。
主成功场景（main sucess scenario）：一切顺利的情况。
扩展（extension）：场景执行过程中出现的异常情况。

下列信息可以作为用例相关信息附加在用例上

1. 用例优先级
2. 期望发生的频率
3. 性能要求
4. 交付日期
5. 次要执行者
6. 业务规则
7. 未解决的问题

用例的作用

激发对目标系统的讨论

记录最终的设计结果

可以作为项目的链接结构

把许多其他需求细节连在一起，作为连接需求中不同部分的信息提供了一个框架。

有助于用户概要信息业务规则和数据格式需求等内容的交叉连接。

除需求文档外，有助于组织项目计划信息，如发布时间信息，优先级和开发状态。

有助于设计小组跟踪某些结果，尤其是用户界面的设计和系统测试。

用例和需求的关系

1.用例确实就是需求，不必转化成其他的形式。
2.但用例不是所有的需求（约1/3，用例没有详细描述外部接口，数据格式，业务规则，复杂公式等），它描述了需求中的行为部分，即必须的功能。

5种使用场景

 1.了解需求
2.业务过程建模
3.设计和量化系统需求
4.短期高强度项目编写功能需求
5.长期，大型项目增量式开发，编写详细的功能需求

* 使用用例收集需求的意义

• 满足自身需求

• 制定如何描述需求的标准

三个命名的目标和层次

概要目标：包含多个用户目标，一般的功能是显示用户目标运行的语境或者显示相关目标的生命周期顺序，也可能是为底层用例提供一个内容列表。

用户目标：基本业务过程，一次处理完成

子功能：在实现用户目标的时候可能会被用到的目标。