RTC Magazine

Requirements traceability has become ubiquitous in the software development process. While useful in many environments, it is especially so in regard to safety-critical systems. The requirements traceability matrix (RTM) is a crucial artifact for the verification process and provides insight into the many interconnected aspects of the development ecosystem. An RTM attempts to represent a complex, dynamic environment within a static context. This conversion introduces weakness into the traceability.

Static Requirements Traceability and its Drawbacks

During the software development process, many artifacts are generated with various links to one another. These artifacts are wide-ranging in scope. Everything from high- and low-level requirements, to models, designs, source code and test cases may be linked. This connection between artifacts gives a view into how each object is decomposed into the others. A high-level requirement may be represented by several lower-level requirements, each with several models, multiple lines of source code, and numerous tests associated with them. These “many-to-many” relationships create a complex web of bonds that can be difficult to grasp (Figure 1).

The use of an RTM can help to unravel that web. The matrix provides an organized structure in which these complex relationships can be understood. From any point within the RTM, developers should be able to determine what it took to get to that point and where they can go from that point. An example of this is the verification of safety-critical systems. The need arises to prove that requirements have been implemented and behave properly. The RTM can show where high-level requirements decompose into lower-level requirements, source code and associated tests. Only when these tests are completed and passed can the requirement be considered fulfilled.

Despite the many benefits of requirements traceability, it does have some drawbacks, the majority of which stem from a limited ability to represent the RTM in a sufficiently useful way. Often the matrix is kept as an addition to the end of each document or as a spreadsheet. This flat representation must be constantly maintained to stay up to date with changing artifacts. Due to the complex nature of what the RTM represents, this maintenance must be performed diligently. Unfortunately, this is not always the case.

The RTM can easily be outpaced by the development of its component parts. This will usually have the effect of rendering the RTM incorrect or completely obsolete. Updates to the traceability are often held until the time of verification or artifact release. This delay introduces the potential of traceability errors. Meanwhile, the sheer complexity of the RTM makes finding and discovering errors more difficult. The challenge of finding a single requirement that is not mapped correctly or a test case that is linked to the wrong source code is compounded when there are hundreds or thousands of these artifacts.

Developers often rely on the RTM to determine the cost and risk involved in making changes to specific objects. If a requirement is being considered for revision, the impact will not fall to that artifact alone—all upstream and downstream associations will be affected. Determining the scope of this impact will require the use of the RTM. If it is out of date, not maintained properly, or difficult to follow, these estimates may not correlate properly to the real world, causing potential catastrophe to the development process.

Traceability Tools to Create a Dynamic Matrix

Modern requirements traceability tools can help to alleviate some of these weaknesses. These tools have been designed to access each artifact of the development process. This includes contact with other tools such as requirements management tools, modeling tools, and even testing tools. Traceability can then be created along these objects to form the RTM. Often this traceability can exist only within the tool and not require any type of modifications to the objects themselves. This linking provides an easily accessible version of the RTM that replaces the previous means of storing the RTM as a static object.

Ease of access is not the only advantage, though. Once the RTM has been developed, traceability tools provide some powerful features. A graphical representation of the traceability can be generated that greatly reduces the complexity inherent in the matrix. The “many too many” relationships can be quickly viewed and understood rather than remaining abstract to the user. Making the RTM easier to understand and view is a significant advantage for users attempting to implement requirements traceability in a dynamic way. An easier-to-digest RTM improves the chances of finding errors in the linkage between objects. In fact, many tools will indicate to the user potential problems with the traceability, including unlinked objects and incorrect or outdated links.

As the complexity of traceability becomes more transparent, the task of assessing the impact of changes is simplified. The upstream and downstream impact of a modification can now be quickly evaluated. If a requirement is to be updated, a simple analysis of the RTM can demonstrate its influence:

• Decomposed requirements or models may need to be updated.

• Source code that implements the requirement may need to be re-written.

• Tests that were developed to verify the old requirement may no longer be valid.

