介绍：
为了交付一个成功的项目，正确和准确地定义需求至关重要。 但是，定义需求可能会很棘手——如果弄错了，您的项目将遭受进度延误、资源浪费或客户不满。 在本指南中，我们将了解需求定义是什么，以及如何在您自己的项目中应用它。 让我们开始吧！
有什么要求？
软件项目的需求是最终产品需要满足的功能、特性和约束。 换句话说，需求定义了软件应该做什么，它应该看起来如何，以及它必须满足的任何条件才能被认为是成功的。
收集要求 对于创建满足客户或客户需求的产品至关重要。 需要注意的是，需求可能会在整个项目过程中发生变化，因此有一个适当的机制来跟踪和管理这些变化是很重要的。
要求类型：
大致有两种要求：
- 系统要求 – 系统需求可以称为用户需求的扩展版本。 系统需求是任何新系统设计的起点。 这些要求是系统必须满足的用户要求的详细描述。
- 用户要求 – 用户需求是功能性和非功能性需求的组合。 这些用户需求的设计方式必须使没有任何技术知识的用户易于理解。 因此，它们必须使用简单的表格、表格和图表以自然语言编写。 此外，请确保该文档没有关于系统设计、软件或正式符号的详细信息。
功能性与非功能性要求：
功能要求 ，顾名思义，描述要设计的系统的功能。 它描述了系统将是什么以及它将如何发挥作用以满足用户需求。 它们清楚地描述了系统应该如何响应特定命令、功能以及用户的期望。
非功能性需求 解释要设计的系统的限制和约束。 这些要求对应用程序的功能没有任何影响。 此外，将非功能性需求细分为各种类别是一种常见做法，例如：
- 用户界面
- 可靠性
- 安全性
- 性能
- 维护
- 标准
对非功能性需求进行细分是一种很好的做法。 在创建要在要设计的系统中满足的要求的清单时，它会有所帮助。
非功能性需求与功能性需求一样重要。 如果功能需求指定系统应该做什么，非功能需求描述系统将如何做。 例如，新应用程序将向我们提供所有连接用户的最终列表。 这是功能需求的一部分。 如果要求说系统只能在 Windows 和 Linux 系统上运行，那将是非功能性要求的一部分。
两者之间的唯一区别是系统不能在不满足所有功能要求的情况下运行。 另一方面，即使系统不满足非功能性要求，它也会给你想要的结果。
定义要求：
任何项目最重要的方面是它的需求文档。 标准中的误解、不正确或过度必然会导致进度延误、资源损失和消费者不满。
需求分析应从业务或组织需求开始，并将其转化为项目需求。 如果达到规定的标准过于昂贵或花费过多的时间，则项目的要求可能不得不在与客户或赞助商的谈判中妥协、缩小或减少。
如何定义需求？
需求定义有不同的方法，但都有一些共同的步骤：
- 确定利益相关者及其需求
- 定义项目范围
- 功能性和非功能性需求草案
- 优先满足需求
- 与利益相关者一起验证需求
让我们仔细看看这些步骤中的每一个。
识别利益相关者及其需求 是 第一步 在需求定义过程中。 利益相关者是在项目中拥有既得利益的个人或团体。 他们可以是内部的（例如，公司的员工）或外部的（例如，客户、供应商、监管机构）。 在项目早期识别所有利益相关者及其需求非常重要，因为他们的输入对于定义需求至关重要。
这款 第二步 是 定义项目范围. 范围定义了项目的边界，并包括将作为其一部分交付的所有内容。 尽早定义范围有助于防止范围蔓延，即在项目中添加超出最初约定的附加特性或功能时。
这款 第三步 是 功能性和非功能性需求草案. 功能需求是那些描述软件应该做什么的需求，例如“软件应该能够登录用户”。 非功能性需求是那些描述软件应该如何工作的需求，例如“软件应该是响应式的”。 起草这两种类型的要求很重要，因为它们都有不同的用途。
这款 第四步 是 优先考虑需求. 这有助于确保在资源或时间有限的情况下首先解决最重要的要求。 可以使用各种方法对需求进行优先级排序，例如 MoSCoW（必须拥有、应该拥有、可能拥有、将拥有）或 Kano（必须拥有、高兴拥有）。
这款 第五步也是最后一步 是 与利益相关者一起验证需求. 这有助于确保需求准确反映利益相关者的需求。 可以通过各种方法进行验证，例如访谈、焦点小组或调查。
总结
定义需求是任何项目的关键步骤。 通过执行上述步骤，您可以确保所有利益相关者的需求都得到满足，并且项目保持在正轨上。 通过了解您的需求，您可以确保获得适合您需求的正确软件。 我们概述的 5 步程序应该可以帮助您收集所需的信息，以便就哪种软件适合您做出明智的决定。
