业务分析 - 快速指南

---

业务分析 - 简介

什么是商业分析？

业务分析是识别业务需求并确定企业业务问题的解决方案所需的任务、知识和技术的集合。尽管一般定义相似，但不同行业的做法和程序可能有所不同。

在信息技术行业，解决方案通常包括系统开发组件，但也可能包括流程改进或组织变革。

还可以执行业务分析来了解组织的当前状态或作为识别业务需求的基础。然而，在大多数情况下，执行业务分析是为了定义和验证满足业务需求、目的或目标的解决方案。

谁是业务分析师？

业务分析师是分析组织或业务领域（真实的或假设的）并记录其业务、流程或系统，评估业务模型或其与技术的集成的人。然而，组织头衔各不相同，例如分析师、业务分析师、业务系统分析师或系统分析师。

为何选择业务分析师？

组织采用业务分析的原因如下：

• 了解要部署系统的组织的结构和动态。

• 了解目标组织当前的问题并确定改进潜力。

• 确保客户、最终用户和开发人员对目标组织有共同的理解。

在项目的初始阶段，当解决方案和设计团队解释需求时，业务分析师的作用是审查解决方案文档，与解决方案设计人员（IT 团队）和项目经理密切合作，以确保要求明确。

在典型的大型 IT 组织中，尤其是在开发环境中，您可以找到具有上述角色的现场和离岸交付团队。您可以找到一位“业务分析师”，他充当连接两个团队的关键人物。

有时，他会与业务​​用户互动，有时会与技术用户互动，最后与项目中的所有利益相关者互动，以获得批准和最终点头，然后再继续处理文档。

因此，BA 的作用对于任何项目的有效和成功启动都至关重要。

IT 业务分析师的角色

业务分析师的角色从定义和界定组织的业务领域开始，然后引出需求，分析和记录需求，将这些需求传达给适当的利益相关者，确定正确的解决方案，然后验证解决方案以确定是否符合要求。要求达到预期标准。

与其他职业有何不同？

业务分析不同于财务分析、项目管理、质量保证、组织发展、测试、培训和文档开发。但是，根据组织的不同，业务分析师可以执行部分​​或全部这些相关职能。

专门从事开发软件系统的业务分析师可以称为 IT 业务分析师、技术业务分析师、在线业务分析师、业务系统分析师或系统分析师。

业务分析还包括利益相关者、开发团队、测试团队等之间的联络工作

软件开发生命周期

软件开发生命周期 (SDLC) 是软件组织内软件项目遵循的过程。它包含一个详细的计划，描述如何开发、维护、替换、更改或增强特定软件。它定义了提高软件质量和整体开发过程的方法。

• SDLC 是 IT 分析师用来开发或重新设计高质量软件系统的过程，以满足客户和现实世界的要求。

• 它考虑了软件测试、分析和后期维护的所有相关方面。

下图描述了 SDLC 的重要阶段 -

策划阶段

每项活动都必须从计划开始。不计划就等于计划失败。不同模型的规划程度有所不同，但通过创建系统规范来清楚地了解我们将要构建的内容非常重要。

定义阶段

在这个阶段，我们分析和定义系统的结构。我们定义架构、组件以及这些组件如何组合在一起以生成一个工作系统。

设计阶段

在系统设计中，详细描述了设计功能和操作，包括屏幕布局、业务规则、流程图和其他文档。此阶段的输出将新系统描述为模块或子系统的集合。

搭建阶段

这是发展阶段。我们使用编译器、解释器、调试器根据系统设计开始代码生成，以使系统栩栩如生。

执行

实施是构建阶段的一部分。在此阶段，我们使用编译器、解释器、调试器根据系统设计开始代码生成，以使系统栩栩如生。

测试阶段

随着系统的不同部分完成；他们要经过一系列的测试。它根据需求进行测试，以确保产品确实解决了需求阶段所解决的需求。

• 测试计划和测试用例用于识别错误并确保系统按照规范运行。

• 在此阶段，完成不同类型的测试，如单元测试、手动测试、验收测试和系统测试。

测试中的缺陷跟踪

软件测试报告用于传达已执行测试计划的结果。在这种情况下，报告应包含与当前正在测试的系统有关的所有测试信息。报告的完整性将在演练会议中进行验证。

项目测试旨在实现两个主要目标 -

• 检测系统中的故障和缺陷。

• 检测需求和实施之间的不一致。

以下流程图描述了缺陷跟踪过程-

为了实现主要目标，所提议系统的测试策略通常包括四个测试级别。

这些是单元测试、集成测试、验收测试和回归测试。以下小节概述了这些测试级别、哪些开发团队角色负责开发和执行它们，以及确定其完整性的标准。

部署

