在完成开发或产品发布后修复 Bug 的成本太高。因此，最好进行需求分析并捕获需求歧义并尽早修复它们
开发生命周期。
我们需要定义一些标准测试来衡量需求。一旦每个要求都通过这些测试，您就可以评估和冻结功能要求。
下面是一个度量要求的示例。假设您正在处理一个基于 Web 的应用程序，并且要求如下：
“Web 应用程序应尽早响应用户查询”
在这种情况下，您将如何冻结要求？
您的需求满足标准是什么？要获得答案，请向以下人员提出此问题
利益相关者：多长时间的响应时间对您来说是可以的？如果答案是，我们将在2秒内接受响应，那么这是您的需求基准。冻结此要求，并对下一个要求执行相同的过程。
现在让我们再举一个例子。对于我们公司的一个项目，我们从客户那里获得了应用程序第一阶段的SRS文档。当我们讨论这些需求时，团队中的每个人都对需求有自己的理解。我们很快意识到本文档中存在很多歧义。我们决定在编写测试用例或开始设计阶段之前先修复这些歧义。所有模棱两可的要求都与问题列表一起发送给客户，以澄清这些问题。后来每个人都了解了整个项目的范围，我们很清楚要开始项目设计和编写测试用例。
需求应该是清晰和一致的 - 在开始编写测试用例之前，确保整个项目范围和要求对每个人都是清楚的。
通常，我们使用自己的方法来发现未指定的需求。当我们阅读 SRS 文档时，除了 SRS 文档应该涵盖的其他要求之外，我们还记下了自己对指定要求的理解。这有助于我们提出正确的要求
有关未指定要求的问题。
测试需求规范的下一个标准是-“发现缺少的需求”。有时，SRS 编写器只是假定一些要求。但需求不应基于假设。要求应明确而完整，涵盖要开发的系统的每个方面。需求规范应该提到这两种类型的需求，即系统应该做什么，不应该做什么。
为了检查需求的完整性，将需求分为三个部分，“必须
实现“需求，这些需求没有指定，而是”假设“的，第三种类型是”想象“类型的需求。在设计阶段之前检查是否解决了所有需求类型。
检查需求是否与项目目标相关 - 有时，SRS 编写者对应用程序后续阶段的功能有自己的看法。为此，他们可能会介绍一些
应用程序当前阶段的需求，他们可能只想实现，但在后面的部分完成之前不会使用。我们需要仔细了解这些要求。如果您认为任何要求与正在开发的当前阶段的范围无关，则可以询问有关该要求的目的的问题。然后，这将详细描述特定要求，以便更轻松地设计和测试应用程序，考虑未来的范围。
使用这个简单的方法 - 设置项目目标并提出以下问题：如果我们不实现此要求，是否会在实现我们的特定目标时造成任何问题？如果不是，那么这是一个无关紧要的要求。了解这些要求对项目经理很有用。他们可以要求客户在紧迫的期限内更改这些要求。
项目功能（应该做什么，不应该做什么）
软件，硬件界面和用户界面
系统正确性、安全性和性能标准
实施问题（风险）（如果有）
要求应明确且具体，没有不确定性
要求应根据具体值进行衡量
需求应该是可测试的，每个需求都有一些评估标准
要求应该是完整的，没有任何矛盾。