Traceability

Analysis of an average-sized solution can contain dozens of artifacts and models which must be organized in an appropriate structure to be manageable. But the structure itself cannot help discover dependencies between the artifacts. During development activities, as well as in the post-release documentation, it is crucial to be able to tell which parts of the solution use which components, which systems take part in which processes or in which solutions the business requirements are realized. The approach of identifying relationships between artifacts and models is called traceability.

Benefits of Traceability

Traceability is most beneficial when searching for impacts of some change - the impact analysis. But generally, traceability helps answer questions in all the following areas:

1. Tracing Requirements
   • "Which requirements were implemented within this project?"
   • Requirements must be traced to the project
2. Finding Implementation Details
   • "When I press this button, customer's previous orders are displayed. From which system do they come from?"
   • Button action must be traced to the service loading the orders
3. Impacts
   • "If we change the contract of this interface, which client systems need to be modified?"
   • Interface must be traced to its clients

Another benefit of traceability is navigation between related artifacts and models. For example, if there is a link between a system function and a business rule describing the algorithm implemented in the function, it is then easy to navigate between them to quickly find information without including it directly in the function. This is good for reusing information and helps avoid duplications.

"But why would we spend valuable time creating traceability when most information is in the source code?", we often hear. So many times have we seen analysts willing to sacrifice a kidney to get a quick answer to one of the questions above, without the need to find somebody who knows the code and then wait until he finds it. It is always more convenient to check one diagram or run one simple database request, instead of starting almost a detective action to find the missing information.

So Why Is It Rare to See Teams Do Tracing?

Despite the enormous service traceability provides, it is used very rarely in organizations. The main reason is the activity itself does not contribute to the project goals. Writing requirements, analyzing them, and modeling the system add value since these activities produce artifacts that will be transformed into working software. Relationships between artifacts do not directly support the development and maintaining them takes time, so they are often missed out because "We don't have time…". It is the same story as with documentation. Deadlines are tight, the team is undersized, and we need to deliver. Customers do not care about the documentation, they are interested only in the solution, so documentation/tracing is the first thing to sacrifice. Even though everybody knows that this will return like a boomerang afterward.

When to Apply Tracing, How and How Much?

1. Traceability should be done during the whole solution development lifecycle, so it should be part of analysis, design, implementation, test, and deployment. In an ideal world, it should be possible to navigate from a high-level requirement to its design, then find out where it is implemented and navigate to a test case. It would not be sensible to manually create all these links, so most of them should be created implicitly by the tools as the analysts model the artifacts, or it should be automatically imported from external sources. Traceability will always present some overhead, so it should be kept as low as possible, and the benefit should be bigger than the overhead.
2. Traceability is beneficial during development, but it is probably even more important as a part of the documentation of the released system. During development, the dedicated team is still on the project, and a lot of things are in their heads. However, after it was released, it is supported by people who may not know the solution in such detail, and they will be grateful for the effort having been put into creating relationships during development.
3. The convenient way of creating traceability is by employing some software such as a CASE tool. Of course, a simple database or a spreadsheet would also do the job, but their benefits are limited.
   Tracing cannot be effectively done using text. Just putting a note that element A is tracked to element B is not sufficient because this information cannot be processed automatically.
4. Traceability is a great servant but should be used wisely. On large projects, there might be hundreds of artifacts, and it would not be reasonable to create traceability for each existing relationship. There should always be a balance between the benefit of the traceability and the price paid for creating it and especially for maintaining it. There should always be a balance between the benefit of traceability and the price paid for creating it and maintaining it.