测试阶段结束后，系统发布并进入生产环境。一旦产品经过测试并准备好部署，就会在适当的市场上正式发布。有时，产品部署会根据组织的业务策略分阶段进行。

该产品可能首先在有限的细分市场中发布，并在真实的业务环境中进行测试（UAT-用户验收测试）。然后，根据反馈，产品可能会按原样发布，或者在目标细分市场中添加建议的增强功能。

SDLC 后流程

产品投放市场后，针对现有客户群进行维护。

一旦进入生产环境，系统将因未检测到的错误或其他意外事件而遭受修改。对系统进行评估并重复该循环以维护系统。

业务分析师在 SDLC 流程中的角色

如下图所示，BA 参与驱动业务需求并将其转换为解决方案需求。

他参与将解决方案功能转化为软件需求。然后领导分析和设计阶段，指导代码开发，然后作为项目团队中的变更代理在错误修复期间进行测试阶段，并最终满足客户的要求。

业务分析 - 角色

业务分析师在 IT 项目中的角色可以是多重的。项目团队成员可以担任多个角色和职责。在某些项目中，当可用资源有限时，BA 可能会担任商业智能分析师、数据库设计师、软件质量保证专家、测试员和/或培训师的角色。

项目协调员、应用程序开发主管或开发人员也可以在特定项目中担任业务分析师的角色。

业务分析与对业务正常运作和优化其运作方式的需求分析有很大的重叠。业务分析的一些例子是 -

• 创建业务架构
• 准备商业案例
• 进行风险评估
• 需求获取
• 业务流程分析
• 需求文件

BA的主要角色

大多数业务分析师的关键角色是业务和技术开发人员之间的联络。业务分析师与业务客户一起收集/定义系统或流程的需求，以提高生产力，同时与技术团队合作设计和实施系统/流程。

作为贡献者

BA 的主要职责是在识别业务问题、需求和功能方面为业务用户/关键用户的发展做出贡献，了解利益相关者的关注点和要求以识别改进机会，并为开发 IT 业务案例提供业务投入系统开发项目。

作为协调员

业务分析师还应该促进/协调需求的获取和分析，与利益相关者协作和沟通，管理他们的期望和需求，并确保需求完整、明确并将其映射到实时业务需求一个组织的。

作为分析师

另一个重要作用是评估拟议的系统和组织对系统实施的准备情况，为用户提供支持并与 IT 人员进行协调。

帮助从业务角度审查拟议IT系统的设计并提供意见，解决利益相关者之间的问题/冲突，通过协助用户开发测试用例来帮助组织全面和高质量的UAT，并帮助组织培训以确保部署的IT系统能够满足业务需求和要求并实现预期效益。

规划和监控业务分析活动，以制定范围、执行与 IT 系统开发项目业务分析相关的活动的时间表和方法，监控进度，与内部项目经理协调，并报告收入、盈利能力、风险和问题合适的。

业务分析师的主要职责

业务分析师的职责要求他在项目的不同阶段履行不同的职责，如下所示 -

启动阶段

此阶段将标志着新项目的开始，业务分析师将承担以下职责 -

• 协助进行项目的成本效益分析。
• 了解业务案例。
• 确定解决方案/项目/产品的可行性。
• 帮助创建项目章程。
• 确定项目中的利益相关者。

规划阶段

此阶段将涉及收集需求和规划以及项目的执行和管理方式。他的职责包括以下职能 -

• 引出需求
• 分析、组织和记录需求。
• 通过创建用例、RTM、BRD、SRS 等来管理需求。
• 评估建议的解决方案。
• 联络并加强与利益相关者的沟通。
• 协助制定项目管理计划。
• 帮助确定项目的范围、限制、假设和风险。
• 协助设计解决方案的用户体验。

执行阶段

此阶段标志着根据收集的需求开发解决方案。职责包括 -

• 向 IT/开发团队解释需求。

• 澄清对拟制定的拟议解决方案的疑虑和担忧。

• 讨论项目范围变更并确定其优先顺序并达成一致。

• 创建用于初始测试的 Beta 测试脚本。

• 与利益相关者共享开发模块并征求他们的反馈。

• 遵循最后期限并管理利益相关者的期望。

• 解决冲突并管理与项目团队的沟通。

监控阶段

在此阶段，将测量和控制项目是否与初始计划有任何偏差。该阶段与执行阶段同时运行。

• 开发测试脚本并进行全面的模块和集成测试。

• 进行UAT（使用验收测试）并创建测试报告。

• 获得客户对可交付成果的接受/批准。

• 向开发团队解释变更请求。

• 监控变更请求的进展并根据项目目标验证其实施情况。

结束阶段

此阶段标志着项目的结束。职责是 -

• 向客户展示已完成的项目并获得他们的认可。

• 创建用户培训手册、任何功能材料和其他教学指南。

• 在生产环境中进行精细的集成测试。

