用例

示例

用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。一下是摘要形式用例的示例：

处理销售：顾客携带所购商品到达收银台。收银员使用POS系统记录每件商品。系统连续现实累计总额，并逐行现实细目。顾客输入支付信息，系统对支付信息进行验证和记录。系统更新库存信息。永康从系统得到购物小票，然后携带商品离开。

注意：上述用例不是图像，而是文本。

定义：参与者、场景和用例

参与者是某些具有行为的事物，可以是人、计算机系统或组织。

场景是参与者和系统之间的一系列特定的活动和交互，也用为用例实例。场景是使用系统的一个特定情节或用例的一条执行路径。

用例就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。

处理退货
主成功场景：顾客携带商品到收银台退货，收银员使用POS系统记录并处理每件退货...
交替场景：
如果客户之前用信用卡付款，而其信用卡账户退还交易被拒绝，则告知顾客并使用现金退款。
如果在系统中未查找到该商品的标识码，则提示收银员并建议手工输入标识码（可能标识码已经损坏）。
如果系统检测到与外部记账系统通信失败，则...

RUP的用例定义：一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对某个参与者而言可观察的返回值。

用例和用例模型

用例模型是所有书面用例的集合；同时，它是系统功能性和缓解的模型。

用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。

用例模型在UP中不是唯一的需求制品。其他制品还有补充性规格说明、词汇表、设想和业务规则。

用例模型还可以包含UML用例图，以现实用例和参与者的名称及其关系。UML用例图可以为系统及其缓解提供良好的语境图，也为按名称列出用例提供了快捷方式。

用例是经典OOA/D的关键需求输入。

动机：为什么使用用例

用例是一种优秀的方法，使领域专家或需求提供者子集编写用例称为可能，并使这项工作难度降低。

用例的另一个价值使强调了用户的目标和观点。

定义：用例是功能性需求吗

用例就是需求，主要使说明系统如何工作的功能性或行为型需求。

定义：参与者的三种类型

参与者使任何具有行为的事物，在所讨论系统（System under Discussion， SuD）调用其他系统的服务时，还包括其自身。相对于SuD，有三种外部参与者：

主要参与者：具有用户目标，并通过使用SuD的服务完成。
- 为何要确定主要参与者？发现驱动用例的用户目标。
协助参与者：为SuD提供服务。
- 为何确定协助参与者？为了明确外部接口和协议。
幕后参与者：在用例行为中具有影响或利益，但不是主要或协助参与者。
- 为何要确定模糊参与者？这是为了确保确定并满足所有必要的重要事物。

表示法：用例的三种常用形式

用例能够以不同形式化程度或格式进行编写：

摘要：简洁的一段式概要，通常用于主成功场景。
- 何时使用？在早期需求分析过程中，为快速了解主题和范围。
非正式：非正式的段落格式。用几个锻炼覆盖不同场景。
- 何时使用？同上。
详述：详细编写所有步骤及各种变化，同时具有补充部分，如果前置条件和成功保证。
- 何时使用？确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量的具有重要架构意义和高价值的用例。

示例：详述风格的处理销售

详述用例时结构化的，它展示了更多细节，并且更为深入。

在迭代和进化式UP需求分析中，第一次需求讨论会应该以这种形式编写10%的关键用例。随后，对这10%中最具有重要架构意义的用例或场景进行设计和编程。

用例名称：以动词开始。
范围：要设计的系统。
级别：”用户目标“或者是”子功能“。
主要参与者：调用系统，使之交付服务。
涉众及其关注点：关注该用例的人，及其需要。
前置条件：值得告知读者的，开始前必须为真的条件。
成功保证：值得告知读者的，成功完成必须满足的条件。
主成功场景：典型的、无条件的、理想方式的成功场景。
扩展：成功或失败的替代场景。
特殊需求：相关的非功能性需求
技术和数据变元表：不同的I/O方法和数据格式。
发生频率：影响对实现的调查、测试和时间安排。
杂项：例如未决问题。

