3. The ASPICE-Processes (VDA Scope)
3.17 Traceability and consistency in Automotive SPICE
What is traceability about?
Traceability makes sure that the essential elements of the subsequent development steps are connected in a bidirectional way. This means, for example, requirements – design – implementation, and from each of these to their corresponding tests. Based on the V-model we distinguish “vertical traceability” (on the left side of the V-model from top to bottom and vice versa) and “horizontal traceability” (from the left side of the V-model to the right side on the same level and vice versa). In addition there is bidirectionaltraceability from change management (SUP.10) to affected work products of all engineering processes and vice versa. On the first picture you can see connections between items modeled through traceability can be one to many, many to one, and many to many.
Automotive products are so complex today that one simply cannot master product development without traceability. The benefits are:
- Supporting coverage analysis: One can make sure that all requirements have been implemented.
- Supporting customer requirements: The customer requirements are known in all development steps and one can report requirements implementation progress to the customer.
- Supporting tests: Testers know the relevant requirements for each test and can proof that all requirements have been tested.
- Supporting consistency checks: Traceability information is a required input for consistency checks.
There are two cases with redundant traceability relationships (see first picture):
- System requirements to software requirements directly (shortcut) vs. system requirements to software requirements via system architectural design
- Software requirements to software units directly (shortcut) vs. software requirements to software units via software architectural design and software detailed design
Whether the redundant shortcut traceability is needed depends on the size and nature of the design element in between. The second picture shows an example where a physical element of the system architecture is too complex and therefore masks the relationship between requirements on both sides. In this case an additional direct link is needed.
Often the development environment used does not provide automated traceability between all work products and the projects end up with hybrid solutions. Technically there are a few ways of implementing traceability:
- Fully automated links provided by the development environment (like DOORS or MKS)
- In the case of automatic code generation, the tracking of software detailed design elements to the source code can be carried out by means of code generation.
- Textual references or hyperlinks from one work product to another work product: There are tools on the market which scan the references and build clickable graphical representations automatically.
- Naming conventions for the identifiers of different work products: For example, for each detailed design component there are one or more software units having the design ID as part of the filename.
- Traceability matrices are sometimes mentioned in the literature. In practice this is rather rare because the change effort is immense
- For many software work products, the use of naming conventions and a configuration management tool folder structure can provide a very efficient means of implementing traceability between software design, source code, test plans and test results.
How much automation is required depends on the number of work products or elements to be linked and the frequency of changes. If there are ten thousands of requirements with lots of change activities a non-automated solution would never work. However, in case of hundred software units which are linked to 25 detailed design descriptions naming conventions are feasible. In this case consistency checks would have to assure that traceability is correct.
What is consistency about?
The concept of Consistency is often not well understood, the effort to develop is underestimated, and is often poorly implemented. Consistency means that the downstream items are based on correct interpretations of the upstream items (contentwise). Also, traceability connections between items need to be correct (no wrong connections), and complete (no links missing). For example, the set of design elements corresponding to one single requirement need to be a correct solution for this requirement.
Why traceability, why consistency?
You can have traceability without consistency. But you cannot have consistency without traceability. Traceability allows you to roughly check the coverage of, for example, requirements by implementations, or requirements by tests. This is useful when processing a large number of items and it allows you to check progress and coverage. However, only consistency checks help you to make sure that downstream items have been correctly derived from upstream items. Therefore, the number of defects in the product is highly influenced by consistency checks. Consistency checking also reduces the effort for testing and bugfixing and the number of unplanned bugfix releases and therefore helps reducing development cost.
Implementing consistency checking
Although consistency checks can be supported by automated queries (such as “find all functional requirements that have no test cases linked”) these queries will never be sufficient. How would you know that if one test case is linked that one test case is enough? Or if you find one test case linked you still do not know whether the test case is correct. In other words: reviews are needed to guarantee consistency.
If you wish to continue to the next chapter click here: