“用户故事和用例是一样的吗?”人们经常会问这个问题，关于敏捷团队应该实践使用故事还是用例的争论已经持续多年了。用户故事和用例是一回事吗?如果不是，哪一个更好?你应该使用哪一个?或者两者都使用?

虽然用户故事和用例之间有一些相似之处，但用户故事和用例是不可互换的;用户场景和用例都标识用户，它们都描述了目标，但是它们服务于不同的目的。

用户场景集中于您所描述的结果和好处，而用例可以更细粒度地描述系统将如何运行。用例在敏捷中有一席之地吗?或者它们可以相互结合使用吗?

本文将告诉您用户故事和用例之间的区别。

用户故事vs用例

用户故事往往一开始一样的用例,在每个描述了一种使用该系统,是围绕一个目标,从用户的角度来看,使用业务的自然语言,——自己不告诉整个故事。

用户故事与用例的相似性

如果我们考虑这两种方法的关键组成部分:

• 用户故事包含用户角色、目标和验收标准。
• 用例包含等价的元素:参与者、事件流和post条件分别(一个详细的用例模板可能包含更多的其他元素)。

用户故事与用例的区别

• 用户故事的细节可能不像用例那样被记录到相同的极端。
• 用户故事故意省略了许多重要的细节。用户故事的目的是通过在scrum会议上提出问题来引出对话。
• 为了更频繁地获得反馈而进行小的增量，而不是像用例中那样拥有更详细的预先需求规格说明。

什么是用户故事?

用户故事是一个记录，它捕捉用户在其工作中所做的或需要做的事情。每个用户故事都由一段用自然语言从用户的角度编写的简短描述组成。与传统的需求捕获不同，用户描述关注的是用户的需求，而不是系统应该交付的内容。这为进一步讨论解决方案和系统结果留下了空间，该系统能够真正适应客户的业务流程，解决他们的操作问题，最重要的是为组织增加价值。

3C的概念

3C指的是优秀用户故事的三个关键方面。这个概念是由用户故事实践的共同发明人Ron Jeffries提出的。现在，当我们谈到用户故事时，我们通常指的是由这三个方面组成的用户故事。

卡(Card)

用户故事被写成卡片。每个用户故事卡上都有一个简短的句子和足够的文字来提醒每个人故事是关于什么的。

