商业分析 - 快速指南

---

---

商业分析 - 简介

什么是商业分析？

商业分析是一组识别业务需求并确定企业业务问题解决方案的任务、知识和技术。尽管总体定义相似，但在不同行业中的实践和程序可能会有所不同。

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

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

谁是商业分析师？

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

为什么需要商业分析师？

组织出于以下原因采用商业分析：

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

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

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

在项目的初始阶段，当解决方案和设计团队正在解释需求时，商业分析师的角色是审查解决方案文档，与解决方案设计师（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职位时，业务分析师应该熟悉各种分析工具和相关技术。

正如我们之前已经了解到的，业务分析是一个过程，在这个过程中，你试图理解一个商业企业，并识别机遇、问题领域、问题，并与各种角色和职责广泛的人员（如CEO、VP、主管）会面，并了解他们的业务需求。

从根本上说，我们可以将业务分析分为三种类型：

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

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

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

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

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

功能性需求和非功能性需求

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

对于所有技术项目，必须将功能性需求和非功能性需求分开，分别进行分析。

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

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

工具和流程的适用性

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

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

但是，业务需求文档是将需求以文档格式呈现的最流行和最被接受的方式。

在接下来的章节中，我们将深入讨论上述一些技术。

商业分析 - JAD 会议

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

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

JAD会议的用途

JAD会议是高度结构化的、辅助的研讨会，它汇集了客户决策者和IT人员，以便在短时间内产出高质量的交付成果。

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

简而言之，JAD会议可以

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

• 识别 - 问题和参与者

• 量化 - 信息和处理需求

• 澄清 - 具体化和澄清会议中商定的所有需求。

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

• 满足 - 客户定义系统；因此，它是他们的系统。共同参与带来了成果的份额；他们对系统的成功充满信心。

JAD会议的参与者

参与JAD会议的参与者如下：

执行赞助商

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

主题专家

这些是业务用户和外部专家，他们对于成功的研讨会是必需的。主题专家是JAD会议的支柱。他们将推动变革。

主持人

他主持会议；他确定可以在会议中解决的问题。主持人不会向会议提供信息。

关键用户

关键用户在某些情况下也称为超级用户，它们可以互换使用，并且在不同的公司之间有所不同。关键用户通常是与IT项目更紧密相关的业务用户，负责在项目期间配置其团队成员的配置文件。

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

与传统的做法相比，JAD 方法被认为能够缩短开发时间并提高客户满意度，因为客户参与了整个开发过程。相比之下，在传统的系统开发方法中，开发者调查系统需求并开发应用程序，客户的输入仅限于一系列访谈。

需求收集技术

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

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

头脑风暴

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

文档分析

审查现有系统的文档可以帮助创建现状流程文档，并推动差距分析以确定迁移项目的范围。理想情况下，我们甚至会审查推动创建现有系统的需求——这是记录当前需求的起点。现有文档中常常埋藏着信息金矿，这些信息可以帮助我们在验证需求完整性时提出问题。

焦点小组

焦点小组是由代表产品用户或客户的人员组成的聚会，以获取反馈。可以收集关于需求/机会/问题的反馈以识别需求，也可以收集反馈以验证和改进已获得的需求。这种市场调研方法不同于头脑风暴法，因为它是一个有特定参与者的管理过程。

接口分析

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

访谈

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

观察

通过观察用户，分析师可以识别流程流程、步骤、痛点和改进机会。观察可以是被动的（不干预）或主动的（在观察时提出问题）。被动观察更适合获得原型反馈（以改进需求），而主动观察更有效地了解现有业务流程。这两种方法都可以使用。

原型设计

原型设计是一种相对现代的需求收集技术。在这种方法中，您收集初步需求，然后用这些需求来构建解决方案的初始版本——原型。您将其展示给客户，然后客户会提供额外的需求。您更改应用程序并再次与客户循环。这个重复的过程持续进行，直到产品满足关键的业务需求或达到商定的迭代次数。

需求研讨会

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

逆向工程

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

调查问卷

当从许多人那里收集信息时——由于预算和时间限制，人数太多而无法进行访谈——可以使用调查问卷。调查可以强迫用户从选项中选择，对某事物进行评分（“非常同意，同意……”），或者提出开放式问题，允许自由形式的回答。调查设计很难——问题可能会影响受访者的回答。

