产品团队的需求分析指南-Toy模板网

这篇具有很好参考价值的文章主要介绍了产品团队的需求分析指南。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

需求分析是软件开发流程中需求识别与管理的关键环节，需求分析的目的在于确保所有产品需求准确地代表了利益相关者的需求和要求。选择合适的需求分析方式可以帮助我们获取准确的产品需求，从而保证我们所交付的成果与利益相关者预期相符。

一、什么是需求分析？

需求分析是一个发现、理解和整理利益相关者对于产品的需求和期望的过程。其主要目标是为了精确地捕捉、解读并展示客户、用户和其他利益相关者的需求，进而将这些需求整理成为一组详尽的产品需求。为了取得理想成效，必须检验产品需求集是否具备良好的需求特性，如必要性、明确性、完整性、一致性、正确性、可行性以及可验证性，并检验其是否真实地表达了符合利益相关者的期望。

二、如何做好需求分析？

利益相关者通过需求和要求表达他们对产品的期望。需求代表了利益相关人希望产品解决的问题或抓住的机遇，而要求是利益相关人定义的顶级产品要求，用于传递对产品期望，是为了满足他们的要求。通常，利益相关者的需求用自然语言表达，不使用“应当”，而利益相关者的要求使用“应当”来确保他们被视为产品必须满足的约束性要求。

在定义产品需求之前，首先需要定义和理解利益相关者的需求和要求，产品将按照这些需求进行设计和构建。由于有多个利益相关者，将存在多套利益相关者的需求和要求。所以项目团队需要去识别这些需求和要求，并解决冲突、不一致和其他问题。最终确定的一套需求必须能准确的代表利益相关者对产品的要求，用以指导产品的开发。

需求追踪对于需求分析过程至关重要。它被用来确保每个需求清楚地传达了其来源的意图。没有追踪，几乎无法知道软件产品是否满足了其利益相关者的需求、目标和约束。需求分析可能执行得非常完美，但如果没有追踪需求到其来源，就无法证明你拥有完整、正确的需求集。

因此，需求分析的最佳实践是确保每个需求都可以追溯到所有对应的工件。这些工件不仅包括他们的来源，还包括下游的工件，包括设计、产品验证计划和产品确认计划。

另一个同样重要的需求分析最佳实践是执行预定的流程。仔细执行每个步骤可能是产品成功满足利益相关者需求或失败的区别。

三、需求分析流程

需求分析过程通常包括以下七个步骤：

1.确定利益相关者

第一步是准确地确定项目的关键利益相关者。这包括内部和外部的客户，用户，监管机构，以及参与产品开发的所有利益相关者。利益相关者是产品必须满足的需求和要求的来源。

2.收集利益相关者的需求和要求

在这个需求分析过程的步骤中，也被称为需求和要求收集，团队与利益相关者合作，确定他们的需求和要求。

3.需求和要求建模

团队可以通过创建需求和要求的视觉表示或图表，作为他们的分析一部分，来引导产品需求的定义，使用案例和用户故事的制定。这些视觉表示和图表用于向利益相关者征求反馈，并在定义和确定产品需求前解决问题，冲突和不一致。

4.回顾

项目团队会回顾在需求收集、图表制作和建模过程中收集的数据和信息。特别关注理解驱动因素和约束，以更好地理解开发产品的可行性和风险，评估是否有遗漏的内容，以及设定预算和时间表。

5.定义一套需求集

项目团队需要确认一套完整的利益相关者需求和要求集合，以反映他们对产品的期望、目标、驱动因素和约束。

6.定义产品需求

在此阶段，团队整合针对产品设计和构建的需求。好的需求的标志是具有良好的结构性特征。团队成员都应了解如何编写优质需求。

7.批准和设定基线

需求分析过程的最后一步是获得所有主要利益相关者（或利益相关者团体的代表）对整合的要求集和衍生的产品需求集的审批。这份正式的协议确保了每个人都清楚按照什么标准去验收和测试产品，以及预期的成本和时间表，有助于避免后续开发过程中出现需求理解不一致和项目范围扩大等问题。

四、需求分析中的挑战

