VerificationValidation

Many different verification and validation (V&V) techniques, methods, and tools are applied during the development of electrical/electronic systems. Different techniques are applicable at different abstraction levels. Also, choosing a technique depends on the properties being validated and/or verified. Furthermore, each partner in a project may develop and employ his own V&V processes and activities. Hence it is impossible for EAST-ADL to model all the objects that can be required by all the possible V&V techniques. As a consequence, EAST-ADL provides the means for planning, organizing and describing V&V activities on a fairly abstract level, and defines the links between those V&V activities, the satisfied and verified requirements, and the objects modeling the system (Functional Analysis Architecture, Functional components, Logical Tasks, etc.). EAST-ADL describes the common parts of all V&V techniques, including: the results expected from the V&V activities, the actual results which were obtained when applying the V&V techniques, and how the V&V activities are constrained. Information that is specific to an individual V&V technique is not described in EAST-ADL, but a place for storing this information is provided.<br/><br/>Individual V&V techniques may be used once or at several stages during an overall V&V effort. Some of them are specific to one modeling design stage; others can be applied at various design stages.<br/><br/>A set of V&V techniques and activities is necessary in order to completely verify and validate a given system. Often these techniques and activities are employed and performed by many different teams and departments, even by different companies. This situation demands the planning and organization of all V&V related information.<br/><br/>A very important aspect of V&V support in EAST-ADL is the distinction between abstract and concrete V&V information:<br/><br/>(1) At an abstract level, verification and validation information is defined without referring to a concrete testing environment and without specifying stimuli or the expected outcome of a particular VVProcedure on a detailed technical level.<br/><br/>(2) On the concrete level, verification and validation information specifies a concrete testing environment and provides all necessary details for testing, e.g. stimuli and expected outcomes, on a concrete technical level applicable to that testing environment.<br/><br/>Using a "what vs. how" definition of requirements one could say: the abstract level defines what needs to be done to verify and validate a certain system, but not precisely how this is done. Conversely, the concrete level defines the precise technical details of particular testing environments. The abstract VVCases and VVProcedures for a particular system form a "to-do"-list, which describes what needs to be done when actually testing the system with a concrete testing environment, but in a form applicable to all conceivable testing environments.<br/><br/>