用例UC1：处理销售

范围：NextGEn POS应用

级别：用户目标

主要参与者：收银员

涉众及其关注点：
- 收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水中扣除。
- 售货员：希望自动更新销售提成。
- 顾客：希望以最小代价完成改名活动并得到快速服务。希望边界、清晰地看到所输入的商品项目和架构。希望得到狗阿米凭证，以便退货。
- 公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票价。希望有一定的容错性，即使在某些服务器构件不可用时（如原创信用卡验证）。也能够完成销售。希望能够自动、快速地更新账户和库存信息。
- 经理：希望能够快速执行超控操作，并已于更正收银员的不当操作。
- 政府税收代理：希望能从每笔交易中抽取税金。可能存在多级税务代理，比如国家级、洲级和县级。
- 支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。

前置条件：收银员必须经过确认和认证。

成功保证（或后置条件）：存储销售信息。准确计算税金。更新账务和库存信息。记录提成。生成票价。记录支付授权的批准。

主成功场景（或基本流程）：
1. 顾客携带所购商品或服务到收银台通过POS机付款。
2. 收银员开始一次新的销售交易。
3. 收银员输入商品条码。
4. 系统逐条记录出售的商品，并现实该商品的描述、架构和累计额。价格通过一组价格规则来计算。
收银员重复3-4步，直到输入结束。
5. 系统显示总额和所计算的税金。
6. 收银员告知客户总额，并请顾客付款。
7. 顾客付款，系统处理支付。
8. 系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。
9. 系统打印票据。
10. 顾客迭代商品和票据离开（如果有）。

扩展（或替代流程）：
*a. 经理在任意时刻要求进行超控操作：
    1. 系统进入经理授权模式。
    2. 经理或收银员执行某一经理模式的操作。例如，变更现金结余，回复其他登录着中断的销售交易，取消销售交易等。
    3. 系统回复到收银员的授权模式。
*b. 系统在任意时刻失败：为了支持回复和更正账务处理，要保证所有交易的敏感状态和事件都能够从场景的任何一步中完全恢复。
    1. 收银员重启系统，登录，请求回复上次状态。
    2. 系统重建上次状态。
        2a. 系统在恢复过程中检测到一场：
            1. 系统向收银员提示错误，记录此错误，并进入一个初始状态。
            2. 收银员开始一次新的销售交易。
1a. 客户或经理需要恢复一个中断的交易。
    1. 收银员执行恢复操作，并且输入ID以提取对应的销售交易。
    2. 系统现实被恢复的销售交易状态及其小计。
        2a. 未发现对应的销售交易。
            1. 系统向收银员提示错误。
            2. 收银员可能会开始一个新销售交易，并重新输入所有商品。
    3. 收银员继续该次销售交易（可能要输入更多的商品或处理支付）。
2-4a. 顾客告诉收银员其免税状况（例如，年长者、本国人等）。
    1. 收银员进行核实，并输入免税状况编码。
    2. 系统记录该状况编码（在计算税金时使用）。
3a. 无效商品ID（在系统中未发现）：
    1. 系统提示错误并拒绝输入该ID。
    2. 收银员响应该错误。
        2a. 商品ID可读（例如，数字型的UPC（通用产品代码））：
            1. 收银员手工输入商品ID。
            2. 系统现实商品项目的描述和价格。
                2a. 无效商品ID：系统提示错误。收银员尝试其他方式。
        2b. 系统内不存在该商品ID，但是该商品附有价签：
            1. 收银员请求经理执行超控操作。
            2. 经理执行相应的超控操作。
            3. 收银员选择手工输入价格。输入价签上的价格，并且请求对该价目进行标准计税。（因为没有产品信息，计税引擎无法确定如何计税。）
        2c. 收银员通过执行【寻找产品帮助】以获取正确的商品ID及其价格。
        2d. 另外，收银员可以向其他员工询问商品ID或价格。然后手工输入ID或价格（参见以上内容）。
