Design Article
Gap analysis forges the links from requirements to verification
Mark Pitchford and Bill St. Clair, LDRA Technology
11/4/2010 4:02 PM EDT
In our example, we ensure in the host environment that "function calls" to the software associated with the ABS system return the values required of them to meet requirements. That information is then updated in the RTM.
Tier 5 target-based verification represents the on-target testing element of formal verification. This frequently consists of a simple confirmation that the host-based verification performed previously can be duplicated in the target environment, although some tests may only be applicable in that environment itself.
Our ABS system is now retested in the target environment, ensuring that the tests results are consistent with those performed on the host. A further RTM layer shows that the tests have been confirmed.
Aerospace and military projects, such as air-traffic control or missile guidance systems, commonly follow a model where the RTM has such high visibility. Since ISO/DIS 26262 places similar demands on the automotive development team, particularly with regards to safety requirements, it follows that a similar model will be appropriate.
By applying gap analyses to current automotive practices, it’s clear that some degree of automation to gather traceability information is often in place, principally across the early lifecycle phases where tool support is strongest. However, automatic tracing to implementation and verification artifacts is typically weak. Where the gap between current working practices and those required to operate under safety-related standards is wide, much work needs to be done. Of course, the upside is that the scope for cost savings is equally huge.
Conclusion
Gap analysis highlights time and again that requirements traceability remains a low-priority, and manual methods prone to error and omission remain the primary approach for many projects. Consequently, when compliance to a specific standard is demanded, the time and effort required to construct a requirements traceability matrix is huge.
Clearly the development of an RTM can be easily automated with investment commensurate with that made in other areas of the development lifecycle, such as modeling and version control. When this is done, the return on investment from tools that manage requirements, support design and enable verification is significant.
When the benefits of the construction of an RTM is pushed into the entire development process through requirements traceability, much greater cost savings and process improvements are also available, saving automakers not only at the development level, but also from the costly litigation that takes places when software quality isn’t established and maintained.
Mark Pitchford has over 25 years’ experience in software development for engineering applications, the majority of which have involved the extension of existing code bases. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally including extended periods in Canada and Australia. For the past 10 years, he has specialized in software test and works throughout Europe and beyond as a field applications engineer with LDRA Technology.
Bill St. Clair is currently director, U.S. Operations for LDRA Technology in San Bruno, California and has more than 25 years in embedded software development and management. He has worked in the avionics, defense, space, communications, industrial controls, and commercial industries as a developer, verification engineer, manager, and company founder. He holds a U.S. patent for a portable storage system and is inventor of a patent-pending embedded requirements verification system. Bill was also chief architect for the TBreq embedded system verification tool and Embed-X, the industry’s first application lifecycle management solution targeting complex critical applications.
Navigate to related information

