商业分析指南/需求文档和管理

组织在关键项目上投入巨资，以确保在快速变化的世界中持续生存。他们投资项目来解决业务问题，抓住机会或实施战略解决方案以促进业务目标。捕获和管理正确需求可避免代价高昂的失误，是交付具有可衡量价值的成功项目的关键。

在本指南部分中，读者应了解与项目和应用程序需求文档和管理相关的活动。这些活动支持在整个项目生命周期中执行业务分析的有序方法，并使分析师能够使组织能够有效地管理应用程序项目和下游维护，以支持组织战略和工作流程。无论分析师是参与项目或倡议的基层或“启动”阶段，还是参与增强更改或仅参与开发生命周期的一部分，本节中包含的信息都应为需求管理流程中涉及的活动提供指导。

需求开发

需求开发包括与收集和分析需求相关的活动。

收集/征求需求

在收集需求时，业务分析师需要在组织的背景下和支持运营需求以满足利益相关者目标的情况下捕获信息。

了解组织运作方式

收集和征求需求的过程始于了解组织的运作方式。大多数项目都涉及整个组织的一小部分。了解企业的顶层流程流程突出了“大局”，并为规划需求收集和管理工作奠定了基础。在公共部门运营中，主要使命是为公众服务。无论是确保公众的健康和安全，执行法律法规，提供支持服务，还是其他任务，确定驱动项目环境的顶层目标，确保项目成果与组织目标保持一致。
构建上下文以确定项目的组织影响涉及多个迭代。每次迭代都探索不同的组织方面，直到识别出受项目范围直接影响的运营，并且对预期交付成果的范围有了清晰的了解。与业务用户沟通并征求这些信息的来源是制定需求管理计划的关键步骤。

学习组织的语言

术语：术语及其使用的研究

语义：对意义的研究

熟悉业务术语是建立对项目领域有知情理解的基本组成部分。业务“语言”的语义和术语弥合了业务、技术和外部利益相关者之间的差距。使用通用术语/语义来传达有关需求的信息，确保交付成果将满足所有利益相关者的期望。

您作为成功联络人的作用部分取决于扩展您的词汇量以满足项目需求。互联网和组织的内部网可以作为获得额外词汇量的资源，以帮助您与所有项目利益相关者清晰地沟通。
在需求中捕获重要的术语和缩写始终很有用，尤其是在资源共享和/或外包的情况下，这些术语和缩写可以放在需求词汇表中。这种词汇表可能在组织级别保留 - 如果是这样，它可以成为您理解业务语言的宝贵资源，以及帮助您编写清晰简洁需求的工具。

规划需求捕获

需求在整个 SDLC 和未来都有用。在项目执行过程中，您的需求将为分析提供来源，用于执行变更请求、设计更改和其他典型项目体验的影响分析。以有条理的方式捕获需求使您能够在整个项目生命周期以及之后（进入应用程序维护阶段）进行全面知情的分析。

当您拥有现有应用程序并需要将增强功能整合到该应用程序的功能中时，您的需求可以被重新使用以确定应用程序的每个功能区域，其中提议的更改可能会影响现有应用程序。规划当前项目和持续维护交付成果需要 BA 制定组织需求的计划。

为存储的需求选择适当的属性将有助于您在项目执行过程中的下游分析。属性（如来源、状态、功能区域等）是关于您需求的信息，可以用于过滤需求，以便分析只关注相关信息。该项目是否足够复杂以至于值得付出这种努力？到什么程度？在项目处于全面“需求收集”模式之前，做出有关如何组织和管理需求的决策。
项目文档的文档存储库可用于确保项目团队拥有项目工件（如流程模型、用例、关键演示文稿、基线需求、项目和工作计划、缺陷和更改日志或其他文档）的唯一权威来源，这些文档用于项目执行中。这种类型的工具使项目团队成员和业务利益相关者能够按需引用需求的源材料，从而促进对项目结果工作的多样化审查。

需求来源

需求来源很多。BA 检查业务运营信息并与利益相关者和其他相关方沟通以收集需求。许多将在需求收集的组织分析阶段被发现。即使是项目文档也包括以高层次描述的其他需求。

业务规则

有一种普遍的误解，认为业务规则就是需求。虽然两者之间可能存在一对一对应关系，但两者之间存在区别。需求描述了实现业务规则所需的内容。业务规则本身描述了业务必须如何运作。下表提供了比较。

