核实要求问题

Question

在阅读大量关于V&V的文章时，我需要澄清以下几点。很多定义(书中不太正式的定义)都是这样定义验证的：

验证:该软件应符合其规范。

但是他们谈到了需求验证，设计验证等等。如果我说这些项目在应用定义上是“软件”，我应该根据什么来检查它们呢？哪些要求是基本信息应该符合的规范？

还有一件事:需求不也应该被验证吗？以确保他们能满足客户的需求？所有的课文，我只讲有关SW验证结束的开发过程！

编辑:为了让它更清楚，我的主要问题是验证的定义如何适用于需求。书或例如，ISO 12207:2008提到，验证是一个过程，产品反映的要求。其中一个过程是需求规范评审。但是，需求如何才能符合需求呢？

Answer 1

这取决于你正在使用的书中的术语是如何定义的。在维基百科中有一篇关于SW验证的有趣文章。

对我来说，对需求的验证基本上意味着需求对于客户和将要交付SW的组织来说是足够清晰的，以便他们能够做出正式的交易。当然，验证过程并不那么简单。我知道QA团队读取需求以验证其正确性的项目。这里有我使用的需求清单示例：

• 清晰性
• 无歧义
• 可行性
• 可证明性
• 一致性
• 必要性
• 无冗余

Answer 2

可以验证需求的一致性。更长的需求文档完全有可能(不幸的是是常见的)在某些地方自相矛盾。这将使序列中的任何后续步骤都不可能符合需求，因此验证需求本身是显而易见且重要的第一步。

Answer 3

如果要进行验证，对需求的最佳验证之一是可以对其进行验证。你将如何核实这些：

• 该系统将响应性和流动性。
• 用户界面将是直观的
• 该系统将很容易适应未来的变化。

我一直在需求中看到这类事情。如果你真的打算一个接一个地遍历所有的要求，然后说“是的，我确认第124号要求已经满足了”，那么上面的陈述并不是要求(而且我不仅仅是在谈论将/将问题)。它们是不可测试的。

什么是可测试的？这类事情：

• 将有一个菜单，使用户能够选择报表。
• 将有一个屏幕输入一个新的客户。它将有以下字段: blah，blah表示页面和页面。
• 只有管理者才能设定订单的优先级(这个测试需要两个测试:一个是经理可以的，另一个是非管理者不能的)。
• 销售税将按以下方式计算：[关于州/省内外的半页资料和所有其他复杂的销售税资料)

每个需求应该导致至少一个测试，您将使用它来验证软件。

用这种方式编写需求的唯一问题是，它们会变得非常长，而且会重复。普通用户会在几次迭代之后拒绝阅读这些内容，并且您的开发人员将产生满足所有需求但没有人想要的东西的风险增加了。一些需要注意的事情。