功能需求文档

功能需求文档 (FRD) 是应用程序功能需求的正式声明。它与合同具有相同的目的。在这里，开发人员同意提供指定的 capabilities。如果客户提供的 capabilities 在 FRD 中指定，则客户同意认为产品令人满意。

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

功能需求文档 (FRD) 具有以下特点：

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

• 它包含应用程序的完整需求集。它不留任何空间让人假设 FRD 中未陈述的任何内容。

• 它是独立于解决方案的。ERD 是关于应用程序应该做什么的陈述，而不是关于它是如何工作的陈述。FRD 不会让开发人员承担设计责任。因此，在 FRD 中任何提及使用特定技术的参考文献都是完全不合适的。

功能需求应包括以下内容：

• 对将输入系统的数据的描述

• 对每个屏幕执行的操作的描述

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

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

• 谁能将数据输入系统？

• 系统如何满足适用的法规要求？

功能规范的设计目的是让一般读者都能阅读。读者应该理解系统，但不应该需要任何技术知识就能理解此文档。

功能需求交付成果

业务需求文档 (BRD) 包括：

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

• 业务流程模型——当前流程状态的模型（“现状”模型）或流程应成为何种状态的概念（“目标”模型）

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

• 流程图（现状或目标）——图解地描述业务流程的操作顺序或数据的移动。根据模型的复杂性，包含一个或多个流程图。

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

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

• 概念模型——业务功能的不同实体及其相互关系的高级显示。

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

• 数据字典和词汇表——关于构成数据库或类似数据管理系统基础的数据模型的数据元素、字段、表和其他实体的详细信息集合。

• 利益相关者地图——确定所有受拟议变更影响的利益相关者及其对需求的影响/权限级别。此文档在项目管理方法 (PMM) 的起源阶段开发，由项目经理拥有，但需要项目团队在整个过程中更新新/更改的利益相关者。

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

软件需求规格说明书

软件需求规格说明书 (SRS) 是一份文档，用作客户之间的沟通媒介。最基本的软件需求规格说明书是用于在客户和开发人员之间沟通软件需求的正式文档。

SRS 文档侧重于需要做什么（做什么），并仔细避免解决方案（怎么做）。它作为开发团队和客户之间的合同。此阶段的需求使用最终用户术语编写。如有必要，稍后将据此制定正式的需求规格说明书。

SRS 是要开发系统的行为的完整描述，可能包括一组用例，这些用例描述用户将与软件进行的交互。

SRS 的目的

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

• 它将为设计阶段奠定坚实的基础
• 支持项目管理和控制
• 帮助控制和发展系统

软件需求规格说明书应该是完整、一致、可追溯、明确和可验证的。

系统规格说明中应解决以下问题：

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

修订历史

文档审批

以下软件需求规格说明书已获得以下人员的接受和批准：

商业分析 - 用例

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

什么是用例？

用例描述了系统执行的一系列操作，这些操作为参与者提供价值。用例描述了系统在各种情况下响应来自利益相关者（称为主要参与者）的请求时的行为。

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

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

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

用例的好处

用例提供以下好处：

• 这是一种简单易行的方法，可以捕捉功能需求，重点关注为用户带来的增值。

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

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

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

用例的构成要素

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

描述 : 用几句话描述用例的功能。

参与者 : 列出参与用例的任何参与者。

前提条件 : 在开始用例之前必须满足的条件。

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

后置条件 : 描述用例执行完毕后系统的状态。

用例模板指南

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

用例识别

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

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

  • 查看零件号信息。

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

  • 订购带有更新软件版本的CD。

用例历史

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

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

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

• 最后更新者 − 提供对用例描述进行最近一次更新的人员的姓名。

• 最后更新日期 − 输入最近更新用例的日期。

用例定义

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

参与者

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

描述

简要描述此用例的原因和结果，或对操作序列和执行用例的结果进行高级描述。

前提条件

列出在用例开始之前必须执行的任何活动或必须为真的任何条件。为每个前提条件编号。

示例

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

后置条件

描述用例执行结束时系统的状态。为每个后置条件编号。

示例

• 文档仅包含有效的SGML标记。
• 数据库中项目的價格已更新为新值。

优先级

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

使用频率

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

正常事件流程

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

备选流程

