3.2.5.1 需求说明的质量特性

＊ 正确性
　　需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正需求。
＊ 完整性
　　需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息，注重用户的任务而不是系统的功能将有助于你避免不完整性。
＊ 一致性
　　需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等。
＊ 无二义性
　　需求规格说明中的描述对所有人都只能有一种明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
＊ 可修改性
　　需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致。我们可以使用软件工具，或者使用目录表、索引和相互参照列表等方法使软件需求规格说明更容易修改。
＊ 可跟踪性
　　可跟踪性意味着每项需求都能与其对应的来源、设计、源代码和测试用例联系起来。
＊ 可验证性
　　需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。

3.2.5.2 需求验证的方法
＊ 审查需求文档
　　对需求文档进行正式审查是保证软件质量的有效方法。组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对SRS及相关模型进行仔细的检查。
＊ 以需求为依据编写测试用例
　　根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求，从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。同时，要使用测试用例来验证需求模型的正确性，如对话框图和原型等。
＊ 编写用户手册
　　在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。
＊ 确定合格的标准
　　让用户描述什么样的产品才算满足他们的要求和适合他们使用的，将合格的测试建立在使用情景描述或用例的基础之上。

　　许多软件开发人员都经历过在开发阶段后期或在交付产品之后才发现需求问题的情况。在软件开发完成以后，回头修补需求的错误需要牵扯大量的时间和经理。根据研究表明，与在需求开发阶段由客户发现然后更正一个错误相比，在开发后期纠正这个错误需要多花68-110倍的时间，因此，对需求规格说明进行验证会节省相当多的时间和金钱。
　　需求验证是针对那些已编写成文档的需求，而对于那些存在于用户或开发人员思维中的没有表露的、含蓄的需求则不予验证。需求验证包括需求评审和需求测试两个部分，需求评审又包括正式的和非正式的两种形式。
　　非正式评审可以根据个人爱好的方式进行评审，通常只是粗略的阅读和文档走查。而正式评审则遵循预先定义好的一系列步骤过程，并且需要专门的评审小组来完成，小组人员涉及项目经理、分析人员、编写人员、开发人员和测试人员等。在规划评审过程和明确评审标准的前提下，评审小组需要阅读、解释和讨论软件需求规格说明中的每一项需求，验证需求说明的完整性、一致性、可修改性、可跟踪性等特征，同时需要记录备案。
　　显然，需求评审是一种有效的需求验证手段，但是仅仅阅读软件需求规格说明，通常很难想像在特定环境下的系统行为。因此，可以在用例模型为基础编写测试用例进行检验，虽然没有在运行系统上执行测试用例，但是设计测试用例的过程可以解释需求的许多问题。如果你在需求开发的早期就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。