• Cost and risk can be applied to these potential changes to create a true estimate that better mirrors the real world.

When linked objects are modified, the dynamic aspects of modern traceability tools are brought into focus. The traceability utility connects to artifacts external to itself. It can detect when changes have been made to those artifacts and report to the user. Potential impacts from these changes can immediately be investigated and acted upon appropriately. This can be as simple as re-running test cases to verify that updated code still meets the linked requirement. It may also become complex enough to touch each linked artifact connected to the changed object. Regardless of complexity, a dynamic RTM can provide the necessary information in real time as changes are made. This alleviates the problem of the RTM becoming outdated or obsolete; instead, the most current version of each object will be represented in the traceability. Any impact from any changes detected will be made visible to the user, who can take the actions needed to keep the RTM in balance (Figure 2).

Traceability Matrix as a Driver of the Development Process

The next step in the evolution of requirements traceability is for it to grow from a simple artifact of the development process into the main driver of the process itself. The foundation for this expansion has already been laid. The RTM consists of all major artifacts generated by the software development process and the relationships between them. Once these links are identified, the associated tasks can be identified as well.

The addition of these tasks to the RTM is the starting point of the transformation. Cutting-edge requirements tools are already implementing the necessary features to allow the RTM to reach its highest potential. For example, each implementation of a requirement in source code will require analysis and testing. These will generally be expanded on in a software testing plan that is included as an artifact in the RTM. Each test outlined in this document becomes a task that must be completed to validate the associated requirements. These tests can then be identified when validation of the requirement is needed such as when linked source code has been modified. The ability of the traceability tools to connect with the software testing tools provides a simple and automated way to execute or update test cases when needed, and to access the results of those tests.

The concept of users and roles is one of great importance. A user can be defined and assigned a role within the development team. Each role is given certain permissions with respect to how they may interact with the traceability (Figure 3). For example, project managers may be given full control of the RTM and its respective objects and also have the ability to assign tasks, while system designers may only be given the option of updating models, other design artifacts and their associated tasks. And software developers may only have access to the source code.

Once these roles are established, the assignment of tasks can begin. The results of work performed on these tasks are immediately made available to the traceability managers. This will give an up-to-date view of the software development progress. As tasks are completed, progress is being made. If changes are made within the RTM, then new tasks may be generated or old tasks repeated to verify that everything still works as expected.

The generation of tasks within an RTM is not always a single-step process. A change to one object in the traceability may cause a cascade of tasks across several users in multiple roles. Take an update to a requirement as an example. Updating that single requirement is a task in itself that will often fall to the manager or technical writer role. Any decomposed requirements may also need to be updated. Design models that are associated with this requirement may need to be modified by a system designer. A software engineer may need to analyze and potentially re-write any source code that was implemented for that requirement. Lastly, a design engineer may need to update test cases or create new tests that fully verify that the implementation behaves as expected.

Creating and enforcing a workflow is needed to manage the many paths that are involved with the software process. Each step can be defined and assigned to a user/role. When a task in the workflow is completed, the next step in the workflow is initiated. This includes informing the assigned users that they have tasks to complete.

The cycle repeats itself until all required tasks have been accomplished. By using a requirement traceability tool that can enforce a workflow into the development environment, each user becomes aware of the tasks that are assigned to them at a given time. Managers gain visibility into bottlenecks that slow down the development process and can redistribute tasks accordingly if users are overloaded with responsibilities.

Requirements traceability has long been a key element in the software development lifecycle. Despite its inherent importance, it has often been lightly regarded and occasionally mistreated. By itself, a static RTM can be viewed as merely another artifact, one that has the constant potential to be obsolete or contain hard-to-diagnose errors. However, buried within the lowly RTM are the makings of a potent tool. By harnessing the best in traceability tools, the RTM can become a dynamic powerhouse that not only links artifacts, but can enforce team- or project-specific workflow to drive the entire software development process. 

LDRA Technology
San Bruno, CA.
(650) 583-8880
www.ldra.com