用例

一个非常简单的用例图一个维基系统。

在软件和系统工程， 词组用例是一个polyseme有两个感官：

  1. 一件软件的使用情况；经常在复数中用于建议软件可能有用的情况。
  2. 系统接收外部请求（例如用户输入）并响应它的潜在场景。

本文讨论了后一种意义。

一个用例是操作或事件步骤的列表，通常定义角色之间的交互（已知统一的建模语言（uml）作为一个演员）和一个实现目标的系统。演员可以是人类或其他外部系统。在系统工程中，用例比内部使用软件工程，通常代表任务或利益相关者目标。然后可以在系统建模语言（SYSML）或作为合同声明。

历史

1987年伊瓦尔·雅各布森在OOPSLA'87会议。[1]他描述了如何使用该技术爱立信使用文本，结构和视觉建模驱动面向对象的分析和设计的技术。[2]最初他使用了这些术语使用场景和用法案例 - 后者直接翻译他的瑞典语AnvändningsFall - 但发现这两个术语在英语中都没有自然，最终他安定下来用例.[3]

1992年，他合著了这本书面向对象的软件工程 - 用例驱动方法，[4]奠定了Oose系统工程方法，并帮助普及用例捕获功能要求，尤其是在软件开发。1994年，他出版了一本关于应用于用例和面向对象的技术的书商业模式和业务流程重新设计.[5]

同时，Grady Booch和詹姆斯·伦贝努力统一他们的面向对象的分析和设计方法，布希方法和对象建模技术（OMT）分别。1995年，伊瓦尔·雅各布森（Ivar Jacobson）加入了他们，他们共同创造了统一建模语言（UML），其中包括用例建模。UML由对像管理组（OMG）1997年。[6]Jacobson，Booch和Rumbaugh还研究了对象软件开发过程。所结果的统一过程于1999年出版，并推广了用例驱动方法。[7]

从那时起，许多作者为这项技术的发展做出了贡献，特别是：拉里·君士坦丁在1995年开发以使用为中心的设计，所谓的“基本用例”，旨在描述用户意图而不是可能限制或偏向用户界面设计的动作或方案序列；[8]Alistair Cockburn2000年出版了基于文本叙述和表格规格的面向目标的用例实践；[9]库尔特·比特纳（Kurt Bittner）和伊恩·斯潘塞（Ian Spence）在2002年开发了用于分析用例的功能要求的高级实践；[10]Dean Leffingwell和Don Widrig提议将用例应用于改变管理和利益相关者的沟通活动；[11]Gunnar Overgaard在2004年提议将设计模式的原理扩展到用例。[12]

2011年，雅各布森（Jacobson）与伊恩·斯潘塞（Ian Spence）和库尔特·比特纳（Kurt Bittner）一起出版了电子书用例2.0为了使技术适应敏捷的环境，用渐进的用例“切片”丰富它，并在整个开发生命周期中促进其使用[13]在年度介绍了新的方法之后IIBA会议。[14][15]

一般原则

用例是用于捕获，建模和指定系统要求的技术。[10]用例对应于系统可能与其参与者互动的一组行为，并产生可观察到的结果，从而有助于其目标。演员代表了人类用户或其他系统在交互中的作用。

在里面需求分析，在他们的身份证中，根据其主要参与者代表的特定用户目标命名用例。该案例通过文本描述或其他图形模型进一步详细说明，这些模型可以解释活动和事件的一般顺序以及特殊条件，异常或错误情况等变体。

根据软件工程知识体（SWEBOK），[16]用例属于基于情况需求启发技术以及[[基于模型的系统工程|基于模型的分析]]技术。但是用例还支持基于叙事的需求收集，增量要求获取，系统文档和接受测试。[1]

变化

