Outline of the verification and validation process in the context

Verification and validation are part of the development process and are contrasted in this report with the quality assurance (QA) process. Verification and validation are means by which the product is checked, and by which its performance is demonstrated and assured to be a correct interpretation of the requirements. A continuous process of V&V must be actively applied throughout the software development cycle. V&V includes a strong element of checking, and leads to remedial action. By contrast, QA ensures that a suitable management process has been specified, that the development process conforms to the requirements of basic standards and that the process specified is followed. Applicable standards may be ISO 9000-3, issued by the International Organization for Standardization, and IEEE Std 730 [9, 10]. Quality control (QC) is performed to check that the specified software development methods and process in the QA plan have been correctly followed.

1.3.1. Verification of original requirements

A correct form of the system requirements specification is needed to start the development and V&V. Experience indicates that some requirement errors will exist.

All system design documentation should be consistent with the stated requirements.

If the requirements specification is incorrect, subsequent parts of the development may contain faults that verification alone may be unable to identify.

A safety system requirements specification will have been produced by reference to the reactor safety analysis during the plant design and by consideration of plant and reactor performance limits. The preparation of the requirements for closed loop control systems may involve extensive modelling of the reactor and plant dynamics to derive the algorithms for control and to demonstrate their stability. The preparation of the requirements for open loop control of switchgear, valves and motors will involve identification and grouping of the logic functions of each control switch or control function. These specifications should provide sufficient detail to allow the development process to take place without any risk of misinterpretation.

The computer based implementation of these functional requirements will therefore have involved system design processes, which are normally subject to review and design control methods. This implies that the requirements specification has been verified against the safety and performance requirements of the plant. These processes are very important to the system integrity, but outside the scope of this publication.

1.3.2. Verification of requirements specification

The requirements specification may have two types of error: requirements incorrect of themselves but correctly implemented and errors of implementation of correct requirements. A well designed system acceptance test should find faults arising from errors in the functional requirements, i.e. the validation tests for acceptance should not be based solely on the written requirements specification but should attempt to test from first principles.

If the final product has inconsistencies with or omissions from the system requirements specification, the position is quite different, and verification can detect the errors. The use of requirement trace methods in development and particularly in verification should, if correctly established and followed, identify inconsistencies and omissions. Verification should also find and account for necessary additional functions, needed for engineering and maintenance reasons, which are not defined in the system requirements specification.

The verified requirements specification can then serve as the initial input to the V&V processes discussed here. It is recognized that in practice this is not always the case, and the requirements may be under some development themselves.

Consequently, there is a need for a procedure to ensure the resolution of any problems identified with the system requirements specification, particularly as experience shows that this is the source of many errors.

1.3.3. V&V in development life cycle

For new software this publication specifically refers to the V&V of the development process phases of IEC 880 [4], described in detail in Section 3.1. These

phases are those of the traditional waterfall model, two versions of which are shown in Fig. 1. This provides a framework for the descriptions generated in this publication.

Other development life cycles may be used. The reference model phases include:

— System requirements specification verification;

— Computer system specification verification;

— Software design verification;

— Code verification;

— Computer system integration verification;

— Integrated computer system test verification;

— Validation and commissioning test verification;

— System handover and acceptance verification;

— Use and maintenance verification.

However, the use of the waterfall model and these phases should not be interpreted in any way as implying a limit on the use of the information and techniques described here. Where a different software life cycle is used, the appropriate information can be identified by establishing the equivalent mapping onto the phases of the development model and applying the information relating to that phase.

The V&V steps listed above are product based, referring to the inputs to and outputs from phases. The information in this publication is also directed to the preparation of:

— V&V plans;

— Test plans.

FIG. 1. Waterfall software development model.

Feasibility study

These plans are important components of the assurance process. Unless the plans are formulated correctly and completely, the effectiveness of the V&V activities is reduced.

The framework developed for new software has also been used as a basis for describing how existing software could be verified and validated. This includes accessible, proprietary and configurable software. These types are discussed later.

The input to, subject of and product of V&V are primarily documentation. The input includes the source code. The importance to effective V&V processes of the completeness and correctness of documentation cannot be overstressed. Clearly, completeness does not mean sheer volume. The information elements identified in this publication for the V&V of the various phases must be present. The planner of the V&V programme must determine the presentation form of this information so that it aids the development and V&V activities. When it is not present in the documents, the planner should require the information from the developers in a suitable document, to allow the V&V to be achieved.

V&V plans should be an integral part of the project development and production plans, and should be produced at the same time. The verification procedures to be used at the end of each phase must be adapted to the software development model being used. They must consider the working environment of the development organization. Important planning concerns include:

— Identifying the teams involved in the development, verification, validation and other qualification processes;

— Determining the interfaces between the V&V team, the development team and the QA team;

— Defining the forms of communication between the teams;

— Organizing the V&V team;

— Declaring the components to be supplied and their expected content and format;

— Preserving independence of the teams;

— Identifying the standards to be applied;

— Defining the acceptance or success criteria;

— Establishing the time schedule.

1.4. ORGANIZATION AND MANAGEMENT OF THE VERIFICATION