|
The need for requirements traceability and verification is typically imposed on automotive electronics suppliers as a contractual requirement. With increasing frequency, vendors are recognizing that requirements-based testing is an essential element of successful software development projects in general.
As a contract deliverable, or more generally, as a work product, the requirements traceability task produces a Test Verification Matrix (TVM)—an artifact that is painfully wrought, consuming valuable resources that are frequently diverted from other more productive activities.
The truly onerous nature of a TVM does not become apparent until one attempts to maintain the TVM through testing, integration, and deployment phases of projects. The inherent inadequacies of the TVM and the manual processes it represents are exposed as defects occur. Specifically, many of these defects are attributed to requirements management, including requirements validation, allocation, and correct implementation. In fact, records indicate that up to 70% of such defects are classified as requirements management related!
The next challenge is to produce a requirements traceability solution that is dedicated to development and test teams that must operate in the context of existing tools and processes. Currently, most customers LDRA sees have a requirements database or flat file capability where they define and maintain system or high-level requirements.
Late mapping
Some customers map these high-level requirements to top-level design; even fewer map these requirements to the as-built design and source code. In the main, customers at least map requirements to the test cases that verify these requirements. However, the possibility of erroneous mappings are very high when customers wait until testing, especially system testing, to perform requirements traceability.
The reason why this very late requirements mapping occurs is the operational constraints imposed by a requirements database located in a project manager's office and the testing environment existing on a developer's workstation or on a target system in a lab. Or perhaps the testing is being performed by a subcontractor in a remote location. At a minimum these operational constraints dictate that a level of integration occur between the requirements database and the test environment in order for an automated solution to be introduced.
A more effective process is to map requirements at least to the as-built (or detailed) design and the embodied source code. Mapping to the as-built system is part of test qualification or the test readiness process that determines the proper correlation of requirements to code; a corollary to this review is the elimination of dead (unreachable) code from the source code listings. Moreover, it can be argued, that infeasible code, or code that cannot be exercised under any combination of test data, should also be remedied or purged as a prerequisite for test readiness.
The optimal solution for requirements traceability includes the mapping of system requirements to the top-level design as a first step, advisably performed while utilizing a design modeling tool. (This option is described in the LDRA white paper "LDRA Tool Suite/ Telelogic I-logix Rhapsody Integration" (complementary registration required).)
Prototyping
The traceability of requirements through the as-built design is further compelled by the existence of low-level and derived requirements. These requirements are commonly defined by the development team in the course of system requirements elaboration (or prototyping) and the construction of a workable and testable system. This pattern of product evolution is most pronounced in the development of software for embedded targets in which target constraints and hardware requirements must also be considered.
The prevalence and the context of low-level requirements present another significant challenge for traceability. These requirements are not considered system or "customer" requirements; they address the "how" of a software system in contrast with customer requirements that define "what" a system shall do. Consequently, low-level and derived requirements are frequently maintained separately from system requirements. This presents yet another data management demand.
A critical aspect of low-level requirements management, traceability and verification is the dissemination of these requirements to developers and testers. The developer needs to be fully informed of the interface specifications for the code he or she will implement and the procedures this code will call. These specifications must be explicitly coupled to the associated high-level requirements in order for the developers to properly understand the context of the implementation. Properly informed, the developer can design for testability and consider the functionality that must be exercised at multiple levels of testing.
|