• 创建最终产品文档，记录项目经验教训。

BA 期望提供什么？

业务分析师充当业务用户和 IT 技术人员之间的桥梁。他们的存在将为 IT 项目的成功做出重大贡献。拥有一名专门的业务分析师有很多好处。专门的业务分析师可以 -

• 从业务角度提供清晰的项目范围。

• 开发合理的业务案例以及对资源和业务收益进行更现实的估计。

• 在成本和进度方面准备更好的项目范围、规划和管理报告，尤其是大型 IT 项目。

• 产生清晰简洁的需求，如果 IT 项目外包，这反过来又有助于提供更清晰、更准确的需求。

• 挖掘用户真实的业务需求，有效管理用户期望。

• 提高拟议 IT 系统的设计质量，使其满足用户需求。

• 确保开发系统的质量，然后再传递给最终用户进行审查和验收。

• 对交付的系统安排全面的质量测试并向 IT 技术人员提供反馈。

业务分析 - 工具和技术

当您担任 BA 帽子时，业务分析师应该熟悉各种分析工具和相关技术。我的意思是，如果你担任这个职位。

正如我们之前已经了解到的，业务分析是一个过程，您试图了解一个企业并识别机会、问题领域和问题，并会见具有广泛角色和职责的各种人员，例如首席执行官、副总裁、总监和了解他们的业务需求。

从根本上来说，业务分析有 3 种类型，我们可以将其分类为 -

• 战略分析- 战略业务分析涉及项目前的工作。它是帮助高层管理人员识别业务问题、制定业务战略、目标和目的的方法或过程。它为有效的决策过程提供管理信息报告。

• 战术分析- 它涉及特定业务分析技术的知识，可在适当的时间应用到适当的项目中。

• 运营分析- 在这种类型的业务分析中，我们通过利用信息技术专注于业务方面。这也是一个研究运营系统的过程，旨在识别业务改进的机会。

对于每种类型的分析，市场上都有一组可用的工具，并且可以根据组织的需求和要求使用这些工具。

然而，为了将业务需求具体化为可理解的信息，优秀的 BA 将在日常活动中利用事实调查、访谈、文件审查、调查问卷、抽样和研究等技术。

功能性和非功能性要求

我们可以将需求分为两种主要类型，例如功能性需求和非功能性需求。

对于所有技术项目，功能性和非功能性需求必须分开并单独分析。

定义适当的工具和适当的技术可能是一项艰巨的挑战。无论您是在创建全新的应用程序还是对现有应用程序进行更改。考虑功能流程的正确技术本身就是一门艺术。

目前市场上广泛使用的业务分析技术的概述 -

工具和流程的适用性

尽管业务分析师可以使用多种工具和程序，但这完全取决于组织当前的实践以及他们希望如何使用它们。

例如，当需要深入研究某个重要领域或功能时，可以使用根本原因分析。

然而，业务需求文档是以文档格式提出需求的最流行和接受的方式。

在后续章节中，我们将深入讨论上述一些技术。

业务分析 - JAD 会议

联合应用程序开发 (JAD) 是用于在为公司开发新信息系统时收集业务需求的过程。JAD 流程还可能包括增强用户参与、加快开发和提高规范质量的方法。JAD 会议的目的是汇集主题专家/业务分析师或 IT 专家来提出解决方案。

业务分析师是与整个团队互动并收集信息、分析信息并生成文档的人。他在JAD会议中扮演着非常重要的角色。

使用 JAD 会话

JAD 会议是高度结构化、便利的研讨会，将客户决策者和 IT 员工聚集在一起，在短时间内生成高质量的交付成果。

换句话说，JAD 会话使客户和开发人员能够快速就项目的基本范围、目标和规范达成一致，或者在无法达成一致的情况下意味着需要重新评估项目。

简而言之，JAD 会话可以

• 简化- 将数月的会议和电话整合到一个结构化的研讨会中。

• 确定- 问题和参与者

• 量化- 信息和处理需求

• 澄清- 明确并澄清会议中商定的所有要求。

• 统一- 一个开发阶段的输出将输入到下一阶段。

• 满足- 客户定义系统；因此，这是他们的系统。共同参与带来成果的分享；他们致力于系统的成功。

JAD 会议的参与者

JAD 会议的参与者如下：

执行发起人

执行发起人是项目的推动者——系统所有者。他们通常职位较高，能够做出决策并提供必要的战略、规划和方向。

主题专家

这些是成功举办研讨会所需的业务用户和外部专家。主题专家是 JAD 会议的骨干。他们将推动变革。

协调员

会议由他主持；他指出了可以在会议中解决的问题。协调人不会向会议提供信息。

关键用户

关键用户或在某些情况下也称为超级用户可以互换使用，并且因公司而异。关键用户通常是与 IT 项目更紧密结合的业务用户，并负责项目期间团队成员配置文件的配置。

