需求分析用例
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
功能 FR 非功能 NFR
What How
用例图
jpetstore System
浏览商店!
<<extend>> 下订单!
搜索商品!
<<extend>>
顾客 注册!
编辑账户! <<extend>>
查询订单!
用例图
用例图描述了系统的功能以及如何使用一 个系统 用例图显示谁将是相关的用户、用户希望 系统提供什么服务 用例图常用来描述系统以及子系统 帮助开发团队以一种可视化的方法理解系 统的功能需求
泛化关系（Generalization） 泛化关系是一般和特殊的关系
– 子用例表示父用例的特殊形式 – 子用例从父用例处继承行为和属性，还可 以添加行为或覆盖、改变继承的行为
泛化关系（Generalization）
同一业务目的（父用例）的不同技术实现（各个子用例）
包含关系（include）
在包含关系中，基本用例吸收了被包含的用 例的行为，如果没有后者它将是ห้องสมุดไป่ตู้完整的。 包含关系的特点
登录
身份验证
交钱
报销
用例之间的关系 用例与参与者之间有关联(association) 关系。 用例之间的关系有： –泛化(generalization) –包含(include) –扩展(extend)
关联关系（Association） 表示参与者在用例中的参与（也就是 参与者实例与用例实例之间的相互通 信） 不同的参与者可以访问相同的用例
用例的描述
• 用例描述是指对一个用例的功能进行的文字 描述，是参与者与系统交互动作序列的说明。 用例描述才是用例的主要部分, 是后续的 交互图分析和类图分析必不可少的部分.
用例描述采用自然语言和同一种语法形式— 一个简单的执行步骤描述参与者与系统的交 互行为，要易于理解。其读者是开发人员、 用户、项目经理、测试人员等。
用例的描述
用例的描述应包含的内容
–用例的目标 –用例是怎么启动的 –参与者和用例之间的消息是如何传送的 –用例中除了主路径外，其他路径是什么 –用例结束后的系统状态 –其他需要描述的内容
描述用例时的原则是尽可能写得“充分”,
而不是形式化、完整或漂亮。
用例的描述
描述项
用例描述 概述用例的几句话
说明
绘制正确的用例图
不要把步骤当用例
把执行者的动作当用例
把系统的活动当用例
要点：用例的粒度(1)
用例要有路径，路径要有步骤；而这一切 都是可观测的 最常犯错误：粒度过细，陷入功能分解
– 过细的粒度，一般都会导致技术语言的描述， 而不再是业务语言
用例粒度(2)
把步骤当用例
会员
<<include>>
输入用户名
“系统就是数据的增删改 查” 关心数据的存储和维护， 反而忽略了用户的目的
增加用户
修改用户
管理员
查询用户
删除用户
要点：用例的粒度(3)
如果确实是CRUD？ – 如果CRUD不涉及复杂的交互，一个用例“管理××” 即可 – 不管是C、R、U、D，都是为了完成“管理”目标 – 甚至很多种的基本数据管理都可以用一个用例表示
–指贯穿用例的一条单一路径，用于显示用例中的某 个特殊情况。 –脚本是用例的实例。 –每个用例都包括一个主要脚本和多个次要脚本。 –脚本用具体的文字描述来表示。
脚本
例：
–从绵阳去北京的过程可以有多种“场景”
坐飞机 – 订票、去机场、登机、… … 坐火车 – 买票、去车站、检票、… … 驾车 - … …
实例分析：语音邮箱系统（续）
1. 找出actor和外部系统，确定系统边界。
参与者：呼叫者、邮箱用户
2. 主要功能分析(参与者期望的系统行为等)
(1) 呼叫者保留信息(留言). (2) 邮箱用户管理信息：收听/存储/删除。 (3) 邮箱用户更改问候语。 (4) 邮箱用户更改密码。
实例分析：语音邮箱系统（续）
用例名称 表明用户的意图或用例的用途 参与者 与此用例相关的参与者
前臵条件 一个条件列表, 这些条件必须在访问用例前得到满足 后臵条件 一个条件列表, 这些条件必须在用例完成之后得到满足 基本路径 描述用例中各项工作都顺利进行时用例的工作方式 扩展 描述出现异常或发生错误的情况下的路径
脚本
脚本（scenario）
扩展关系（extend）
扩展用例被定义为基础用例的增量扩展
扩展关系是把新的行为加入到已有的用例 中去
扩展关系（extend）
扩展关系的特点 – 基础用例没有扩展用例也是完整的用例 – 基础用例被执行时，一般不会涉及扩展用 例，只有特定的条件发生，扩展用例才可 能被执行，这是与包含关系的差别
几种关系的比较
用例图的组成
用例图包含 6 个元素 – 参与者（Actor） – 用例（Use Case） – 关联关系（Association） – 包含关系（Include） – 扩展关系（Extend） – 泛化关系（Generalization）
参与者
• 参与者是指系统以外的、需要使用系统或与系 统交互的事物，包括：人、设备、外部系统等。
基于用例的需求建模方法
1 用例图是由哪些要素组成的？ 2 用例之间有什么样的关系？ 3 怎样描述用例？ 4 怎样撰写需求文档？
基于用例的需求建模方法
采用“基于用例的方法”来识别和获 取需求，是从外部的角度来看系统功能， 建立系统的用例模型。整个工作的焦点集 中在 从用户的角度 说明 系统能够干什么 ， 完全不考虑具体的实现细节 ，从而达到准 确地理解客户需求的目的。
什么是用例？
针对某个特定的外部用角，系统通过与其交互 而执行的，能够产生可观测的、有价值的结果 的一个动作序列。 • 例：“到数据库取某字段”对客户是不可理 解和验证的。 • 例：登录系统和输入密码哪个是有效的用例？
如何表示用例？
• UML中用例用椭圆表示。 • 用例命名的基本原则是：
– 从参与者的角度出发进行命名 – 使用动词加宾语的结构，尽量使用行业术语
语音邮箱系统----用例描述
用例4: 接收信息 参与者：邮箱用户 前臵条件：邮箱用户完成登录操作. 后臵条件：语音邮件系统播放信息 基本路径： 1. 邮箱用户选择 “接收信息”菜单选项. 2. 语音邮件系统播放信息菜单: 按1收听当前信息; 按2存储当前信息; 按3删除当前信息; 按4返回邮箱菜单. 3. 邮箱用户选择“收听当前信息”菜单选项. 4. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信 息.(注意: 只播放,不删除) 5. 语音邮件系统播放信息菜单. 6. 用户选择”删除当前信息”,则信息被永久删除. 7. 继续执行第3步.
语音邮箱系统----用例描述
用例2: 保留信息 参与者：呼叫者 前臵条件：呼叫者完成邮箱号输入操作 后臵条件：语音邮件系统将记录的信息存放在接收者的邮 箱中 基本路径： 1.呼叫者说出信息. 2.呼叫者挂断电话. 3.系统将记录的信息存放在接收者的邮箱中
语音邮箱系统----用例描述
用例3: 登录系统 参与者：邮箱用户 前臵条件：邮箱用户完成邮箱号输入操作 后臵条件：语音邮件系统播放邮箱菜单 基本路径： 1.邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同) 2.语音邮件系统播放邮箱菜单: 按1键接收信息. 按2键更改密码. 按3键更改问候语. 扩展路径： 1a.密码输入错误 1a1.语音提示错误，请重新输入密码 1a2.返回1
语音邮箱系统----用例描述
扩展路径: 6a.用户选择“存储当前信息”. 6a1. 当前信息从新信息队列中删除并添 加到旧信息队列中.
理清责任
书写用例文档
ATM系统“取款”用例的两个错误描述：
Use case: Withdraw cash
Actor: customer 主事件流：
Use case: Withdraw cash
关系类型 说明 表示符号
关联
泛化 包含 扩展
actor与use case 之间
actor之间或use case之间 use case之间 use case之间
实例分析：语音邮箱系统
目标：构建一个语音邮箱系统 问题描述： 语音邮箱系统中，可以为每个系统用户(邮箱主人)分配 一个语音邮箱号码。 进行留言时, 拨打语音邮箱系统的主号码，在听到提示 音“请输入邮箱号”后，输入语音邮箱号，听到主人设定的 问候语后，进行留言然后挂断电话。 邮箱主人拨打语音邮箱系统的主号码，在听到提示音 “请输入邮箱号”后，输入语音邮箱号，听到主人设定的问 候语后，输入密码+#进行邮箱管理。此时系统提供三种服务： 1.接收信息；2.更改问候语；3.更改密码。其中接收留言包 括收听新留言、存储留言、删除留言等。
会员
登录
验证用户名和密码
把系统活动当用例
<<include>> 建立数据库连接 <<include>> 查询订单 执行SQL语句
要点：用例的粒度(2)
“四轮马车”
– C(Create) R(Read) U(Update) D(Delete) – 所有业务最终对会成为 CRUD？ – CRUD能为Actor提供价值？ – CRUD掩盖业务，锐变成关 系数据库的建模：
如何识别系统的参与者
– 谁将使用该系统的主要功能 – 谁将需要该系统的支持以完成其工作 – 谁将需要维护、管理该系统系统需要处理哪些硬 件设备 – 与该系统交互的是什么系统 – 谁或什么系统对本系统产生的结果感兴趣
参与者间的关系
参与者是类，所以参与者之间可以具有类之间 的关系在用例图中，使用泛化关系来描述多个 参与者之间的公共行为。
管理员
管理用户
绘制正确的用例图
什么是完整的用例图 一个完整的用例图至少由三个部分组成：
•一个角色
•一个地方
•一件事情
比如描述一次网上购物，完整的用例图至少
要包括“登录”，“检索”，“加入购物车”、
和“付款”。
UML用例图——绘图的建议
防止过度图形化 用例的重点在于书写文本，而不是图 和用例关系，不要花很多小时甚至几 天讨论用例图和用例关系
–用例：订货
脚本1：订货进行顺利的脚本 脚本2：相关货源不足的脚本 脚本3：涉及购货者的信用卡被拒的脚本
语音邮箱系统----用例描述
用例1: 拨打邮箱号 参与者：呼叫者 前臵条件：呼叫者访问语音邮件系统 后臵条件：语音邮件系统发出问候语 基本路径： 1. 呼叫者拨打语音邮件系统的主号码. 2. 语音邮件系统发出提示音：输入邮箱号码并加#号. 3. 呼叫者输入接收者的邮箱号. 4. 语音邮件系统发出问候语：已进入XX的邮箱,请留言.
3. 初步找到的用例
呼叫者：保留信息 邮箱主人：接收信息、更改问候语、更改密码
4. 进一步寻找用例
邮箱主人：登录邮箱 呼叫者、邮箱主人：拨打邮箱号码
5. 分析用例之间的关系
本例较为简单,只使用“包含关系”即可。
实例分析：语音邮箱系统（续） 6. 绘制初步用例图
绘制正确的用例图
用例是有意义的目标
绘制正确的用例图
Actor: customer 主事件流：
(1)储户插入ATM卡,并输入密码
• ATM系统获得ATM卡和密码
设置交易类型为“取款” ATM系统获得取款金额 输出现金、收据和ATM卡 系统复位 只描述了System的行为
(2)储户按“取款”按钮,并输入取款 • 数目 • (3)储户取走现金/ATM卡/收据 • (4)储户离开 • 只描述了actor的行为
–包含用例执行，则被包含用例必须执行
包含关系（include）
什么时候使用包含关系？ 如果两个以上的用例有大量一致的功能，则 可以将这个功能分解到另一个用例中，实现 功能代码的复用。其他用例可以和这个用例 建立包含关系；
包含关系使得我们在一个用例中局部化多个 用况中共同的活动序列。这样，可以避免多 次描述同一事件流；当这个共同的序列发生 变化时，这样就显现出优势，即只需要在一 个地方进行改动。
出纳员
吃饭
• 系统需要处理的，由系统生成
绘制正确的用例图
用户的观点而非系统的观点
绘制正确的用例图
用例命名规则
命名用例一般是用“动词+名词”的方式，但要注意动词 要选择有实际意义的词，而不要用一些对理解用例没
有帮助的词。
比如不要用这些动词：进行、使用、复制、加载、重 复„„ 可以使用：检索、打印、查询„„ 名词不要选择那些意义不明确的词：数据、报表、表 格、表单、系统„„ 而应该用：成绩单、订单、零件„„
书写用例文档
Use case: Withdraw cash
Actor: customer
主事件流： • 储户通过读卡机插入ATM卡
What How
用例图
jpetstore System
浏览商店!
<<extend>> 下订单!
搜索商品!
<<extend>>
顾客 注册!
编辑账户! <<extend>>
查询订单!
用例图
用例图描述了系统的功能以及如何使用一 个系统 用例图显示谁将是相关的用户、用户希望 系统提供什么服务 用例图常用来描述系统以及子系统 帮助开发团队以一种可视化的方法理解系 统的功能需求
泛化关系（Generalization） 泛化关系是一般和特殊的关系
– 子用例表示父用例的特殊形式 – 子用例从父用例处继承行为和属性，还可 以添加行为或覆盖、改变继承的行为
泛化关系（Generalization）
同一业务目的（父用例）的不同技术实现（各个子用例）
包含关系（include）
在包含关系中，基本用例吸收了被包含的用 例的行为，如果没有后者它将是ห้องสมุดไป่ตู้完整的。 包含关系的特点
登录
身份验证
交钱
报销
用例之间的关系 用例与参与者之间有关联(association) 关系。 用例之间的关系有： –泛化(generalization) –包含(include) –扩展(extend)
关联关系（Association） 表示参与者在用例中的参与（也就是 参与者实例与用例实例之间的相互通 信） 不同的参与者可以访问相同的用例
用例的描述
• 用例描述是指对一个用例的功能进行的文字 描述，是参与者与系统交互动作序列的说明。 用例描述才是用例的主要部分, 是后续的 交互图分析和类图分析必不可少的部分.
用例描述采用自然语言和同一种语法形式— 一个简单的执行步骤描述参与者与系统的交 互行为，要易于理解。其读者是开发人员、 用户、项目经理、测试人员等。
用例的描述
用例的描述应包含的内容
–用例的目标 –用例是怎么启动的 –参与者和用例之间的消息是如何传送的 –用例中除了主路径外，其他路径是什么 –用例结束后的系统状态 –其他需要描述的内容
描述用例时的原则是尽可能写得“充分”,
而不是形式化、完整或漂亮。
用例的描述
描述项
用例描述 概述用例的几句话
说明
绘制正确的用例图
不要把步骤当用例
把执行者的动作当用例
把系统的活动当用例
要点：用例的粒度(1)
用例要有路径，路径要有步骤；而这一切 都是可观测的 最常犯错误：粒度过细，陷入功能分解
– 过细的粒度，一般都会导致技术语言的描述， 而不再是业务语言
用例粒度(2)
把步骤当用例
会员
<<include>>
输入用户名
“系统就是数据的增删改 查” 关心数据的存储和维护， 反而忽略了用户的目的
增加用户
修改用户
管理员
查询用户
删除用户
要点：用例的粒度(3)
如果确实是CRUD？ – 如果CRUD不涉及复杂的交互，一个用例“管理××” 即可 – 不管是C、R、U、D，都是为了完成“管理”目标 – 甚至很多种的基本数据管理都可以用一个用例表示
–指贯穿用例的一条单一路径，用于显示用例中的某 个特殊情况。 –脚本是用例的实例。 –每个用例都包括一个主要脚本和多个次要脚本。 –脚本用具体的文字描述来表示。
脚本
例：
–从绵阳去北京的过程可以有多种“场景”
坐飞机 – 订票、去机场、登机、… … 坐火车 – 买票、去车站、检票、… … 驾车 - … …
实例分析：语音邮箱系统（续）
1. 找出actor和外部系统，确定系统边界。
参与者：呼叫者、邮箱用户
2. 主要功能分析(参与者期望的系统行为等)
(1) 呼叫者保留信息(留言). (2) 邮箱用户管理信息：收听/存储/删除。 (3) 邮箱用户更改问候语。 (4) 邮箱用户更改密码。
实例分析：语音邮箱系统（续）
用例名称 表明用户的意图或用例的用途 参与者 与此用例相关的参与者
前臵条件 一个条件列表, 这些条件必须在访问用例前得到满足 后臵条件 一个条件列表, 这些条件必须在用例完成之后得到满足 基本路径 描述用例中各项工作都顺利进行时用例的工作方式 扩展 描述出现异常或发生错误的情况下的路径
脚本
脚本（scenario）
扩展关系（extend）
扩展用例被定义为基础用例的增量扩展
扩展关系是把新的行为加入到已有的用例 中去
扩展关系（extend）
扩展关系的特点 – 基础用例没有扩展用例也是完整的用例 – 基础用例被执行时，一般不会涉及扩展用 例，只有特定的条件发生，扩展用例才可 能被执行，这是与包含关系的差别
几种关系的比较
用例图的组成
用例图包含 6 个元素 – 参与者（Actor） – 用例（Use Case） – 关联关系（Association） – 包含关系（Include） – 扩展关系（Extend） – 泛化关系（Generalization）
参与者
• 参与者是指系统以外的、需要使用系统或与系 统交互的事物，包括：人、设备、外部系统等。
基于用例的需求建模方法
1 用例图是由哪些要素组成的？ 2 用例之间有什么样的关系？ 3 怎样描述用例？ 4 怎样撰写需求文档？
基于用例的需求建模方法
采用“基于用例的方法”来识别和获 取需求，是从外部的角度来看系统功能， 建立系统的用例模型。整个工作的焦点集 中在 从用户的角度 说明 系统能够干什么 ， 完全不考虑具体的实现细节 ，从而达到准 确地理解客户需求的目的。
什么是用例？
针对某个特定的外部用角，系统通过与其交互 而执行的，能够产生可观测的、有价值的结果 的一个动作序列。 • 例：“到数据库取某字段”对客户是不可理 解和验证的。 • 例：登录系统和输入密码哪个是有效的用例？
如何表示用例？
• UML中用例用椭圆表示。 • 用例命名的基本原则是：
– 从参与者的角度出发进行命名 – 使用动词加宾语的结构，尽量使用行业术语
语音邮箱系统----用例描述
用例4: 接收信息 参与者：邮箱用户 前臵条件：邮箱用户完成登录操作. 后臵条件：语音邮件系统播放信息 基本路径： 1. 邮箱用户选择 “接收信息”菜单选项. 2. 语音邮件系统播放信息菜单: 按1收听当前信息; 按2存储当前信息; 按3删除当前信息; 按4返回邮箱菜单. 3. 邮箱用户选择“收听当前信息”菜单选项. 4. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信 息.(注意: 只播放,不删除) 5. 语音邮件系统播放信息菜单. 6. 用户选择”删除当前信息”,则信息被永久删除. 7. 继续执行第3步.
语音邮箱系统----用例描述
用例2: 保留信息 参与者：呼叫者 前臵条件：呼叫者完成邮箱号输入操作 后臵条件：语音邮件系统将记录的信息存放在接收者的邮 箱中 基本路径： 1.呼叫者说出信息. 2.呼叫者挂断电话. 3.系统将记录的信息存放在接收者的邮箱中
语音邮箱系统----用例描述
用例3: 登录系统 参与者：邮箱用户 前臵条件：邮箱用户完成邮箱号输入操作 后臵条件：语音邮件系统播放邮箱菜单 基本路径： 1.邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同) 2.语音邮件系统播放邮箱菜单: 按1键接收信息. 按2键更改密码. 按3键更改问候语. 扩展路径： 1a.密码输入错误 1a1.语音提示错误，请重新输入密码 1a2.返回1
语音邮箱系统----用例描述
扩展路径: 6a.用户选择“存储当前信息”. 6a1. 当前信息从新信息队列中删除并添 加到旧信息队列中.
理清责任
书写用例文档
ATM系统“取款”用例的两个错误描述：
Use case: Withdraw cash
Actor: customer 主事件流：
Use case: Withdraw cash
关系类型 说明 表示符号
关联
泛化 包含 扩展
actor与use case 之间
actor之间或use case之间 use case之间 use case之间
实例分析：语音邮箱系统
目标：构建一个语音邮箱系统 问题描述： 语音邮箱系统中，可以为每个系统用户(邮箱主人)分配 一个语音邮箱号码。 进行留言时, 拨打语音邮箱系统的主号码，在听到提示 音“请输入邮箱号”后，输入语音邮箱号，听到主人设定的 问候语后，进行留言然后挂断电话。 邮箱主人拨打语音邮箱系统的主号码，在听到提示音 “请输入邮箱号”后，输入语音邮箱号，听到主人设定的问 候语后，输入密码+#进行邮箱管理。此时系统提供三种服务： 1.接收信息；2.更改问候语；3.更改密码。其中接收留言包 括收听新留言、存储留言、删除留言等。
会员
登录
验证用户名和密码
把系统活动当用例
<<include>> 建立数据库连接 <<include>> 查询订单 执行SQL语句
要点：用例的粒度(2)
“四轮马车”
– C(Create) R(Read) U(Update) D(Delete) – 所有业务最终对会成为 CRUD？ – CRUD能为Actor提供价值？ – CRUD掩盖业务，锐变成关 系数据库的建模：
如何识别系统的参与者
– 谁将使用该系统的主要功能 – 谁将需要该系统的支持以完成其工作 – 谁将需要维护、管理该系统系统需要处理哪些硬 件设备 – 与该系统交互的是什么系统 – 谁或什么系统对本系统产生的结果感兴趣
参与者间的关系
参与者是类，所以参与者之间可以具有类之间 的关系在用例图中，使用泛化关系来描述多个 参与者之间的公共行为。
管理员
管理用户
绘制正确的用例图
什么是完整的用例图 一个完整的用例图至少由三个部分组成：
•一个角色
•一个地方
•一件事情
比如描述一次网上购物，完整的用例图至少
要包括“登录”，“检索”，“加入购物车”、
和“付款”。
UML用例图——绘图的建议
防止过度图形化 用例的重点在于书写文本，而不是图 和用例关系，不要花很多小时甚至几 天讨论用例图和用例关系
–用例：订货
脚本1：订货进行顺利的脚本 脚本2：相关货源不足的脚本 脚本3：涉及购货者的信用卡被拒的脚本
语音邮箱系统----用例描述
用例1: 拨打邮箱号 参与者：呼叫者 前臵条件：呼叫者访问语音邮件系统 后臵条件：语音邮件系统发出问候语 基本路径： 1. 呼叫者拨打语音邮件系统的主号码. 2. 语音邮件系统发出提示音：输入邮箱号码并加#号. 3. 呼叫者输入接收者的邮箱号. 4. 语音邮件系统发出问候语：已进入XX的邮箱,请留言.
3. 初步找到的用例
呼叫者：保留信息 邮箱主人：接收信息、更改问候语、更改密码
4. 进一步寻找用例
邮箱主人：登录邮箱 呼叫者、邮箱主人：拨打邮箱号码
5. 分析用例之间的关系
本例较为简单,只使用“包含关系”即可。
实例分析：语音邮箱系统（续） 6. 绘制初步用例图
绘制正确的用例图
用例是有意义的目标
绘制正确的用例图
Actor: customer 主事件流：
(1)储户插入ATM卡,并输入密码
• ATM系统获得ATM卡和密码
设置交易类型为“取款” ATM系统获得取款金额 输出现金、收据和ATM卡 系统复位 只描述了System的行为
(2)储户按“取款”按钮,并输入取款 • 数目 • (3)储户取走现金/ATM卡/收据 • (4)储户离开 • 只描述了actor的行为
–包含用例执行，则被包含用例必须执行
包含关系（include）
什么时候使用包含关系？ 如果两个以上的用例有大量一致的功能，则 可以将这个功能分解到另一个用例中，实现 功能代码的复用。其他用例可以和这个用例 建立包含关系；
包含关系使得我们在一个用例中局部化多个 用况中共同的活动序列。这样，可以避免多 次描述同一事件流；当这个共同的序列发生 变化时，这样就显现出优势，即只需要在一 个地方进行改动。
出纳员
吃饭
• 系统需要处理的，由系统生成
绘制正确的用例图
用户的观点而非系统的观点
绘制正确的用例图
用例命名规则
命名用例一般是用“动词+名词”的方式，但要注意动词 要选择有实际意义的词，而不要用一些对理解用例没
有帮助的词。
比如不要用这些动词：进行、使用、复制、加载、重 复„„ 可以使用：检索、打印、查询„„ 名词不要选择那些意义不明确的词：数据、报表、表 格、表单、系统„„ 而应该用：成绩单、订单、零件„„
书写用例文档
Use case: Withdraw cash
Actor: customer
主事件流： • 储户通过读卡机插入ATM卡