Each newly discovered vulnerability implies a changed or new requirement that requires an immediate response.
Revised code must then undergo static analysis and all impacted unit and integration tests need to be re-run
The system itself may not have been touched by development engineers for a long time, so
being able to isolate and automatically test only the functions impacted becomes much more significant.
This adds new importance to automated requirements traceability tools and techniques. By linking requirements,
code, static and dynamic analysis results and unit- and system-level tests, the entire software development
cycle becomes traceable. That makes it easy for developers to identify problems and implement solutions faster
and more cost effectively—even after product release.
Figure 1 - Software-development V-model with cross-references to ISO 26262 and standard development tools
Process Objectives and Phases Using V-Model and Industry Standards
Using our connected car example, Figure 1 illustrates a V-model with cross-references to the automotive ISO
26262 standard and tools likely to be deployed at each phase in the development of complex automotive software.
(Other process models such as agile and waterfall can be equally well supported and the same principles apply to
other safety-critical industries and standards). Moving through the V-model, we’ll examine each phase in terms
of its impact on traceability.
This phase sees the technical safety requirements refined and allocated to hardware and
The selection of appropriate tools helps in the maintenance of bi-directional traceability between phases of
Specification of Software Safety Requirements:
This phase provides the interface between the
design standard and software-specific requirements, and details the process of evolution of lower-level,
Figure 2 - Graphical representation of control and data flow as depicted in the LDRA tool suite
Software Architectural Design:
Static analysis tools help verify the design by means of control and data flow
analysis of the code derived from it, providing graphical representations of the relationship between code
components for comparison with the intended design (see Figure 2).