Ensure Traceability

Traceability refers to the ability to trace, or track, requirements throughout the lifecycle and into the final solution. Tracking requirements through the project ensures that all requirements are considered as a part of design, all requirements are built into the solution, all requirements are tested and all requirements are implemented in the final solution. Likewise, the process also ensures that features and functions are not designed and built into the final solution if they are not a part of the agreed-upon requirements.

The easiest way to create a link between your requirements and other development elements (like use cases, design elements and test cases) is by developing a Traceability Matrix. The Traceability Matrix provides a quick glance at all of the requirements and validates that they are being considered throughout the rest of the lifecycle.

Not all projects need to trace requirements. Smaller projects typically do not need to. If your have a set of ten requirements for an enhancement project, for instance, it is probably pretty easy to validate that they are all accounted for throughout the project lifecycle. However, if you have a large number of requirements to track, you might even look into using an automated tool.

Before you start tracking, consider the type of tracking numbers you will use. The tracking scheme you use will allow you to trace the requirements through the rest of the lifecycle. You could just number the requirements as “1”, “2”, “3”, etc. However, you might want to build more sophistication into the numbering scheme. For instance, perhaps the requirements can be grouped into logical sections, and each section can have a unique identifier. In this case, the requirements tracking numbers might be “TAB-001”, “TAB-002”, “DIS-001”, “DIS-002”, etc.

Once they are identified, tracking the requirements themselves can be done in a couple ways. One way, probably the simplest, is to just validate that each requirement is accounted for in subsequent project phases. For instance, something like the following table might do.

The “X” in each box validates that each particular requirement was accounted for in each phase. In the example above, for instance, the first requirement has been designed for, constructed and tested. The second and third requirements have not yet been tested. In a similar manner, the project phase could be further subdivided. For instance, the Test Phase could be subdivided into Unit Test, Integration Test, System Test and User Acceptance test.

A more sophisticated example is shown below. In this case, the requirements are being tracked through each project phase, but the components where the requirements appear are also being identified.

This tracking requires the team to keep track of more details as the requirements are proceeding through the lifecycle. However, you also have more auditability. If you want to actually track how a requirement proceeds through the lifecycle, you can identify the initial requirement, the design element, the component that contains the code for the requirement and the particular test case that ensured that the requirement worked correctly.

The key thing to remember about traceability is that it must be enforced throughout the lifecycle or else it doers not work. If the team assigns tracking numbers to the requirements in the Analysis Phase, but the numbers are not utilized in the Design Phase, the whole tracking scheme will break down. Likewise if the Design Team follows up on the tracking, but the requirements are not tracked to the actual components, it will be difficult to track whether they have been tested or not and the scheme will break down. If you want to track requirements, you need to have a process to track and document them throughout the project.

Once you have the traceability process defined, you can cross reference your project work two ways. First, you can validate that all of the requirements are being carried forward into subsequent phases of the project. If you find that multiple components in the same phase are associated with a single requirement, it may be a sign that you have duplicate and redundant work going on. Likewise, you can look at your subsequent components and see whether they map back to the requirements. For instance, if you are doing tests that don’t relate back to a requirement, you may be testing for features that are not necessary. Other benefits to tracking requirements include:

• Documentation for enhancements. Over time, enhancements will probably be made to the business features and functionality of the solution. The enhancements will typically be completed sooner if the developer can easily track the modified features and functions to the appropriate components that might be affected.
• Documentation for the support team. The support team is not going to have the full knowledge of how all of the requirements are implemented in the final solution. The Traceability Matrix will especially be helpful when the support team is tracking down bugs, since they will have an easier time isolating the affected components.
• Reuse. Having access to information that traces requirements, design, coding and testing can help similar solutions in the future reuse components from this solution.

One word of caution, however – if the support team does not keep the Requirements Traceability Matrix updated, then it will quickly become useless. The support team will not utilize the matrix if it is not reliable, even if they are the ones that caused it to be unreliable to begin with.

Identify the Source of Requirements

In addition to tracking each requirement downstream throughout the rest of the project lifecycle, you may want to track the requirement back to the source that it came from. In most cases, this will be a particular person or group, but it might also be a vendor or customer. If you pulled requirements from current processes, this might refer to a system, business process or just “current state.” Identifying the source would be helpful if there were questions on the requirements later in the lifecycle. The project team could go back and see where the requirement came from. If a person or group was identified, the project team could go back to that specific source for further information and clarity. Just as important, if a requirement cannot be accommodated, the team can go back to the source to see what the impact would be.

tenstep