业务分析 - 用例

UML 的九种图之一是用例图。这些图不仅重要，而且是软件项目必要的需求。它主要用于软件生命周期。众所周知，开发周期中存在各个阶段，而用例最常用的阶段是在需求收集阶段。

什么是用例？

用例描述了一系列由系统执行的动作，这些动作为参与者提供价值。用例描述了系统在各种条件下的行为，因为它响应来自利益相关者之一（称为**主要参与者**）的请求。

参与者是系统的“谁”，换句话说，他是最终用户。

在软件和系统工程中，用例是一系列步骤的列表，通常定义角色（在 UML 中称为“参与者”）与系统之间的交互，以实现目标。参与者可以是人类或外部系统。

用例指定了系统中的事件流程。它更关注系统为了执行一系列操作而执行的操作。

用例的益处

用例提供了以下好处：

它是一种易于捕获功能需求的方法，重点关注为用户带来的价值。
与传统的需求方法相比，用例相对易于编写和阅读。
用例迫使开发人员从最终用户的角度思考。
用例让用户参与到需求过程中。

用例的结构

名称 : 说明用例目的的描述性名称。

描述 : 用几句话描述用例的作用。

参与者 : 列出参与用例的任何参与者。

前提条件 : 在开始用例之前必须满足的条件。

事件流程 : 描述系统与参与者之间的交互。

后置条件 : 描述用例运行完成后的系统状态。

用例模板指南

使用本章末尾给出的模板记录每个用例。本节提供了用例模板中每个部分的描述。

用例识别

用例 ID - 为每个用例提供一个唯一的数字标识符，采用分层形式：X.Y。相关的用例可以在层次结构中分组。功能需求可以追溯到标记的用例。
用例名称 - 为用例指定一个简洁、面向结果的名称。这些名称反映了用户需要能够使用系统完成的任务。包含一个动作动词和一个名词。一些示例：
- 查看零件号信息。
- 手动标记超文本源并建立到目标的链接。
- 订购带有更新软件版本的 CD。

用例历史

在这里，我们提到了用例文档的利益相关者的人员姓名。

创建者 - 提供最初记录此用例的人员的姓名。
创建时间 - 输入最初记录用例的日期。
最后更新者 - 提供对用例描述进行最近更新的人员的姓名。
最后更新时间 - 输入最近更新用例的日期。

用例定义

以下是用例关键概念的定义：

参与者

参与者是软件系统外部的人员或其他实体，他们与系统交互并执行用例以完成任务。不同的参与者通常对应于从将使用产品的客户群体中识别出的不同的用户类别或角色。命名将执行此用例的参与者。

描述

简要描述此用例的原因和结果，或执行用例的动作序列和结果的高级描述。

前提条件

列出在用例开始之前必须发生的任何活动或必须为真的任何条件。为每个前提条件编号。

示例

用户身份已通过身份验证。
用户的计算机有足够的可用内存来启动任务。

后置条件

描述用例执行结束时系统的状态。为每个后置条件编号。

示例

文档仅包含有效的 SGML 标记。
数据库中项目的價格已更新为新值。

优先级

指示实现允许执行此用例所需的功能的相对优先级。使用的优先级方案必须与软件需求规格说明书中使用的方案相同。

使用频率

估计参与者在某个适当的时间单位内执行此用例的次数。

正常事件流程

详细描述在正常、预期条件下执行用例期间将发生的用户的操作和系统的响应。此对话序列最终将实现用例名称和描述中陈述的目标。此描述可以写成对假设问题的回答，“如何<完成用例名称中陈述的任务>？” 最好将其作为参与者执行的操作的编号列表，与系统提供的响应交替进行。

备选流程

在本节中分别记录在此用例中可能发生的其他的合法使用场景。陈述备选流程，并描述发生的步骤序列的任何差异。使用用例 ID 作为前缀为每个备选流程编号，后跟“AC”表示“备选流程”。例如：X.Y.AC.1。

异常

描述在用例执行期间可能发生的任何预期的错误条件，并定义系统如何响应这些条件。此外，描述如果用例执行因某种意外原因失败，系统如何响应。使用用例 ID 作为前缀为每个异常编号，后跟“EX”表示“异常”。例如：X.Y.EX.1。

包含

列出此用例“调用”的任何其他用例。出现在多个用例中的常见功能可以拆分为一个单独的用例，该用例包含需要该常见功能的用例。

特殊需求

识别用例在设计或实现期间可能需要解决的任何其他需求，例如非功能性需求。这些可能包括性能要求或其他质量属性。

假设

列出分析中做出的任何假设，这些假设导致将此用例纳入产品描述并编写用例描述。

备注和问题

列出有关此用例的任何其他注释或任何剩余的未决问题或待定事项 (TBD)。确定谁将解决每个问题、截止日期以及最终的解决方案。

变更管理和版本控制

版本控制是对文档、大型网站和其他信息集合的更改进行管理。更改通常由数字或字母代码标识，称为修订号或修订级别。每个修订版都与时间戳和进行更改的人员相关联。

打印页面