良好的需求规划

---

---

那么，什么构成了良好的需求？良好的需求应该是有价值且可操作的；它应该定义需求，并提供通往解决方案的途径。团队中的每个人都应该理解它的含义。需求的复杂性各不相同。

• 一份良好的需求文档可以作为包含高级需求分解成子需求的组的一部分。

• 它们还可以包含非常详细的规范，其中包括一组功能需求，描述最终产品的行为或组件。

• 良好的需求需要简洁明了，并应回答“我们需要什么？”而不是“我们如何满足需求？”

• 良好的需求确保所有利益相关者都理解他们计划中的部分；如果部分内容不明确或被误解，最终产品可能会出现缺陷或失败。

在需求演进过程中，通过持续不断地从团队那里获得反馈，可以帮助避免需求的失败或误解。与每个人的持续协作和认同是成功的关键。

需求收集和分析

需求是指利益相关者为解决问题或实现组织目标而需要的一个条件或能力；系统必须满足或拥有的条件或能力。

在软件工程中，需求分析涵盖了确定新产品或更改产品的需求或条件的任务，同时考虑各种利益相关者之间可能存在的冲突需求，分析、记录、验证和管理软件或系统的需求。

需求应：

• 已记录
• 可操作的
• 可衡量的
• 可测试的
• 可追溯的

需求应与已识别的业务需求或机会相关，并定义到足以进行系统设计的详细程度。

商业分析师通过观察现有系统、研究现有流程、与客户和最终用户讨论来收集信息。分析师在没有工作系统的情况下也应该具备想象力和创造力。分析收集到的需求以找到缺失环节就是需求分析。

需求获取方法

为了获取目标，向业务专家、开发经理和项目发起人提出以下问题：

• 这个项目将帮助公司实现哪些业务目标？

• 我们为什么现在做这个项目？

• 如果我们以后再做会怎么样？

• 如果我们根本不做会怎么样？

• 谁将从这个项目中受益？

• 那些将从中受益的人认为这是目前可能做出的最重要的改进吗？

• 我们是否应该做其他项目？

可能的目标包括降低成本、改进客户服务、简化工作流程、替换过时的技术、试用新技术等等。此外，请确保您完全理解拟议的项目将如何帮助实现既定的目标。

不同类型的需求

商业分析师最感兴趣的需求类型如下：

业务需求

业务需求是企业必须执行的关键活动，以便在保持与解决方案无关的情况下满足组织目标。业务需求文档 (BRD) 详细说明了项目的业务解决方案，包括客户需求和期望的文档。

用户需求

用户需求应指定用户期望/想要从软件项目构建的软件中获得的特定需求。用户需求应可验证、清晰简洁、完整、一致、可追溯、可行。

用户需求文档 (URD) 或用户需求规格说明书通常用于软件工程中，它指定用户期望软件能够做什么。

系统需求

系统需求处理定义软件资源需求和先决条件，这些需求和先决条件需要安装在计算机上才能提供应用程序的最佳功能。

功能需求

功能需求捕获并指定所开发系统的特定预期行为。它们定义诸如系统计算、数据操作和处理、用户界面以及与应用程序的交互等内容，以及其他显示如何满足用户需求的特定功能。为每个需求分配一个唯一的 ID 号。

非功能需求

非功能需求是指定可以用来判断系统操作的标准，而不是特定行为的标准。系统架构说明了实现非功能需求的计划。

非功能需求说明系统应该是什么样子，或者可以将其描述为“系统应该……”。非功能需求被称为系统的质量。

过渡需求

过渡需求描述解决方案必须满足的能力，以便促进企业从当前状态向预期未来状态过渡，但在过渡完成后将不再需要这些能力。

它们与其他需求类型不同，因为它们本质上总是临时的，并且因为只有在定义了现有解决方案和新解决方案后才能开发它们。它们通常涵盖来自现有系统的数据转换、必须解决的技能差距以及为达到预期未来状态而进行的其他相关更改。它们是通过解决方案评估和验证来开发和定义的。

可追溯性和变更管理

需求可追溯性是一种组织、记录和跟踪所有需求的方法，从最初的想法产生到测试阶段。

需求可追溯性矩阵 (RTM) 提供了一种方法来跟踪功能需求及其在整个开发过程中的实现。每个需求都包含在矩阵中，以及其关联的章节号。

随着项目的进展，RIM 会更新以反映每个需求的状态。当产品准备好进行系统测试时，矩阵列出每个需求、哪个产品组件解决了该需求以及哪个测试验证了它是否已正确实现。

在 RTM 中包含以下每一列：

• 需求描述
• FRD 中的需求参考
• 验证方法
• 测试计划中的需求参考

示例 - 连接点以识别项目内各项之间的关系。它是常见下游流的连接器。

创意 需求 设计 测试 业务目标

您应该能够将每个需求追溯到其原始业务目标。

通过追溯需求，您可以识别变化产生的连锁反应，查看需求是否已完成以及是否正在正确测试。可追溯性和变更管理为管理者提供了安心感和必要的可见性，以便预测问题并确保持续的质量。

质量保证

第一次就正确交付需求意味着更高的质量、更快的开发周期以及更高的客户满意度。需求管理不仅有助于做到正确，还有助于您的团队在整个开发过程中节省资金和避免许多麻烦。

简洁明了的需求可以帮助您尽早发现和解决问题，而不是在以后解决问题时成本高得多。此外，在开发过程后期编码后纠正缺陷的成本可能高达100 倍，而早期在需求时纠正的成本则要低得多。

通过将需求管理集成到您的质量保证流程中，您可以帮助您的团队提高效率并消除返工。此外，返工是大多数成本问题发生的地方。

换句话说，开发团队正在将大部分预算浪费在第一次没有正确执行的工作上。例如，开发人员根据旧的规范文档编写功能代码，之后才了解到该功能的需求已更改。通过有效的需求管理最佳实践，可以避免此类问题。

总而言之，需求管理听起来可能是一门复杂的学科，但当您将其简化为一个简单的概念时——它是关于帮助团队回答“每个人都理解我们正在构建什么以及为什么？”这个问题。从商业分析师、产品经理和项目领导到开发人员、质量保证经理和测试人员，以及相关的利益相关者和客户——项目的失败根源往往是对项目范围的误解。

当每个人都在协作，并且对整个项目生命周期中与需求相关的讨论、决策和更改具有完整的背景和可见性时，成功就会持续发生，并且您可以保持持续的质量。此外，该流程更加流畅，参与其中的每个人都会减少摩擦和挫败感。

注意 - 研究表明，项目团队可以通过有效地管理需求来消除 50-80% 的项目缺陷。根据卡内基梅隆软件工程研究所的说法，“60-80% 的软件开发成本用于返工。”

获取需求签字

需求签字确认正式确认项目干系人对已记录需求的内容和表达方式的准确性和完整性达成一致。正式确认降低了在实施期间或之后，干系人引入新的（以前未遇到过的）需求的风险。

获得需求签字确认通常涉及对已记录的需求进行面对面的最终审查，审查对象为每个项目干系人。在每次审查结束时，都会要求干系人正式批准已审查的需求文档。此批准可以物理方式或电子方式记录。

获得需求签字确认通常是需求沟通中的最终任务。业务分析师需要正式需求审查的输出结果，包括对审查过程中提出的任何意见或异议的处理。