In this Product How-To design article, Jared Fry and Shan Bhattacharya of LDRA go into detail on how to use the company’s tool suite to analyze code to trace requirements, identify and fix standards violations, monitor code coverage, and rapidly and effectively bring reliable products to market.
As software becomes increasingly important in safety-critical medical, automotive, aviation, and industrial systems, the risks presented by coding errors have intensified from merely squandering time to endangering lives, destroying property, and costing millions of dollars. In response, a variety of standards such as IEC 62304 (medical), ISO 26262 (automotive), DO-178C (aviation), EN 50128 (railway) and IEC 61508 (industrial) have been developed to put the focus on code quality and risk mitigation to promote the development of robust, reliable, error-free software.
Requirements fulfillment and bug-free integration of collaborating systems are of paramount importance to the multipart development teams common with complex safety-, mission- and security-critical products. These teams require best-of-breed tools that automate code analysis and software testing.
The LDRA tool suite offers a comprehensive set of competencies from static and dynamic analysis to requirements traceability, unit testing, and verification. It automates all stages of the development process, helping vendors to verify their software from requirements right through the model, code, and tests, to verification. By focusing on the development process as well as accurate coding, LDRA helps clients ensure a sound process while identifying and eliminating errors early, dramatically reducing platform risk and cost of development.
The types of standards discussed above break code development into a methodical, well-controlled process that starts with key elements like certification plans, verification plans, validation plans, and so forth. These documents typically establish objectives, or requirements, that specify the production of various assets and artifacts.
By assets, we mean items principally generated during the design phase, such as system requirements, software requirements, risk and safety documents, source code, etc. By artifacts, we mean items principally generated during the verification and validation of the design, such as test cases, code coverage reports, code analysis reports, etc. These assets and artifacts in turn need to be traced back to the requirements, both to satisfy those objectives and to provide the traceability necessary to confirm the process.
True requirements traceability is a multistep effort that involves linking system requirements to software requirements, software requirements to design requirements, then tying those design requirements to source code and to the associated test cases. Tracing requirements demonstrates compliance to standards, but more important, it guards against missing features and bloated software that includes unnecessary (“dead”) code and/or unnecessary complexity. Requirements traceability ensures that the final system does exactly what is specified—nothing more and nothing less.
Traditionally, traceability between requirements and downstream artifacts has been assumed to take place as a by-product of the development process. The reality is that all too often, explicit trace links are seldom recorded and even if requirements are referenced, they may not be traced in a formal manner that will prove useful at a later date. Whether or not the links are physically recorded and managed, they still exist, though, putting the establishment of a Requirements Traceability Matrix (RTM) at the heart of any project (Figure 1 below). That’s where automated tools can help, both in building and tracking the RTM.