优秀的需求规格说明应该准确地、完整地表达软件需求，其中的需求描述应该易于理解，并且在测试和验证时不会出现二义性和不可验证的问题。虽然不存在十全十美的需求规格说明，但只要在编写需求文档时始终记住其质量特性，则会产生优秀的需求文档，为后续的软件开发工作打下良好的基础。

在单个需求描述方面，需求文档的质量特性包括正确性、完整性、无二义性、优先级和可验证性等。

1.正确性

正确性是指需求规格说明对系统功能、行为、性能等的描述，必须与用户的期望相吻合，代表了用户的真正需求。

[举例1]下面的需求描述正确吗？

在用户每次存钱的时候系统将进行信用检查。

分析：在现实情况中，用户存钱时并不需要信用检查，因此这个需求描述是错误的。

2.无二义性

无二义性是指需求规格说明中的描述对所有人都只能有一种明确统一的解释。由于自然语言极易导致二义性，所以应尽量把每项需求用简洁明了的用户语言表达出来。

[举例2]下面的需求描述是无歧义的吗？

如果用户试图透支，系统将采取适当的行动。

分析：“适当的行动”对不同的人来说有不同的解释，显然是歧义的。

改正：如果用户试图透支，系统将显示错误信息并拒绝取款操作。

3.完整性

完整性是指每一项需求必须完整地描述即将交付使用的功能。需求遗漏问题很难被发现，需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息，注重用户的任务而不是系统的功能将有助于避免不完整性。如果知道缺少某项信息，可用“待定”作为标准标识来识别这项缺漏。对于所有“待定”项，应当首先描述造成“待定”情况的条件，再描述必须做哪些事才能解决问题。

4.可验证性

可验证性是指需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。对于每一个需求项，需要指定所使用的方法进行合格性检查，以确保需求得到满足。其合格性检查方法包括对系统的功能进行检查，使用测试工具来测试软件系统，对测试结果的数据进行归纳、解释和推断，对软件系统的代码、文档进行审查，以及采用特殊的手段进行检查。

[举例3]下面的需求描述是否可验证？

系统应尽快响应所有有效的请求。

分析：“尽快”是不可验证的，应该给出具体数量值。

改正：系统将在20秒内响应所有有效的请求。

5.一致性

一致性是指需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等。所以，一致性要求需求不会与同一类型的其他需求或更高层次的业务、系统或用户需求发生冲突。必须在开发前解决需求不一致的问题。为了保持需求的一致性，必须反复检查在不同视图的需求模型中的需求描述，一旦发现不一致，需要寻找其根本原因，并和用户进行有效的沟通，并做出决策，从而消除需求不一致的问题。

[举例4]下面的需求描述是否有矛盾？

（1）系统允许立即使用所存资金。

（2）只有在手工验证所存资金后，系统才能允许使用。

分析：“立即使用”与“手工验证”是相矛盾的，应该对同一功能描述进行统一。

改正：经过验证后的所存资金，系统允许使用。

[举例5]下面的两个需求描述是否有矛盾？

（1）所有命令的响应时间应小于0.1 s。

（2）BUILD命令的响应时间应小于0.5 s。

分析：所有命令中必然会包括BUILD命令，因此这两个需求描述是矛盾的。

改正：可以去掉需求描述（2）。

6.可修改性

需求会随着技术的发展、环境的变化等方面产生变更。可修改性是指需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致。我们可以使用软件工具或者目录表、索引和相互参照列表等方法使软件需求规格说明更容易修改。能够对需求规格说明做必须的修订，并可以为每项变更需求维护其修改记录。因此，这需要对每项需求进行唯一标识，与其他需求分开表述，从而实现需求的唯一性。在需求规格说明中，每一个需求标识只能出现一次，每个需求项应尽量独立，使其在修改某项需求时不会影响到其他需求项。

7.可追踪性

每项需求应该是可追踪的，都可以追溯到其来源，它对应的设计单元、实现它的源代码以及用于验证其是否被正确实现的测试用例。需求的可追踪性可用软件需求项的唯一标识符来进行追踪。

在对设计和编码文档进行审查时，需要追踪每一个程序模块与需求的对应，以查实是否每一个设计都能对应到一个需求，或每一个需求都得到设计和实现；同样，在需求变更时可以知道哪些设计受到了影响。此外，当用户需求变更时，也可以立刻知道，哪些软件需求必须改变。