定义：参与者、场景和用例
[b]参与者[/b]是某些具有行为的事物，可以是人、计算机系统或组织，例如收银员。
[b]场景[/b]是参与者和系统之间的一系列特定的活动和交互，也称为用例实例。场景是使用系统的一个特定情节或用例的一条执行路径。例如，使用现金成功购买商品的场景，或者由于信用卡付款被拒绝造成的购买失败场景。
[b]用例[/b]就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。
用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。
用例的主要思想是：为功能性需求编写用例，从而降低详细的老式特性列表的重要性或减少这种列表的使用。
定义：参与者的三种类型
主要参与者：具有用户目标，并通过使用SuD的服务完成。例如，收银员。
为何确定主要参与者？发现驱动用例的用户目标。
协作参与者：为SuD提供服务（录入，信息服务）。自动付费授权服务即是一例。协助参与者通常是计算机系统，但也可以是组织或人。
为何确定协助参与者？为了明确外部接口和协议。
幕后参与者：用例行为中具有影响或利益，但不是主要或协助参与者。例如，税收机构。
为何要确定幕后参与者？这是为了确保确定并满足所有必要的重要事物。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。
表示法：用例的三种常用格式：
摘要——简洁的一段式概要，通常用于主成功场景。
何时使用：在早期需求分析过程中，为快速了解主题和范围。可能只需要几分钟进行编写。
非正式——非正式的段落格式。用几个段落覆盖不同场景。
何时使用：同上。
详述——详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。
何时使用？确定并以摘要形式编写大量用例后，在第一次需求研讨会中，详细地编写其中少量（10%）的具有重要架构意义的高价值的用例。
用例书写范例p50-p55
如何发现用例
1. 选择系统边界。
2. 确定主要参与者——通过使用系统的服务实现其目标的那些人或事物。
3. 确定每个主要参与者的目标。
4. 定义满足用户目标的用例，根据其目标对用例命名。
什么样的问题有助于寻找参与者和目标
除明显的主要参与者和目标外，下列问题有助于确定其他可能会遗漏的参与者目标：
谁来启动和停止系统。
谁来完成用户管理和安全管理？
谁来完成系统管理？
时间是参与者吗？因为系统要响应时间事件而完成某些活动。
当系统失败时，是否存在监控进程将系统重新启动。
软件升级是如何处理的？是推模式还是拉模式？
除了人作为主要参与者之外，还有其他外部的软件或自动机器系统调用该系统的服务吗？
谁来考察系统活动或性能？
系统发生错误或故障时应通知谁？
用例名称应该使用动词开头。
什么样的测试有助于发现有用的用例
老板测试，EBP测试，规模测试。
老板测试
你的老板问：“你整天都做了什么？”你回答：登录系统。你的老板肯定不会高兴。
EBP测试
EBP即给予业务过程，是源于业务过程工程领域的术语：
一个人于某个时刻在一个地点所执行的任务，用以响应业务事件。该任务能够增加可量化的业务价值，并且以持久状态留下数据，例如，批准信用卡的信用额或者确定订购的价格。
规模测试(略)