Using requirements traceability with model-driven development

John Thomas and Jared Fry, LDRA

June 11, 2012

John Thomas and Jared Fry, LDRAJune 11, 2012

Fitting the Model into the Requirements Mold
An issue that arose in many companies within the avionics industry, and which DO-178C clarified, was exactly how design models fit within the requirements traceability methodology. Since models can represent a high-level overview of the project, some companies treated them as high-level requirements. Others treated models as source-code since they can be used to generate the actual implementation.

The approach approved for DO-178C, and which likely makes the most sense from the viewpoint of requirements traceability, is that design models are low-level requirements. This means that models should be treated as design documents that show how the implementation is to be performed. It is important to treat design models in this manner to allow for more accurate verification (Figure 1 below).

Without establishing a high-level definition of the system, it is difficult to ensure that the model is functioning as desired. It is also important to avoid treating the model as the actual implementation. This ignores possible defects introduced by the code generation process, external code elements (hand code) added to the generated code, and verification in the target environment.

Click on image to enlarge.

Figure 1 - Requirements Traceability tools allow requirements from a design model to be integrated into the overall traceability process to make it easier to meet standards such as DO-178C

Treating models produced by MDD as sets of low-level requirements has important implications for the requirements traceability process. For full requirements traceability to be satisfied, all high-level requirements must be implemented in lower level requirements, and for bidirectional traceability, all low-level requirements must be relatable to higher level requirements.

Moreover, for the traceability to be meaningful the links must be between the actual model elements and the requirement from which it is decomposed. It is tempting to link all high-level requirements to an opaque model (a top-level model with no elements visible to the traceability process). Doing so ignores the purpose of traceability (Figure 2, below).

Only the portion of the model which represents a given requirement can provide evidence that the requirement has been realized in the design. If a requirement has not been realized, it is important to be able to isolate the exact model element at fault.

Click on image to enlarge.

Figure 2 - Linking requirements to an opaque model gives little insight to the actual links between individual design elements, requirements and procedures

Achieving traceability between the model and the higher level requirements can be challenging, especially since the two are usually stored and presented in very different ways. High-level requirements are predominantly textual in nature, while most modeling tools provide graphic interfaces for design. Modern requirement traceability tools can bridge this gap, by pulling high-level requirements and model elements from their respective repositories. These components can then be linked and managed alongside other traceability linkage, such as the connections between requirements and functional tests.

< Previous
Page 2 of 3
Next >

Loading comments...