例如：假设 John 是关键用户，Nancy、Evan 是 SAP 系统的用户。在这种情况下，Nancy 和 Evan 无权更改功能和配置文件，而 John 作为关键用户可以以更多权限编辑配置文件。

与更传统的做法相比，JAD 方法被认为可以缩短开发时间并提高客户满意度，因为客户参与整个开发过程。相比之下，在传统的系统开发方法中，开发人员调查系统需求并开发应用程序，并通过一系列访谈组成客户输入。

需求收集技术

技术描述了在特定情况下如何执行任务。一项任务可能没有相关技术，也可能没有一个或多个相关技术。一项技术应该与至少一项任务相关。

以下是一些众所周知的需求收集技术 -

头脑风暴

头脑风暴用于收集需求，以从人群中获得尽可能多的想法。通常用于确定问题的可能解决方案，并阐明机会的细节。

文件分析

查看现有系统的文档有助于创建 AS-IS 流程文档，并推动差距分析以确定迁移项目的范围。在理想的情况下，我们甚至会审查推动现有系统创建的需求——这是记录当前需求的起点。信息块通常隐藏在现有文档中，帮助我们提出问题，作为验证需求完整性的一部分。

焦点小组

焦点小组是代表产品用户或客户的人员聚集在一起以获得反馈。可以收集有关需求/机会/问题的反馈来识别需求，或者可以收集反馈来验证和完善已经提出的需求。这种形式的市场研究与头脑风暴不同，因为它是一个由特定参与者管理的过程。

界面分析

软件产品的接口可以是人的或机器的。与外部系统和设备的集成只是另一个接口。以用户为中心的设计方法非常有效地确保我们创建可用的软件。界面分析——检查与其他外部系统的接触点对于确保我们不会忽视用户无法立即看到的需求非常重要。

面试

利益相关者和用户的访谈对于创建优秀的软件至关重要。如果不了解用户和利益相关者的目标和期望，我们就不太可能满足他们。我们还必须认识到每个受访者的观点，以便我们能够正确衡量和解决他们的意见。倾听是一种技能，可以帮助优秀的分析师从面试中获得比普通分析师更多的价值。

观察

通过观察用户，分析师可以识别流程、步骤、痛点和改进机会。观察可以是被动的，也可以是主动的（观察时提出问题）。被动观察更适合获取原型反馈（以细化需求），而主动观察更能有效了解现有业务流程。可以使用任何一种方法。

原型制作

原型设计是一种相对现代的收集需求的技术。在这种方法中，您收集初步需求，用于构建解决方案的初始版本 - 原型。您将其展示给客户，然后客户会向您提出其他要求。您更改应用程序并再次与客户循环。这个重复的过程一直持续到产品满足业务需求的临界量或达到商定的迭代次数为止。

需求研讨会

研讨会对于收集需求非常有效。比头脑风暴会议更加结构化，相关各方协作记录需求。捕获协作的一种方法是创建域模型工件（如静态图、活动图）。由两名分析师参加的研讨会比由一名分析师参加的研讨会更有效。

逆向工程

当迁移项目无法访问现有系统的足够文档时，逆向工程将识别系统的功能。它不会识别系统应该做什么，也不会识别系统何时做了错误的事情。

调查/问卷

当从很多人那里收集信息时——由于预算和时间限制，太多人无法采访——可以使用调查或问卷。该调查可以迫使用户从选项中进行选择，对某些内容进行评分（“强烈同意，同意......”），或者提出允许自由形式回答的开放式问题。调查设计很困难——问题可能会让受访者产生偏见。

功能需求文档

功能需求文档 (FRD) 是应用程序功能需求的正式声明。它与合同具有相同的目的。在此，开发人员同意提供指定的功能。如果产品提供了 FRD 中指定的功能，客户同意对产品感到满意。

功能需求捕获系统的预期Behave。这种Behave可以表示为系统需要执行的服务、任务或功能。该文件应根据特定项目的需要进行定制。它们定义了系统计算、数据操作和处理、用户界面以及与应用程序的交互等内容。

功能需求文件（FRD）具有以下特点 -

• 它表明该应用程序在未来几年的业务目标和业务流程方面提供了价值。

• 它包含一整套应用程序的要求。它没有给任何人留下任何空间来假设 FRD 中未规定的任何内容。

• 它是独立于解决方案的。ERD 是应用程序要做什么的声明，而不是它如何工作的声明。FRD 不向开发人员承诺设计。因此，在 FRD 中任何提及特定技术的使用都是完全不合适的。

功能要求应包括以下内容 -

• 要输入系统的数据的描述

• 各画面的操作说明

• 系统执行的工作流程的描述

• 系统报告或其他输出的描述

• 谁可以将数据输入系统？