3b. 当有多个商品项目属于同一类别的时候（如5个汉堡包），不必记录每个商品项目的唯一标识。
    1. 收银员可以输入类别的标识和商品的数量。
3c. 需要手工输入类别和价格（例如，花卉或纸牌及其价格）：
    1. 收银员手工输入特定的类别代码及其价格。
3-6a. 顾客要求收银员从所购商品中去掉一项：所去除商品的价格必须小于收银员权限，否则需要经理执行超控操作。
    1. 收银员输入商品ID并将其删除。
    2. 系统删除该项目并现实更新后的累计额。
        2a. 商品价格超过了收银员权限：
            1. 系统提示错误，并建议经理超控。
            2. 收银员请求经理超控，完成超控后，重做该操作。
3-6b. 顾客要求收银员取消销售交易：
    1. 收银员在系统中取消销售交易。
3-6c. 收银员延迟销售交易：
    1. 系统记录销售交易信息，使其能够在任何POS登录中恢复操作。
    2. 系统现实用来恢复销售交易的”延迟票据“。其中包含商品项目和销售交易ID。
4a. 系统定义的商品价格不是顾客预期的价格（顾客对此产生抱怨并要求减价）：
    1. 收银员请求经理批准。
    2. 经理执行超控操作。
    3. 员工手工输入超控后的价格。
    4. 系统显示新价格。
5a. 系统检测到与外部税务计算系统服务的通信故障：
    1. 系统在POS机节点上重启此服务，并继续操作：
        1a. 系统检测到该服务无法重启。
            1. 系统提示错误。
            2. 收银员手工计算和输入税金。或者取消该销售交易。
5b. 顾客声称它们符合打折条件（例如，是雇员或重要顾客）：
    1. 收银员提出打折请求。
    2. 收银员输入顾客ID。
    3. 系统按照打折规则显示折扣总计。
5c. 顾客要求兑现账户积分，用于此次销售交易：
    1. 收银员提交积分请求。
    2. 收银员输入顾客ID。
    3. 系统应用积分指导价格未0，同时扣除结余积分。
6a. 顾客要求现金支付，但所携现金不足：
    1. 顾客要求使用其他支付方式。
        1a. 顾客要求取消此次销售交易，收银员在系统上取消该销售交易。
7a. 现金支付：
    1. 收银员输入收取的现金额。
    2. 系统显示找零金额，并弹出现金抽屉。
    3. 收银员放入收取的现金，并给顾客找零。
    4. 系统及记录该现金支付。
7b. 信用卡支付：
    1. 顾客输入信用卡账户信息。
    2. 系统显示其支付信息以备验证。
    3. 收银员确认。
        3a. 收银员取消付款步骤。
            1. 系统回复到”商品输入模式“。
    4. 系统向外部支付授权服务系统发送支付授权请求，并请求批准该支付。
        4a. 系统检测到与外部系统协作时的故障。
            1. 系统向收银员提示错误。
            2. 收银员请求顾客更换支付方式。
    5. 系统收到批准支付的应答并提示收银员。同时弹出现金抽屉（以便放入前面后的信用卡支付票据）。
        5a. 系统收到拒绝支付的应答：
            1. 系统向收银员提示支付被拒绝。
            2. 收银员请求顾客更换支付方式。
        5b. 应答超时。
            1. 系统提示收银员应答超时。
            2. 收银员重试，或者请求顾客更换支付方式。
    6. 系统记录信用卡支付信息，其中包括支付批准。
    7. 系统显示信用卡支付的前面输入机制。
    8. 收银员请求顾客签署信用卡支付。顾客输入签名。
    9. 如果在纸质票据上签名，则收银员将该票据放入现金抽屉并关闭抽屉。
7c. 支票支付...
7d. 记账支付...
7e. 收银员取消支付步骤：
    1. 系统回到”商品输入“模式。
7f. 顾客出示优惠券：
    1. 在处理支付之前，收银员记录每张优惠券，系统扣除相应金额。系统记录已使用的优惠券以备账务处理之用。
        1a. 输入的优惠券不适用于所购商品：
            1. 系统向收银员提示错误。
