CHAPTER 11
Business Requirements Traceability

Traceability of business requirements is a very important consideration when developing systems. You should be able to trace each piece of functionality incorporated into a system back to the original business requirement. But as business requirements evolve into design and solution, you will discover what is known in the information technology world as derived or implicit requirements. These are requirements mandated by the chosen solution. The number of requirements tends to explode at this point because the solution process is complex.¹ Robert L. Glass writes, “This requirements explosion is part of the reason that it is difficult to implement requirements traceability—the tracing of the original requirements through the artifacts of the various phases—even though everyone agrees it is desirable to do so.”²

Traceability as presented in this book is not about forward tracing—the tracing of original requirements to the artifacts of the succeeding phases—but rather tracing the design or solution back to the original business requirements to make sure every requirement that the business deemed important and high-priority is accounted for in the ensuing phases.

How can we ensure this? Traceability can be mapped:

• Back to the original business requirement

• By line of business (or division)

• By actor (internal or external)

• By object.

Traceability to
an Original Business Requirement

Tracing a design back to the original business requirement really helps make certain that the requirement is not missed during system development. Of course, forward tracing of the requirements is even more helpful; it allows you to identify every piece of coding or design that must be changed should the requirement change.

I suggest listing the requirement number or the event name in the use case. You can also update your requirements document after the use cases have been developed, adding the identifier for each use case to the requirement from which the use case was derived.

This approach—linking artifacts—is very simplistic, but it requires rigorous attention to updating and maintaining your documentation. This is not always an easy task, nor is it usually considered high-priority compared with working to deliver a solution.

Types of Traceability

• Traceability by line of business refers to tracing the original business requirement to the line of business that needs it or performs it. This analysis allows the enterprise to view the operations performed by each department and determine whether they are aligned with the overall vision of the business. I suggest identifying the line of business that is responsible and accountable for the performance of each business event.

• Traceability by actor refers to tracing the original business requirement to the actor who performs it. Doing so shows the responsibilities and accountabilities assigned to different roles within the organization and may show redundancy of work or performance of work by more than one actor. To do this, you obviously have to identify the actors of each business event. Traceability by actor also helps in the testing phase, when you will need to identify who should verify the results of the tests conducted on the system being implemented.

• Traceability by object refers to tracing the original business requirement to the objects participating in it. This helps identify the accessibility and availability of the objects, especially if the objects are to be shared by more than one system. This is also a good opportunity to establish ownership of the business object. Who is responsible for maintaining the data integrity of the object? In other words, who should be allowed to create it and make changes to it? If the enterprise has control over who updates the contents of an object, the integrity of the system’s data will be easier to manage.

Practical Traceability Tips

You can implement these steps after eliciting the requirements and developing the use cases.

1. Assign a unique ID to each event.

2. Assign a unique ID to each process.

3. Align each event with a process. For example, event 1 is supported by process 1; event 2 is supported by process 2.

4. Use case ID must be assigned the process ID.

5. Associate the event with:

   • • Each use case

   • • Each document (e.g., business requirements, use cases, test scenarios, test cases)

   • • Each interface between the system and external entities

   • • Each actor

   • • Each test case.

6. Associate each event with a business case.³ For example, event 1 supports business case x, as identified in the project charter document.

7. Associate the event with a business objective. Which objective does the business event satisfy?

In Brief

When managing change, business requirements traceability allows an organization to quickly identify the processes that will be affected by any changes implemented by the organization.

NOTES

1. Generally, there are at least 50 times more implicit requirements than explicit requirements. From Robert L. Glass, Facts and Fallacies of Software Engineering (Boston: Addison-Wesley, 2003).

2. Ibid.

3. A business case is normally developed to highlight the reason for initiating a project; it typically quantifies the benefits and the risks associated with the project. A business event should always align with a business case; it should affect either a benefit or a risk associated with the project.