在本节中分别记录在此用例中可能发生的其它合法使用场景。说明备选流程，并描述步骤序列中发生的任何差异。使用用例 ID 作为前缀对每个备选流程进行编号，后跟“AC”表示“备选流程”。示例：X.Y.AC.1。

异常情况

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

包含

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

特殊需求

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

假设

列出分析中做出的任何假设，这些假设导致将此用例纳入产品描述并编写用例描述。

备注和问题

列出关于此用例的任何附加注释或必须解决的任何剩余未决问题或待定事項 (TBD)。确定谁将解决每个问题，截止日期以及最终解决方案是什么。

变更管理和版本控制

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

用例图

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

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

用例代表参与者在追求目标的过程中使用您的系统执行的活动。我们需要定义这些用户（参与者）需要系统提供什么。用例应反映用户的需求和目标，并且应由参与者启动。参与业务用例的业务、参与者、客户应通过关联连接到用例。

绘制用例图

下图显示了用例在 UML 示意图形式中的外观。用例本身看起来像一个椭圆形。参与者被绘制成小的简笔人物。参与者通过线条连接到用例。

用例 1 − 销售员结账

• 顾客将商品放在柜台上。
• «uses» 刷 UPC 阅读器。
• 系统在数据库中查找 UPC 代码，获取商品描述和价格
• 系统发出可听见的蜂鸣声。
• 系统通过语音输出宣布商品描述和价格。
• 系统将价格和商品类型添加到当前发票。
• 系统将价格添加到正确的税款小计

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

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

示例 ─ 取款用例

客户与我们的自动取款机 (ATM) 相关的目标是取款。因此，我们正在添加取款用例。从自动取款机取款可能涉及银行进行交易。因此，我们还添加了另一个参与者 – 银行。参与用例的两个参与者都应通过关联连接到用例。

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

参与者和用例之间的关系

可以使用以下关系组织用例：

• 泛化
• 关联
• 扩展
• 包含

用例之间的泛化

可能存在参与者与类似用例关联的情况。在这种情况下，子用例继承父用例的属性和行为。因此，我们需要泛化参与者以显示功能的继承。它们由带有大空心三角形箭头头的实线表示。

用例之间的关联

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

扩展

有些功能是可选触发的。在这种情况下，使用扩展关系并附加扩展规则。需要注意的是，即使未调用扩展用例，基本用例也能够自行执行功能。

扩展关系显示为虚线，带有从扩展用例指向扩展（基本）用例的开放箭头。箭头用关键字«extend»标记。

包含

它用于提取在多个用例中重复的用例片段。它还用于通过将大型用例拆分为多个用例以及提取两个或多个用例行为的公共部分来简化大型用例。

用例之间的包含关系，由从基本用例到包含用例的带有开放箭头头的虚线箭头表示。箭头用关键字«include»标记。

用例仅处理系统的功能需求。其他需求，例如业务规则、服务质量要求和实现约束，必须单独表示。

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

成功应用用例的基本原则

• 通过讲述故事来简化
• 无需完美即可高效
• 理解全局
• 识别用例的重用机会
• 关注价值
• 分片构建系统
• 增量交付系统
• 适应团队的需求

用例模板

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

业务分析 - 需求管理

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

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

项目失败的原因

项目失败的原因有很多，但一些常见领域包括以下方面：

• 市场和战略失败
• 组织和规划失败
• 质量失败
• 领导力和治理失败
• 技能、知识和能力失败
• 参与度、团队合作和沟通失败

问题的核心在于项目日益复杂，变化频繁，沟通具有挑战性。

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

需求管理是关于让您的团队保持同步并提供项目内部情况的可见性。

对于项目的成功至关重要的一点是，您的整个团队都理解您正在构建什么以及为什么要构建它——这就是我们对需求管理的定义。“为什么”很重要，因为它为关于需求的目标、反馈和决策提供了背景。

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

让我们从基础开始

需求是利益相关者为解决问题或实现目标所需的条件或能力。系统或系统组件必须满足或具备的条件或能力，以满足合同、标准、规范或其他正式施加的文件。

需求可以用文本、草图、详细的模型或模型来表达，任何能够最好地向工程师传达要构建什么以及向质量保证经理传达要测试什么的资料。

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

