业务分析 - 用例
UML 的九个图之一是用例图。这些对于软件项目来说不仅是重要的而且是必要的要求。它基本上用于软件生命周期。我们知道，开发周期有多个阶段，而用例最常用的阶段是需求收集阶段。
什么是用例？
用例描述了由为参与者提供价值的系统执行的一系列操作。用例描述了系统在响应利益相关者之一（称为主要参与者）的请求时在各种条件下的Behave。
参与者是系统的谁，换句话说，他是最终用户。
在软件和系统工程中，用例是一系列步骤，通常定义角色（在 UML 中称为“参与者”）和系统之间的交互，以实现目标。参与者可以是人类或外部系统。
用例指定系统中的事件流。它更关心系统为了执行一系列操作而执行的操作。
用例的好处
用例提供以下好处 -
这是一种捕获功能需求的简单方法，重点关注为用户增加的价值。
与传统的需求方法相比，用例相对容易编写和阅读。
用例迫使开发人员从最终用户的角度进行思考。
用例让用户参与需求过程。
用例剖析
名称： 说明用例目的的描述性名称。
描述： 用几句话描述用例的作用。
参与者： 列出参与用例的所有参与者。
前置条件： 开始用例之前必须满足的条件。
事件流： 系统和参与者之间交互的描述。
后置条件： 描述用例运行后系统的状态。
用例模板指南
使用本章末尾给出的模板记录每个用例。本节提供用例模板中每个部分的描述。
用例识别
用例 ID - 以分层形式为每个用例提供一个唯一的数字标识符：XY 相关用例可以在层次结构中分组。功能需求可以追溯到标记的用例。
用例名称- 为用例指定一个简洁的、面向结果的名称。这些反映了用户需要能够使用系统完成的任务。包括一个动作动词和一个名词。一些例子 -
查看零件号信息。
手动标记超文本源并建立到目标的链接。
订购包含更新软件版本的 CD。
用例历史
在这里，我们提到了用例文档的利益相关者的名字。
创建者- 提供最初记录此用例的人员的姓名。
创建日期- 输入最初记录用例的日期。
最后更新者- 提供对用例描述执行最新更新的人员的姓名。
上次更新日期- 输入最近更新用例的日期。
用例定义
以下是用例关键概念的定义 -
演员
参与者是指定的软件系统外部的人或其他实体，他们与系统交互并执行用例以完成任务。不同的参与者通常对应于从将使用该产品的客户社区中识别出的不同用户类别或角色。命名将执行此用例的参与者。
描述
提供该用例的原因和结果的简要描述，或者执行该用例的操作序列和结果的高级描述。
前提条件
列出在启动用例之前必须发生的任何活动或必须满足的任何条件。对每个先决条件进行编号。
例子
- 用户身份已通过认证。
- 用户的计算机有足够的可用内存来启动任务。
岗位条件
描述用例执行结束时系统的状态。对每个帖子条件进行编号。
例子
- 文档仅包含有效的 SGML 标签。
- 数据库中商品的价格已更新为新值。
优先事项
指示实现允许执行该用例所需的功能的相对优先级。使用的优先级方案必须与软件需求规范中使用的优先级方案相同。
使用频率
估计参与者在某个适当的时间单位执行此用例的次数。
事件的正常过程
提供在正常预期条件下执行用例期间将发生的用户操作和系统响应的详细描述。该对话序列最终将实现用例名称和描述中所述的目标。该描述可以作为对假设问题的回答，“我如何<完成用例名称中规定的任务>？” 最好将其作为参与者执行的操作的编号列表来完成，并与系统提供的响应交替进行。
替代课程
本节中单独记录此用例中可能发生的其他合法使用场景。说明替代方案，并描述发生的步骤顺序中的任何差异。使用用例 ID 作为前缀对每个替代课程进行编号，后跟“AC”以指示“替代课程”。示例：XYAC.1。
例外情况
描述用例执行期间可能发生的任何预期错误情况，并定义系统如何响应这些情况。另外，描述如果用例执行由于某些意外原因失败，系统将如何响应。使用用例 ID 作为前缀对每个异常进行编号，后跟“EX”以指示“异常”。示例：XYEX.1。
包括
列出此用例包含（“调用”）的任何其他用例。出现在多个用例中的通用功能可以拆分为一个单独的用例，该用例包含在需要该通用功能的用例中。
特殊要求
确定在设计或实现过程中可能需要解决的用例的任何附加需求，例如非功能性需求。这些可能包括性能要求或其他质量属性。
假设
列出在分析中做出的所有假设，这些假设导致接受该用例到产品描述中并编写用例描述。
注意事项和问题
列出有关此用例的任何其他注释或任何剩余的未决问题或必须解决的 TBD（待定）。确定谁将解决每个问题、截止日期以及最终的解决方案是什么。
变更管理和版本控制
版本控制是对文档、大型网站和其他信息集合的更改的管理。更改通常由数字或字母代码标识，称为修订号或修订级别。每个修订都与时间戳和进行更改的人员相关联。