87福利电影网宅男频道:如何验证软件是否满足最初设想

如何验证软件是否满足最初设想

        需求验证主要是分析需求规格说明的正确性和可行性，检验需求是否反映客户的意愿，从而确定能否转入概要设计阶段；而概要设计验证主要是检查《概要设计规格说明》是否满足《软件需求规格说明》的各项要求，设计是否合理，是否可以据此产生《详细设计规格说明》，并确定能否转入详细设计阶段。   软件需求验证   如果在构造设计开始之前，通过验证基于需求的测试计划和原型测试来验证需求的正确性及其质量，就能大大减少项目后期的返工现象。而如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工，因为需求的变化总会带来系统设计和实现的改变，从而使系统必须重新测试，由需求问题对系统做变更的成本比修改设计或代码错误的成本要大得多。需求的验证过程主要是检查需求规格说明，这个过程中要对需求文档中定义的需求执行多种类型的验证，主要包括：   1． 有效性验证   有效性验证是指开发人员和用户应该对需求进行认真地复查，以确保将用户的需要充分、正确地表达出来，并且对于提出的每项需求，必须保证它确实能够满足用户的需要、解决用户的问题。   2． 一致性验证   一致性是指需求之间以及需求和相应的规范或标准之间不应该出现冲突，对同一个系统功能不应出现不同的描述或矛盾的约束。一致性验证主要包括四方面内容：一是验证各个需求之间是否一致，是否有冲突或矛盾；二是验证《软件需求规格说明》中规定的模型、算法和数值方法相互是否兼容；三是验证《软件需求规格说明》中所采用的技术和方法是否与用户要求的技术及方法保持一致；四是验证需求的软硬件接口是否具有兼容性。   3． 完备性验证   完备性验证是指检查需求文档是否包括用户需要的所有功能和约束，满足用户的所有要求。一个完备的需求文档应该对所有可能的状态、状态变化、转入、约束都进行了完整、准确的描述。主要包括以下六个方面的内容：一是验证《软件需求规格说明》是否包括了所有需求，并且是否按优先级作了排序；二是验证《软件需求规格说明》是否明确规定了哪些是绝对不能发生的故障或设计缺陷；三是验证《软件需求规格说明》中出现所有的需求项是否都被列入需求描述表，在这张表中各需求项是否都被编号并能支持索引或回溯；四是验证《软件需求规格说明》中出现的各种图表、表格是否都有标号，各类专业术语及测量单位是否都给出了相应的定义或引用的标准化文件；五是验证软件需求规格说明中时间关键性功能是否都被清晰地标识出来了，对时间的具体要求是否作了规定。六是验证功能需求部分是否包括了对所有异常的响应（尤其是对各种有效的、无效的输入值的响应规定），对各种操作模式（如：正常、非正常、有干扰等）下的环境条件、系统响应时间等是否都作了相应的规定。   4．  可行性验证   可行性验证是指根据现有的软硬件技术水平和系统的开发预算、进度安排，对需求的可行性进行验证，以保证所有的需求都能实现。   可行性验证主要包括以下三方面的内容：一是验证《软件需求规格说明》中定义的需求对软件的设计、实现、运行和维护而言是否是可行的；二是验证《软件需求规格说明》中规定的模型、算法和数值方法对于要解决的问题而言是否合适，他们是否能够在给定的约束条件下实现；三是验证约束性需求中所规定的质量属性是个别地还是成组地可以达到。   5． 可验证性验证   可验证性是指为了减少客户和开发商之间可能产生的争议，系统需求应该能够通过一系列检查方法来进行验证，以确定交付的系统是否满足需要。   可验证性验证主要包括以下三个方面的内容：一是验证各个需求项是否能够通过测试软件产品和软件开发文档来证明这些需求项已经被实现；二是验证各个需求项描述是否清楚、最好能量化。避免使用模糊不清的词汇；三是验证《软件需求规格说明》中每一个需求是否都对应于一个验证方法。   6．可跟踪性验证   可跟踪性是指需求的出处应该被清晰地记录，每一项功能都能够追溯到要求它的需求，每一项需求都能追溯到用户的要求。可跟踪性验证主要包括以下三方面的内容：一是验证每个需求项是否都具有唯一性并且被唯一标识，以便被后续开发文档引用；二是验证在需求项定义描述中是否都明确地注明了该项需求源于上一阶段中哪个文档，包含该文档中哪些有关需求和设计约束；三是验证是否可以从上一阶段的文档中找到需求定义中的相应内容。   7．  可调节性验证   可调节性是指需求的变更不会对其他系统带来大规模的影响。可调节性验证主要包括以下三方面的内容：一是验证需求项是否被组织成可以允许修改的结构，（例如采用列表形式）；二是验证每个特有的需求是否被规定了多余一次，有没有如何冗余的说明？（可以考虑采用交叉引用表避免重复）；三是验证是否有一套规则用来在余下的软件生命周期里对《软件需求规格说明》进行维护，（这很重要，原则上讲，SRS不是可以随便修改的）。   8．  其他方面的验证   主要包括以下几个方面内容：一是验证《软件需求规格说明》编写格式是否符合相应的规范或标准（如GB 8567-88、或GJB1091-91）；二是验证需求中提出的算法和方法方面的需求项是否有科技文献或其他文献作为基础；三是验证《软件需求规格说明》中是否出现“待定”之类的不确定性词汇，如果出现，是否注明是何种原因导致的不确定性。   对于一个中型软件项目而言，以上验证项绝大多数是必须的，各测试团队可以根据项目的实际工程环境对此做裁减和细化。需求验证的执行应该遵循“策划→执行→检查→评估”的顺序完成。验证采取的形式可以是走查、审查、会议评审以及用户正式、非正式会议。不管采用哪种形式，上述验证的内容应该尽量覆盖到。   概要设计是软件开发过程中决定软件产品质量的关键阶段。这个阶段设计人员需要站在全局的高度，在比较抽象的层次上分析、对比多种可能的系统实现方案和多种可能的软件体系结构，从中选出最佳的方案和最合理的软件结构。概要设计验证在这个阶段是非常必要的，通过验证可以确保《软件设计说明书》中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性、完整性，从而以保证用较低的成本开发出较高质量的软件系统。   1.1概要设计验证的主要内容   （1）设计系统在项目软件中所处的层次结构描述是否准确以及在本设计系统中的指导性作用。 重点验证以下两个方面：   一是验证《概要设计规格说明》中对所要设计的系统在整个项目软件（或在大系统中）中所处的地位、作用，及其与同级、上级系统之间的关系描述是否准确；二是《概要设计规格说明》是否可以作为《详细设计规格说明》撰写的基础性文档是否对《详细设计规格说明》具有指导性作用。   （2） 验证系统描述是否具有可追溯性   重点验证以下四个方面   一是验证《概要设计规格说明》的每一部分的设计是否都可以追溯到《软件需求说明书》、《接口设计说明书》或其他开发文档；二是验证非功能需求项（如：接口需求、操作需求、资源需求、可靠性需求、安全性需求等）是否已经分配到《概要设计规格说明》中。三是验证对《软件需求说明书》中不完整、易变动或潜在的需求项是否都进行了相应的设计分析，对各种设计限制是否做了全面的考虑；四是验证《概要设计说明书》中模块的规格及大小划分是否和《软件需求说明书》中的功能需求项以及约束性需求项之间保持一致。   （3）验证总体设计是否合理   重点验证以下五个方面：   一是检查《概要设计规格说明》的设计目标描述是否明确清晰；二是检查《概要设计规格说明》是否阐述了设计所依赖的运行环境，并核对是否和《软件需求规格说明》中规定的运行环境相一致；三是检查《概要设计规格说明》中的业务逻辑是否准确并且完备；四是《概要设计规格说明》中是否对不同的设计方案作了介绍并比较，是否有选择方案的结论，是否清楚阐述了方案选择的理由。五是检查   《概要设计规格说明》是否合理地划分了模块并对各模块之间的关系作了清晰的阐述。六是检查《概要设计规格说明》中给出的系统设计结构和数据处理流程是否能满足软件需求规格说明中所要求的全部功能性需求。   （4）接口设计是否合理 重点验证以下几个方面：   一是验证《概要设计规格说明》中用户接口设计是否正确全面，是否有单独的用户界面设计文档；二是验证《概要设计规格说明》是否包含有硬件接口设计，硬件接口设计是否正确且全面；三是验证概要设计规格说明是否包含有软件接口设计，软件接口设计是否正确且全面；四是验证《概要设计规格说明》是否包含有通信接口设计，通信接口设计是否正确且全面；五是验证《概要设计规格说明》是否描述了各类接口的功能、各接口与其他接口或模块之间的关系已经接口的设计是否具有可测试性。   （5） 验证模块及模块内部分的设计是否合理   重点验证以下四个方面：   一是验证模块的划分是合适（如：代码规模是否适中？是否便于协同开发？）、模块与模块之间是否具有一定的独立性（如：模块与模块之间应做到低耦合，模块设计应做到高内聚）。二是验证每个模块的功能和接口定义是否正确（如：数据的输入输出、模块间的通信等等）。三是验证数据结构的定义（比如面向对象编程中的数据封装是否适当？继承的使用是否合适？各方法中的的参数定义及使用是否适当？各数据项的数据类型是否适当？数据项的初始值设定和值域范围是否有考虑？等等）是否正确。四是验证模块内的数据流和控制流的定义（如：串行操作和并行操作、同步和异步等）是否正确。   （6）  验证概要设计是否包含相关属性设计   重点验证以下几个方面：   一是验证《概要设计规格说明》中是否有可靠性设计，设计是否合理、有效；二是验证概要设计规格说明中是否有安全性设计，设计是否合理、有效；三是验证《概要设计规格说明》中是否有可维护性设计，设计是否合理、有效；四是验证《概要设计规格说明》中是否有可移植性设计，设计是否合理、有效。五是验证《概要设计规格说明中》是否有可测试性设计，设计是否合理、有效。六是验证是否对上述属性设计进行了性能分析，是否有论证过程的性能数据。   （7） 验证计算机资源的利用和余量设计是否合理   重点验证《概要设计规格说明》是否对余量设计做了相应考虑。包括：CPU的处理能力要求是否留有余量；内存的容量要求是否留有余量；外存储设备的容量要求是否留有余量；算法的效率是否可接受；安全关键软件部件发生故障时是否有快速恢复能力等等。   以上我们讨论了概要设计验证的一般性内容，各测试团队可以根据待测项目的规模进行裁减和细化。概要设计在执行中采取的形式以评审会形式为多，也可以采用非正式审查或内部专题会议的形式进行。由于概要设计的验证在很大程度上与软件需求规格说明的内容有关，建议聘请软件需求规格说明的起草人参与到概要设计的验证活动中来。