本文来自我提供用例培训的PPT。本文内容包括
1.用例基本概念
2.用例的作用
3.从何处发现用例线索
4.如何发现用例
5.编写用例的准则
6.如何判断系统用例是否有效
1.用例基本概念
（1）需求分析（用例技术）、系统分析（OOA）、系统设计（OOD）、系统实现（OOP）
（2）用例的主要作用是：用来捕获系统的高层次（High Level）用户功能性需求
（3）用例从用户的视角描述了在逻辑上相对完整的一个功能流程。用例演示了人们如何使用系统。
（4）用例 VS 功能列表。
（5）用例最主要的价值在于：它强调了用户的目标和观点。
（6）用例表示法：用例图和用例文本
举例：POS系统处理销售用例图：
POS系统处理销售的用例文本：
1.顾客携带所购买的商品到达收银台。
2.收银员开始一次新的销售交易。
3.收银员输入商品条码。
4.系统逐条记录出售的商品，并显示该商品的描述、价格和累计金额。 价格通过一组价格规则来计算。
收银员重复3～4步，直到输入结束。
5.系统显示总额。
6.收银员告知顾客总额，并请顾客付款。
7.顾客付款，系统处理支付。
8.系统记录完整的销售信息，并将信息通知给帐务系统和库存系统。
9.系统打印票据。
10.顾客携带商品和票据离开。
（7）场景。
场景是用例执行的一条路径。
主（成功）场景、交替（扩展）场景
通常，一个用例包含一个主场景和多个（或0个）扩展场景。
用例的主场景不要超过十步。
用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。
2.用例的作用
在使用UML的整个软件开发过程中，用例处于一个中心地位。
（1）工作量的预估需要依据当前发现的用例。
（2）界面（UI）是在用例的辅助下进行设计
（3）很多类是根据用例来发现的
（4）用例的场景描述是创建时序图和协作图的依据。
（6）测试实例是根据用例来生成的
（7）整个开发的管理和任务分配，需要依据用例来进行组织
3.从何处发现用例线索
（1）蓝图文档。
（2）预排文档。
（3）域术语表。
（4）与域专家和终端用户会谈。
（5）功能规范和工作陈述。
4.如何发现用例
（1）确定谁会直接使用该系统。这些都是参与者
（2）选取其中一个参与者
（3）定义该参与者希望系统做什么。参与者希望系统做的每件事成为一个用例
（4）对每件事来说，参与者何时会使用系统，使用的过程中通常会发生什么，这就是用例的基本过程（主成功场景）
（5）描述该用例的基本过程。（此时，可能会发现更多的参与者）
（6）考虑一些可变情况，把他们创建为扩展场景。
（7）重复步骤2～6，以找出每一个用例。
5.编写用例的准则
（1）准则1：用例不是图形而是文本
用例建模的主要活动是编写文本，而非创建图形。唯有文本才可以完整地描述一个用例。
文本和图形是相互补充的两个方面，我们可以通过图形来快速浏览、检视所有用例，如果需要深入到一个用例的细节，则可以阅读相应的用例文本。
（2）准则2：以本质风格编写用例
例子：收银员登录
具体风格：比如界面上的TextBox、Button
本质风格：
a.收银员标志自己的身份
b.系统对此身份进行认证
编写用例时，需要屏除用户界面并且关注参与者的意图。以具体风格编写用例会造成对以后设计的潜在约束，如果没有这些约束，设计者能更自由地建立一个正确实现客观可见行为的系统，并为突破性方案的出现提供了可能性。
（3）准则3：编写黑盒用例
黑盒用例不对系统内部工作、构件或设计进行描述，相反，它通过职责来描述系统。
用例规定了系统必须做什么（行为和功能性需求），而不必决定系统如何去做（设计）。在用例建模中，应避免进行“如何”的决策。
（4）准则4：从参与者的角度来定义用例
面向用例的需求与传统的功能列表式需求之间最显著的区别在于actor ，系统之所以存在是因为actors 要通过与该系统进行交互来实现某些目标。
系统的视点＝》actor视点
（5）准则5：编写简洁的用例
6.如何判断系统用例是否有效
如果系统用例能通过下列三个测试，则表明该系统用例有效。
（1）老板测试 （避免用例的层次太低）
（2）EBP（基本业务过程）测试 （避免时间过长或过短、避免步骤过多或过少）
（3）规模测试 （避免规模过小或过大）