该技术中有不同种类的用例和变化：

  • 系统用例指定要开发的系统的要求。[2]他们在详细描述中不仅确定了与演员的相互作用，而且还标识了处理中涉及的实体。它们是进一步分析模型和设计活动的起点。
  • 业务用例专注于业务组织，而不是软件系统。它们用于在业务流程重新设计计划的背景下指定业务模型和业务流程需求。[5]
  • 基本用例，也称为抽像用例，描述了参与者的潜在意图以及系统如何解决这些情况，而无需定义任何顺序或描述场景。[8]开发这种做法是为了支持以用户为中心的设计，并避免在系统规范的早期阶段引起对用户界面的偏见。[7]
  • 用例2.0适应敏捷开发方法的上下文。[1]这种技术丰富了需求收集实践，并支持用户叙事。它还提供了用例“切片”，以促进需求的增量启发并实现增量实现。

范围

用例的范围可以由主体和目标定义：

  • 主题标识将提供交互的系统，子系统或组件。[17]
  • 可以考虑到对目标感兴趣的组织级别（例如，公司，部门，用户）以及用户的目标分解为子目标，可以从层次结构构建目标。[9]目标的分解是从用户的角度和系统独立于传统功能分解而独立的。[10] 

用法

已知用例在以下情况下应用：

模板

有很多方法可以在文本中编写用例用例简介，随意的，大纲， 至整齐等，并带有多样化的模板。在由各个供应商或专家设计的模板中编写用例是获得高质量功能系统要求的常见行业实践。

Cockburn风格

由Alistair Cockburn在他的书中编写有效用例一直是使用最广泛的用例使用案例之一。

设计范围

Cockburn建议用符号注释每个用例以显示“设计范围”，该示波器可能是黑框（内部细节是隐藏的）或白色盒子（显示了内部细节）。有五个符号可用：[20]

范围图标
组织（Black-Box）填满的房子Scope-icons-filled-house
组织（白色框）毫无用处的房子
Scope-icons-unfilled-house
系统（黑色框）装满的盒子
Scope-icons-filled-box
系统（白色框）未填充的盒子
Scope-icons-unfilled-box
零件螺钉或螺栓
Scope-icons-screw-bolt

其他作者有时在组织级别将用例调用为“业务用例”。[21]

目标水平

目标水平的层次结构

Cockburn建议用符号注释每个用例以显示“目标水平”；[22]首选的级别是“用户目标”（或俗称“海平面”[23]：101）。

目标水平图标象征
非常高的摘要云++
Goal-level-icons-cloud.png
概括飞行风筝+
Goal-level-icons-flying-kite.png
用户目标海上波浪！
Goal-level-icons-waves-at-sea.png
子功能鱼-
Goal-level-icons-fish.png
太低海床蛤壳--
Goal-level-icons-seabed-clam-shell.png

有时，在文本写作中，用例名称加上替代文本符号（！ +， - 等）是一种更简洁，更方便的方式来表示级别，例如下订单！，登录-.

整齐

Cockburn描述了用例的更详细的结构，但允许在需要较少详细信息时将其简化。他穿着整齐的用例模板列出了以下字段：[24]

  • 标题：“一个主动动力的目标短语，命名了主要演员的目标”[25]
  • 主要演员
  • 上下文中的目标
  • 范围
  • 等级
  • 利益相关者和利益
  • 前提
  • 最少的保证
  • 成功保证
  • 扳机
  • 主要成功情况
  • 扩展
  • 技术和数据变化列表

此外，Cockburn建议使用两种设备指示每种用例的性质：用于设计范围和目标水平的图标。

科克本的方法影响了其他作者。例如，亚历山大（Alexander）和Beus-dukic将Cockburn的“穿好衣服的用例”模板从软件到各种系统的系统概括，以下字段与Cockburn不同：[26]

  • 变化方案“（也许从并可能返回主要场景）”
  • 例外“即异常事件及其异常处理场景”

随意的

Cockburn认识到项目可能并不总是需要详细的“完全穿着”的用例。他描述了一个随意的用例：[24]

  • 标题（目标）
  • 主要演员
  • 范围
  • 等级
  • （故事）：用例的主体只是一段或两段文本，非正式地描述了发生的情况。

