•正确性：对照原始需求检查SRS
•必要性：不能回溯到出处的需求项可能是多余的
•优先级：恰当划分并标识
•明确性：不使用含糊的词汇
•可测性：每项需求都必须是可验证的
•完整性：不能遗漏必要和必需的信息
•一致性：与原始需求一致、内部前后一致
•可修改性：良好的组织结构使需求易于修改
注意，其实现在很多公司做的所谓需求规格说明书评审并不是真正的需求评审，他们更多的是关注有没有需求，需求打算如何实现，而没有把精力放在评价上面的几个“性”上。
SRS测试步骤
•第一步：获取最新版本的SRS，同时尽量取得用户原始需求文档
•第二步：阅读和尝试理解SRS描述的所有需求项
•第三步：对照SRS Review Checklist进行检查并记录
•第四步：针对检查结果进行讨论、修订SRS后回到第一步，直到Checklist的所有项通过
软件需求规格说明书评审检查单模板
项目编号 | ||||
检查人 | ||||
检查日期 | ||||
序号 | 检查项 | 检查结果 | 说明 | |
1 | 是否所有需求都体现了 | 是[ ] 否[ ] NA[ ] | ||
2 | 用语是否清晰无歧义（查找诸如也许、可能、大概、大约等关键字） | 是[ ] 否[ ] NA[ ] | ||
3 | 是否清楚描述软件要做什么及不做什么？ | 是[ ] 否[ ] NA[ ] | ||
4 | 是否描述了软件使用的目标环境，指明并简短描述了目标环境中其它相关软件产品/子系统/模块 | 是[ ] 否[ ] NA[ ] | ||
5 | 是否每一个具体需求都有唯一的编号 | 是[ ] 否[ ] NA[ ] | ||
6 | 每一个需求是否切实可行、可测试、前后一致、彼此不冲突 | 是[ ] 否[ ] NA[ ] | ||
7 | 是否说明了对每个输入的验证措施，并描述了每个输入的属性，如：度量单位、边界值、时序要求等 | 是[ ] 否[ ] NA[ ] | ||
8 | 是否说明了对每个输入的处理 | 是[ ] 否[ ] NA[ ] | ||
9 | 是否说明了对每个输出项是如何输出的，并且描述了每个输出的属性，如：度量单位、边界值、时序要求等 | 是[ ] 否[ ] NA[ ] | ||
10 | 是否描述了性能需求 | 是[ ] 否[ ] NA[ ] | ||
11 | 所描述的性能需求是否能通过测试来进行验证 | 是[ ] 否[ ] NA[ ] | ||
12 | 是否说明了所有对系统可能的约束 | 是[ ] 否[ ] NA[ ] | ||
13 | 质量属性是否以可测量或可验证的术语进行描述 | 是[ ] 否[ ] NA[ ] | ||
14 | 是否清楚描述了系统中与其它子系统、模块或硬件设备的相关接口 | 是[ ] 否[ ] NA[ ] | ||
文章来源于软件测试时代 http://www.testage.net/