无论您的团队称它们为什么或您使用什么流程；需求对于所有产品的开发都是必不可少的。如果没有明确定义需求，您可能会产生不完整或有缺陷的产品。在整个过程中，可能有许多人参与定义需求。

利益相关者可能会请求一个功能，该功能描述产品将如何通过解决问题来提供价值。设计师可能会根据最终产品从可用性或用户界面角度应该如何外观或执行来定义需求。

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

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

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

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

利益相关者的协作和认同

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

实际上，您并不一定需要“共识”，您需要团队的“认同”以及控制者的批准，以便您可以推进项目。达成共识，您试图让每个人都妥协并就决策达成一致。获得认同，您试图让人们支持最佳解决方案，做出明智的决策并做必要的事情来推进项目。

您不需要每个人都同意该决策是最佳的。您需要每个人都支持该决策。团队协作有助于在决策中获得支持以及在规划良好的需求方面获得支持。

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

当开发人员、测试人员或其他利益相关者感到“脱离循环”时，沟通问题就会出现，人们会感到沮丧，项目也会被延误。一旦每个人都认同了工作范围，需求就必须清晰且有据可查。跟踪所有需求的地方是事情变得棘手的地方。

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

规划良好的需求

那么，什么构成了良好的需求？良好的需求应该是有价值且可操作的；它应该定义需求并提供通往解决方案的途径。团队中的每个人都应该理解它的含义。需求的复杂性各不相同。

• 一份良好的需求文档可以作为一组文档的一部分，其中高层需求分解为子需求。

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

• 良好的需求必须简洁明了，并且应该回答“我们需要什么？”而不是“我们如何满足需求？”

• 良好的需求确保所有利益相关者都了解其计划的一部分；如果部分内容不清楚或被误解，最终产品可能会出现缺陷或失败。

通过在需求演变过程中不断从团队那里获得反馈，可以防止需求失败或误解。与每个人的持续协作和认同是成功的关键。

需求收集和分析

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

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

需求应：

• 有记录的
• 可操作的
• 可衡量的
• 可测试的
• 可追溯的

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

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

引出方法

要引出目标，请向业务专家、开发经理和项目发起人提出以下问题：

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

• 我们为什么现在要进行这个项目？

• 如果我们以后再做会怎样？

• 如果我们根本不做会怎样？

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

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

• 我们是否应该做不同的项目？

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

不同类型的需求

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

业务需求

业务需求是企业必须执行的关键活动，以满足组织目标，同时保持与解决方案无关。业务需求文档 (BRD) 详细说明项目的业务解决方案，包括客户需求和期望的文档。

用户需求

用户需求应指定用户期望/想要从软件项目构建的软件中获得的具体需求。用户需求应可验证、清晰简洁、完整、一致、可追溯、可行。

用户需求文档 (URD) 或用户需求规范通常用于软件工程中，它指定用户期望软件能够执行的操作。

系统需求

系统需求涉及定义软件资源需求和前提条件，这些需求和前提条件需要安装在计算机上才能提供应用程序的最佳功能。

功能需求

功能需求捕获并指定正在开发的系统的特定预期行为。它们定义诸如系统计算、数据操作和处理、用户界面以及与应用程序的交互等内容，以及其他显示如何满足用户需求的特定功能。为每个需求分配唯一的 ID 号。

非功能性需求

非功能需求是指指定可用于判断系统操作的标准，而不是特定行为的标准。系统架构说明了实现非功能需求的计划。

非功能需求说明系统应该是什么样的，或者可以像“系统应该……”一样提及。非功能需求被称为系统的质量。

过渡需求

过渡需求描述解决方案必须满足的功能，以便促进企业从当前状态过渡到理想的未来状态，但在过渡完成后将不再需要这些功能。

它们与其他需求类型有所不同，因为它们本质上总是临时的，并且因为它们只有在定义现有解决方案和新解决方案后才能开发。它们通常涵盖从现有系统转换数据、必须解决的技能差距以及为达到理想的未来状态而进行的其他相关更改。它们是通过解决方案评估和验证来开发和定义的。

可追溯性和变更管理

需求可追溯性是一种组织、记录和跟踪从最初的想法产生到测试阶段的所有需求的方法。

需求可追溯性矩阵 (RTM) 提供了一种方法来跟踪功能需求及其在开发过程中的实现。每个需求都包含在矩阵中以及其关联的节号。

