【IT168 技术文章】
开发文档遗漏了某些重要内容或某些设计，不能全部满足既定的技术指标; 或存在逻辑错误、引用错误; 再或者引入了不必要的风险。这些问题在软件开发文档中屡见不鲜，而软件验证技术就是着力于解决这些问题，力争使开发文档臻于完善。
通过图1可以发现，软件缺陷错误绝大多数是在需求和设计阶段引入的，不清晰的需求分析、不合理的系统设计常常导致后续的开发活动困难重重。因此，需求验证和设计验证是软件验证的重点，对于排除软件缺陷而言是非常关键的。
软件需求验证
一份未经验证的《软件需求规格说明》（以下简称《需求说明》），极可能是包含着种种隐藏的软件缺陷，这些缺陷如果被带入到后续的开发阶段或当系统投入使用时才被发现，将会导致较高代价的返工，因为需求的变化常会导致系统设计和实现的相应变化，从而使系统重新经历编码、集成、系统测试、交付等阶段。需求的验证过程主要是检查需求规格说明，对该文档中定义的各需求项执行多种类型的验证。一般来说，需求验证主要包括以下内容：
1．有效性验证
有效性验证是指开发人员和用户应该对需求规格说明中各用户需求项进行认真地审核，以确保用户的需求被充分、正确地表达了出来，并且对于规格说明中提出的各项软件需求，必须保证它确实能够满足用户的相关需要、解决用户的问题。
2．一致性验证
一致性是指各需求项之间以及需求项和相应的规范或标准之间没有冲突，对同一个系统功能不应出现不同的描述或矛盾的约束。一致性验证主要包括四方面内容：一是验证各个需求项之间是否一致; 二是验证《需求说明》中规定的模型、算法和数值方法相互是否兼容; 三是验证《需求说明》中所采用的技术和方法是否与用户要求的技术及方法保持一致; 四是验证各需求项中涉及到的软硬件接口是否具有兼容性。
3．完备性验证
完备性验证是指检查需求文档是否包括用户需要的所有的功能、性能和约束，是否满足用户的所有要求。一个完备的需求文档应该对所有可能的状态、状态变化、转入条件、相关约束等都进行了完整、准确的描述。
完备性验证主要包括对《需求说明》六个方面的验证：是否包括了所有有意义的需求，并按优先级排序; 是否明确规定了哪些是绝对不能发生的故障或设计缺陷; 所有的需求项是否都被列入需求描述表，并被编号，能支持索引或回溯; 各图表、表格是否都有标号，各类专业术语及测量单位是否都给出相应的定义或引用的标准化文件; 时间关键性功能是否都被清晰地标识出来，对时间的具体要求是否作了规定; 是否包括了对所有异常的响应，尤其是对各种有效的、无效的输入值的响应规定，对各种操作模式下的环境条件、系统响应时间等是否都作了相应的规定。
4．可行性验证
可行性验证是指根据现有的软硬件技术水平和系统的开发预算、进度安排，对需求的可行性进行验证，以保证所有的需求都能实现。包括验证《需求说明》中定义的需求对软件的设计、实现、运行和维护而言是否是可行的，验证其规定的模型、算法和数值方法对于要解决的问题而言是否合适，验证约束性需求中所规定的质量属性是个别地还是成组地可以达到。
5．可验证性验证
可验证性是指为了减少客户和开发商之间可能产生的争议，系统需求应该能够通过一系列检查方法来进行验证，以确定交付的系统是否满足需要。它包括验证各个需求项是否能够通过测试软件产品和软件开发文档来证明这些需求项已经被实现; 各个需求项描述是否清楚、最好能量化; 每一个需求是否都对应于一个验证方法。
6．可跟踪性验证
可跟踪性是指需求的出处应该被清晰地记录，如每一项功能都能够追溯到要求它的用户需求或相关文件。主要验证每个需求项是否都具有惟一性并且被惟一标识，需求项定义描述中是否都明确地注明了该项需求源于上一阶段中哪个文档，以及是否可以从上一阶段的文档中找到需求定义中的相应内容。
7．可调节性验证
可调节性是指需求的变更不会对其他系统带来大规模的影响，主要验证需求项是否被组织成可以允许修改的结构，例如采用列表形式; 验证每个特定的需求的具体规定是否多于一次，有没有出现冗余的说明; 以及是否有一套规则用来在后续的软件生命周期里对《需求说明》进行维护。
8．其他方面的验证
另外，对《需求说明》的验证还包括编写格式是否符合相应的规范或标准（如GB 8567-88、或GJB1091-91），需求中提出的算法和方法方面的需求项是否有科技文献或其他文献作为基础，以及是否出现“待定”之类的不确定性词汇，如果出现，是否注明是何种原因导致的不确定性。
对于一个中型软件项目而言，以上验证项绝大多数是必须的，各测试团队可以根据项目的实际工程环境对此做裁减和细化。需求验证的执行应该遵循“策划→执行→检查→评估”的顺序完成。验证采取的形式可以是走查、审查、会议评审以及用户正式、非正式会议。不管采用哪种形式，上述验证的内容应该尽量覆盖到。