由于在需求分析过程中变更经常发生，所以我们可能要不断重复上述步骤。每当新功能被引入时，就要重复这些步骤，从而生出额外的需求和要求。解决这个问题的方法就是要遵循既定的步骤，并在项目开始时对整体产品和每个功能进行审批确认，这样就可以降低需求变更的风险。

需求变更的一个原因可能是未能覆盖所有利益相关者。

仅关注客户或用户就可能忽视其他利益相关者的需求和要求。因为利益相关者的很多，需求表述可能会不一致、或者相互冲突。如果这些问题在开发早期未能解决，就会导致需求变更。在为要求和产品需求集设定基线之前，充分利用各种可视化工具、图表和模型可以确保需求完整、准确且一致，否则可能会导致需求变更发生以及高成本且耗时的返工。

另外，在看到产品如何运行之前，有些利益相关者可能无法准确地知道自己的需求。

项目约束也可能导致解决方案的调整。敏捷团队会持续地进行迭代和更新，也就是说评估需求和要求的过程一直在持续进行。上述图表和建模是与利益相关者互动、更好理解他们的需求的有效方式。我们的目标是在第一次流程后尽可能地全面捕捉需求，以尽可能减少返工。

五、各种类图表和建模技术的优缺点

在需求获取、图表制作和建模过程中，有各种各样的技术可供选择。其中一些比其他的更有益。在这里，我们将回顾一些流行的技术，并指出每种技术的优点和缺点。

1.流程图

流程图是用来展示相关活动的顺序流程和控制逻辑的图表，可用于表示数据流、系统内部和外部的交互，以及其他相关信息。

优点：

提供多种格式选择：线性、跨职能、自上而下
易于团队成员创建和理解
突出关键过程

缺点：

变更管理耗时，需要重新绘制流程图以适应变更。
复杂的过程会导致流程图密集，难以理解。

2.数据流图

数据流图展示了信息通过系统的流动。数据流图的组成部分包括过程、流、存储和终止节点。

优点：

可以在分析过程的需求获取步骤中创建，以定义项目的范围。
技术人员和非技术人员都能理解。

缺点：

创建它们可能会耗费大量时间，特别是对于复杂的软件应用。
物理考虑因素并不会包含在数据流图中。

3.角色活动图：

角色活动图将业务和软件开发过程描述为角色执行的一系列操作。这些活动与特定的角色关联起来，并按职责进行分组，用于描述用例、工作流、业务流程或软件协议。

优点：

解释活动中各个步骤及其执行顺序
支持跨角色的沟通

缺点：

每个工作流都需要一个新的图，否则它们会变得过于复杂。这使得很难全面了解系统
这些图表无法提供关于对象如何行为或协作的详细信息

4.统一建模语言 (UML)

统一建模语言（UML）是一种在软件工程中用于建模、可视化、开发和记录软件系统的标准化语言，使用一套图形表示法来描述系统的设计。在需求分析过程中，UML图表可对规范进行建模。简单来说，就是用图形的方式来描述系统的需求和功能。UML图可以分为两种类型的模型：行为模型，提供关于软件应用将做什么的信息；结构模型，提供关于构成系统部分的洞见。

优点：

多种UML图类型可供选择，如用例图、序列图、交互图、类图等
可直接与需求工具集成

缺点：

UML图需要与软件代码保持同步，增加了额外的工作量，必须持续维护
流程复杂可能导致图表过于复杂，不好理解

5.业务流程建模和符号 (BPMN)

业务流程建模和符号 (BPMN) 建立在流程图技术基础之上，如UML的活动图。使用特定的符号标准来创建图形，包括流对象、连接对象、泳道和工件，有助于简化对业务流程的理解，回答谁执行活动和执行所需的数据元素等问题。

优点：

目标是被所有业务利益相关者理解，但同时也能表示复杂的流程语义
大多数建模工具都支持BPMN

缺点：

仅适用于业务流程的建模概念，不适用于非流程的概念。

6.甘特图

在需求分析中，甘特图有助于协调、规划和跟踪项目任务。需要执行的任务沿着垂直轴列出。水平轴列出了给定任务的分配时间以及执行这些功能的人员或团队。甘特图为项目的时间表和所需资源提供了一个视觉表示。