随着项目的进展，将更新 RIM 以反映每个需求的状态。当产品准备好进行系统测试时，矩阵将列出每个需求、哪些产品组件解决了该需求以及哪些测试验证了它是否已正确实现。

在 RTM 中包含以下每一列：

• 需求描述
• FRD 中的需求参考
• 验证方法
• 测试计划中的需求参考

示例：连接点以识别项目中各项之间的关系。它是常见下游流的连接器。

理念 需求 设计 测试 业务目标

您应该能够将每个需求追溯到其原始业务目标。

通过追踪需求，您可以识别变更的连锁反应，查看需求是否已完成以及是否正在得到正确测试。可追溯性和变更管理为管理者提供了安心感和必要的可见性，以便预测问题并确保持续质量。

质量保证

第一次就交付正确的需求意味着更高的质量、更快的开发周期以及更高的客户满意度。需求管理不仅帮助您做到正确，还帮助您的团队在整个开发过程中节省资金和避免许多麻烦。

简洁、具体的需求可以帮助您尽早发现和修复问题，而不是在修复成本高得多的时候才发现。此外，在开发过程后期修复代码中的缺陷，成本可能高达修复需求时成本的100倍。

通过将需求管理整合到您的质量保证流程中，您可以帮助您的团队提高效率并消除返工。此外，返工是大多数成本问题出现的地方。

换句话说，开发团队浪费了大部分预算在第一次没有正确执行的工作上。例如，开发人员根据旧的规范文档编写一个功能，后来才发现该功能的需求已经改变了。通过有效的需求管理最佳实践，可以避免这些类型的问题。

总而言之，需求管理听起来像是一门复杂的学科，但当您将其简化为一个简单的概念时——它关乎帮助团队回答这个问题：“每个人都理解我们在构建什么以及为什么？”从业务分析师、产品经理和项目领导到开发人员、质量保证经理和测试人员，以及相关的利益相关者和客户——项目的失败根源往往是对项目范围的误解。

当每个人都在协作，并且对整个项目生命周期中与需求相关的讨论、决策和变更拥有完整的上下文和可见性时，成功就会持续发生，并且您可以保持持续的质量。此外，这个过程更加顺畅，减少了参与者的摩擦和挫折。

注意 − 研究表明，项目团队可以通过有效地管理需求来消除50-80%的项目缺陷。卡内基梅隆软件工程研究所的数据显示，“60-80%的软件开发成本用于返工”。

获得需求签字

需求签字正式确认项目利益相关者对已记录的需求内容和表达方式的准确性和完整性达成一致。正式协议降低了在实施期间或之后利益相关者引入新的（以前未遇到的）需求的风险。

获得需求签字通常包括与每个项目利益相关者面对面地最终审查已记录的需求。在每次审查结束时，都会要求利益相关者正式批准已审查的需求文档。此批准可以物理地或电子地记录。

获得需求签字通常是需求沟通中的最后一步。业务分析师需要正式需求审查的输出，包括在审查过程中提出的任何意见或异议。

商业分析 - 建模

业务模型可以定义为对业务或解决方案的表示，通常包括图形组件以及支持文本以及与其他组件的关系。例如，如果我们必须了解公司的业务模型，那么我们希望研究以下领域：

• 公司的核心价值观
• 它服务于什么？
• 它的独特之处是什么？
• 它的关键资源
• 主要关系
• 它的交付渠道

借助建模技术，我们可以创建对企业使用的现有和拟议的组织结构、流程和信息的完整描述。

业务模型是一个结构化模型，就像最终产品的蓝图一样。它为规划提供了结构和动力。它也为最终产品提供了基础。

业务建模的目的

业务建模用于设计企业的当前状态和未来状态。业务分析师和利益相关者使用此模型来确保他们对企业的当前“现状”模型有准确的理解。

它用于验证利益相关者是否对拟议的解决方案的“未来状态”有共同的理解。

需求分析是业务建模过程的一部分，并且构成了核心关注领域。“现状”期间收集功能需求。这些需求由利益相关者提供，涉及业务流程、数据和业务规则，这些规则描述了将在未来状态中设计的所需功能。

执行差距分析

