用例是代表系统中各个项目相关人员之间就系统（System under Discussion，SuD）的行为所达成的契约。用例描述了在不同条件下，系统对某一相关人员的请求所作出的响应。提出请求的项目相关人员叫做主执行者（primary actor）。主执行者通过发起与系统的一次交互来实现某个目标。根据执行者的请求和请求涉及的条件，系统将执行不同的行为序列。一个行为序列叫做一个场景（scenario）。用例是多个不同场景的集合。
如果使用用例来记录一个组织的业务过程，那么被讨论的系统是组织本身。项目相关人员是指公司的股东、客户、供应商和政府管理部门。主要执行者包括公司的客户，也可能还包含客户的供应商。如果使用用例来记录一个软件的行为需求，那么被讨论的系统指计算机程序。项目相关人员是指使用该程序的人、拥有该程序的公司、政府管理部门和其他一些计算机程序。主执行者指坐在计算机屏幕前的用户或者另一个计算机系统。
要写好一个用例，必须掌握三个概念：范围（scope）、主执行者（primary actor）和层次（level）。范围解答了真正被讨论的系统是什么；主执行者解答了谁有要实现的目标；层次说明了目标是高还是低。这三个概念适用于用例和用例中的每一个句子。
在进一步讨论之前，首先介绍一些术语和几个例子。
执行者（actor）：任何具有特定行为的人或物。
项目相关人员（stakeholder）：对被讨论系统的行为有特定兴趣的人或物。
主执行者（primary actor）：启动与被讨论系统的一次交互活动，从而达到某一目标的人或物。
用例（use case）：规定被讨论系统行为的契约。
范围（scope）：界定被讨论的系统。
前置条件和保证（precondition and guarantee）：在用例执行之前和执行之后必须被满足的条件。
主成功场景（main success scenario）：一切顺利的情况。
扩展（extension）：场景执行过程中出现的不同情况。
用例的用途有很多，比如：
用来描述业务过程。
用来集中讨论未来系统的业务问题，而不是需求描述。
作为系统的功能性描述。
将系统设计结果文档化。
根据用途不同，用例的编写可以较为随意，或者比较详细。如果使用用例来记录需求，有两点必须要注意：一、用例确实是需求，不需要将用例转换为其他需求方式。二、用例不是全部的需求。用例只记录需求中的一部分，用例不会详细的描述外部接口、数据格式、业务规则等。
下面是一个需求大纲示例
第一章 目的和范围
1a. 整理范围和目标是什么？
1b. 项目相关人员（谁关心？）
1c. 什么在范围之内，什么在范围之外？
第二章 使用的术语/词汇
第三章 用例
3a. 主执行者及其总体目标
3b. 业务用例（操作概念）
3c. 系统用例
第四章 采用的技术
4a. 这个系统有什么技术需求？
4b. 这个系统会与哪些系统发生交互，其需求是什么？
第五章 其他需求
5a. 开发过程
Q1. 哪些人时项目参与者？
Q2. 项目的价值反映在哪些方面（简单、及时、迅速或灵活）？
Q3. 用户或出资人希望得到什么反馈或项目可见性？
Q4. 什么是可以买到的，什么是我们必须要创建的，我们在哪些方面是有竞争的？
Q5. 还有什么其他的过程需求（如测试、安装等）？
Q6. 项目运行依赖哪些条件？
5b. 业务规则
5c. 性能
5d. 操作、安全、文档
5e. 使用和可用性
5f. 维护和可移植性
5g. 还未解决的问题和推迟解决的问题
第六章 人工备份、法律性、政治性和组织性问题
Q1. 为系统操作所做的人工备份是什么？
Q2. 有什么法律性和政治性的需求？
Q3. 这个系统完成后对人们的影响是什么？
Q4. 有哪些培训需求？
Q5. 对人类还有哪些假设和依赖？
按照从粗犷到精细的顺序，用例可以分为4个精确度等级：
执行者和目标。这个精确度等级的用例列出系统所支持的执行者及目标，审查这个列表的正确性和完整性。
用例概述和主成功场景。对于选出的需要进一步细化的用例，勾画其主成功场景。审查这些草图以确保证系统能够真正表达我们所关心的项目相关人员的利益。
失败情况。完成主成功场景，集中讨论所有可能发生的失败情况。
失败情况处理。写出系统应该如何对失败情况作出反应。
网友评论