优点：

一个图表可以跟踪多个活动，即使这些活动是并行的
可视化展示了项目实际所需时间和所需资源

缺点：

无法提供所有任务的单一视图
分配给任务的时间并不代表任务所涉及的工作量
对于复杂的软件项目，创建甘特图非常耗时，而且很难及时、同步更新信息

7.功能建模 (IDEF) 图

IDEF是一套建模语言，广泛应用于功能建模、数据建模、模拟、面向对象分析/设计和知识获取等领域。其目标是通过探索流程功能关系与子/父系统之间的功能关系来理解整个系统或组织的运作方式。

优点：

IDEF几乎适用于任何环境、行业和技术领域。
图表易于技术和非技术团队成员理解。

缺点：

难于整合不同的IDEF技术
只是业务分析工具，不是一套完善的软件应用程序开发方法论

8.差距分析

差距分析，也称为需求分析、需求评估或需求差距分析，这种技术有助于分析软件应用的性能差距，以验证是否成功满足了业务需求。差距分析表达的是当前状态和目标状态之间的差异，识别项目所处的位置以及还需要做什么。

优点：

确保满足了业务需求或数据需求
帮助发现哪些领域需要关注或额外的资源

缺点：

成功取决于执行分析的人的技能，而虽然差距可能被揭示，但其真正的原因可能仍然未被发现

六、不同需求图表和建模技术的不同优势

在选择需求图表和建模技术时，我们应考虑其各自的优势：一些需求图表和建模技术更适合分析业务需求，而其他的则更适合发现用户需求。

BPMN最适合发掘和明确业务需求；而差距分析作为一种独特的分析方法，则适合揭示当前状态与期望状态之间的差异，从而引出一系列用户需求以填补差距。其结果可能会补充一系列用户需求，以帮助业务填补这个差距。

上文虽然未提及“客户旅程图”，但它也是获取业务需求非常有效的工具。客户旅程地图能以故事的形式描绘出客户与企业之间随时间变化的关系，能帮助我们识别出客户所遇到的问题，进而指引出以改善这些问题为目标的用户需求。然而，如果我们只对一种类型的利益相关者进行分析，就可能会忽视其他客户需求。最好用”利益相关者的声音”（Voice of Stakeholder, VOX），来揭示所有相关利益相关者与企业之间的关系变化，帮助我们识别所有利益相关者（而不仅仅是客户）所遇到的问题，从而引导我们明确产品需求，以解决这些问题。

数据流程图等技术可有效的帮助我们寻找和理解用户需求。如上文所述，数据流程图在项目早期阶段创建，可为我们提供关于特定流程中数据流动的高级视图。用例和用户故事则是从用户角度收集软件需求的优秀工具，但是只关注用户的需求，而不需要展示满足这些需求所需要的产品功能和特性。

七、简化需求分析过程

在需求分析过程中，图表、模型、需求集和产品需求集是有效地定义和管理需求的关键成果。产品需求集具体描述了正在开发的软件需要满足哪些特性和预期行为才能满足利益相关者的需求。确定产品需求集基线有助于我们精确了解项目细节，从而减少不必要的时间消耗和返工。

越来越多的企业摒弃传统文档形式，选择需求管理软件工具来处理需求。这是因为基于文档的方法缺乏灵活性和可扩展性，无法应对复杂的敏捷项目，尤其是那些需要证明合规性的高监管行业。文档无法及时更新信息以确保信息一致，会出现人为失误，无法保证数据完整，无法进行版本控制以及建立和维护追溯性。总而言之，文档无法确定一个需求是否得到了满足。

开发复杂产品的敏捷团队，特别是受到高度监管的行业，更适合采用需求管理软件应用来简化需求定义和管理过程。需求定义和管理解决方案，如 PingCode，能够自动定义、管理需求，建立可追溯性和验证复杂产品需求，从而简化整个需求定义和管理的流程。

通过实时需求和数字线程，PingCode 能帮助团队实现实时协作，解决基于文档进行需求分析所带来的问题，即使在受到严格监管行业，也能自动实现需求可追溯性，以验证所完成的工作。