规划好需求
那么，什么才是好的需求呢？一个好的需求应该是有价值的、可操作的；它应该定义需求并提供解决方案的途径。团队中的每个人都应该明白这意味着什么。要求的复杂程度各不相同。
好的需求文档可以是高级需求分解为子需求的组的一部分。
它们还可能包括非常详细的规范，其中包括描述最终产品的Behave或组件的一组功能要求。
好的需求需要简洁、具体，并且应该回答“我们需要什么？”的问题。而不是“我们如何满足需求？”
良好的要求确保所有利益相关者都了解他们的计划部分；如果零件不清楚或误解，最终产品可能有缺陷或失败。
随着需求的发展，在整个过程中不断接收来自团队的反馈，可以帮助防止需求失败或误解。与每个人的持续合作和支持是成功的关键。
需求收集和分析
需求是利益相关者解决问题或实现组织目标所需的条件或能力；系统必须满足或拥有的条件或能力。
软件工程中的需求分析涵盖了确定满足新产品或更改产品的需求或条件的任务，考虑到各个利益相关者可能存在的冲突需求，分析、记录、验证和管理软件或系统需求。
要求应该是 -
- 记录在案
- 可行的
- 可测量的
- 可测试
- 可追溯
需求应与已确定的业务需求或机会相关，并定义到足以进行系统设计的详细程度。
业务分析师通过观察现有系统、研究现有程序、与客户和最终用户讨论来收集信息。在缺乏有效系统的情况下，分析师还应该具有想象力和创造力。分析收集到的需求以找到缺失的环节就是需求分析。
诱导法
为了得出目标，请向业务专家、开发经理和项目发起人询问以下问题 -
该项目将帮助公司实现哪些业务目标？
我们为什么现在做这个项目？
如果我们稍后再做会发生什么？
如果我们根本不这样做怎么办？
谁将从这个项目中受益？
将从中受益的人是否认为这是目前可能做出的最重要的改进？
我们应该做一个不同的项目吗？
可能的目标可能是降低成本、改善客户服务、简化工作流程、更换过时的技术、试用新技术等等。另外，请确保您准确理解拟议的项目将如何帮助实现既定目标。
不同类型的要求
业务分析师感兴趣的最常见的需求类型如下 -
业务需求
业务需求是企业必须执行的关键活动，以满足组织目标，同时保持解决方案独立。业务需求文档 (BRD) 详细说明了项目的业务解决方案，包括客户需求和期望的文档。
用户需求
用户需求应指定用户期望/希望从软件项目构建的软件的具体要求。用户需求应该是可验证的、清晰简洁的、完整的、一致的、可追溯的、可行的。
用户需求文档（URD）或用户需求规范是软件工程中通常使用的文档，它指定用户期望软件能够执行的操作。
系统要求
系统要求涉及定义软件资源要求和需要安装在计算机上以提供应用程序最佳功能的先决条件。
功能要求
功能需求捕获并指定正在开发的系统的特定预期Behave。它们定义了诸如系统计算、数据操作和处理、用户界面和与应用程序的交互以及显示如何满足用户需求的其他特定功能等内容。为每个需求分配一个唯一的 ID 号。
非功能性需求
非功能性需求是指指定可用于判断系统运行的标准而不是特定Behave的需求。系统架构讲述了实现非功能性需求的计划。
非功能性需求涉及系统应该是什么样子，或者可以称为“系统应该是”。非功能性需求称为系统的质量。
过渡要求
过渡需求描述了解决方案必须满足的功能，以便促进从企业当前状态过渡到所需的未来状态，但一旦过渡完成，就不再需要这些功能。
它们与其他需求类型不同，因为它们本质上总是临时的，并且在定义现有解决方案和新解决方案之前无法开发它们。它们通常涵盖现有系统的数据转换、必须解决的技能差距以及达到所需未来状态的其他相关更改。它们是通过解决方案评估和验证来开发和定义的。
可追溯性和变更管理
需求可追溯性是一种组织、记录和跟踪从最初的想法生成到测试阶段的所有需求的方法。
需求跟踪能力矩阵（RTM）提供了一种在开发过程中跟踪功能需求及其实现的方法。每个要求及其相关部分编号都包含在矩阵中。
随着项目的进展，RIM 会更新以反映每个需求的状态。当产品准备好进行系统测试时，矩阵会列出每个需求、哪些产品组件满足该需求以及哪些测试验证其是否正确实现
在 RTM 中包含以下各项的列 -
- 需求描述
- FRD 中的需求参考
- 验证方法
- 测试计划中的需求参考
示例- 连接点以识别项目中项目之间的关系。它是公共下游流的连接器。
想法需求设计测试业务目标
您应该能够将每个需求追溯到其最初的业务目标。
通过跟踪需求，您可以识别变更所产生的连锁反应，查看需求是否已完成以及是否正在正确测试。可追溯性和变更管理使管理人员高枕无忧，并具有预测问题和确保持续质量所需的可见性。
质量保证
第一次正确交付需求意味着更好的质量、更快的开发周期以及更高的客户对产品的满意度。需求管理不仅可以帮助您正确完成任务，还可以帮助您的团队在整个开发过程中节省资金并减少许多麻烦。
简洁、具体的要求可以帮助您及早发现并解决问题，而不是等到后期才发现问题，否则修复成本要高得多。此外，在编码后的开发过程后期纠正缺陷的成本可能比在需求早期纠正的成本高出100 倍。
通过将需求管理集成到质量保证流程中，您可以帮助您的团队提高效率并消除返工。此外，返工是大多数成本问题发生的地方。
换句话说，开发团队将大部分预算浪费在第一次未正确执行的工作上。例如，开发人员根据旧的规范文档对功能进行编码，后来才知道该功能的需求发生了变化。通过有效的需求管理最佳实践可以避免这些类型的问题。
总之，需求管理听起来像是一门复杂的学科，但当你将其归结为一个简单的概念时，它是为了帮助团队回答这个问题：“每个人都了解我们正在构建什么以及为什么构建？” 从业务分析师、产品经理和项目负责人到开发人员、质量保证经理和测试人员，以及所涉及的利益相关者和客户——项目失败的根本原因往往是对项目范围的误解。
当每个人都在协作，并且对整个项目生命周期中与需求相关的讨论、决策和变更有完整的背景和可见性时，那就是成功持续发生并且您保持持续的质量的时候。此外，整个过程更加顺利，每个参与人员在此过程中的摩擦和挫折都会减少。
注- 研究表明，项目团队可以通过有效管理需求来消除 50-80% 的项目缺陷。根据卡内基梅隆软件工程研究所的说法，“软件开发成本的 60-80% 都来自于返工。”
获取需求签核
需求签核使项目利益相关者正式同意，所记录的需求的内容和表示是准确和完整的。正式协议降低了在实施期间或实施之后利益相关者引入新的（以前未遇到的）要求的风险。
获得需求签核通常涉及与每个项目涉众对记录的需求进行面对面的最终审查。每次审核结束时，利益相关者都需要正式批准经过审核的需求文档。该批准可以以物理方式或电子方式记录。
获得需求签核通常是需求沟通中的最终任务。业务分析师将需要正式需求评审的输出，包括对评审过程中提出的任何意见或反对意见的包容。