• 系统如何满足适用的监管要求？

该功能规范旨在供普通读者阅读。读者应该了解该系统，但不需要任何技术知识即可理解本文档。

功能需求交付成果

业务需求文件（BRD）包括 -

• 功能要求- 包含正在开发的系统的详细要求的文档。这些需求定义了系统必须具备的功能特性和能力。确保业务案例中确定的任何假设和约束仍然准确且是最新的。

• 业务流程模型- 流程当前状态的模型（“原样”模型）或流程应成为什么的概念（“成为”模型）

• 系统上下文图- 上下文图显示系统边界、与系统交互的外部和内部实体以及这些外部和内部实体之间的相关数据流。

• 流程图（按现状或未来） - 图表以图形方式描述业务流程的操作顺序或数据移动。根据模型的复杂程度，包含一个或多个流程图。

• 业务规则和数据要求- 业务规则定义或约束业务的某些方面，并用于定义数据约束、默认值、值范围、基数、数据类型、计算、异常、所需元素和数据的关系完整性。

• 数据模型- 实体关系图、实体描述、类图

• 概念模型- 业务功能的不同实体的高级显示以及它们如何相互关联。

• 逻辑模型- 说明业务功能中涉及的特定实体、属性和关系，并表示业务、技术或概念环境中数据的所有定义、特征和关系。

• 数据字典和术语表- 有关构成数据库或类似数据管理系统底层数据模型的数据元素、字段、表和其他实体的详细信息的集合。

• 利益相关者地图- 识别受拟议变更影响的所有利益相关者及其对需求的影响/权限级别。该文件是在项目管理方法 (PMM) 的初始阶段开发的，由项目经理拥有，但需要由项目团队更新，因为在整个过程中确定了新的/变更的利益相关者。

• 需求可追溯性矩阵- 说明各个功能需求和其他类型的系统工件之间的逻辑链接的表格，包括其他功能需求、用例/用户故事、架构和设计元素、代码模块、测试用例和业务规则。

软件需求规范

软件需求规范（SRS）是一个文档，用作客户之间的沟通媒介。软件需求规范最基本的形式是用于在客户和开发人员之间沟通软件需求的正式文档。

SRS 文档集中于需要做什么，并小心地避免解决方案（如何做）。它充当开发团队和客户之间的合同。此阶段的要求是使用最终用户术语编写的。如果有必要，稍后将根据它制定正式的需求规范。

SRS 是对要开发的系统Behave的完整描述，并且可能包括一组描述用户与软件的交互的用例。

SRS 的目的

SRS 是客户/客户、业务分析师、系统开发人员、维护团队之间的沟通工具。它也可以是买方和供应商之间的合同。

• 将为设计阶段奠定坚实的基础
• 支持项目管理和控制
• 有助于系统的控制和演化

软件需求规范应该是完整的、一致的、可追踪的、明确的和可验证的。

系统规范中应解决以下问题 -

• 定义系统的功能
• 定义硬件/软件功能分区
• 定义性能规格
• 定义硬件/软件性能分区
• 定义安全要求
• 定义用户界面（用户手册）
• 提供安装图纸/说明
• 软件需求规格模板

修订记录

文件审批

以下软件需求规范已被以下机构接受和批准 -

业务分析 - 用例

UML 的九个图之一是用例图。这些对于软件项目来说不仅是重要的而且是必要的要求。它基本上用于软件生命周期。我们知道，开发周期有多个阶段，而用例最常用的阶段是需求收集阶段。

什么是用例？

用例描述了由为参与者提供价值的系统执行的一系列操作。用例描述了系统在响应利益相关者之一（称为主要参与者）的请求时在各种条件下的Behave。

参与者是系统的谁，换句话说，他是最终用户。

在软件和系统工程中，用例是一系列步骤，通常定义角色（在 UML 中称为“参与者”）和系统之间的交互，以实现目标。参与者可以是人类或外部系统。

用例指定系统中的事件流。它更关心系统为了执行一系列操作而执行的操作。

用例的好处

用例提供以下好处 -

• 这是一种捕获功能需求的简单方法，重点关注为用户增加的价值。

• 与传统的需求方法相比，用例相对容易编写和阅读。

• 用例迫使开发人员从最终用户的角度进行思考。

• 用例让用户参与需求过程。

用例剖析

名称： 说明用例目的的描述性名称。

描述： 用几句话描述用例的作用。

参与者： 列出参与用例的所有参与者。

前置条件： 开始用例之前必须满足的条件。

事件流： 系统和参与者之间交互的描述。

后置条件： 描述用例运行后系统的状态。

用例模板指南

使用本章末尾给出的模板记录每个用例。本节提供用例模板中每个部分的描述。

用例识别