谈话(Conversation）

在整个软件项目中，通过客户和开发团队之间的持续对话来发现和重新确定需求。重要的想法和决定会在涉众会议期间被发现并记录下来。

确认（Confirmation）

确认也称为用户故事的验收标准。在讨论需求的过程中，客户不仅告诉分析师他/她想要什么，还确认在什么条件和标准下接受或拒绝工作软件。定义的案例以确认书的形式书写。注意，确认关注于验证相应用户描述工作的正确性。它不是一个集成测试。

什么是用例?

用例是在20多年前由Ivar Jacobson引入的，用于在描述系统的功能需求时捕获用户(参与者)的观点。它们描述了用户使用软件系统一步步完成目标的过程。

用例是对最终用户想要“使用”系统的所有方式的描述。用例捕获用户和系统交互的所有可能方式，从而使用户实现目标。它们还捕捉了在过程中可能出现的所有问题，这些问题会妨碍用户实现目标。

用例模型由许多模型元素组成。最重要的模型元素是:

• 用例,
• 演员
• 以及它们之间的关系。

详细的用例说明

用例规范是系统提供的功能的文本描述。它捕获了角色与系统的交互。也就是说，它指定用户如何与系统交互，以及系统如何响应用户的操作。它通常以参与者和系统之间对话的形式出现。用例规格说明在用例图中由一个椭圆形表示，并且是大多数人在听到术语用例时想到的。

为什么我们仍然需要用例?

Alistair Cockburn解释说，他发现(在他咨询的公司)用户故事有三个主要问题:

• 缺乏背景(最大的目标是什么)
• 完成感，你涵盖了与目标相关的所有基础。
• 没有预见未来工作的机制。

集成用例、用户故事和故事映射技术

Visual Paradigm提供了一个完整的敏捷环境，它将用例、用户故事、故事映射、关联评估和看板集成到一个完全无缝的、自动化的端到端流程中。这个过程可以通过补充用例和故事映射工具来解决Alistair在上面提到的用户故事技术的缺点。为了更快、更好、更智能地管理您的敏捷项目，还整合了其他有用的敏捷工具。

下面的概念图概述了Visual Paradigm支持的敏捷工具。

1. 将可视化模型中的需求作为产品待办事项列表项发送(用于构建故事图)
2. 故事图中的用户活动，它代表了一个大的系统上下文作为一个整体
3. 活动、任务和故事的垂直结构——待办事项的完整性
4. 发布管理
5. 根据用户的开发工作和风险评估用户描述
6. 使用sprint管理开发活动
7. 使用sprint任务板跟踪进度

第1点到第3点是用来补充用户故事不足的工具。其他用户敏捷工具列在第4到第7点。

 

原文：https://www.visual-paradigm.com/guide/agile-software-development/user-story-vs-use-case/

本文：http://jiagoushi.pro/node/1218

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

需求分析，也称为需求工程，是定义用户对正在构建或修改的新软件的期望的过程。在软件工程中，它有时被一些松散的名称所引用，例如需求收集或需求捕获。需求分析包括那些为一个新的或改变的产品或项目确定需要或满足的条件的任务，考虑不同涉众的可能冲突的需求，分析、记录、验证和管理软件或系统需求。以下是在软件项目的早期阶段进行需求分析的目标:

• 从什么到如何（From What to How）:
  • 弥合系统需求工程和软件设计之间差距的软件工程任务。
• 3个正交视图:为软件设计人员提供如下模型:

  • 系统信息(静态视图)

  • 函数(功能视图)

  • 行为(动态视图)

• 软件架构:模型可以转换为数据、体系结构和组件级设计。
• 迭代和增量过程:期望在分析期间做一点设计，在设计期间做一点分析。

需求是什么?

软件需求是用户解决问题或实现目标所需要的能力。换句话说，需求是系统或系统组件必须满足或拥有的软件能力，以满足合同、标准、规格说明或其他正式强加的文档。最终，我们想要实现的是在预算范围内及时开发出满足客户实际需求的高质量软件。

也许软件开发人员面临的最大挑战是与客户共享最终产品的远景。项目中的所有涉众——开发人员、终端用户、软件经理、客户经理——必须对产品将会是什么样子以及要做什么有一个共同的理解，否则当产品交付时，会有人感到惊讶。软件领域的意外几乎从来不是好消息。

因此，在指定软件产品的需求时，我们需要一些方法来准确地捕获、解释和表示客户的声音。

需求分析的活动

需求分析对系统或软件项目的成功或失败至关重要。需求应该被记录下来，可操作的，可测量的，可测试的，可跟踪的，与已识别的业务需求或机会相关的，并且被定义到足以用于系统设计的详细级别。从概念上讲，需求分析包括四种类型的活动:

• 获取需求:与客户和用户沟通以确定他们的需求的任务。这有时也称为需求收集。
• 分析需求:确定所陈述的需求是否不清楚、不完整、含糊或矛盾，然后解决这些问题。
• 需求建模:需求可能以各种形式被记录，例如自然语言文档、用例、用户故事或过程规范。
• 评审（review）和回顾（retrospective）:团队成员对迭代中发生的事情进行反思，并确定下一步改进的行动。

需求分析是一项团队工作，需要硬件、软件和人的因素、工程专业知识以及与人打交道的技能的结合。以下是在需求分析中涉及到的主要活动:

• 确定客户的需求。
• 评估系统的可行性。
• 进行经济和技术分析。
• 分配功能到系统元素。
• 制定时间表和约束条件。
• 创建系统定义。

需求分析技术

需求分析帮助组织确定涉众的实际需求。同时，它使开发团队能够用他们能够理解的语言(如图表、模型、流程图)与涉众进行交流，而不是使用页面文本。

一旦收集了需求，我们就将需求记录在软件需求规范(SRS)文档、用例或用户故事中，与涉众共享以获得批准。该文档对于普通用户和开发人员来说都很容易理解。要求中的任何变更也要形成文件，并通过变更控制程序，并在批准后定稿。

业务需求vs软件需求

一个商业计划或项目需要各种各样的需求来帮助定义目标和建立将要进行的工作的范围。需求还提供了环境和客观的方法来度量进展和成功。一旦建立了业务需求，就可以定义和开发软件需求，以便将项目向前推进。

业务需求

业务需求与业务的目标、愿景和目标相关。它们还提供了需要通过特定活动或项目来解决的业务需求或问题的范围。例如，如果一个行业协会的目标是促进其成员提供的服务，那么项目的业务需求可能包括创建一个成员目录，以提高成员的认知度。良好的业务需求必须是:

• 清晰的，通常在一个非常高的层次上定义。
• 提供足够的信息和指导，以帮助确保项目满足确定的需求。
• 理解组织的任务、目标或目标、特定的业务需求或正在处理的问题
• 在开发业务需求之前，应该清楚地定义和理解。
• 需求或问题可以与组织或业务有关，也可以集中于利益相关者群体，如客户、客户、供应商、员工或其他群体。

软件需求

软件需求分解满足业务需求或需求所需的步骤。业务需求描述了项目的“为什么”，而软件需求则描述了“是什么”。

例如,如果业务需求是创建一个贸易协会成员的一个目录,软件需求将概述谁有权访问的目录,有会员注册目录,谁会有数据的所有权,将使用什么车辆或车辆如一个网站或纸质目录,等等。

发现业务需求的技术

根据业务改进和软件开发过程，可以使用各种需求分析技术。下面列出了其中的一些技术。

使用BPMN或ArchiMate进行Gap分析

差距常被说成是“你现在的位置和你想要的位置之间的距离”。差距分析是基线和目标业务场景之间的比较过程。换句话说，差距分析是对企业当前在做什么以及未来想要去哪里的研究，是作为一种连接两者之间空间的手段。差距分析的目标是确定在优化性能方面的差距。这为企业提供了对潜在改进的洞察。它回答了一些问题，比如项目的当前状态是什么?我们想去哪里?等。

ArchiMate - Gap分析

ArchiMate是一种开放和独立的企业架构建模语言，支持以明确的方式描述、分析和可视化业务域内和跨业务域的架构。它是一个完美的建模工具，具有执行差距分析所需的符号。

BPMN -原有和将来的分析

原有流程

我们将要演示的示例是关于销售商品的在线商店的当前情况(原有流程)。该流程从销售代表收到客户的采购订单开始，然后检查库存水平。如果手头有足够的存货来满足订单的要求，销售代表将对其进行包装。这个过程结束于将它们连同发票一起发送。当库存不足时，销售代表将建议客户修改采购订单。

将来流程

假设我们的生意发展得很好，我们现在有一个仓库来存放我们的存货。因此，我们正在寻找改进现有流程的方法，以更好地分配新资源。此外，我们将在下面的将来流程图中展示一个对增强进行建模的示例。

业务动机模型

如果一个企业为其业务活动规定了某种方法，它应该能够说出该方法要达到的原因(why)和目的(what)。业务动机模型(BMM)是一种OMG建模符号，用于支持关于如何对不断变化的世界作出反应的业务决策。企业可以通过获取BMM建模工具来使用它，然后创建自己的BMM——用特定于企业的业务信息填充模型。主要有两个目的:

• 获取关于对变化的反应的决策和做出决策的理由，目的是使它们可分享，增加清晰度，并通过经验学习来改进决策。
• 参考决策的结果及其对运营业务的影响(例如，对业务流程和组织责任的变更)，提供从影响者到运营变更的可追溯性。

End ：定义一个企业想要成为什么样子——它想要进入的状态。

Means (意味者)：——定义一个企业需要做什么来实现它的目标。

Influencer （影响者）——是企业决定可能影响它的东西。

Assessment （评估）——当影响者引起重大变化时，企业对其影响进行评估，识别风险和潜在回报。可能会有多个评估，可能来自不同的利益相关者。

客户旅程映射

客户旅程图是一项非常有用的技术，它可以帮助你理解是什么激发了你的客户——他们的需求是什么，他们的犹豫和担忧。尽管大多数组织相当擅长收集关于客户的数据，但仅凭数据无法传达客户所经历的挫折和体验。一个故事可以做到这一点，而商业中最好的讲故事工具之一就是客户旅程图。

客户旅程地图(Customer journey map)使用讲故事和视觉效果来说明客户在一段时间内与企业之间的关系。故事是从客户的角度讲述的，这提供了对客户整体体验的洞察。它帮助您的团队更好地理解和解决客户的需求和痛点，因为他们在体验您的产品或服务。换句话说，规划好客户之旅可以让你的企业有机会看到你的品牌如何首先吸引潜在客户，然后再通过整个销售过程的接触点。

最后，团队可以针对每个接触点提出改进或采取的行动。这些建议的行动可能是软件需求的潜在来源。

从业务需求中识别软件需求的技术

数据流图

数据流程图(DFD)可在SDLC(系统开发生命周期)内分析阶段的需求引出过程的早期设计，以界定项目范围。DFD通常用作创建系统概述的一个初步步骤，而不需要详细说明，稍后可以详细说明。

例如，如果需要在某个特定流程中显示更多细节，则该流程将在较低级别的DFD中分解为许多较小的流程。这样，内容图或上下文层次的DFD被标记为“0级DFD”，下一级分解被标记为“1级DFD”，下一级分解被标记为“2级DFD”，以此类推。

用例

UML用例图是未开发的新软件程序的系统/软件需求的主要形式。用例指定了预期的行为(什么)，而不是使其发生的确切方法(如何发生)。用例一旦指定，就可以同时表示为文本和可视化表示(例如UML)。用例建模的一个关键概念是，它帮助我们从最终用户的角度设计系统。它是一种通过指定所有外部可见的系统行为来用用户的术语交流系统行为的有效技术。

• 用例图通常很简单。它没有显示用例的细节。
• 它只是总结了用例、参与者和系统之间的一些关系。
• 它没有显示为实现每个用例的目标而执行的步骤的顺序。

用例图的标准形式是用统一建模语言定义的，如下面的用例图示例所示:

用户故事

用户故事是捕捉用户在工作中所做或需要做的事情的注释。每个用户故事都由一段用自然语言从用户的角度编写的简短描述组成。与传统的需求捕获不同，用户描述关注的是用户需要什么，而不是系统应该交付什么。这为进一步讨论解决方案和系统结果留下了空间，该系统能够真正适应客户的业务流程，解决他们的操作问题，最重要的是为组织增加价值。用户故事与其他敏捷软件开发技术和方法(如scrum和极限编程)很好地兼容。

用户故事与用例的相似性

如果我们考虑这两种方法的关键组成部分:

• 用户故事包含用户角色、目标和验收标准。
• 用例包含等价的元素:参与者、事件流和分别的post条件(一个详细的用例模板可能包含更多的其他元素)。

用户故事与用例的区别

• 用户故事的细节可能不像用例那样被记录到相同的极端。
• 用户故事故意省略了许多重要的细节。用户故事的目的是通过在scrum会议上提出问题来引出对话。
• 为了更频繁地获得反馈而进行小的增量，而不是像用例中那样拥有更详细的预先需求规格说明。

 

原文：https://www.visual-paradigm.com/guide/requirements-gathering/requirement-analysis-techniques/

本文：http://jiagoushi.pro/node/1216

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】