Project management 什么是用例？如何识别用例？

这个问题相当笼统。识别有效用例时应该记住哪些要点？如何接近一个用例？

一个用例以特定的方式确定了用户将能够使用程序完成的任务或目标。它应该用用户能够理解的术语编写

太正式了。我很快就会翻阅我的其他文章。 相比之下，它更容易接近

阿拉斯泰尔·科伯恩（Alastair Cockburn）的一篇文章（被积极引用）包含了一个很好的模板

---

仅几天前发布的，是非常密切相关的，但稍微具体一些。

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

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

---

用例的定义很简单：

参与者与系统的交互，以创造业务价值

更正式地说：

执行的一系列事务 通过产生可测量的 特定参与者的一组值

他们的意图非常简单：演员、互动、价值。您可以添加一些细节，但不能太多

使用用例很容易。请阅读以下内容：

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

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

• 信息
• 决断
• 行动

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

来自Eclipse人员：

确定参与者

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

通过命名来定义每个候选参与者 然后写一个简短的描述。 包括演员的活动范围 责任和目标 演员将尝试完成以下任务： 使用该系统。淘汰演员 没有任何目标的候选人

这些问题在实践中很有用 确定行动者：

• 谁将提供、使用或移除 来自系统的信息
• 谁会 使用这个系统
• 谁对一家公司感兴趣 由……提供的某些特征或服务 系统
• 谁会支持和支持 维护系统
• 有什么问题 系统的外部资源
• 什么 其他系统需要相互作用 系统正在开发中

审查利益相关者名单 你在愿景宣言中捕捉到了这一点。 并非所有利益相关者都将成为行动者 （也就是说，它们不会相互作用 直接与系统进行交互 但是这个列表 利益相关者有助于确定 演员候选人

识别用例

找到用例的最佳方法是 考虑每个演员需要什么 系统。对于每个演员，人或 不要问：

• 演员的目标是什么 试图用这个系统来完成吗
• 公司需要完成的主要任务是什么 参与者希望系统执行什么操作
• 演员会创造，储存，改变， 删除或读取系统中的数据
• 演员需要通知观众吗 关于外部突然变化的系统
• 演员需要被告知吗 关于某些事件，例如 网络资源不可用， 在系统中
• 演员会表演吗 系统启动还是关闭

了解目标如何 组织的运作及其方式 信息系统可能是 并入现有业务 给出了系统的基本概念 周围的环境这些信息可以 揭示其他用例候选者

请给出唯一的名称和摘要 描述，清楚地描述了 每个用例的目标。如果 候选用例没有 目标，问问自己它为什么存在，以及 然后，要么确定一个目标，要么 消除用例

概述用例

不谈细节，写一篇文章 活动流程初稿 确定为可用的用例 高度优先。首先，写一个 简单的一步一步描述 用例的基本流程。这个 一步一步的描述很简单 之间交互的有序列表 参与者和系统。例如 基本流程的描述 应用程序的提取现金用例 自动取款机（ATM）将 是这样的：

客户插入一张银行卡

系统验证卡并提示 输入个人信息的人 识别号（PIN）

客户输入PIN

系统 验证PIN并提示 客户选择一个操作

客户选择提取现金

系统会提示客户进行选择 哪个账户

客户选择 支票帐户

系统 提示输入金额

顾客 输入要提取的金额

系统验证金额（假设 资金充足），然后发行 现金和收据

客户拿到现金和收据，然后 检索银行卡

用例结束

当你一步一步地创建这个 描述