业务规则	需求
客户可以通过安排与部门代表会面的日期和时间来预约。	• 面向公众的网站将显示客户可以拨打的电话号码来预约。 • 面向公众的网站将允许客户导航到预约预订请求表单。 • 预订请求表单将包括客户姓名、地址、电话和电子邮件联系信息以及所需的预约日期和时间。 • 客户不得在预订请求表单中选择已经预订的预约日期和时间。 • 客户可以从表单界面直接提交其请求。 • 提交的预订请求表单将安排在部门日历上。
在截止日期前未支付费用将导致客户支付 0.02% 的罚款。	• 应用程序将根据当前日期和应收款到期日自动确定客户费用何时逾期。 • 当客户费用逾期时，应用程序将计算并更新客户应收款记录上的罚款金额。 • 逾期费用计算的罚款将等于 0.0002 * 逾期客户应收款余额 + 以前累积的费用。

业务规则 (BABOK v2.0)
• 定义或约束业务的某些方面
• 适用于跨流程和程序（系统无关）
• 旨在断言业务结构或控制/影响业务行为
• 规则是原子的 - 也就是说，它们不能被分解

许多组织积极管理其业务规则。还有许多组织将规则嵌入到用于指导运营的政策和程序中。许多程序没有记录在任何文档中，而是存在于员工知识库中。无论您在哪个环境中工作，都应识别影响您项目的业务规则，以确保您的项目交付成果支持整体运营。

对于那些有效管理其业务规则的组织来说，理解它们相当简单。如果组织没有正式管理规则，则需要进行分析以识别规则。了解适用的政策和程序以及公认的 IT 和安全标准，可以帮助您确保用户表达的要求符合项目交付成果必须支持的业务运营。

商业案例/ITIR

商业案例、项目章程、信息技术投资请求 (ITIR) 或项目启动期间创建的其他文档明确概述了项目交付成果的期望和理由。本文件通常将提供高级业务需求，您将使用这些需求来指导功能需求和非功能需求的开发。它甚至可能包含一些功能需求和非功能需求本身。这是用户需求发现的起点，为讨论和沟通提供了一个背景。

约束

识别适用于项目的约束条件，确保交付成果可行。没有任何软件应用程序可以在不了解其所在的的技术环境的情况下构建或实施。没有任何业务应用程序可以在不了解其所在的法律环境的情况下构建或实施。解决方案必须支持技术 IT 策略和安全标准，以及适用于业务和/或业务流程的法律法规。影响解决方案的约束条件对于识别非功能需求以及在开发功能需求期间与项目利益相关者沟通时使用至关重要。

现有应用程序

当项目目标是替换或增强现有应用程序时，该应用程序可以提供许多适用于解决方案的需求。这种“现状”场景是确定必要功能和项目需求的金矿。如果为旧应用程序管理了需求，则可以将它们重新用于当前项目，并进行适当的修改。也许项目交付成果解决了现有应用程序不支持的全新需求。如果是这种情况，项目解决方案可能需要合并多个现有应用程序和业务流程的业务规则和功能需求。这种类型的“现状”场景分析通常适用于系统集成项目。

业务用户/利益相关者

虽然对组织结构、业务流程、规则和项目工件的调查提供了对项目创建来解决的业务问题或机会的基础理解，但这是一种受限于单一视角的分析 - 分析师的视角。业务用户和其他项目利益相关者提供验证，以确保需求正确，并且他们还提供以前未识别的需求，这些需求不一定存在于组织文档、流程分析或其他方法中。收集这些类型需求需要沟通，包括访谈、调查和需求收集会议。
协调和整合用户和利益相关者的多种视角是重要的 BA 活动。

分析需求

收集需求后，应在其他需求、整个项目和组织的背景下对其进行分析。此活动将识别无效的需求，突出显示缺失或不完整的需求，并提供完成需求定义所需的信息。

分类

捕获需求时，应将类别信息记录为需求属性。分配给需求的类别有助于筛选需求以进行分析。项目的上下文将决定如何以及在何种程度上将需求组织成类别。对需求进行分类的主要目标是促进分析。一些组织可能具有标准的分类，而其他组织则使用项目特定的分类。分类支持快速评估拟议更改的影响，并支持下游工作（如设计和测试）的可追溯性，帮助指导活动。

尽可能使用对项目有意义的类别。例如，涉及多个集成应用程序的开发工作可能希望包括一个类别，用于指定需求适用的单个应用程序。然后，您可以在分析工作、成本等时轻松地仅检查与单个应用程序关联的需求。对于小型独立的应用程序项目，此类别不会增加任何价值。无论使用什么类别，它们都应提供一种组织方式来促进分析，最大限度地减少开发返工并确保项目目标得到交付。

依赖关系