9a. 存在产品回扣：
    1. 系统对每个具有回扣的商品给出回扣表单和票据。
9b. 顾客索要赠品票据（不显示价格）：
    1. 收银员请求赠品票据，系统给出赠品票据。
9c. 打印票据。
    1. 如果系统能够检测到错误，给出提示。
    2. 收银员更换纸张。
    3. 收银员请求打印其他票据。

特殊需求：
* 使用大尺寸平面显示器触摸屏UI。文本信息可见距离为1米。
* 90%的信用卡授权响应时间小于30秒。
* 由于某些原因。我们希望在访问远程服务（如库存系统）失败的情况下具有比较强的恢复功能。
* 支持文本显示的语言国际化。
* 在步骤3和步骤7中能够加入可拔插的业务规则。
* ...

技术与数据变元表：
* a. 经理超控需要刷卡（由读卡器读取超控卡）或在键盘上输入授权码。
3a. 商品ID可用条码扫描器（如果有条形码），或键盘输入。
3b. 商品ID可以使用UPC（通用产品代码）、EAN（欧洲物品编码）、JAN（日本物品编码）或SKU（库存单位）等任何一种编码方式。
7a. 信用卡账户信息可以用读卡器或键盘输入。
7b. 记录在纸质票据上的信用卡支付签名。但我们预测，两年内会有许多客户希望使用数字签名。

发生频率：可能会不断地发生。

未决问题：
* 税法如何变化？
* 研究原创服务的恢复问题。
* 针对不同的业务需要怎样进行定制？
* 收银员是否必须在从系统注销后带走他们的现金抽屉？
* 顾客是否可以之间使用读卡器，还是必须由收银员完成？

各小节的含义

绪言元素

范围

范围界定了索要设计的系统。通常，用例描述的是对一个软件系统的使用，这种情况下称之为系统用例。在更广义的范围上，用例也能够描述顾客和有关人员如何使用业务。被称为业务用例。

级别

用例主要分为用户目标级别或子功能级别。

用户目标级别是通常所使用的级别，描述了实现主要参与者目标的场景，该级别大致相当于业务流程工程中的基本业务流程。
子功能级别用例描述支持用户目标所需的子不知，当若干常规用例共享重复的子步骤时，则将其分离出来，创建为子宫内级别用例；信用卡就是子宫内用例的例子，该用例可以被需要常规用例所共享。

主要参与者

调用系统服务来完成目标的主要参与者

涉众及其关注点列表--重要！

该列表比看上去要重要和实用的多。它建议并界定了系统必须要做的功能。见一下引用：

【系统】实现了涉众之间的锲约，同时用例详细描述了该企业的行为部分...用例作为行为的锲约，专门和完整地捕获与满足涉众关注点相关的行为。

这就回答了以下问题：用例应该包含什么？答案是：用例应该包含满足所有涉众关注点的事物。另外，在编写用例其余部分之前就确定涉众及其关注点，能够让我们更加清楚地了解详细的系统职责。

前置条件和成功保证（后置条件）

前置条件：给出在用例中场景开始之前必须永远为真的条件。前置条件传达的时编写者认为应该引起读者警惕的那些值得关注的假设。
成功保证（或后置条件）：给出用i成功结束后必须为真的事物，包括主成功场景及其替代路径。该保证应该满足所有涉众的需求。

主成功场景和步骤（或基本流程）

描述了满足涉众关注与点的典型成功路径。

将所有条件和分支延迟到扩展部分进行说明

记录以下三种步骤：

参与者之间的交互。
确认过程（通常由系统来完成）。
系统完成的状态变更（例如，记录或更改某事物）。

用例的第一个步骤通常不属于以上分类，但它指出了启动场景的出发时间。

扩展（或替代流程）

扩展部分描述了其他所有场景或分支，包括成功和失败路径。

扩展由两部分组成：条件和处理