福勒风格

马丁·福勒指出“没有标准的方法来编写用例的内容，并且不同的格式在不同的情况下效果很好。”[23]：100他描述了“使用的常见风格”，如下所示：[23]：101

  • 标题：“目标案例正在尝试满足”[23]：101
  • 主要成功方案：编号的步骤列表[23]：101
    • 步骤：“对演员与系统之间的相互作用的简单陈述”[23]：101
  • 扩展名：单独编号的列表，每个扩展名[23]：101
    • 扩展：“从..主要成功方案导致不同交互的条件”。主步骤3的扩展名为3A，等等。[23]：101

Fowler样式也可以看作是Cockburn模板的简化变体。这个变体称为用户故事.

阿利斯泰尔·科克本（Alistair Cockburn）说：[27]

将用户的故事视为用用例，以2位精确度。精度名称的位1个用例的目标，位2添加了主要方案。位3添加了故障条件，位4添加了故障操作。位5添加了IN/OUT数据的数据描述。我将催化放在第六位的精度上，因为它们还包括消息的收件人的模型。在Crystalmethodology家族中，以不同级别的精度为基础的项目用例。一种方法上的轻度项目使用用户故事，一个方法上的重重项目使用用例使用了4位精确度，而催化使用了6位精确度。

马丁·福勒（Martin Fowler）说：[28]

这全都与人们的使用情况有关。我见过许多人以非常形式化的方式使用案例。肯特以更平易近人的方式来做他的狂暴。我确实会像肯特的用户故事一样使用用例。我打电话给他们用例更好地与其他开发人员进行交流，并影响他们使用更轻巧的方法。

演员

主要文章：演员（UML）

用例定义了外部参与者与正在考虑的系统之间的相互作用以实现目标。演员必须能够做出决策，但不必是人类：“演员可能是一个人，公司或组织，计算机程序或计算机系统，即硬件，软件或两者兼而有之。”[29]演员永远利益相关者，但并非所有利益相关者都是参与者，因为他们可能“永远不要与系统直接互动，即使他们有权关心系统的行为方式”。[29]例如，“系统的所有者，公司的董事会和监管机构（例如国税局和保险部）都可以是利益相关者，但不太可能是演员。[29]

同样，使用系统的人可能会因为扮演不同的角色而被代表为不同的演员。例如，用户“乔”在使用自动柜员机从自己的帐户中提取现金或扮演银行出租人的角色时，可能会扮演客户的角色。

演员经常代表别人工作。科克本写道：“这些天，我为客户写'销售代表'或“营销部门的店员”，以捕获系统的用户为其他人行事。”这告诉项目，“用户界面和安全许可”应为销售代表和书记员设计，但客户和市场部是对结果的关注的角色。[30]

利益相关者可能会扮演主动和不活动角色：例如，消费者既是“大众市场购买者”（不与系统交互），也是用户（演员，与购买的产品进行积极互动）。[31]反过来，用户既是“普通运算符”（用于其预期目的使用该系统的演员），又是“功能受益人”（从使用系统使用中受益的利益相关者）。[31]例如，当用户“乔”从他的帐户中提取现金时，他正在操作自动柜员机并代表他自己获得结果。

Cockburn建议在系统的利益相关者中寻找演员，用例的主要和支持（次要的）参与者，设计中的系统（SUD）本身，最后是“内部参与者”，即系统的组成部分设计。[29]

业务用例

用用例描述用户（或其他类型的演员）和系统之间的一系列事件和交互的方式，为了产生价值（目标）的结果，业务用例描述了更一般的交互在业务系统和该系统的用户/参与者之间，以产生价值的业务结果。主要区别在于，业务用例模型中考虑的系统除技术系统外还包含人员。这些“系统中的人”被称为商业工人。在餐厅的示例中，必须做出决定，是否将每个人视为演员（因此在系统之外）或商业工作者（在系统内部）。如下所示，如果服务员被认为是演员，那么餐厅系统不包括服务员，并且该模型揭示了服务员和餐厅之间的互动。另一种选择是将服务员视为餐厅系统的一部分（商业工作者），同时考虑客户在系统之外（演员）。[32]

