基于用例的需求分析

界面类 控制类
实体类
开发过程的用例
在迭代过程中分析每个用例，考虑实现该用例需要哪些分
析类元和关联，这些类元之间的协作实现了该用例。
分析每个分析类元在一个用例实现中扮演的角色，类元角
色详细说明了该类元参与实现某个用例的职责和属性等。
细化分析类，将其转化为一个或多个设计类，并将其职责
和属性重新进行分类。
李杭 2009年3月
议题
前言 什么是用例？ 完整的用例格式 用例的核心要素 需求分析中的用例 开发过程中的用例 讨论
前言之一
软件开发过程中常见的场景
这个做还不错，不过 好像不是我想要的。 你这做的是什么 东西！
我们这很混乱，你这 个系统应该把我们的 所有问题全部解决掉！
我们的口号是：
由表及里，逐步求精！
轻松一刻，讨论一下
？
用例规定了一个动作序列（可以有多种实现），系统可以执行这些动作并
产生出一个对于特定参与者有价值的可见结果。
在系统层，用例表示整个系统对外部用户可见的行为。一个用例就像外部
用户可使用的系统操作。 主事件流
异常事件流 扩展事件流
用例的示例
ATM取款用例

储户将信用卡插入ATM，系统要 求银行储户提供密码。
用例是代表系统中各个相关人员之间就系统的行为所达
成的契约。用例描述了不同条件下，系统对某一相关人
员的请求所做出的响应。提出请求的相关人员叫主执行 者(Primary Actor)。主执行者通过发起与系统的一次交
互来实现某个目标。系统对任一执行者所做出的响应，
要保证所有相关人员的利益不受侵害。
用例的本质是文本的。
触发事件：什么引发了用例的执行，包括时间事件。
主成功场景： 扩展场景： 业务规则： 相关信息：包括优先级、执行频率、非功能需求、待定问题等等。
用例中的核心要素
范围（SCOPE）：真正要讨论的系统是什么？ 主执行者（Primary Actor）：谁有要实现的目标？ 层次（Level）：目标的层次是高，还是低？
“弱弱”地问：“您 到底想要什么？”
前言之二
需求分析与管理—软件开发过程中的“永远的痛”
来自百度文库
前言之二
应对之利器：结构化分析方法（数据流图、IDEF
（Integrated Computer－Aided Manufacturing Definition Language ）
什么是用例？
UML中的定义
用例示例
完整的用例模板
用例名：用主动语态动词短语表示的目标 使用语境：该用例的上下文环境 范围：设计范围，将系统作为一个黑盒来考虑 级别：概要（业务用例）、用户目标（系统用例）和子功能 主执行者：角色名称或描述 项目相关人员和利益：用例中的项目相关人员和关键利益列表 前置条件： 最小保证：在所有操作退出前，至少应达到的要求。 成功保证：在成功后，应达到的状态。
系统级
业务级（概要级）
需求分析中的用例
用例的局限性
适合于描述具有交互性的功能性需求 不适合描述数据变换和科学计算性质的需求
需求规格说明书中的功能需求可以采用用例
需求分析中的用例
实体关系 模型 外部接口
…
用例
UI需求
维护和可 移植性需 求 安全需求
性能需求
开发过程中的用例
用例 模型 《跟踪》 分析 模型 《跟踪》 设计 模型

储户输入密码，系统验证用户密 码正确后，允许用户进入系统。

储户输入取款金额，系统验证该 账户金额大于或等于取款金额后， 提供给储户相应金额的现金，并
问题：为什么要写系统验证账 户金额的过程？
在该账号上扣除相应的金额。
用例之间的关系
扩展关系
包含关系
泛化关系
什么是用例？
Alistair Cockburn的定义