在定义业务需求后，必须确定当前状态（例如，当前业务流程、业务职能、当前系统功能和提供的服务/产品以及系统必须响应的事件），以了解人员、流程和技术、结构和架构如何通过寻求IT人员和其他相关利益相关者（包括业务所有者）的投入来支持业务。

然后执行差距分析，通过将确定的当前状态与预期结果进行比较，评估是否存在任何妨碍实现业务需求的差距。

如果没有差距（即，当前状态足以满足业务需求和预期结果），则可能不需要启动IT项目。否则，应确定需要解决的问题/问题以弥合差距。

可以使用SWOT（优势、劣势、机会和威胁）分析和文档分析等技术。

评估拟议系统

BA应协助IT项目团队评估拟议的IT系统，以确保其满足业务需求并最大限度地提高为利益相关者提供的价值。BA还应审查组织支持向拟议的IT系统过渡的准备情况，以确保系统实施顺利进行。

BA应帮助IT项目团队确定拟议的系统选项和高级系统设计是否能够满足业务需求并提供足够的业务价值来证明投资合理性。如果有多个系统选项，BA应与IT人员合作，帮助识别每个选项的优缺点，并选择能够提供最大业务价值的选项。

业务建模的指导原则

业务建模的主要作用主要在项目的启动阶段和详细阐述阶段，在构建和过渡阶段逐渐减弱。它主要与业务的分析方面以及应用程序或软件解决方案的技术映射有关。

• 领域和用户差异 − 开发业务模型通常会揭示利益相关者之间存在分歧或混淆的领域。业务分析师需要记录现状模型中的以下差异。

• 多个工作单元执行相同的职能 − 记录现状模型中的差异。这可能是不同的部门或地区。

• 多个用户执行相同的工作 − 不同的利益相关者可能会以不同的方式进行类似的工作。差异可能是不同业务部门的不同技能和方法的结果，也可能是企业服务的外部利益相关者需求不同的结果。记录现状模型中的差异。

• 解决方案机制 − 业务分析师应记录ToBe解决方案是否将适应当前业务模型中的不一致之处，或者解决方案是否需要标准化。利益相关者需要确定遵循哪种方法。ToBe模型将反映他们的决定。

BA在ERP系统建模中的作用示例

业务分析师应该定义一个标准的业务流程并将其设置到ERP系统中，这对于高效实施至关重要。BA的职责还在于在实施之前用易于理解的语言定义开发人员的语言，然后利用最佳实践并根据系统功能对其进行映射。

对系统的一个需求是GAAP匹配分析，它必须在以下方面取得平衡：

• 对技术变更的需求，即为了与现有实践保持一致而进行的增强。

• 有效的变更，这与重新设计现有业务流程有关，以允许实施标准功能和应用流程模型。

功能业务分析师

领域专业知识通常是通过长期从事“业务”而获得的。例如：

• 银行职员了解客户（个人和企业）可以操作的各种类型的账户以及详细的业务流程。

• 保险销售代表可以理解获取保险单所涉及的各个阶段。

• 市场分析师更有可能理解客户关系管理系统中涉及的关键利益相关者和业务流程。

• 参与资本市场项目的业务分析师应该具备主题专业知识和对股票、固定收益和衍生品的深入了解。此外，他还应该处理后台、前台，并在应用风险管理模型方面拥有实际经验。

• 医疗保健业务分析师需要对美国医疗保健财务和利用率指标有基本的了解，以及对EDI 837/835/834、HIPAA指南、ICD编码–9/10和CPT代码、LOINC、SNOMED知识的技术经验和理解。

一些业务分析师通过测试业务应用程序和与业务用户合作来获得领域知识。他们通过人际交往和分析能力创造了良好的学习环境。在某些情况下，他们会通过AICPCU/IIA和LOMA在保险和金融服务领域提供的少量领域认证来补充他们的领域知识。还有其他机构提供其他领域的认证。

其他主要活动

在彻底检查了当前的业务流程之后，您可以提供高度专业的帮助，以识别最佳的系统建模方法。

• 组织准备以正式和统一的方式描述业务流程，以确保系统中的高效自动化。

• 协助您的团队填写开发人员可能提供的相关系统的标准问卷。

• 参与工作会议，定义对开发人员的需求。

• 检查和控制您设置的需求是否已在描述系统未来模型的文档（蓝图）中正确“复制”和记录。

• 准备数据并协助系统原型设计。