业务用例图描绘了几个模型业务用例（目标）代表餐厅（商业系统）与其主要利益相关者之间的互动商业演员和商业工作者）。

视觉建模

用例不仅是文本，而且是图表。在里面统一的建模语言，用例和参与者之间的关系表示用例图最初基于伊瓦尔·雅各布森对象符号。sysml在系统块级别使用相同的符号。

此外，其他行为UML图，例如活动图，序列图，沟通图， 和状态机图也可以用来相应地可视化用例。具体而言，系统序列图（SSD）是一个序列图，通常用于显示外部参与者与设计下的系统之间的相互作用（SUD），通常用于可视化用例的特定情况。

用例分析通常从绘制用例图表开始。为了敏捷开发，描述用例的许多UML图的需求模型以及一些文本描述，注释或用例简介将非常轻巧，足以容纳小型或简单的项目使用。作为对用例文本的良好补充，用例的视觉图表表示也是有效的促进工具，以更好地理解，沟通和设计复杂的系统行为要求。

例子

以下是示例用例编写，并带有稍微修改的Cockburn式模板。请注意，在基本用例描述中没有按钮，控件，表单或任何其他UI元素和操作，其中仅在基本流或扩展的每个步骤中都表示用户目标，子目标或意图。这种做法使需求规范更清晰，并最大程度地提高了设计和实施的灵活性。

Edit an article.svg

用例：编辑文章

主要演员： 成员（注册用户）

范围： 一个维基系统

等级：！（用户目标或海平面）

简短的：（相当于用户故事或史诗）

成员编辑他们正在阅读的文章的任何部分（整个文章或仅一部分）。在编辑过程中允许预览和更改比较。

利益相关者

...

后条件

最少的保证：
成功保证：
  • 该文章已保存并显示了更新的视图。
  • 该文章的编辑记录是由系统创建的，因此文章的观察者稍后可以告知该更新。

前提：

启用编辑的文章将提交给会员。

触发器：

成员在本文中调用编辑请求（全文或仅一部分）。

基本流程：

  1. 该系统提供了一个新的编辑区域/盒子，其中包含所有文章的相关内容，并提供信息的编辑摘要，以供成员编辑。如果成员只想编辑报告的一部分，则仅显示本节的原始内容，并且在编辑摘要中自动填写了部分标题。
  2. 成员修改文章的内容，直到满足会员为止。
  3. 成员填写编辑摘要，告诉系统是否要观看本文，并提交编辑。
  4. 系统保存文章，记录编辑事件，并完成任何必要的后处理。
  5. 该系统向会员提供了文章的更新视图。

扩展：

2–3。

一个。 Show Preview：
  1. 成员选择显示预览提交修改后的内容。
  2. 系统重新运行步骤1，添加了渲染的更新内容进行预览，并告知会员他/她的编辑尚未保存，然后继续进行。
b。显示更改：
  1. 成员选择显示变化提交修改后的内容。
  2. 系统重新运行步骤1，并添加了比较成员当前编辑之间的差异的结果，而本文的最新保存版本则继续进行。
C。取消编辑：
  1. 成员选择取消.
  2. 该系统会丢弃成员所做的任何更改，然后转到步骤5。

4a。暂停：

...

优点

