project-management - 什么是用例？如何识别用例？

Question

这个问题很笼统。识别有效用例时应牢记哪些要点？如何处理用例？

Answer 1

用例明确地标识用户将能够使用程序完成的任务或目标。它应该以用户可以理解的方式编写。

维基百科的描述过于正式。我很快就会浏览我的其他文本。相比之下，原始 wiki 的文章更易于访问。

Alastair Cockburn的早期文章被The Pragmatic Programmer积​​极引用，其中包含一个很好的模板。

这个问题，就在几天前，非常相关，但稍微具体一些。

Answer 2

用例的定义很简单：

参与者与系统的交互以创造商业价值。

更正式地说：

系统执行的一系列事务，为特定参与者产生一组可测量的值。

它们旨在非常简单：Actor、Interaction、Value。您可以添加一些细节，但不能太多。

使用用例很容易。阅读： http ://www.gatherspace.com/static/use_case_example.html

最大的错误是忽略了actor和系统之间的交互。用例不是写下冗长、详细的技术算法设计的地方。用例是参与者做某事的地方。

人们与系统交互，以便他们可以采取行动（下订单、批准计费、拒绝保险索赔等）。要采取行动，他们首先要做出决定。为了做出决定，他们需要信息

• 信息
• 决定
• 行动

这些是用例的“交互”部分中的成分。

Answer 3

一个有效的用例可以描述：

• 目标受众/用户
• 先决条件（即必须已登录等）
• 预期结果
• 可能的故障点
• 用户工作流程

Answer 4

来自指南：Eclipse 人员识别和概述参与者和用例：

识别参与者

找出正在开发的系统必须与之交互的外部实体。候选人包括需要系统帮助来执行任务和运行系统的主要或次要功能以及外部硬件、软件和其他系统的用户组。

通过命名并编写简短描述来定义每个候选演员。包括参与者的责任范围和参与者在使用系统时将尝试实现的目标。淘汰没有任何目标的演员候选人。

这些问题有助于识别参与者：

• 谁将提供、使用或删除系统中的信息？
• 谁将使用该系统？
• 谁对系统提供的某个功能或服务感兴趣？
• 谁将支持和维护该系统？
• 系统的外部资源是什么？
• 还需要哪些其他系统与正在开发的系统进行交互？

查看您在愿景声明中捕获的利益相关者列表。并非所有利益相关者都是参与者（也就是说，他们不会都直接与正在开发的系统交互），但这个利益相关者列表对于确定参与者的候选人很有用。

识别用例

寻找用例的最佳方法是考虑每个参与者对系统的要求。对于每个演员，无论是否为人，请询问：

• 参与者将尝试通过系统实现的目标是什么？
• 参与者希望系统执行的主要任务是什么？
• 参与者会在系统中创建、存储、更改、删​​除或读取数据吗？
• 演员是否需要通知系统突然的外部变化？
• 参与者是否需要被告知系统中的某些事件，例如网络资源不可用？
• 演员会执行系统启动或关闭吗？

了解目标组织如何运作以及如何将这个信息系统整合到现有运营中，可以了解系统环境。该信息可以揭示其他用例候选者。

给出一个独特的名称和简短的描述，清楚地描述每个用例的目标。如果候选用例没有目标，问问自己它为什么存在，然后确定目标或消除用例。

概述用例

无需详述，编写被确定为具有高优先级的用例的事件流的初稿。最初，为用例的基本流程编写一个简单的分步描述。分步描述是参与者和系统之间交互的简单有序列表。例如，自动柜员机 (ATM) 的提款现金用例的基本流程描述如下：

1. 客户插入银行卡。
2. 系统验证卡并提示此人输入个人识别码 (PIN)。
3. 客户输入 PIN。
4. 系统验证 PIN 并提示客户选择操作。
5. 客户选择提取现金。
6. 系统提示客户选择哪个账户。
7. 客户选择支票账户。
8. 系统提示输入金额。
9. 客户输入要取款的金额。
10. 系统验证金额（假设资金充足），然后发出现金和收据。
11. 客户取现金和收据，然后取回银行卡。
12. 用例结束。

当您创建基本事件流的逐步描述时，您可以发现替代的和异常的流。例如，如果客户输入了无效的 PIN 会发生什么？记录您确定的每个备用流程的名称和简要说明。

表示参与者和用例之间的关系

可以捕获或记录参与者和用例之间的关系。有几种方法可以做到这一点。如果您在项目中使用用例模型，则可以创建用例图来显示参与者和用例如何相互关联。有关更多信息，请参阅指南：用例模型。

如果您没有为项目使用用例模型，请确保每个用例都标识了相关的主要参与者和次要参与者。