• 协助准备数据，以便以系统所需的形式迁移列表和余额。

• 审查设置原型是否符合业务流程所有者定义的需求。

• 作为支持资源，协助您的IT团队准备数据并实际执行系统中的功能和集成测试。

在下一节中，我们将简要讨论一些大型组织在IT环境中使用的一些流行的业务建模工具。

工具1：Microsoft Visio

MS-Visio是一款绘图和图表软件，可以帮助将概念转换为可视化表示。Visio为您提供预定义的形状、符号、背景和边框。只需将元素拖放到图表中即可创建专业的沟通工具。

步骤 1 − 要打开新的 Visio 绘图，请转到“开始”菜单并选择“程序”→“Visio”。

步骤 2 − 将光标移到“业务流程”上，然后选择“基本流程图”。

以下屏幕截图显示了 MS-Visio 应用程序的主要部分。

现在让我们讨论每个组件的基本用途：

A − 屏幕顶部的工具栏与其他 Microsoft 程序（如 Word 和 PowerPoint）类似。如果您以前使用过这些程序，您可能会注意到一些不同的功能，我们稍后会探讨这些功能。

选择“帮助”→“图表库”是熟悉 Visio 中可以创建的绘图和图表类型的好方法。

B − 屏幕左侧显示特定于您正在创建的图表类型的菜单。在本例中，我们看到：

• 箭头形状
• 背景
• 基本流程图形状
• 边框和标题

C − 屏幕中央显示图表工作区，其中包括实际的图表页面以及页面旁的一些空白空间。

D − 屏幕右侧显示一些帮助功能。有些人可能会选择关闭此窗口以增加图表工作区的面积，并在需要时重新打开帮助功能。

工具 2：企业架构师 (Enterprise Architect)

企业架构师是一个基于 UML 的可视化建模和设计工具。该平台支持软件系统的设计和构建、业务流程建模和基于行业的领域建模。企业和组织使用它不仅可以建模其系统的架构，还可以处理这些模型在整个应用程序开发生命周期中的实现。

企业架构师的目的是确定组织如何最有效地实现其当前和未来的目标。

企业架构师有四个视角，如下所示：

• 业务视角 − 业务视角定义了业务日常运营的流程和标准。

• 应用视角 − 应用视角定义了组织使用的流程和标准之间的交互。

• 信息视角 − 这定义和分类了组织为了有效运营而需要的大量数据，例如文档文件、数据库、图像、演示文稿和电子表格。

• 技术视角 − 这定义了组织使用的硬件、操作系统、编程和网络解决方案。

工具 3：Rational RequisitePro

收集、记录、组织、跟踪和更改需求，并在项目团队之间沟通这些信息的过程，以确保在整个项目生命周期中保持迭代和意外的更改。

监控状态并控制对需求基线的更改。主要要素是变更控制和可追溯性。

RequisitePro 用于上述活动和项目管理目的，该工具用于查询和搜索，查看作为需求一部分的讨论。

在 RequisitePro 中，用户可以处理需求文档。该文档是在 Reqpro 应用程序中创建并与项目数据库集成的 MS-Word 文件。在 RequisitePro 之外创建的需求可以导入或复制到文档中。

在 RequisitePro 中，我们还可以处理可追溯性，这里它是两个需求之间的依赖关系。可追溯性是一种通过链接彼此相关的需求来管理更改的方法性方法。

RequisitePro 使跟踪需求在整个开发周期中的更改变得容易，因此无需单独查看所有文档即可确定哪些元素需要更新。您可以使用可追溯性矩阵或可追溯性树视图来查看和管理可疑关系。

RequisitePro 项目使我们能够创建一个项目框架，在其中组织和管理项目工件。每个项目都包含以下内容：

• 常规项目信息
• 包
• 常规文档信息
• 文档类型
• 需求类型
• 需求属性
• 属性值
• 跨项目可追溯性

RequisitePro 允许多个用户同时访问相同的项目文档和数据库，因此项目安全方面非常关键。安全措施可防止未经授权的用户访问项目文档，从而防止系统使用、潜在损害或数据丢失。

建议为所有 RequisitePro 项目启用安全功能。这样做可以确保对项目的所有更改都与进行更改的个人的正确用户名相关联，从而确保您拥有所有更改的完整审计跟踪。