自从敏捷运动的成立以来用户故事来自极端编程如此受欢迎，以至于许多人认为这是所有项目敏捷要求的唯一和最佳解决方案。Alistair Cockburn列出了他仍在写用例的五个原因敏捷发展.[33]

  1. 目标名称列表提供了最短摘要系统将提供的内容（即使在当时的用户故事）。它还提供了一个项目规划骨骼，用于建立初始优先级，估计，团队分配和时机。
  2. 每种用例的主要成功情况为所有与系统基本上要做什么以及它不做什么的协议相关的人。它为每个特定的订单项需求（例如细粒度的用户故事）提供了上下文，这种上下文很难获得其他任何地方。
  3. 每种用例的扩展条件提供了一个框架，用于调查所有小小的努力，这些东西以某种方式占用了开发时间和预算的80％。它提供了一种外观的机制，因此利益相关者可能会发现可能需要很长时间才能获得答案的问题。这些问题可以并且应该提前安排时间表，以便在开发团队开始努力时可以准备好答案。
  4. 用例扩展方案片段为许多详细，通常很棘手且忽略的商业问题提供了答案：“在这种情况下，我们该怎么办？”这是一个与if ...然后...的思维/文档框架相匹配。除了在调查时完成，而不是编程时间。
  5. 完整的用例表明，调查人员已经考虑了每个用户的需求，对系统的每个目标以及所涉及的每个业务变体。

总而言之，与传统或其他方法相比，用例指定系统要求具有这些明显的好处：

用户专注

用例构成了用于软件需求规范过程的功能强大的，以用户为中心的工具。[34]用例建模通常从识别关键利益相关者角色开始（演员）与系统互动及其目标必须实现的目标（外部视角）。然后，这些用户目标成为代表系统提供的所需功能功能或服务的用例名称或标题的理想候选者。这种以用户为中心的方法可确保具有实际业务价值和用户真正想要的东西，而不是从开发人员或系统（内部）角度推测的那些琐碎的功能。

用例创作一直是重要且有价值的分析工具以用户为中心的设计（UCD）多年。

更好的沟通

用例通常用带有结构化模板的天然语言编写。这种叙述性的文本形式（清晰的需求故事），几乎每个人都可以理解，并在所有利益相关者（包括客户，最终用户，开发人员，测试人员和经理）中提供了更好和更深入的沟通。更好的通信导致质量要求，从而交付了质量系统。

结构化探索的质量要求

用例最有力的事情之一是用例格式模板，尤其是主要的成功场景（基本流）和扩展方案片段（扩展，特殊和替代流）。分析从前提到后条件到后条件，探索和调查用例流的每个动作步骤（从基本到扩展）的每个动作步骤，以识别那些棘手的，通常是隐藏和忽略的那些棘手的，看似琐碎但实际上昂贵的要求（正如Cockburn提到的那样，上面）是一种系统的结构化和有益的方法，可以系统地获得清晰，稳定和质量要求。

最小化和优化用例以实现用户目标的动作步骤也有助于更好交互设计和用户体验系统。

促进测试和用户文档

借助基于动作或事件流结构的内容，编写良好的用例模型还可以作为设计案例和系统或产品的用户手册的出色基础和有价值的指南，这是一项努力的投资-正面。用例及其测试用例的流动路径之间存在明显的连接。通过其场景（用例的运行实例）从用例中得出功能性测试用例很简单。[35]

限制

用例的局限性包括：

  • 用例不适合捕获系统的非相互作用要求（例如算法或数学要求）或非功能要求（例如平台，绩效，时机或关键安全方面）。这些是在其他地方声明地指定的。
  • 由于没有完全标准的用例定义，因此每个项目都必须形成自己的解释。
  • 一些用例关系，例如扩展，解释性含糊不清，利益相关者很难理解Cockburn指出（问题6）[36]
  • 用例开发人员经常发现很难确定用户界面（UI）依赖性在用例中纳入。虽然用例理论表明在用例中不反映UI，但要抽象设计的这一方面可能会很尴尬，因为它使用例难以可视化。在软件工程中，通过申请解决这个困难要求可追溯性，例如用可追溯性矩阵。将UI元素与用例相关联的另一种方法是将UI设计附加到用例中的每个步骤。这称为用例情节板。
  • 用例可以过分强调。贝特兰·迈耶（Bertrand Meyer）讨论诸如从字面上的驾驶系统设计之类的问题，并使用用例使用其他潜在有价值的需求分析技术。[37]
  • 用例是测试设计的起点，[38]但是，由于每个测试都需要自己的成功标准，因此可能需要修改用例以为每条路径提供单独的后条件。[39]
  • 尽管用例包括目标和环境，但这些目标背后的目标和动机（利益相关者的关注点及其评估包括非交互）冲突还是对其他系统目标进行负面影响，是面向目标的需求建模技术的主题（例如BMM，我*，高锦鱼和存档盔甲）。

