- 确定利益相关者。第一步是准确指出项目的关键利益相关者。这包括内部和外部客户、用户、监管机构以及参与产品开发的利益相关者。利益相关者是产品必须满足的需求和要求的来源。
- 引出利益相关者的需求和要求。在需求分析过程的这一步（也称为需求和要求收集）中，团队与利益相关者合作以确定后者的需求和要求。
- 建模需求和要求。在捕获了利益相关者的初始需求和要求集后，团队可以创建需求和要求的可视化表示或图表作为其分析的一部分，以告知产品要求、用例和用户故事的定义。这些可视化表示和图表用于在定义和确定产品要求之前征求利益相关者的反馈并解决问题、冲突和不一致。
- 回顾。项目团队审查在引出、绘制图表和建模过程中收集的数据和信息。特别值得关注的是了解驱动因素和约束条件，以便更好地了解与开发产品相关的可行性和风险，评估是否遗漏了任何内容，并制定预算和时间表。
- 定义一组综合需求。项目团队得出一组综合的利益相关者需求和要求，这些需求和要求代表了利益相关者对产品的期望、目标、目的、驱动因素和约束条件。
- 定义产品要求。此时，团队审查最终的综合需求和利益相关者要求，并将其转换为产品设计和制造所需的一组产品要求。重要的是，最终的需求是具有良好格式需求特征的高质量需求。确保所有团队成员都知道如何编写良好的需求是明智的做法。
- 签字和基准。需求分析过程的最后一步是获得第一步中确定的所有关键利益相关者（或利益相关者团体的代表）对综合需求集和最终产品要求集的签字同意。这是一份正式合同，让每个人都知道将根据什么来验证和确认产品、成本和时间表。它有助于消除开发过程后期的意外和范围蔓延。
- 多种格式：线性、跨职能、自上而下。
- 易于创建，所有团队成员都能理解。
- 突出显示关键流程属性。
- 变更管理耗时，因为需要重新绘制流程图以适应流程变更。
- 复杂的流程会导致流程图密集，难以理解。
- 可以在分析过程的需求获取步骤中创建，以定义项目范围。
- 技术和非技术受众都可以理解它们。
- 创建它们可能很耗时，尤其是对于复杂的软件应用程序。
- 数据流图中不包含物理考虑因素。
- 说明活动中的各个步骤以及执行这些步骤的顺序。
- 支持跨角色通信。
- 每个工作流都需要一个新图表，否则它们会变得太笨重。这使得很难全面了解系统。
- 这些图表没有提供有关对象如何行为或协作的详细信息。
- 有多种 UML 图表可供选择，例如用例、序列、交互、类等。
- 可以直接输入到需求工具中。
- UML 图表必须与软件代码同步，这需要额外的工作和持续的维护。
- 复杂的流程会导致图表过于复杂和混乱。
- 旨在让所有业务利益相关者都能理解，但代表复杂的流程语义。
- 大多数建模工具都支持。
- 仅支持适用于业务流程的建模概念；非流程目的超出范围。
- 单个图表可以跟踪许多活动，即使是并行发生的活动。
- 它提供了项目需要多长时间以及开发各个阶段需要哪些资源的现实视图。
- 无法提供所有任务的单一视图。
- 分配给任务的时间不能代表完成任务所涉及的工作量。
- 复杂的软件项目需要极高的任务数量，因此创建甘特图非常耗时，而且几乎不可能及时、一致地更新。
- IDEF 几乎可用于任何环境、行业和技术领域。
- 图表对于技术和非技术团队成员来说都很容易理解。
- 集成不同的 IDEF 技术可能很困难。
- 它被设计为一种业务分析工具，并不是一种很好的软件应用程序开发方法。
- 确保业务需求或数据需求已按预期得到满足。
- 帮助发现哪些领域需要关注或额外资源。
- 成功取决于执行分析人员的技能，虽然差距可能会被揭示，但其真正原因可能仍未被发现。
各种图表和建模技术的重点
需求分析是软件开发中需求定义和管理流程的关键部分。需求分析的目的是确保所有产品需求准确反映利益相关者的需求和要求。正确执行需求分析会产生一组产品需求，满足这些需求后，将产生符合利益相关者期望的可交付成果。
什么是需求分析？
需求分析是发现利益相关者对正在开发的系统或软件应用程序的需求和要求的过程。它确认准确捕获、解释和表示客户、用户和其他利益相关者的需求，并将这些需求转化为产品需求集。为了获得最佳结果，必须验证产品需求集是否具有格式良好的需求的特征（例如需要、明确、完整、一致、正确、可行、可验证），并验证它们是否代表了它们所转化的需求的意图。
需求分析的最佳实践
利益相关者可以通过多种形式传达他们的期望——需求和要求。利益相关者需求代表利益相关者需要产品做什么来解决产品要解决的问题或机会；利益相关者要求是利益相关者定义的顶级产品要求，用于传达利益相关者对产品的要求，以满足他们的需求。利益相关者需求以自然语言表达，不使用“必须”，而利益相关者要求则使用“必须”来传达，以确保它们被视为产品将被验证满足的约束性要求。
在定义产品设计和构建的产品要求之前，定义和理解利益相关者的需求和要求非常重要。由于有多个利益相关者，因此将有多组利益相关者的需求和要求。项目团队需要引出这些需求和要求，并解决冲突、不一致和其他问题。结果将是一组综合的需求，产品要求将从中转化而来。由此产生的产品要求代表产品必须做什么才能使需求满足所述需求。
需求可追溯性对于需求分析过程至关重要。它用于确保每个需求清楚地传达其来源的意图。如果没有可追溯性，几乎不可能知道软件产品是否满足其利益相关者的需求、目标和约束。需求分析可以完美地执行，但如果没有需求到其来源的可追溯性，就无法证明您拥有完整、正确的需求集。
因此，需求分析的最佳实践是确保每个需求都可以追溯到所有相应的工件。这些工件不仅包括其来源，还包括下游工件，包括设计、产品验证规划和产品确认规划。
需求分析的另一个同样重要的最佳实践是执行预定的流程。仔细执行每个步骤可能是产品成功或无法满足利益相关者需求的区别。
需求分析过程
通常，需求分析过程分为七个步骤。
需求分析过程中的常见挑战
上述步骤可能需要重复，因为需求分析最常见的挑战是需求可能会在整个软件开发过程中发生变化。随着团队实现各种功能，应针对每个功能重复这些步骤；这样做通常会导致额外的需求和要求。通过遵循规定的步骤并在项目开始时不仅对集成产品而且对软件应用程序提供的每个功能进行签字，可以降低变更风险。
变更的一个原因是未能包括所有相关利益相关者。如果只关注客户或用户，则会忽略与其他利益相关者相关的需求和要求。鉴于利益相关者数量众多，将存在不一致、冲突和问题。未能尽早处理这些问题将导致变更。在对集成需求和产品要求进行基准化之前使用各种可视化、图表和模型有助于确保完整性、正确性和一致性。同样，在对产品要求进行基准化之前未能做到这一点将导致变更并导致昂贵且耗时的返工。
在其他情况下，一些利益相关者可能直到看到产品实际运行后才知道自己需要什么。项目限制也可能需要对解决方案进行更改。无论如何，敏捷团队都在不断迭代和更新设计。这意味着评估需求和要求的过程几乎永无止境。上面的图表和建模步骤是一个很好的工具，可用于与利益相关者互动，以更好地了解他们的需求。目标是第一次就尽可能全面，并获得全局视图，以最大限度地减少废品和返工。
各种图表和建模技术的优缺点
在引出、绘制图表和建模过程中，有多种技术可用。有些比其他技术更有用。这里我们回顾了一些流行的技术，并指出了每种技术的优缺点。
流程图
流程图显示一组相关活动的顺序流程和控制逻辑。它们可用于表示数据流、系统（软件应用程序）交互（内部和外部）等。
优点
缺点
数据流图
这些图显示了信息在系统中的流动。数据流图组件包括流程、流程、存储和终止符。
优点
缺点
角色活动图
角色活动图将业务和软件流程显示为角色执行的一系列操作。角色通过活动进行识别，并按职责进行分组。它们可用于描述用例、工作流、业务流程或软件协议。
优点
缺点
统一建模语言 (UML)
统一建模语言创建用于在需求分析过程中建模规范、开发、可视化和记录的图表。UML 图表可以分为两种类型的模型：行为模型（告知软件应用程序将执行的操作）和结构模型（提供有关组成系统的各部分的见解）。
优点
缺点
业务流程建模和符号 (BPMN)
BPMN 基于流程图技术，类似于统一建模语言 (UML) 中的活动图。它使用独特的符号标准来创建图形，包括流对象、连接对象、泳道和工件。这些有助于简化对业务流程的理解，回答有关谁执行活动以及执行活动所需的数据元素的问题。
优点
缺点
甘特图
在需求分析中，甘特图有助于协调、规划和跟踪项目任务。要执行的任务沿纵轴列出。横轴列出分配给给定任务的时间以及执行功能的人员或团队。甘特图直观地表示了项目的时间表和所需的资源。
优点
缺点
功能建模集成定义 (IDEF) 图表
IDEF 是一系列建模语言，涵盖了从功能建模到数据、模拟、面向对象的分析/设计和知识获取等广泛用途。[i] 目标是通过探索与子/父系统之间的流程功能关系来了解组织的系统。
优点
缺点
差距分析
这种技术也称为需求分析、需求评估或需求差距分析，有助于分析软件应用程序性能差距，以验证业务需求是否得到成功满足。差距分析传达了当前状态和目标状态之间的差异，确定了项目的现状以及尚待完成的工作。
优点
缺点
一些需求图表和建模技术更适合分析业务需求和要求，而其他一些更适合发现用户需求和要求。
BPMN 严格来说是一种发现业务需求和要求的技术，必须在产品需求集内解决这些需求和要求，并能取得优异的结果。差距分析也是了解业务需求的好方法。如上所述，它可以帮助确定企业当前所处位置与期望位置之间的差异。结果可能会引发一系列用户需求，以帮助企业缩小差距。
虽然上面没有提到，但客户旅程图也有利于发现业务需求。客户旅程图是一个“客户之声” VOC 故事，展示了客户与企业在一段时间内的关系。它有助于识别客户方面的挫败感来源，从而可以告知用户需求以改善这些痛点。注意：将此分析限制在单一类别的利益相关者可能会导致需求和要求缺失。更具包容性的方法是“利益相关者之声” VOX，它显示了所有相关利益相关者与企业在一段时间内的关系。它有助于识别所有利益相关者（而不仅仅是客户）的挫败感来源，从而可以告知定义产品需求以改善这些痛点。
用户需求和要求的发现受益于数据流图等技术。如上所述，它们可以尽早创建并提供特定流程内数据流的高级视图。用例和用户故事也是从用户角度征求软件需求的绝佳工具，因为它们关注的是用户的需求，而不是产品如何满足这些需求和愿望。
简化需求分析流程
需求定义和管理的需求分析阶段的结果是，作为分析的一部分使用的图表和模型、一组综合需求和一组作为设计过程输入的产品需求。产品需求集定义了正在创建的软件应用程序的功能和预期行为，以便在设计中实施时满足利益相关者的需求。拥有一组基准产品需求有助于明确项目细节，减少浪费的时间和潜在的返工。
虽然一些组织会以文档形式传达这组产品需求（例如，软件需求规范），但越来越多的趋势是在需求管理软件应用程序中管理需求。
组织转向以数据为中心的产品开发实践的原因是，任何基于文档的方法都很难足够灵活和可扩展以应对复杂的敏捷项目。对于必须证明合规性的严格监管行业来说尤其如此。由于多种因素（缺乏一致更新、人为错误、数据不完整、版本控制、需要建立和维护可追溯性等），文档根本无法用于确定需求或要求是否得到满足。
在高度监管的行业中，开发复杂产品的敏捷产品团队将使用需求管理软件应用程序来简化需求定义和管理的需求分析阶段，从而获得更大的成功。现代需求定义和管理解决方案（如 Jama Connect®）可帮助自动定义、管理、建立可追溯性和验证复杂产品需求，这不仅简化了需求分析，还简化了整体需求定义和管理流程。
通过实时需求和数字线程，Jama Connect 可帮助团队实时协作。这降低了使用文档进行需求分析的风险。它还自动启用可追溯性，因此可以证明所做的辛勤工作——即使是最复杂、监管最严格的软件产品也是如此。
了解 Jama Connect 如何简化需求分析和需求管理。
