Reduce code devt cost using traceability tools

For almost two decades, the requirements-driven development mantra and all that it encompasses has been documented and discussed extensively. This is in the pursuit of building better and more reliable applications. This mantra has been the underlying motivation behind software processes, certifying authorities, and industry standards focused on realising requirements-driven development in its utopian form.

Despite these efforts, the majority of defects in the embedded software space is still requirements related. One of the prime contributors to this problem is the continuous change in requirements introduced by modifications in product scope. To shield themselves from the added risks contributed by this flux, organisations need to learn to manage change in the requirements and subsequent implementation phases of a product lifecycle.

Good requirements management practices usually involve a well-thought-out breakdown or decomposition of requirements from system level on down. If this decomposition is managed well, if its artifacts are configuration controlled, and if the various engineering disciplines work well together, flux can then be handled throughout the development phases of the lifecycle.

Although some development teams create the requirements traceability matrix (RTM) on release of the product, they can avoid many errors if they use the RTM as the driving force at the heart of the development process. This paper will examine how to create an RTM and maintain it throughout the course of a project, despite the inevitable development challenges along the way.

Need for traceability toolsLarge-scale projects include millions of lines of code strewn across multiple sub-systems and interfaces. Such programs are often developed by multiple organisations and tiers of customers with large specification trees.

These projects usually start with an operational concept and systems-level documents describing the expected behaviour and other requirements of the system. Once these system-level requirements are decomposed into sub-systems and engineering disciplines, such as software, they must be validated and reconciled by subject matter experts (SME). These logistics are usually managed with the help of requirements management tools such as IBM Rational DOORS, configuration-control board meetings, and change-management tools like IBM Rational Synergy and ClearCase.

As requirements are validated and a project enters the detailed design phase, the number of artifacts increases rapidly. Introducing changes at this point can introduce myriad unresolved issues. Driving the RTM at this level of complexity requires a rich set of traceability tools.

Requirements traceability bi-directionally tracks a requirement, its implementation, and verification through the lifecycle of the project. Bi-directional requirements traceability ensures that code tracks back to requirements and forward to testing and verification. As a requirement is realised in design, implemented in code, and tested, it must be linked through the artifacts of each stage to ensure its correct implementation. Artifact data may reside in several forms such as text, graphical models, code, and various forms of test data. For effective change management, developers need to identify components from different phases and collate them with their data, all in a single environment. Performing this task manually can be difficult and time-consuming; traceability tools provide a more efficient method.

Traceability tools bridge the different media that contain artifacts to link those artifacts with requirements across the full range of development activities. Effective traceability tools also offer reports such as upstream and downstream impact analysis, and matrix generation that enable users to leverage traceability information to better understand the impact of change.

Managing an RTMA traceability matrix is built only around the artifacts it links. The artifacts and activities tied to an RTM need to be configuration controlled. As modes and state requirements are worked out, for example, they are coordinated with power management, security systems, and the software that implements them. Artifacts involved in these efforts may range from PowerPoint slides and white papers to state diagrams and code repositories. All of these artifacts are usually in their own flux, but their snapshots must be version controlled to present a complete picture of the system as it exists at any given time. Version control plays a vital part of a comprehensive change-management workflow that manages the content driving an RTM.