误解

关于用例的常见误解是：

用户故事很敏捷；用例不是。

敏捷和Scrum对需求技术是中性的。作为Scrum底漆[40]状态，

产品积压项目以任何清晰可持续的方式阐明。与流行的误解相反，产品积压不包含“用户故事”。它只是包含项目。这些项目可以表示为用户故事，用例或任何其他要求的方法。但是，无论方法如何，大多数项目都应该专注于为客户提供价值。

用例技术已经进化为通过使用用例切片来逐步丰富用例，以考虑敏捷方法。[13]

用例主要是图。

克雷格·拉曼（Craig Larman）强调“用例不是图表，它们是文本”。[41]

用例具有过多的与UI相关的内容。

正如某些人所说，[谁？]

用例通常包含一定程度的细节（即标签和按钮的命名），这使其不适合从头开始捕获新系统的要求。

新手误会。写得很好的用例的每个步骤都应存在演员目标或意图（功能要求的本质），通常不应包含任何用户界面详细信息，例如标签和按钮，UI操作等的命名，这是一个坏的练习，并将不必要地使用例写作复杂化并限制其实施。

至于从头开始捕获新系统的要求用例图加用例简介通常被用作方便而有价值的工具，至少像用户故事一样轻巧。

为大型系统编写用例很繁琐，而且时间浪费。

正如某些人所说，[谁？]

用例的格式使得很难在不到数百页的情况下描述大型系统（例如CRM系统）。这很耗时，您会发现自己花时间做不必要的返工。

花很多时间编写乏味的用例，这些用例不增加价值或很少的价值，并导致大量返工是一个臭气表明作家的技能不佳，并且对如何有效地编写质量用例不了解。用例应在迭代，增量和进化中撰写（敏捷） 方法。应用用例模板并不意味着应使用使用案例模板的所有字段，并在特殊的专用阶段进行全面填写，即传统的需求阶段瀑布发展模型。

实际上，用例格式由那些流行的模板样式，例如RUP和Cockburn的（也由OUM方法）等在实践中已被证明是捕获，分析和记录大型系统复杂要求的宝贵和有用的工具。好的用例文档的质量（模型）不应大部分或仅根据其大小来判断。大型系统的质量和全面用例模型也可能最终变成数百页，主要是因为该页面的固有复杂性问题手头，不是因为作者的写作技巧差。

工具

文本编辑和/或文字处理器使用模板支持通常用于编写用例。对于大型和复杂的系统要求，专用的用例工具很有帮助。

一些著名的用例工具包括：

最多UML工具支持用例的文本写作和视觉建模。

也可以看看