单个需求之间存在的依赖关系有助于指导优先级排序并突出显示项目成功可能存在的风险。例如，如果您有一个需求是捕获客户地址，另一个需求是系统将根据客户居住地为员工分配工作，那么“工作分配”需求取决于客户地址需求。从这种依赖关系分析中，您现在知道必须/应在满足工作分配需求之前捕获客户地址。它还提供了改进地址需求以包含所有相关地址元素的动机。

需求也可能依赖于其他项目或现有基础设施。例如，如果您的项目将与另一个项目的交付成果进行接口，您可能有一些需求依赖于另一个项目的输出。如果该项目失败，您的需求可能需要修改或失效。

影响和可行性分析

组织影响
超越项目重点，可能包括
• 基础设施和技术策略
• 其他应用程序
• 工作流程变更

实施的需求会对组织、技术架构、安全、业务流程和/或人员群体（内部和外部）产生变更。项目团队将能够通过了解项目将如何影响这些组织变量来缓解风险、设定期望并防止出现意外后果。影响分析包括确定如果未实施需求的影响，以及如果将需求包含在项目交付成果中会产生的影响。使用此信息来设置优先级并提供变更管理指南。

在需求收集和促进过程中，您可能会发现一些需求，这些需求当然有可能，但它们并不实用。可以使用简单的清单来关注影响关注领域的需求。可以估计影响级别（无、低、中、高），并且可以根据此分析指导有关接受需求的可行性的决策。

如果项目计划包含分阶段实施交付成果或项目将使用敏捷开发方法执行，则可能需要进行影响分析以确定哪些需求应实施进行开发周期。在执行影响和/或可行性分析时，要考虑的因素包括

• 相关成本，
• 实施需求的复杂性，
• 技术开发团队和使用该应用程序的用户的技能水平，以及
• 组织支持已完成项目交付成果的操作能力。
  

这些因素可以提供需求属性定义（即，实施需求相关的成本是“高”、“中”还是“低”？），有助于对需求进行分类。
项目经理和业务赞助商应仔细审查“高”影响变更，以验证其有效性、成本、可行性、对运营的影响以及在影响分析期间发现的任何其他因素。此评估应防止在项目执行期间和之后出现意外结果。

需求管理

需求管理为项目分析、设计、开发、质量保证和持续维护活动奠定了基础。与需求管理相关的首要任务包括：捕获需求以供重用，验证需求，管理与需求相关的变更，并确保可交付成果与组织目标和需求的可追溯性。

捕获需求

常用需求属性列表

捕获需求以便在整个项目生命周期内对其进行管理，并将其用于将来重复使用。需求的级别可能识别出应该捕获的适当属性。例如，关联成本对于详细的系统需求来说可能不是一个现实的属性，但对于高级的业务需求来说，它可以支持优先级排序。对于每个需求，识别并记录与项目相关的需求信息（属性）。右侧的常用需求属性列表列出了一些通常包含在需求库中的常用属性，并包括捕获该属性的适当需求级别。请注意，这些属性代表一般性指南，应根据项目范围进行调整。


文字处理文档通常是跨项目利益相关者群体传达需求的良好载体。但是，使用基于文档的方法来管理需求会导致一些问题，这些问题可以通过将需求和需求属性存储在电子表格、简单数据库或其他需求管理工具中来避免。这些问题包括

• 文档难以保持最新
• 需求变更难以传达
• 管理需求所需的信息难以存储和使用
• 难以将需求追溯到其他项目工件
  

应该捕获多少需求以及捕获到什么程度？这通常根据具体情况而定。它取决于各种因素，包括业务的性质、涉及的利益相关者、可交付成果的复杂性/范围以及项目管理方法。例如，涉及实施现成应用程序的项目通常不会像负责整合来自多个数据库的信息的项目那样广泛地记录所有需求。每个项目必须根据项目可交付成果确定适当的需求定义级别。

捕获需求的级别应由项目复杂性和环境驱动。至少必须捕获高级业务需求。这些需求清楚简洁地陈述了解决方案的需求和目标，为利益相关者群体提供了共同的理解。它们代表了在发布前进行的质量保证活动期间验证解决方案的基础。它们提供了对所实施的详细需求的“向后追溯性”的来源。

在项目的定义阶段，会识别和细化功能性和非功能性需求，或业务和技术需求。这些类型的需求可以在非常详细的级别（例如，UI、用户、利益相关者等）或仅封装解决方案的“为什么”和“什么”的高级级别进行捕获。每个较低级别的需求都应直接与它支持的高级业务需求相关联。这确保了对解决方案的完整验证。

可能还需要过渡需求来涵盖从现有流程/应用程序到项目将交付的新解决方案的切换。

