用例
用例就是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。
- 参与者
参与者是任何具有行为的事物。
参与者的三种类型：
l 主要参与者，具有用户目标，并通过使用系统的服务完成。例如收银员。
l 协助参与者，为系统提供服务，一般是计算机系统。比如说自动付费服务授权。
l 幕后参与者，在用例行为中具有影响或利益，但不是主要或协助参与者。例如政府税收机构。
- 详述风格的用例模版
- 详述用例是结构化的，它展示了更多的细节，并且更为深入。
- 在迭代和进化式UP需求分析中，第一次需求讨论会应该以这种形式编写10%的关键用例，然后对这10%中最具有重要架构意义的用例或场景进行设计和编程。
- 详细用例格式的模板采用以下风格，是目前使用最为广泛的格式：
用例名称：以动词开始。 - 范围：范围界定了索要设计的系统。通常用例描述的是对一个软件系统（或硬件加软件）的使用，这种情况下称之为系统用例。在更广义的范围上，用例也能够描述顾客和有关人员如何使用业务。这种企业级的过程描述被称为业务用例。
- 级别：用例主要分为用户目标级别或子功能级别。用户目标级别是通常所使用的级别，描述了实现主要参与者目标的场景，该级别大致相当于业务流程工程中的基本业务流程。子功能级别用例支持用户目标所需要的自步骤，当若干常规用例共享重复的自步骤时，将其分离出来，创建为子功能级别用例（以避免重复公共的文本），比如信用卡支付，该用例可以被许多常规用例所共享。
- 主要参与者：调用系统服务来完成目标的参与者。
- 涉众及其关注点列表：该列表建议并界定了系统必须要做的工作。用例应该包含满足所有涉众关注点的事物，在编写用例其余部分之前就确定涉众及其关注点，能够让我们更加清楚地了解详细的系统职责。从涉众及其关注点的角度出发，能够为发现并记录所有行为需求提供彻底、系统的过程。
- 前置条件：给出在用例中场景开始之前必须永远为真的条件。通常前置条件隐含已经成功完成的其他用例场景，例如“登录”。注意有些条件也必须为真，但是不值得编写出来，例如“系统有电力供应”。前置条件传达的是编写者认为应该引起读者警惕的那些值得注意的假设。
- 成功保证：给出用例成功结束后必须为真的事物，包括主成功场景及其替代路径。该保证应该满足所有涉众的需求。
- 主成功场景和步骤（或基本流程）：也被称为“理想路径”场景，或“基本流程”及“典型流程”。它描述了满足涉众关注点的典型成功路径，要注意的是，它通常不包括任何条件或分支，保持一定的连贯性，并且将所有条件处理都推延至扩展部分，这样的做法更易于理解和扩展。场景记录三种步骤：1.参与者之间的交互；2.确认过程（通常由系统来完成）；3.系统完成的状态变更（例如记录或更改某事物）；
- 扩展：扩展是重要的并通常占据了文本的大部分篇幅。扩展部分描述了其他所有场景或分支，包括成功和失败路径。在整个用例编写中，理想路径与扩展路径相结合应该满足“几乎”所有涉众所关注的问题。但是有些关注问题最好是作为非功能性需求在补充规格说明中描述，比如顾客要求显示商品描述和价格。扩展由两部分组成：条件和处理。尽可能用系统内给或参与者能够检测到的事物作为条件，例如，系统检测到与外部税务计算系统服务的通讯故障和外部税务计算系统工作不正常，前一种比较好，因为那个是系统能够检测的条件，而后一种只是推断。
- 特殊需求：相关的非功能性需求；将所有非功能性需求集中于补充规范规格说明中，对于内容管理、可理解性和可读性而言更为有效，因为在架构分析时通常将这些需求作为整体来考虑。
- 技术和数据变元表：不同的I/O方法和数据格式，在需求分析中发现的一些技术变元，这些变元是关于必须如何实现系统的，而不是实现系统的哪些功能。
- 发生频率：影响对实现的调查、测试和时间安排；
- 杂项：例如未决问题；
- 详细用例格式的模板采用以下风格，是目前使用最为广泛的格式：
用例示例：
范围：NextGen POS 应用（销售时点信息系统）
级别：用户目标
主要参与者：收银员
涉众及其关注点：
- 收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收贷款，将从薪水中扣除。
- 售货员：希望自动更新销售提成。
- 顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。
- 公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即使在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新账务和库存信息。
- 经理：希望能够快速地执行超控操作，并易于更正收银员的不当操作。
- 政府税收代理：希望能从每笔交易中抽取税金，可能存在多级税务代理，比如国家级、省级、市级。
- 支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。
前置条件：收银员必须经过确认和认证。
成功保证（或后置条件）：存储销售信息。准确计算税金。更新账务和库存信息。记录提成。生成票据。记录支付授权的批准。
主成功场景（或基本流程）：
- 顾客携带所购商品或服务到收银台通过POS机付款。
- 收银员开始一次新的销售交易。
- 收银员输入商品条码。
- 系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。
收银员重复3~4步骤，直到输入结束。 - 系统显示总额。
- 收银员告知顾客总额，并请顾客付款。
- 顾客付款，系统处理支付。
- 系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。
- 系统打印票据。
- 顾客携带商品和票据离开。
扩展（或替代流程）：例如系统在某一步失败、无效的商品、顾客告知免税状况、需要手工输入类别和价格、顾客要求取消销售交易等。这些情况和步骤需要结合实际的场景进行详细的描述，例如：
在主成功场景的第3步，出现无效商品ID，第一个描述条件及响应扩展被标记为“3a”，第二个标记为“3b”，以此类推。
用例图
用例图用于描述用例名称和参与者及其之间的关系。简单的用例图能够为系统提供简洁可视的语境图，能够阐述外部参与者及其对系统的使用。用例图能够展示系统边界、位于边界之外的事物以及系统如何被使用。
用例图所包含的元素如下：
1. 参与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2. 用例(Use Case)
用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
3. 子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密
示例
用例为附加可选文档