「需求工程」需求工程——需求验证(第4部分)

确保规定要求知足客户需求的过程。

需求验证

它是一个确保特定需求知足客户需求的过程。它关心的是找到需求中的问题。

当这些问题在后期发现时，或者在系统投入使用后，这些问题会致使大量的返工成本。

经过系统变动来修复需求问题的成本一般比修复设计或代码错误的成本要大得多。由于对需求的更改一般意味着设计和实现也必须更改，并从新测试。

在需求验证过程当中，应对需求进行不一样类型的检查。这些检查包括:

• 有效性检查:涉众提出的功能应该与系统须要执行的功能保持一致。稍后您可能会发现须要其余或不一样的功能。

• 一致性检查:文档中的需求不该该冲突或同一功能的不一样描述

• 完整性检查:文档应该包括全部的需求和约束。

• 真实性检查:确保需求可以利用现有技术、预算、进度等方面的知识实际实现。

• 可验证性:编写需求时应该让它们可以被测试。这意味着您应该可以编写一组测试来证实系统知足指定的需求。

您可使用一些技术来验证需求，根据您的须要，您能够同时使用其中的一个或多个。

需求评审

系统客户团队;那些与客户交互以收集需求的人，以及系统开发人员开始阅读文档中的需求，并进行详细调查，以检查错误、不一致、冲突和任何不明确之处。

而后他们可能会与客户协商如何解决发现的问题和错误。

原型设计

咱们已经讨论了做为(非独立的)软件过程方法之一的原型设计，它被用做完整方法的一部分，而且咱们还在需求工程中提到了它。

在这种验证方法中，系统的可执行模型被向客户和最终用户进行验证，并确保它是否知足他们的须要。

原型设计一般在需求不明确时使用。为此，咱们对系统进行了快速设计，以验证需求。若是失败了，咱们就改进它，并再次检查，直到它知足客户的需求。

这确定会下降成本，由于有一个清晰的、能够理解的、一致的需求。

测试用例的生成

正如咱们刚才提到的，需求须要是可测试的。若是需求测试是做为验证过程的一部分添加的，这一般会揭示需求问题。

若是a测试很难或不可能设计，这一般意味着需求将很难实现，应该从新考虑。

这里的术语“测试”并不意味着为每一个函数编写和运行一些代码。它意味着编写执行每一个功能的“输入”、“指望值”和“采起的步骤”的文本描述。

这是一个测试用例的模板。

测试用例模板

要证实一组需求确实知足了用户的需求是很困难的。由于用户须要在操做中使用系统，并想象该系统将如何适应他们的工做。所以，进一步的需求变化是不可避免的。