功能性/业务性	定义应用程序的行为和功能，应用程序将管理的信息以及所需输入/输出。这些需求必须考虑业务的运营方式、支持项目目标和需求所需的改进和更改，并纳入必须支持的任何现有约束。
非功能性/技术性	必须支持并得到应用程序必须保持有效性的环境条件的支持。它们包括应用程序必须具有的质量。它们包含与性能、可扩展性、安全性、可用性、系统可用性和底层信息架构相关的标准。
过渡性	仅在从项目可交付成果的“现状”状态过渡到“目标”状态期间存在，并且只有在系统设计后才确定。它们包括数据转换、用户培训和其他必须在解决方案实施过程中得到支持的过渡需求。

验证需求

在初始发现之后，通常需要一些时间来收集相关信息并最终确定需求。每个需求都应具有完整的一套捕获的属性，并表达将得到支持的业务需求或“什么？”。实际需求文本应编写得清晰简洁，以便所有项目审阅者和批准者都能对每个需求达成共识。

导致需求批准的过程涉及所有项目团队成员、业务专家和技术监督。需求将分发给指定为负责审阅的人员。审阅者将接受所写的需求，对需求信息提出异议，详细说明其理由或依赖关系，并总体上提供反馈以更正或完善需求。重要的是，需求审阅者应了解他们在此过程中的作用。应向审阅者提供明确的指导，包括评估标准和验证的签字流程。

一旦对需求进行了审阅并针对任何更正或遗漏的信息进行了调整，就必须由指定的运营和/或技术部门进行批准。批准过程包括对需求的运营和技术准确性进行审阅，并考虑实施的可行性。已批准的需求将为需求管理过程提供“基线”，设定用户和其他利益相关者对项目可交付成果的期望。对于可交付成果将分阶段或冲刺完成的 IT 项目，在开始初始开发工作之前，不必完成对将在项目后期阶段支持的需求的批准。

在审阅和批准期间，应使用一个流程来解决冲突和/或问题。此流程将提供一个框架来支持项目的前进。每个项目都可能具有一个独特的解决问题的流程，具体取决于参与的业务、文化和团队成员。无论建立了哪个流程，都应将其清楚地传达给所有项目团队成员。然后，应遵循它。问题解决的一致性将增强执行项目并实现目标的能力。

管理变更

随着项目的进展，将会有进一步的变更和/或改进，这些变更和/或改进会影响已批准的需求，或者会创建新的需求。变更可能是由识别新的所需功能、当前实施中的错误或缺陷以及提高现有功能的高优先级请求所产生的。应分析每个潜在变更，以确定相关的可行性、成本和收益。对进行变更影响的分析应识别对项目进度、成本或其他现有需求的任何相关变更。

用于管理变更的收集属性的描述

变更请求通常与项目需求分开捕获。识别将受到变更影响的需求对于维护项目正确和最新的需求至关重要。变更请求应包括详细说明以证明增强功能或识别相关工作必要性的信息。实际上，每个请求都必须包含一个简要的商业案例来证明变更的合理性。右侧用于管理变更的收集属性描述表列出了一些建议的变更请求属性。与捕获的需求属性一样，应确定变更属性以包含适用的项目范围和需求。

管理变更包括捕获变更，获得利益相关者的批准，修改现有项目计划、流程或其他图表/模型以及需求以包含变更，执行变更，对变更执行 QA，最后实施变更。此过程将影响现有需求并创建新的项目（或应用程序）需求。应使用唯一的变更请求 ID 号作为需求（或修改后的需求）“来源”来识别对基线需求的变更。

当需求“已批准”时，它将成为基线需求。此“已批准”状态一直有效，直到被更改。例如，已批准实施一项变更请求，该变更请求将修改我们现有的“已批准”需求。现在，现有的基线需求将使用包含已批准变更的需求更新版本来替换。此需求更新版本是新的基线，当前“已批准”的需求。先前已批准的需求已停用。其他依赖于该需求的项目可交付成果，包括质量保证测试和用户文档，也需要根据批准的修订版进行更新。

变更管理流程

右侧的变更管理流程图说明了可能用于管理变更的简化流程。有关变更的信息，包括范围、可行性、成本、收益以及对现有需求和技术架构的影响，将需要供批准者审阅。指定人员将负责批准变更。

一旦变更请求获得批准，该变更将被纳入当前的项目工作进度、预算和需求库中。对于新的需求，将捕获需求库中的属性。对于对现有已批准需求的变更，应使用已更改的需求替换原始需求。应将原始需求标记为非活动状态，并将其保留以供历史分析之用。

追溯需求