• 用例 ID - 以分层形式为每个用例提供一个唯一的数字标识符：XY 相关用例可以在层次结构中分组。功能需求可以追溯到标记的用例。

• 用例名称- 为用例指定一个简洁的、面向结果的名称。这些反映了用户需要能够使用系统完成的任务。包括一个动作动词和一个名词。一些例子 -

  • 查看零件号信息。

  • 手动标记超文本源并建立到目标的链接。

  • 订购包含更新软件版本的 CD。

用例历史

在这里，我们提到了用例文档的利益相关者的名字。

• 创建者- 提供最初记录此用例的人员的姓名。

• 创建日期- 输入最初记录用例的日期。

• 最后更新者- 提供对用例描述执行最新更新的人员的姓名。

• 上次更新日期- 输入最近更新用例的日期。

用例定义

以下是用例关键概念的定义 -

演员

参与者是指定的软件系统外部的人或其他实体，他们与系统交互并执行用例以完成任务。不同的参与者通常对应于从将使用该产品的客户社区中识别出的不同用户类别或角色。命名将执行此用例的参与者。

描述

提供该用例的原因和结果的简要描述，或者执行该用例的操作序列和结果的高级描述。

前提条件

列出在启动用例之前必须发生的任何活动或必须满足的任何条件。对每个先决条件进行编号。

例子

• 用户身份已通过认证。
• 用户的计算机有足够的可用内存来启动任务。

岗位条件

描述用例执行结束时系统的状态。对每个帖子条件进行编号。

例子

• 文档仅包含有效的 SGML 标签。
• 数据库中商品的价格已更新为新值。

优先事项

指示实现允许执行该用例所需的功能的相对优先级。使用的优先级方案必须与软件需求规范中使用的优先级方案相同。

使用频率

估计参与者在某个适当的时间单位执行此用例的次数。

事件的正常过程

提供在正常预期条件下执行用例期间将发生的用户操作和系统响应的详细描述。该对话序列最终将实现用例名称和描述中所述的目标。该描述可以作为对假设问题的回答，“我如何<完成用例名称中规定的任务>？” 最好将其作为参与者执行的操作的编号列表来完成，并与系统提供的响应交替进行。

替代课程

本节中单独记录此用例中可能发生的其他合法使用场景。说明替代方案，并描述发生的步骤顺序中的任何差异。使用用例 ID 作为前缀对每个替代课程进行编号，后跟“AC”以指示“替代课程”。示例：XYAC.1。

例外情况

描述用例执行期间可能发生的任何预期错误情况，并定义系统如何​​响应这些情况。另外，描述如果用例执行由于某些意外原因失败，系统将如何响应。使用用例 ID 作为前缀对每个异常进行编号，后跟“EX”以指示“异常”。示例：XYEX.1。

包括

列出此用例包含（“调用”）的任何其他用例。出现在多个用例中的通用功能可以拆分为一个单独的用例，该用例包含在需要该通用功能的用例中。

特殊要求

确定在设计或实现过程中可能需要解决的用例的任何附加需求，例如非功能性需求。这些可能包括性能要求或其他质量属性。

假设

列出在分析中做出的所有假设，这些假设导致接受该用例到产品描述中并编写用例描述。

注意事项和问题

列出有关此用例的任何其他注释或任何剩余的未决问题或必须解决的 TBD（待定）。确定谁将解决每个问题、截止日期以及最终的解决方案是什么。

变更管理和版本控制

版本控制是对文档、大型网站和其他信息集合的更改的管理。更改通常由数字或字母代码标识，称为修订号或修订级别。每个修订都与时间戳和进行更改的人员相关联。

用例图

统一建模语言（UML）的一个重要部分是绘制用例图的工具。在项目的分析阶段使用用例来识别和划分系统功能。他们将系统分为参与者和用例。参与者代表系统用户可以扮演的角色。

这些用户可以是人类、其他计算机、硬件，甚至其他软件系统。唯一的标准是它们必须位于被划分为用例的系统部分的外部。他们必须向系统的该部分提供刺激，并且必须从该部分接收输出。

用例代表参与者在系统的帮助下为追求目标而执行的活动。我们需要定义这些用户（参与者）需要从系统中获得什么。用例应该反映用户的需求和目标，并且应该由参与者发起。参与业务用例的业务、参与者、客户应通过关联连接到用例。

绘制用例图

下图显示了用例的 UML 示意图形式。用例本身看起来像一个椭圆形。演员被画成小人物。参与者通过线条连接到用例。

用例 1 - 销售员检查商品

• 顾客将物品放在柜台上。
• «使用» 刷卡 UPC 阅读器。
• 系统在数据库中查找UPC代码采购物品描述和价格
• 系统发出蜂鸣声。
• 系统通过语音输出宣布商品描述和价格。
• 系统将价格和项目类型添加到当前发票。
• 系统将价格添加到正确的税收小计中

