确保规定要求满足客户需求的过程。
需求验证
它是一个确保特定需求满足客户需求的过程。它关心的是找到需求中的问题。
当这些问题在后期发现时，或者在系统投入使用后，这些问题会导致大量的返工成本。
通过系统变更来修复需求问题的成本通常比修复设计或代码错误的成本要大得多。因为对需求的更改通常意味着设计和实现也必须更改，并重新测试。
在需求验证过程中，应对需求进行不同类型的检查。这些检查包括:
- 有效性检查:涉众提出的功能应该与系统需要执行的功能保持一致。稍后您可能会发现需要其他或不同的功能。
- 一致性检查:文档中的需求不应该冲突或同一功能的不同描述
- 完整性检查:文档应该包括所有的需求和约束。
- 真实性检查:确保需求能够利用现有技术、预算、进度等方面的知识实际实现。
- 可验证性:编写需求时应该让它们能够被测试。这意味着您应该能够编写一组测试来证明系统满足指定的需求。
您可以使用一些技术来验证需求，根据您的需要，您可以同时使用其中的一个或多个。
需求评审
系统客户团队;那些与客户交互以收集需求的人，以及系统开发人员开始阅读文档中的需求，并进行详细调查，以检查错误、不一致、冲突和任何不明确之处。
然后他们可能会与客户协商如何解决发现的问题和错误。
原型设计
我们已经讨论了作为(非独立的)软件过程方法之一的原型设计，它被用作完整方法的一部分，并且我们还在需求工程中提到了它。
在这种验证方法中，系统的可执行模型被向客户和最终用户进行验证，并确保它是否满足他们的需要。
原型设计通常在需求不明确时使用。为此，我们对系统进行了快速设计，以验证需求。如果失败了，我们就改进它，并再次检查，直到它满足客户的需求。
这肯定会降低成本，因为有一个清晰的、可以理解的、一致的需求。
测试用例的生成
正如我们刚才提到的，需求需要是可测试的。如果需求测试是作为验证过程的一部分添加的，这通常会揭示需求问题。
如果a测试很难或不可能设计，这通常意味着需求将很难实现，应该重新考虑。
这里的术语“测试”并不意味着为每个函数编写和运行一些代码。它意味着编写执行每个功能的“输入”、“期望值”和“采取的步骤”的文本描述。
这是一个测试用例的模板。
测试用例模板
要证明一组需求确实满足了用户的需求是很困难的。因为用户需要在操作中使用系统，并想象该系统将如何适应他们的工作。因此，进一步的需求变化是不可避免的。
