下面这个知识图片可参照
用例驱动开发
现代需求实践
•共性：站在用户的角度看待系统、定义系统 ；使用用户能够看懂的语言来表述
| 实践名称 | 描述 |
| 用例(Use case) | 描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员(风险承担人，Stakeholder)之间就系统的行为所达成的契约 |
| 用户故事(user story) | 由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语编写，其长度约为三句话左右 |
| 特性(Feature) | 就是一个小的，具有客户价值的功能，通常表示为<action><result><object> |
用例驱动开发过程
•知名的“用例驱动”的开发过程有两个，一个就是重型的RUP，另一个则是“离地1000公尺”的ICONIX
•在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个系统之后，还将根据用例模型设计出测试模型来对系统进行验证
•这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每次都将越来越精化
参与者
•参与者是为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色
•参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟
1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；
2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写
器就是一个参与者；
3）时钟：当系统需要定时触发
时，时钟就是参与者
用例
•用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例
•用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景
•用例应该给参与者带来可见的价值，这点十分关键
阅读用例图
•这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账
•客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。
•总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。
•当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。
包含与扩展关系
•被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现，（包含性的一会执行的）
（选择性的叫扩展，不一定会执行的）
•基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展
泛化关系
•可以用来表示参与者与参与者之间，用例与用例之间的特殊/一般化关系，（特殊继承自一般化）
用例图的组成元素
•图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线
•所有的用例都位于方框之内，该方框称为“系统边界”
•参与者与用例的关系：在参与者和用例之间的关联是用一根带箭头的线来表示的
•用例之间的关系：
1）包含关系 include
2）扩展关系 extend
3）泛化关系 Generalization
用例描述
•用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事
事件流。
用例描述模板
| 用例编号 | [为用例制定一个唯一的编号，通常格式为UCxx] | ||
| 用例名称 | [应为一个动词短语，让读者一目了然地知道用例的目标] | ||
| 用例概述 | [用例的目标，一个概要性的描述] | ||
| 范围 | [用例的设计范围] | ||
| 主参与者 | [该用例的主Actor，在此列出名称，并简要的描述它] | ||
| 次要参与者 | [该用例的次要Actor，在此列出名称，并简要的描述它] | ||
| 项目相关人 利益说明 | 项目相关人 | 利益 | |
| [项目相关人员名称] | [从该用例获取的利益] | ||
| …… | …… | ||
| 前置条件 | [即启动该用例所应该满足的条件。] | ||
| 后置条件 | [即该用例完成之后，将执行什么动作。] | ||
| 成功保证 | [描述当前目标完成后，环境变化情况。] | ||
| 基本事件流 | 步骤 | 活动 | |
| 1 | [在这里写出触发事件到目标完成以及清除的步骤。] | ||
| 2 | ……(其中可以包含子事件流，以子事件流编号来表示) | ||
| 扩展事件流 | 1a | [1a表示是对1的扩展，其中应说明条件和活动] | |
| 1b | ……(其中可以包含子事件流，以子事件流编号来表示) | ||
| 子事件流 | [对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。] | ||
| 规则与约束 | [对该用例实现时需要考虑的业务规则、非功能需求、设计约束等] | ||
用例图的绘制流程
记录需求—特性表
| 编号 | 说明 |
| FEAT01 | 新增书籍信息 |
| FEAT02 | 修改已有的书籍信息 |
| FEAT03 | 书籍信息按计算机类、非计算机类分别建档 |
| FEAT04 | 录入新书时能够自动按规则生成书号 |
| FEAT05 | 计算机类与非计算机类书籍采用不同的书号规则 |
| FEAT06 | 录入新书时如果重名将自动提示 |
| FEAT07 | 按书名、作者、类别、出版社等关键字组合查询书籍 |
| FEAT08 | 列出所有书籍信息 |
| FEAT09 | 记录外借情况 |
| FEAT10 | 外借状态能够自动反应在书籍信息中 |
| FEAT11 | 按人、按书查询外借情况 |
| FEAT12 | 列出所有的外借情况 |
| FEAT13 | 按特定时间段统计购买金额、册数 |
| FEAT14 | 所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 |
把每个需求都记录下来
识别参与者
•已有的上下文关系图（表示系统范围）及其他相关模型：它们描述了系统与外部系统的边界，从这些图中可以寻找出与系统有交互关系的外部实体。
•项目相关人员分析：对项目的相关人员进行分析，就能够决定出哪些人将会与系统进行交互。
•书面的规格说明和其它项目文档（如会谈备忘录等）
•需求研讨会和联合应用开发会议的记录：这些会议的参与者通常是很重要的，因为他们在组织中所代表的角色就是可能与系统发生交互的参与者。
•当前过程和系统的培训指南及用户手册：这些东西中经常会有潜在参与者。
合并需求获得用例
| 特性 | 用例 |
| FEAT01.新增书籍信息 FEAT03.书籍信息按计算机类、非计算机类分别建档 FEAT04.录入新书时能够自动按规则生成书号 FEAT05.计算机类与非计算机类书籍采用不同的书号规则 FEAT06.录入新书时如果重名将自动提示 | UC01.新增书籍信息 |
| FEAT02.修改已有的书籍信息 | UC02.修改书籍信息 |
| FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍 FEAT08.列出所有书籍信息 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 | UC03.查询书籍信息 |
| FEAT09.记录外借情况 FEAT10.外借状态能够自动反应在书籍信息中 | UC04.登记外借信息 |
| FEAT11.按人、按书查询外借情况 FEAT12.列出所有的外借情况 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 | UC05.查询外借信息 |
| FEAT13.按特定时间段统计购买金额、册数 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 | UC06.统计金额和册数 |
绘制用例图
细化用例描述—搭框架
1.用例名称：新增书籍信息（UC01）
2.简要说明：录入新购书籍信息，并自动存储建档。
3.事件流：
3.1 基本事件流
3.2 扩展事件流
4.非功能需求
5.前置条件：用户进入图书管理系统。
6.后置条件：完成新书信息的存储建档。
7.扩展点：无
8.优先级：最高（满意度 5，不满意度5）
细化用例描述—细化内容
3.事件流：
3.1 基本事件流
1）图书管理员向系统发出“新增书籍信息”请求；
2）系统要求图书管理员选择要新增的书籍是计算机类还
是非计算机类；
3）图书管理员做出选择后，显示相应界面，让图书管理
员输入信息，并自动根据书号规则生成书号；
4）图书管理员输入书籍的相关信息，包括：书名、作者、
出版社、ISBN号、开本、页数、定价、是否有CDROM；
5）系统确认输入的信息中书名未有重名；
6）系统将所输入的信息存储建档。
3.2 扩展事件流
5a）如果输入的书名有重名现象，则显示出重名
的书籍，并要求图书管理选择修改书名或取消输入；
5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作；
5a2）图书管理员选择修改书名后，转到5）
4.非功能需求：无特殊要求
编写要点
•使用简单的语法：主语明确，语义易于理解；
•明确写出“谁控制球”：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；
•从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是从第三者观察的角度；
•显示过程向前推移：也就是第一步都有前进的感（例如，用户按下tab键作为一个事件就是不合适的）；
•显示参与者的意图而非动作（如果只描述了动作，人们不能够很容易地直接从事件流描述中理解用例）；
•包括“合理的活动集”（带数据的请求、系统确认、更改内部、返回结果）；
•用“确认”而非“检查是否”，例如“系统确认所输入的信息中书名未有重名”；
•可选择地提及时间限制；
•采用“用户让系统A与系统B交互”的习惯用语；
•采用“循环执行步骤x到y，直到条件满足”的习惯用语。
用例图应用说明
用例模型的运用方法
•增量开发的用例模型
•模型的无缝转换
建模要点
•构建结构良好的用例：
1）为系统和部分系统中单个的、可标识和合理的原子行为命名；
2）将公共的行为抽取出来，放到一个被包含用例中，再将它《include》进来；
3）对于变化部分，将其抽取出来，放到一个扩展用例（用《extent》连接）中；
4）清晰地描述事件流，使得读者能够轻而易举地理解
•构建结构良好的用例图：摆放元素时，应该避免交叉线的出现；对于语义上接近的行为和角色，最好使它们在物理上也更加接近；
•根据系统实际情况控制粒度
回顾
•首先从三种现代需求技术开始，引入了用例驱动开发过程的方法，并且详细地阐述了参与者和用例的概念
•结合了一个“棋牌馆管理系统”的用例图讲解了阅读用例图的方法，包括系统边界、包含关系、扩展关系以及泛化关系，并在此基础上介绍了用例描述的方法、格式及相关的要点
•绘制方法：从记录需求到识别参与者、合并需求生成用例到最后的细化用例描述，进行了详尽的描述与说明
•阐述了增量开发的用例模型、模型元素的无缝转换这两个重要观点
内容源自：UML 面向对象建模PPT