参考

  1. ^一个bcd伊瓦尔·雅各布森博士；伊恩·斯宾斯（Ian Spence）；库尔特·比特纳（Kurt Bittner）（2011年12月）。“用例2.0电子书”.伊瓦尔·雅各布森国际。 p。 4。检索8月9日2020.
  2. ^一个b雅各布森，伊瓦尔（1987年12月1日）。“工业环境中面向对象的发展”.ACM Sigplan注意到.22（12）：183–191。doi：10.1145/38807.38824.
  3. ^阿利斯泰尔的科克本（2002年3月）。“用例，十年后”.alistair.cockburn.us。 Alistair Cockburn。存档原本的2008年9月15日。检索4月17日2013.
  4. ^一个b雅各布森·伊瓦（Jacobson Ivar）；Christersson Magnus；乔恩森·帕特里克（Jonsson Patrik）；ÖvergaardGunnar（1992）。面向对象的软件工程：用例驱动方法。 ACM出版社。ISBN 0-201-54435-0.OCLC 26132801.
  5. ^一个b雅各布森，伊瓦尔。爱立信，玛丽亚；雅各布森（Jacobson），阿格尼塔（Agneta）（1995）。对象优势：使用对象技术重新设计业务流程。 Addison-Wesley。ISBN 0-201-42289-1.OCLC 32276135.
  6. ^“关于统一的建模语言规范版本2.5.1”.www.omg.org。检索8月9日2020.
  7. ^一个bcd统一软件开发过程。雅各布森（Ivar。）雷丁，马萨诸塞州：艾迪生 - 韦斯利。1999。ISBN 0-201-57169-2.OCLC 636807532.{{}}：CS1维护：其他（链接）
  8. ^一个b君士坦丁，拉里·L。（1995年4月1日）。“基本建模：用户界面的用例”.互动.2（2）：34–46。doi：10.1145/205350.205356.S2CID 17209049.
  9. ^一个b科克本，阿利斯泰尔。 （2001）。编写有效用例。 Addison-Wesley。ISBN 0-201-70225-8.OCLC 44046973.
  10. ^一个bcBittner，Kurt（2003）。用例建模。 Spence，伊恩。艾迪生·卫斯理。ISBN 0-201-70913-9.OCLC 50041546.
  11. ^Leffingwell，院长。 （2003）。管理软件要求：用例。威德里格，唐。（第二版）。Addison-Wesley。ISBN 0-321-12247-X.OCLC 51653240.
  12. ^Övergaard，Gunnar。 （2005）。用例：图案和蓝图。帕尔克维斯特，卡林。印第安纳波利斯，印第安纳州：艾迪生 - 韦斯利。ISBN 0-13-145134-0.OCLC 59554401.
  13. ^一个b雅各布森，伊瓦;Spence，伊恩；Bittner，Kurt（2011年12月）。“用例2.0：用用例成功指南”。伊瓦尔·雅各布森国际。检索5月5日2014.
  14. ^“ 2011年欧洲商业分析会议 - 2011年9月26日，英国伦敦”。 irmuk.co.uk。存档原本的2013年6月17日。检索4月17日2013.
  15. ^“用例2.0演示”.伊瓦尔·雅各布森国际。 2011年9月27日。检索8月9日2020.
  16. ^IEEE计算机协会（2014）。SWEBOK：软件工程知识体系指南。Bourque，Pierre，Fairley，R。E.（Richard E.）（版本3.0版）。IEEE计算机协会。pp。1-6至1-8。ISBN 978-0-7695-5166-1.OCLC 880350861.
  17. ^一个b对像管理组（2017）。“统一建模语言规范版本2.5.1”.www.omg.org。检索8月16日2020.
  18. ^Wiegers，Karl Eugene（2010）。有关软件要求的更多信息：棘手的问题和实用建议。 Microsoft Press。第11章。ISBN 978-0-7356-2267-8.OCLC 73814167.
  19. ^阿姆布勒，斯科特（2004）。“系统用例：敏捷介绍”.agileModeling.com。检索8月16日2020.
  20. ^Cockburn，2001年。前封面内部。图标“设计范围”。
  21. ^苏珊·罗伯逊（Suzanne Robertson）。需求中的方案发现。亚历山大和少女的第3章，2004年。第39-59页。
  22. ^Cockburn，2001年。前封面内部。图标“目标水平”。
  23. ^一个bcdefgh福勒，2004年。
  24. ^一个bCockburn，2001年。第120页。
  25. ^Cockburn，2001年。内部盖。字段“用例标题”。
  26. ^Alexander and Beus-Dukic，2009年。第121页
  27. ^http://wiki.c2.com/?userstoryandusecasecomparison[裸露的URL]
  28. ^http://wiki.c2.com/?userstoryandusecasecomparison[裸露的URL]
  29. ^一个bcdCockburn，2001年。第53页。
  30. ^Cockburn，2001年。第55页。
  31. ^一个bAlexander and Beus-Dukic，2009年。第39页。
  32. ^Eriksson，Hans-Erik（2000）。使用UML的业务建模。纽约：Wiley Computer Publishing。pp。52.ISBN 0-471-29551-5.
  33. ^阿利斯泰尔的科克本（2008年1月9日）。“为什么我仍然使用案例”.alistair.cockburn.us.
  34. ^卡尔·威格斯（Karl Wiegers）（1997年3月）。“听客户的声音”.过程影响。软件开发。
  35. ^Peter Zielczynski（2006年5月）。“从用例到测试案例的可追溯性”。 IBM Developerworks。
  36. ^“ alistair.cockburn.us-将用例结构为目标”.alistair.cockburn.us。检索3月16日2018.
  37. ^迈耶，2000年。（需要页面）
  38. ^Armor and Miller，2000年。（需要页面）
  39. ^丹尼，2005年。（需要页面）
  40. ^皮特·迪默（Pete Deemer）；加布里埃尔·恩奇菲尔德；克雷格·拉曼（Craig Larman）；Bas Vodde（2012年12月17日）。“ Scrum Primer：Scrum理论和实践的轻量级指南（版本2.0）”。 infoq。
  41. ^拉曼（Larman），克雷格（2005）。应用UML和图案。 Prentice Hall。第63-64页。ISBN 0-13-148906-2.