因此，“uses”关系非常类似于函数调用或子例程。

以这种方式使用的用例称为抽象用例，因为它不能单独存在，而是必须由其他用例使用。

示例 ─ 提款用例

客户使用我们的自动售货机 (ATM) 的目标是取款。因此，我们正在添加提款用例。从自动售货机取款可能需要银行来进行交易。所以，我们还添加了另一个演员——Bank。参与用例的两个参与者应该通过关联连接到用例。

自动售货机为客户和银行参与者提供取款用例。

参与者和用例之间的关系

可以使用以下关系来组织用例 -

• 概括
• 协会
• 延长
• 包括

用例之间的泛化

在某些情况下，参与者可能与类似的用例相关联。在这种情况下，子用例继承父用例的属性和Behave。因此，我们需要概括参与者以显示函数的继承性。它们由带有大空心三角形箭头的实线表示。

用例之间的关联

参与者和用例之间的关联在用例图中用实线表示。每当参与者参与用例描述的交互时，关联就存在。

延长

有一些功能是可选触发的。在这种情况下，将使用扩展关系并将扩展规则附加到其上。要记住的是，即使未调用扩展用例，基本用例也应该能够自行执行功能。

扩展关系显示为带有空心箭头的虚线，从扩展用例指向扩展（基本）用例。箭头标有关键字“extend”。

包括

它用于提取在多个用例中重复的用例片段。它还用于通过将大型用例分成几个用例来简化大型用例，并提取两个或多个用例的Behave的公共部分。

包括用例之间的关系，用带空心箭头的虚线箭头表示，从基本用例到包含的用例。箭头标有关键字“include”。

用例仅涉及系统的功能需求。其他要求（例如业务规则、服务质量要求和实施约束）必须单独表示。

下图是一个简单用例图的示例，其中标记了所有元素。

成功应用用例的基本原则

• 通过讲故事保持简单
• 高效但不完美
• 了解大局
• 确定用例的重用机会
• 关注价值
• 分片构建系统
• 增量交付系统
• 适应团队的需求

用例模板

在这里，我们展示了一个用例模板，业务分析师可以填写该模板，以便技术团队确定有关项目的信息。

业务分析 - 需求管理

收集软件需求是整个软件开发项目的基础。征求和收集业务需求是每个项目的关键第一步。为了弥合业务和技术需求之间的差距，业务分析师必须充分理解给定上下文中的业务需求，使这些需求与业务目标保持一致，并将需求正确地传达给利益相关者和开发团队。

主要利益相关者希望有人能用简单的英语解释客户/客户的需求。这会让他们从高层理解价值中受益吗？这将是主要关注领域，因为他们将尝试将文档与需求进行映射，以及 BA 如何以最佳方式进行沟通。

项目为何失败

项目失败的原因有很多，但一些常见的原因包括：

• 市场与策略失败
• 组织和计划失败
• 质量缺陷
• 领导和治理失败
• 技能、知识和能力失败
• 敬业度、团队合作和沟通失败

问题的核心是项目越来越复杂，变化不断发生，沟通也面临挑战。

为什么成功的团队进行需求管理

需求管理是为了让您的团队保持同步并提供项目内正在发生的情况的可见性。

让整个团队了解您正在构建的内容及其原因对于项目的成功至关重要 - 这就是我们定义需求管理的方式。“为什么”很重要，因为它提供了有关需求的目标、反馈和决策的背景。

这提高了对未来成功和潜在问题的可预测性，使您的团队能够快速纠正任何问题，并在预算范围内按时成功完成项目。作为起点，对于每个相关人员来说，基本了解需求是什么以及如何管理它们是很有价值的。

让我们从基础开始

需求是利益相关者解决问题或实现目标所需的条件或能力。系统或系统必须满足或拥有的条件或能力。满足合同、标准、规范或其他正式强制文件的组件。

需求可以用文本、草图、详细的模型或模型来表达，任何信息都可以最好地向工程师传达要构建的内容以及向 QA 经理传达要测试的内容。根据您的开发过程，您可能会使用不同的术语来捕获需求。

高级别要求有时简称为需求或目标。在软件开发实践中，需求可能被称为“用例”、“特性”或“功能需求”。更具体地说，在敏捷开发方法中，需求通常被捕获为史诗和故事。

无论您的团队如何称呼它们或您使用什么流程；需求对于所有产品的开发至关重要。如果没有明确定义要求，您可能会生产出不完整或有缺陷的产品。在整个过程中，可能会有很多人参与定义需求。

利益相关者可能会请求一个描述产品如何在解决问题时提供价值的功能。设计人员可能会根据最终产品的外观或性能从可用性或用户界面的角度来定义需求。