尽可能使用系统或参与者能够检测到的事物作为条件。

在扩展处理结束时，默认情况下，扩展场景将重新并入主成功场景，出发扩展指出了其他方式。

由时候，某个扩展点非常复杂，在这种情况下可以使用单独的用例来表达该扩展。

执行其他用例场景

有时候，用例会产生分支以执行其他用例场景，使用下划线表示所执行的第二个用例。

特殊需求

如果由于用例相关的非功能性需求、质量属性或约束，那么应该将其写入用例，其中包含需要考虑的或必须包含在内的质量属性和设计约束。

将特殊需求写入用例是UP的建议，同时这种做法对于第一次编写用例也是合理的。然而许多从业者发现，最终把所有非功能性需求集中于补充规范规格说明中，对于内容管理、可理解性和可读性而言更为有效，因为的价格分析时通常将这些需求作为整体来考虑。

技术和数据变元表

需求分析中通常会发现一些技术变元，这些变元时关于必须如何实现系统的，而非实现系统那些功能，这种变元需要记录的用例中。一般来说，应该避免早期不成熟的设计决策，但有时候这些决策时明显的或不可避免的，特别时关于I/O技术的决策。

表示法：有其他格式吗？两栏变体

有时提倡使用两栏或对话的格式，这种格式强调参与者和系统之间的交互。

准则：以无用户界面约束的本质风格编写用例

新式和改良！适于指纹的情形

通过对目标层次的研究（”何为目标之目标“），系统分析与会发现与实现机制无关的目标。

这种对根源目标的发现过程能够拓展视野，以促成新的改进和改进的解决方案。

以本质风格编写用例

摒除UI细节并集中于用户真实意图的用例编写风格称为本质风格。

以本质风格编写用例：摒除用户界面并且关注参与者的意图。

对比示例

本质风格

...
1. 管理员表示子集的身份。
2. 系统对此身份进行认证。
3. ...

具体风格--在早期需求工作中应该避免

...
1. 管理员在对话框中输入ID和口令（见图3）.
2. 系统对管理员进行认证。
3. 系统显示”编辑用户“窗口（见图4）.
4. ...

在这种风格中，用力文本中涵盖对用户界面的决策。对于在稍后的步骤中设计具体和详细的GUI的工作来说，这些具体用例可以时有用的工具，但是它并不适用于早期的需求分析工作。

准则：编写简洁的用例

准则：编写黑盒用例

黑盒用例时最常用和推荐使用的类型；它不对系统内部工作、构件或设计进行描述。繁殖，它以通过职责来描述系统，这是面向对象思想中普遍统一的隐喻主题--软件元素具有职责，并且与其他具有职责的元素进行协作。

通过使用黑盒用例定义系统职责，人们可以规定系统必须做什么（行为和功能性需求），而不必决定系统如何去做。在需求分析中应该避免进行”如何“的决策，二十规定系统的外部行为，此后，在设计过程中创建满足该规格说明的解决方案。

准则：采用参与者和参与者目标的视点

一组用例实例，每个实例时系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。

短语”对特定参与者具有价值的可观察结果“强调了需求分析的两个态度：

关注系统的用户或参与者来编写需求，询问其目标和典型情况。
关注理解参与者所考虑的有价值结果。

准则：如何发现用例

为满足主要参与者的目标而定义用例。因此，基本过程如下：

选择系统边界。
确定主要参与者。
确定每个主要参与者的目标。
定义满足用户目标的用例，根据其目标对用例命名。

步骤1：选择系统边界

如果对被设计系统的边界定义不清晰，那么可以通过此后对系统外部事物的定义加以明确。一旦定义了外部参与者，系统边界将变得清晰。

步骤2和3：寻找主要参与者和目标

在需求讨论会上，人们会集体讨论并同时形成对两者的识别。有时目标会反映参与者，反之亦然

准则：首先集体讨论主要参与者，因此这样可以为将来的研究建立框架

什么样的问题有助于寻找参与者和目标：

