业务分析 - 需求管理

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

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

项目失败的原因

项目失败有很多原因，但一些常见领域包括以下内容 -

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

问题的核心在于，项目越来越复杂，变化不断发生，沟通也充满挑战。

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

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

对于整个团队了解正在构建什么以及为什么构建至关重要，这是项目成功的关键 - 这就是我们如何定义需求管理。“为什么”很重要，因为它为关于需求的目标、反馈和决策提供了上下文。

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

让我们从基础开始

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

需求可以用文本、草图、详细的模型或模型来表达，无论哪种信息最能传达给工程师要构建什么以及传达给 QA 经理要测试什么。根据您的开发流程，您可能使用不同的术语来捕获需求。

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

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

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

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

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

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

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

利益相关者的协作和认同

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

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

您不需要每个人都同意该决定是最好的。您需要每个人都支持该决定。团队协作可以帮助获得对决策的支持以及规划良好的需求。

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

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

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