进一步阅读

  • 亚历山大，伊恩（Ian）和贝斯·杜基（Beus-Dukic），ljerka。发现要求：如何指定产品和服务。威利，2009年。
  • 亚历山大，伊恩和梅登，尼尔。场景，故事，用例。 Wiley 2004。
  • 装甲，弗兰克和格兰维尔·米勒。高级用例建模：软件系统。 Addison-Wesley，2000年。
  • Kurt Bittner，Ian Spence，用例建模，Addison-Wesley Professional，2002年8月20日。
  • 科克本，阿利斯泰尔。编写有效的用例。Addison-Wesley，2001年。
  • 拉里·康斯坦丁（Larry Constantine），露西·洛克伍德（Lucy Lockwood），使用软件：以使用为中心设计的基本模型和方法的实用指南，Addison-Wesley，1999年。
  • 丹尼，理查德。成功案例成功：智能工作以提供质量。 Addison-Wesley，2005年。
  • 福勒，马丁。UML蒸馏（第三版）。 Addison-Wesley，2004年。
  • 雅各布森·伊瓦尔（Jacobson Ivar），Christersson M.，Jonsson P.，ÖvergaardG.，面向对象的软件工程 - 用例驱动方法，Addison-Wesley，1992年。
  • 雅各布森·伊瓦（Jacobson Ivar），斯宾塞（Spence I.）用例2.0：用用例成功指南，IJI SA，2011年。
  • Dean Leffingwell，Don Widrig，管理软件要求：用例，Addison-Wesley专业人士。2012年12月7日。
  • Kulak，Daryl和Eamonn Guiney。用例：上下文中的要求。Addison-Wesley，2012年。
  • 迈耶，伯特兰。面向对象的软件构建。（第二版）。Prentice Hall，2000年。
  • 施耐德（Schneider），格里（Geri）和温特斯（Winters），杰森（Jason P.）应用用例第二版：实用指南。 Addison-Wesley，2001年。
  • Wazlawick，Raul S.信息系统面向对象的分析和设计：使用UML，OCL和IFML建模。摩根·考夫曼（Morgan Kaufmann），2014年。

外部链接