谁来启动和停止系统？
谁来完成用户管理和安全管理？
”时间“时参与者吗？因为系统要响应时间事件而完成某些活动。
当系统失败时，是否存在监控进程将系统重新启动？
软件升级时如何处理的？是”推“模式还是”拉“模式？
处理人作为主要参与者之外，还有其他外部的软件或自动机器系统调用该系统的服务吗？
谁来考察系统活动或性能？
谁来考察日志？是否可以原创检索？
系统发生错误或故障时应通知谁？

如何组织参与者和目标：

当你发现了结果，将其绘制为用例图，以目标作为用例名称。
首先写出参与者-目标列表，复审并精化之，然后绘制用例图。

为什么提问总是围绕着参与者目标而不是用例

参与者尤其目标，并且使用应用以达成目标。用例建模的观点就是寻找这些参与者及其目标，创建产生由价值结果的解决方案。在开始用例建模时，首先要询问的时”谁来使用系统，它们的目标时什么？“而非”系统的任务时什么？“

主要参与者时收银员还是顾客

处理销售用例中的主要参与者为什么时收银员，而不是顾客？其答案和所设计系统的边界，以及我们设计系统的主要对象有关。

有其他方法来寻找产于这和目标吗？事件分析

有助于寻找参与者、目标和用例的另一个方法时确定外部事件。有哪些外部事件，源于何处，为什么？通常，一组事件处于同一用例。

步骤4：定义用例

一般来说，为每个用户目标分别定义用例。用例的名称应该和用户目标类似。

用例名称应使用动词开头。

对于每个目标的一个用例来说，最场景的例外时，将分散的CRUD目标合并成一个CRUD用例，并习惯性地称为管理XXX

准则：什么样的测试有助于发现有用的用例

一般来说不要提出”什么是有效用例“这样的问题，更为实际的问题是”对应用需求分析来说，表示用例的有效级别是什么？“下面给出一些经验方法：

老板测试
EBP测试
规模测试

老板测试

你的老板问：”你整天都做了写什么？“你回答：“登录系统！”你的老板会高兴吗？

如果不会，那么该用例不会通过老板测试，这意味着该用例与达到可量化价值的结果没有太大关系。这也许是更地级别目标的用例，但不是需求分析所使用的级别。

这也不意味着要忽略在老板测试中失败的用例。用户认证可能不会通过老板测试，但却是重点和难点。

EBP测试

EBP即基本业务过程（Elementary Business Process），是源于业务过程工程领域的属于，定义如下

一个人于某个时刻在一个地点所执行的任务，用以响应业务事件。该任务能够增加可量化的业务价值，并且以持久状态留下数据，例如，批准信用卡的信用额或者确定订购的价格。

EBP测试于老板测试类似，尤其是对于业务价值可量化这一限制而言。

规模测试

用例很少由单独的活动或步骤组成，相反，用例通常包含多个步骤，在详述形式的用例通常需要3-10页文本。用例建模中的一个常见错误就是仅将一系列相关步骤中的一个步骤定义为用例。

示范：应用上述测试

就供应者合同进行协商
- 比EBP更广泛，用时更长。更适合作为业务用例，而非系统用例。
办理退货
- 能够通过老板测试。看上去比EBP类似。规模合适。
登录
- 如果你一整天都在登录，老板不会满意。
在游戏版上移动棋子
- 单一步骤，不能通过规模测试。

测试的合理违例

有时，需要为子任务或常规EBP界别用例中的步骤编写单独的子宫内级别用例。如果由这种现象，即使不能真正满足EBP和规模测试，也需要考虑将其分离为单独的用例，并且将其链接到哥哥基本用例上。

应用UML：用例图

UML 提供了用例图表示法，用以描述用例名称和参与者及其之间的关系

用例图和用例关系在编写用例工作中是次要的。用例是文本文档。编写用例意味着编写文本。

简单的用例图还是能够为系统提供简洁可是的语境图，能够阐述外部参与者及其对系统的使用。