需求是确保项目可交付成果支持证明该项目合理的需要的基础。每个捕获的需求都应包含一个属性，该属性提供对需求来源的“向后”可追溯性。
一旦需求获得批准，其他项目工件将会被生成。需求和项目工作之间存在对应关系。对于 IT 项目，需求将分配到设计交付品的不同领域。对于非 IT 项目，需求也必须由项目交付品来满足。质量测试、用户文档和培训也源于需求。可追溯性，从最初的项目文档贯穿项目生命周期到实施的解决方案，都应该在捕获的需求和其他项目工件中得到支持。

前向可追溯性图

右侧的图表展示了从需求来源到交付品设计、项目质量保证过程的测试脚本和最终用户文档的“前向”可追溯性。可以通过逆向流程来查看“后向”可追溯性路径。使用支持这种跟踪功能的方法可以确保项目交付品支持所有已识别的项目需求和目标。

矩阵展示了任务与功能需求之间的对应关系，以便于可追溯性

可追溯性通常使用矩阵来表示，该矩阵关联任何两个基线项目工件。它在确定更改可能产生的影响时特别有用。右侧的矩阵提供了一个需求可追溯性矩阵的示例，该矩阵可用于评估需求更改对新开发工作质量测试的影响。

在这个例子中，对与第三个“表单”相关功能需求的功能更改有可能影响到创建、编辑和编辑/复制表单任务的 23 个现有功能验证测试。
与捕获需求一样，需求的跟踪程度应根据项目的具体情况确定。当相关工作带来的业务价值较低时，保持非常高的可追溯性水平可能过分。但如果无法维持足够的可追溯性，很容易影响项目在成本和进度约束内保持的能力。

沟通

需求收集和管理活动期间的必要沟通将由项目的用途、利益相关者和环境决定。对于较小的项目，可能不需要需求沟通计划；对于较大的项目，正式计划可能是确保所有团队和管理人员在工作中协调一致以及所有项目目标都能实现的关键因素。
无论项目的正式程度如何，与需求沟通相关的目标都围绕着一个概念，即所有利益相关者应该对需求有一个共同的理解。

适合接收者

沟通应该始终以适合信息接收者的程度呈现。针对单个利益相关者的沟通水平应该与他们在项目执行中的角色相匹配。
例如，高管可能会收到一份执行摘要需求文档，该文档以非常高的层级呈现需求。主题专家和其他利益相关者可以审查描述需要哪些输入、输出、行为和能力的中层功能需求。开发和质量保证人员需要详细的功能和系统需求。
在沟通需求时使用这些不同的层级可以防止接收者获得过多或不足的信息，以满足他们的目的。

需求工件

需求工件

在生成正式的需求工件时，这些工件应该遵循标准格式，并包含一致的内容以完成它们支持的工作任务。有关格式和内容的标准可以从许多标准制定机构采用，或者可以在组织内部自行制定。需求信息呈现的一致性将促进所有利益相关者群体之间的共享理解。
右侧的图像列出了一些用于需求管理的常见工件。在项目执行过程中实际使用到的需求工件可能包括这些工件，以及其他适用于项目的工件。

需求信息交付

在项目需求收集阶段发生的沟通通常采取项目团队和业务客户之间非正式对话和电子邮件的形式。一些项目可能拥有一个共享的存储库，供多个人同时审查文档，并可能包括电子审批；其他项目可能依赖于利益相关者接收通过电子邮件发送的文档，以便打印并存放在项目文件夹中。无论采用何种交付方式，确保所有项目利益相关者拥有适当的需求信息以在项目中履行其职责，都是业务分析师的主要职责。

沟通需求变更

对基线需求的更改必须通知项目利益相关者。大部分沟通是在审批过程中完成的，但对于没有参与该过程的人，应该使用通知、演示或其他沟通方式，以便所有人员都知道变更及其对项目工作的影响。更改可能需要应用于上游和/或下游项目交付品。例如，法律的变更可能需要修改高级项目文档、需求文档、设计计划、测试计划或其他正式工件。当进行包含此类修订的更改时，使用或依赖于该工件的人员应该收到通知，告知工件已更改以及更改的原因。通知应该包括受影响的工件文档的更新版本。

本节提供材料的应用

分析工作的范围可能包括业务分析师参与项目的整个执行过程，也可能仅限于整个项目工作的一部分。需求文档和管理提供了一个框架，可以完成项目生命周期中的所有必要活动。以有条理的方式记录需求的好处包括能够执行诸如更改影响分析、为创建用户指南提供完整的范围信息、确定质量保证测试以验证业务目标以及支持以有条理的方式管理项目团队沟通等任务。在定义项目需求时投入精力捕获需求，即使对于涉及项目交付品的未来开发项目也是有益的。