來源：http://space.itpub.net/118838/viewspace-483405
一、难点：
写 好用例就必须理解以下三个概念：
--范围 scope：真正被讨论的系统是什么？
--主执行者 primary actor： 谁有要实现的目标？
--层次 level： 目标泊层次是高，还是低？
经典，现在只体会到先确定范围和 主执行者才能提到描述用例，还要在沉淀。经验只能借鉴而不能照搬！！！！
转：
---------------------------
正体字为原文，斜体字 为本人见解
1、用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例描述了在不同 条件下，系统对某一项目相关人员的请求所作出的响应。
从文字上看，比较难理解，举个比较经典的例 子：某人在ATM机提款，这个本身就可以看作一个用例，只是它的层次比较高，细分下去，人可以在ATM上做什么？粗略一想，就有几条：(1)查询余额 (2)提款(3)转帐(4)存款，这四点都可以独立成为一个用例，而且执行者都是人，简单来说，用例就是描述执行者和系统之间的交互的集合。
2、 从根本上说，用例是文本形式；他们是作为人与人之间，尤其是没有受过专门培训的人员之间互相交流的一种手段。因此，简单的文本通常是编写用例的首选形式。
很 多人一看到“用例”这两个字就和用例图联系在一起，就是一个小人，一个椭圆，中间有线连接那种图，其实用例图只是用例的图形化表示，用例真正的内容体现在 它的文本描述中，而且描述的语言和平时人们日常写作的语言一样，一般有初中文化的人都看的懂。
3、 编写用例必须掌握的三个概念：
(1) 范围(scope)：真正被讨论的系统是什么？
(2) 主执行者(primary actor)：谁有要实现的目标？
(3) 层次(level)：目标的层次是高还是低？
范围很重要，这个和
项目管理 里 面的项目范围概念差不多，不过可能它的粒度小一点，有个可能一个用例只是一个项目的一小块功能交互，只有明确好范围，才能真正把握需求，但这个还需开发方 与客户不断的沟通才能确定。主执行者与项目管理的项目干系人有些联系，很多用例主执行者就是项目干系人中的一员。
4、 只有一个用例模板是不够的。至少要有两个用例模板：一个是非正式的（或称随意的），在要求不严的项目中使用；另一个是完整正式的，在要求严格的项目中使 用。
无论正式还是非正式，只要能使客户和开发人员能建立有效的沟通途径，就是好用例，只是有时候一 些项目要求比较严格，文档写的也比较正式而已。
5、如果把用例作为需求来编写，请
谨记以下两点 ：
(1) 用例确实是需求。不必将用例转变成行为需求的其他形式。
(2) 用例不是所有的需求。用例不详细地描述外部接口、数据格式、业务规则和复杂公式。
需求包含用例，用 例属于需求的一部分，这恰恰反应了：“用例不是万能的....”，下一句想必不用说都知道了吧，呵呵。
6、
用例仅仅是行为需求，并且是所有的行为需 求。
注意后半句
小结：这一章 主要是为用例定位，以及怎么样在不同的环境和时间安排下编写用例，使其达到最好的效果。
------------------------------------------------
二、基本定义：
执 行者 actor：任何具有行为的人或物。
项目相关人员 stakeholder ：对被讨论系统的行为有特定兴趣的人或物。
主 执行者 primary actor：启动与被讨论系统的一次交互活动，从而达到某一目标的人或物。
用例 use case：规定被讨论系统行为的契约。
范围 scope：界定被讨论的系统。
前置条件和保证 precondition and guarantee：在用例执行之前和之后必须满足的条件。
主成功场景 main success scenario：一切顺利的情况。
扩展 extension：场景执行过程中出现 的不同情况。
扩 展中的编号：是指在主成功场景中不同情况发生时所处的执行步骤号码（例如，步骤4a步骤4b是指主成功场景中步骤4的两种不同情况）
下 划线：当一个用例引用另一个用例时，被引用的用例加下划线。
----详细 格式 begin ------
用例名称：
通常为动宾词组，体现出对用户有价值的功能目标
类型：
BUC|BUCR|SUC
范 围：
写出具体的SuD名称
层次：
++|+|!|-|--
优先级：
High|Medium|Low
版 本：
当前版本
作者:
当前版本的作者
日期:
当前版本的日期
变更历史：
历史 版本号 (日期) 版本说明；变更事项 修订者
用例图： 说明此用例的 SuD 以及主要用角关系（主用角、次用角、辅用角）和用例关系（包含、扩展、继承）等
相关用例：
与此用例相关、存在重要联系的用 例
简述/背景：
说明此用例的主要目的，基本内容和相关背景
实现的特性：
依次列出此用例实现的主要系统特 性(Feature)
情节举例：
用具体的实例说明用例执行的一个情况。
主用角责权利：
主用角： 责权利
其他干系者责权利：
说明除主用角外，其他次用角、干系人、外部系统的责权利，所扮演的角色
干系者名 称：责权利
...
后置状态
与条件
最小保证：
无论用例执行成功或失败，系统对所有干系者作出的 最小/最起码的承诺
保证条件说明
成功保证：
用例目标成功达成后，系统为满足所有干系者的利益而作出的承诺，达到的 状态和满足的条件
成功状态名称：状态说明，应满足的条件
...
失败保证：
用例目标失败后，系统 为满足所有干系者的利益而作出的承诺，达到的状态和满足的条件
失败状态名称：状态说明，应满足的条件
...
前置状 态与条件：
用例开始执行前所处的状态和/或应满足的条件
状态名称：状态说明，条件说明
...
触发事 件：
触发用例从前置状态开始执行的事件
基本流：
说明一个最主要的成功执行路径
{名称标记}
步 骤编号 事件/步骤描述
...
公共流： 被此用例的其他动作流引用的公共步骤
{动作流名称}
{片 断名称标记}
步骤编号 事件/步骤描述
...
扩展流：
说明除基本流之外的其他成功流、 失败流和可选、替换流
{扩展名称标记}
扩展位置引用
扩展条件：
扩展处理
...
扩 展点：
此用例允许其他用例扩展插入的位置
扩展点名称 {扩展点在基本流、扩展流当中的位置}
技术和数据变化：
此 用例执行时，在技术和数据方面不同的做法
非功能需求：
(URPS+)
包括易用性、可靠性、性能、可维护性等方面的要求
业 务规则：
作用于此用例的各项业务约束
数据字段：
说明此用例中用到数据的字段名称、类型等细节，可与领域模型联系起 来
未决问题：
此用例当前存在的问题
备注：
其他任何需要说明、补充的事项
---- 详细 格式 end ------
三、例子
用例1：（符号）通过万维网购买股票
（注：这里的符号可以是“黑盒”符号，表示程序运行在与万维网相连的工作站上，表示所讨论的系统 是一个计算机系统，符号的使用完全可以根据个人的喜好来选择，但对范围和层次的标记却不是）
主 执行者：购买者
范围：私人顾问/金融包
层次：用户目标
项目相关人员和利益：
购买者----购买股票，并希望所买股票能自动被加到PAF记录中。
股票代理商----希望得到全部的购买信息。
前置 条件：用户已经打开PAF。
最小保证：有足够的登录信息，以便当出现问题时，PAF能够检测到问题，并要求用户提供更详细的信息。
成功保 证：远程web 站点认可此次购买事件；日志和用户记录被更新。
主 成功场景：
1、购买者选择通过万维网来购买股票。
2、PAF从用户那里得到所用站点的名称（如E*Trade、Schwab等）。
3、 PAF与该站点建立网络连接，并保持控制权。
4、购买者在该站点上浏览并购买股票。
5、PAF截取站点的响应信息，并更新购买者的记录。
6、 PAF向用户显示更新后的记录情况。
扩展：
2a、购买者要使用一个PAF不支持的站点：
2a1：系统从购买者那里获取新建议，带有取消用例的选项。
3a、在设置过程中，网络发生故障：
3a1：系统向购买者报告错误，并建议他退回到前一步。
3a2：购买者或者此用例，或者重新再试。
4a、计算机系统崩溃或者在 交易过程中被关掉：
4a1：（这时，我们该怎么办？）
4b、Web站点没有及时认可此次购买活动，而是把它推迟处理：
4b1：PAF把这次推迟事件记入日志，设置一个时钟，定期向购买者询问结果。
5a、Web站点没有返回关于购买情况的必要信息：
5a1：PAF把缺少信息的事件记入日志，要求购买者更新存有疑问的交易 。 |
下 面是用例网站公告发布的用例描述
用例名称：网站公告发布
用例标识号：202
参与者：负责人
简要说明：
负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的 首页上。
前置条件：
负责人已经登陆家教网站管理系统
基本事件流：
1． 负责人鼠标点击“修改公告”按钮
2． 系统出现一个文本框，显示着原来的公告内容
3． 负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告
4． 负责人编辑完文本框，按“提交”按钮，首页公告就被修改
5． 用例终止
其他事件流A1：
在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框 的任何修改内容都不会影响网站首页的公告
异常事件流：
1． 提示错误信息，负责人确认
2． 返回到管理系统主页面
后置条件：
网站首页的公告信息被修改
注释：无
例 子3
用例：
用例视图向外部用户展示了其捕获的系统、子系统、类 或者组件的行为。它将系统功能划分成对执行者和有意义的事物。而交互功能的部分被称作用例。
是 代表系统中各个项目相关人员之间就形态行为。所达成的契约。
编写用例必须掌握三个概念
- 范 围：真正被讨论的系统是什么？
- 主执行者：谁有要实现的目标？
- 层 次：目标的层次是高是低？
其它概念：
- 执 行者：任何具有行为的人或物
- 项 目相关人员：对被讨论的系统的行为有特定兴趣的人或物
- 主执行者：启动与被讨论系统得一次交互活动，从而达到 某一个目标的人或物
- 用例：规定被讨论系统行为的契约
- 范围：界 定被讨论的系统
- 前置条件和保证：在用例执行之前和之后必须满足的条件
- 主 成功场景：一切顺利的情况
- 扩展：场景执行过程中出现的不同情况
三 个命名的目标层次
1. 概 要层次
包含多个用户目标。在描述系统时，它们有如下三个方面的功能：
显示用户目标运行的语境
显示相关目标的生命周期顺序
为 低层用例（包括白色用例和蓝色用例）提供一个目录表。
2. 用 户目标级
它是主执行者努力使工作得以完成的目标，或是用户使用系统的目标。
3. 子 功能级
是指那些再实现用户目标时可能会被用到的目标。
用例模板
用例图只是简单地可视化描述系统，我们还需要对用例进行详细的说明。为了明确的描述用例我们需要一个用例模板，但是至今并没有统一的用例模板。用例模板的 内容一般包括：简要描述、前置条件、后置条件、基本事件流、备选事件流等等。
简要描述：对用例的角色、目的的简要描述。
前置条 件：执行用例之前系统必须要处于的状态，或者要满足的条件。
后置条件：用例一旦执行后系统所处的状态。
基本事件流：描述该用例的 基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流而只有最有可能发生的事件流。
备选事件流：表示这个行为或流程是可选的或 备选的，并不是总要总要执行它们。
下面是一个用例模板的示例：
用例： < 编号 >< 名 称 >
特 征信息：
用例在系统中的目标（用例目标描述）
范围（当前考虑的是哪个系统）
级别（概要任务 / 首 要任务 / 子功能）
前提条件（用例执行前系统用具有的状态）
成功后继条件（用例成功执行后应具有的状态）
失效后继条件（用例没有完成目标的状态）
首要角色（与该用例关联的首要角色）
触发（启动该用例执行的系统动作）
主 要步骤：
< 步骤编号 >< 动作描述 >
扩 展：
< 有变化情况的步 骤编号 >< 条件 >:< 动作或另外一个用例 >
变 异：
< 步骤或变化编号 >< 变异列表 >
相 关信息：（可选）
优先级（该用例对于系统组织 的关键程度）
性能目标（该 用例的执行时间耗费）
频 度（该用例被执行的频度）
从属用例：（可选）
下 属用例：
与首要角色的联系渠道（包括交互式、静态文件、数据库 等）
公 开问题：（可选）
9648
到【灌水乐园】发言
评论
#1楼 [楼主 ] 2006-11-07 22:09 王兴
用例名 称：
通常为动宾词组，体现出对用户有价值的功能目标
类型：
BUC|BUCR|SUC
范围：
写 出具体的SuD名称
层次：
++|+|!|-|--
优先级：
High|Medium|Low
版 本：
当前版本
作者:
当前版本的作者
日期:
当前版本的日期
变更历史：
历史 版本号 (日期) 版本说明；变更事项 修订者
用例图： 说明此用例的 SuD 以及主要用角关系（主用角、次用角、辅用角）和用例关系（包含、扩展、继承）等
相关用例：
与此用例相关、存在重要联系的用 例
简述/背景：
说明此用例的主要目的，基本内容和相关背景
实现的特性：
依次列出此用例实现的主要系统特 性(Feature)
情节举例：
用具体的实例说明用例执行的一个情况。
主用角责权利：
主用角： 责权利
其他干系者责权利：
说明除主用角外，其他次用角、干系人、外部系统的责权利，所扮演的角色
干系者名 称：责权利
...
后置状态
与条件
最小保证：
无论用例执行成功或失败，系统对所有干系者作出的 最小/最起码的承诺
保证条件说明
成功保证：
用例目标成功达成后，系统为满足所有干系者的利益而作出的承诺，达到的 状态和满足的条件
成功状态名称：状态说明，应满足的条件
...
失败保证：
用例目标失败后，系统 为满足所有干系者的利益而作出的承诺，达到的状态和满足的条件
失败状态名称：状态说明，应满足的条件
...
前置状 态与条件：
用例开始执行前所处的状态和/或应满足的条件
状态名称：状态说明，条件说明
...
触发事 件：
触发用例从前置状态开始执行的事件
基本流：
说明一个最主要的成功执行路径
{名称标记}
步 骤编号 事件/步骤描述
...
公共流： 被此用例的其他动作流引用的公共步骤
{动作流名称}
{片 断名称标记}
步骤编号 事件/步骤描述
...
扩展流：
说明除基本流之外的其他成功流、 失败流和可选、替换流
{扩展名称标记}
扩展位置引用
扩展条件：
扩展处理
...
扩 展点：
此用例允许其他用例扩展插入的位置
扩展点名称 {扩展点在基本流、扩展流当中的位置}
技术和数据变化：
此 用例执行时，在技术和数据方面不同的做法
非功能需求：
(URPS+)
包括易用性、可靠性、性能、可维护性等方面的要求
业 务规则：
作用于此用例的各项业务约束
数据字段：
说明此用例中用到数据的字段名称、类型等细节，可与领域模型联系起 来
未决问题：
此用例当前存在的问题
备注：
其他任何需要说明、补充的事项