绘制简单的用例图，并于参与者-目标列表关联。

用例图是一种优秀的系统语境图；也就是说，用例图能够展示系统边界、位于边界之外的事物以及系统如何被使用。

准则：制图

建议表示法：

另一种参与者表示法：

准则：不要倚重于制品，保持其简短

用例工作在于编写文本，而非图形或用例关系。

引用UML：活动图

UML 包含一种有助于使工作流和业务过程可视化的图：活动图。因为用例涵盖过程和工作流分析，所以活动图能够称为编写用例文本的有用的辅助措施，对于哪些描述复杂工作流的业务用来说更是如此，因为其中设计大量参与者和并发活动。

动机：用例还有其他益处吗？语境中的需求

用例的冬季时在于关注谁时关键参与者，其目标和一般的任务时什么。

除此之外，究其本质而言，用例时一种简单的、被广泛理解的形式。

零一冬季时以用例代替详细的、底层的功能列表。

在使用系统的典型场景的语境下，用例组织了一组需求。以面向用户的场景作为公共线索，考虑并组织需求，可以增强对需求的理解，并且能够提高需求分组的内聚性。

容许高阶系统特性列表

虽然不希望使用详细功能列表，但是在设想文档中加入简洁的高阶特性列表有助于概括系统的功能性，该列表也称为系统特性列表。

什么时候详细特性列表比用例更适合。

有时候用例不一定合适，某些应用迫切需要特定驱动的观点。

示例：Monopoly游戏

过程：在迭代方法中如何使用用例

UP 提倡用例驱动开发，这意味着：

功能需求首先记录在用例中；无论如何使用，其他需求技术都是次要的。
用例时迭代计划的重要部分。迭代的工作时通过选择一些用例场景或整个用例来定义的。同时，用例时预算的关键输入。
用例实现驱动设计。也就是说，小组设计写作对象和子系统就是为了执行或实现用例。
用例通常会影响用户手册的组织。
功能或系统测试应当符合用例的场景。
为重要用例的最常用场景创建UI“向导”或会计方式可以方便执行常用任务。

在迭代中如何烟花用例和其他规格说明

示例：

完成此项工作时间和地点方面的建议：

何时创建各种UP制品

初始阶段如何编写用例

在初始阶段，并不是要以详述形式编写所有用例。在开始的部分时间里，主要工作时确定目标和涉众，并且推出项目的范围。开始绘制用例的语境图。以摘要形式编写大部分需要关注的、复杂的、具有风险的用例。小组开始对系统的功能性达成共识。

此后以详述形式重新编写其中10%-20%的用例，这些用例代表复杂的核心功能、需要构件呵呵将或者在某些方面极具风险。通过对具有影响力的用例所完成的小范围深入调查，小组能够进行略为深入地研究，贸易获取对项目规模、复杂的、移仓风险的理解。

在细化阶段如何编写用例

该阶段含有多次时间定量的迭代，在这些爹地啊中，逐步构件具有风险、搞兼职或具有重要价格意义的部分系统，同时确定需求的“主题”。源于具体编程步骤的反馈会影响和干预小组对需求的理解，对需求的迭代时地带的和可适应的。每次迭代都可以由一个为其两天的需求讨论会。但是并不是要在每个讨论会上调查所有用例。这里具有优先级，较早的讨论关注最重要用例的子集。

在随后的每个简短的需求讨论会中，精化用户目标和用例列表。以详述形式编写和宠幸编写更多的用例。在细化阶段结束时，将详细编写“80%-90%”的用例。

细化阶段设计对部分系统编程。在该步骤结束时，不仅应该拥有更详细的用例定义，还应该由一些可执行的软件。

构造阶段如何编写用例

在细化阶段中，一旦解决了哪些具有风险的和不稳当的核心问题，那么在由时间定量的迭代组成的构造阶段中，则着重于完成系统。这一阶段中，可能还要编写一些次要的用例，也可能会举行需求讨论会，但是次数都会大大少于细化阶段。

用例

示例