业务分析师可能会创建遵守特定技术或组织约束的系统需求。对于当今正在构建的复杂产品和软件应用程序，通常需要数百或数千个需求才能充分定义项目或版本的范围。因此，团队必须能够访问、协作、更新和测试每个需求直至完成，因为需求在开发过程中会随着时间的推移而自然变化和发展。

现在我们已经在高层定义了需求管理的价值，让我们更深入地了解每个团队成员和利益相关者都可以从理解中受益的四个基本原理 -

• 规划良好的需求：“我们到底要构建什么？”
• 协作和支持：“只要批准规范就可以了！”
• 可追溯性和变更管理：“等等，开发人员知道发生了变化吗？”
• 质量保证：“你好，有人测试过这个东西吗？”

每个人都知道我们正在构建什么以及为什么？这就是需求管理的价值。

利益相关者的协作和支持

每个人都在循环中吗？我们是否已批准继续推进的要求？这些问题在开发周期中出现。如果每个人都能就需求达成一致那就太好了，但对于拥有许多利益相关者的大型项目来说，这种情况通常不会发生。试图让每个人都达成一致可能会导致决策被推迟，或者更糟糕的是，根本无法做出决策。对每项决定达成共识并不总是那么容易。

在实践中，您不一定需要“共识”，您需要团队的“支持”以及控制人员的批准，以便您可以推动项目向前发展。通过共识，你试图让每个人都妥协并就决定达成一致。通过支持，您可以尝试让人们支持最佳解决方案，做出明智的决定，并采取必要的行动来推动前进。

你不需要每个人都同意这个决定是最好的。你需要每个人都支持你的决定。团队协作有助于获得决策支持和规划良好的需求。

协作团队努力确保每个人都参与项目并提供反馈。协作团队不断分享想法，通常有更好的沟通，并且倾向于支持所做的决策，因为对项目目标有共同的承诺和理解。

当开发人员、测试人员或其他利益相关者感到“脱离循环”时，就会出现沟通问题，人们会感到沮丧，项目也会被推迟。一旦每个人都接受了工作范围，就必须明确要求并记录完整。跟踪所有需求是事情变得棘手的地方。

想象一下，有一个一英里长的待办事项清单，需要与多人合作才能完成。您将如何保持所有这些物品整齐？您将如何跟踪对某个项目的一项更改将如何影响项目的其余部分？这就是可追溯性和变更管理增加价值的地方。

规划好需求

那么，什么才是好的需求呢？一个好的需求应该是有价值的、可操作的；它应该定义需求并提供解决方案的途径。团队中的每个人都应该明白这意味着什么。要求的复杂程度各不相同。

• 好的需求文档可以是高级需求分解为子需求的组的一部分。

• 它们还可能包括非常详细的规范，其中包括描述最终产品的Behave或组件的一组功能要求。

• 好的需求需要简洁、具体，并且应该回答“我们需要什么？”的问题。而不是“我们如何满足需求？”

• 良好的要求确保所有利益相关者都了解他们的计划部分；如果零件不清楚或误解，最终产品可能有缺陷或失败。

随着需求的发展，在整个过程中不断接收来自团队的反馈，可以帮助防止需求失败或误解。与每个人的持续合作和支持是成功的关键。

需求收集和分析

需求是利益相关者解决问题或实现组织目标所需的条件或能力；系统必须满足或拥有的条件或能力。

软件工程中的需求分析涵盖了确定满足新产品或更改产品的需求或条件的任务，考虑到各个利益相关者可能存在的冲突需求，分析、记录、验证和管理软件或系统需求。

要求应该是 -

• 记录在案
• 可行的
• 可测量的
• 可测试
• 可追溯

需求应与已确定的业务需求或机会相关，并定义到足以进行系统设计的详细程度。

业务分析师通过观察现有系统、研究现有程序、与客户和最终用户讨论来收集信息。在缺乏有效系统的情况下，分析师还应该具有想象力和创造力。分析收集到的需求以找到缺失的环节就是需求分析。

诱导法

为了得出目标，请向业务专家、开发经理和项目发起人询问以下问题 -

• 该项目将帮助公司实现哪些业务目标？

• 我们为什么现在做这个项目？

• 如果我们稍后再做会发生什么？

• 如果我们根本不这样做怎么办？

• 谁将从这个项目中受益？

• 将从中受益的人是否认为这是目前可能做出的最重要的改进？

• 我们应该做一个不同的项目吗？

可能的目标可能是降低成本、改善客户服务、简化工作流程、更换过时的技术、试用新技术等等。另外，请确保您准确理解拟议的项目将如何帮助实现既定目标。

不同类型的要求

业务分析师感兴趣的最常见的需求类型如下 -

业务需求

业务需求是企业必须执行的关键活动，以满足组织目标，同时保持解决方案独立。业务需求文档 (BRD) 详细介绍了 ap 的业务解决方案