业务分析 - 需求管理

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

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

项目为何失败

项目失败的原因有很多，但一些常见的原因包括：

问题的核心是项目越来越复杂，变化不断发生，沟通也面临挑战。

需求管理是为了让您的团队保持同步并提供项目内正在发生的情况的可见性。

让整个团队了解您正在构建的内容及其原因对于项目的成功至关重要 - 这就是我们定义需求管理的方式。“为什么”很重要，因为它提供了有关需求的目标、反馈和决策的背景。

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

需求是利益相关者解决问题或实现目标所需的条件或能力。系统或系统必须满足或拥有的条件或能力。满足合同、标准、规范或其他正式强制文件的组件。

需求可以用文本、草图、详细的模型或模型来表达，任何信息都可以最好地向工程师传达要构建的内容以及向 QA 经理传达要测试的内容。根据您的开发过程，您可能会使用不同的术语来捕获需求。

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

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

利益相关者可能会请求一个描述产品如何在解决问题时提供价值的功能。设计人员可能会根据最终产品的外观或性能从可用性或用户界面的角度来定义需求。

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

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

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

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

在实践中，您不一定需要“共识”，您需要团队的“支持”以及控制人员的批准，以便您可以推动项目向前发展。通过共识，你试图让每个人都妥协并就决定达成一致。通过支持，您可以尝试让人们支持最佳解决方案，做出明智的决定，并采取必要的行动来推动前进。

你不需要每个人都同意这个决定是最好的。你需要每个人都支持你的决定。团队协作有助于获得决策支持和规划良好的需求。

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

当开发人员、测试人员或其他利益相关者感到“脱离循环”时，就会出现沟通问题，人们会感到沮丧，项目也会被推迟。一旦每个人都接受了工作范围，就必须明确要求并记录完整。跟踪所有需求是事情变得棘手的地方。

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