Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Embedded
?
?
Embedded??

Employ requirements traceability with model-driven devt

Posted: 29 Jun 2012 ?? ?Print Version ?Bookmark and Share

Keywords:Model-driven development? software development? Requirements traceability?

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).

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.

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).

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.

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.

Parallel traces
The central innovation of MDD is a separation between the development and coding process. This separation, however, can cause issues with requirements traceability. If the development and coding processes exist independently, establishing traceability for both can be complicated and error-prone. Requirements traceability is meant to be a continual effort spanning the entire software development lifecycle. If implementation and design are not linked, traceability work performed during design needs to be repeated during implementation.

The best-of-breed modeling tools do mitigate this danger somewhat. Many modeling tools provide means of establishing automatic connections between the model elements and their corresponding code. While that automatic mapping works in theory, many modeling tools are combined with customized build processes, additional hand-written code, and custom code generators that make the connections between code and model more obscure.

Even when traceability between code and model has been utilized, there may be disconnects that exist between testing occurring in the model and testing source code in the target environment. In the MDD paradigm, it is important to verify model behavior according to the high-level requirements, and ensure that tests exist to prove that model execution.

?First Page?Previous Page 1???2???3?Next Page?Last Page



Article Comments - Employ requirements traceability wit...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top