Requirements Traceability

A requirement is traceable if you can identify all parts of the product that exist because of the requirement and, for any part of the product, you can identify the requirement or requirements that caused it. Similarly, no part of the product should lack a set of related requirements. Requirements must be traceable to maintain consistency between the product and the world using the product.

If you want to change some aspect of the product, you must identify which requirementsare affected by the change. You need to trace the effect of the change not just within the product, but also within the business affected by the product. Similarly, if there arenew or changed requirements in the business, you need to trace which other business requirements and which parts of the implemented product are affected. No matter which part ofthe world changes, you need to be able to trace the requirements both backward and forward.

When you are specifying requirements, give each requirement a unique identifier, use terminology consistently to specify the requirement, and identify which business use cases and which product use cases are associated with that requirement. So far, so good. Whenyou design a solution to meet the requirements, you must know which parts of each requirement are satisfied by each piece of technology. The problem is that when implemented, therequirements are translated into whichever form is appropriate for the technology; because they are implemented using more than one piece of technology, they may become fragmented.

Let's use an example from the IceBreaker product to demonstrate how we trace requirements.

Tracing a Business Event

Earlier in this book, we discussed dealing with largeness and complexity by partitioning the context of the work using business events (see Chapter 4). Whenever you apply somekind of partitioning, you create a need for traceability. In this case the traceability needs to connect the business event to the work context.

One of the business events in the IceBreaker system is

Business Event 10: Truck depot reports problem with truck.

Truck Breakdown (input flow from Truck Depot)

Amended de-icing Schedule (output flow from Truck Depot)

In this business event, the truck depot tells the engineers that one of the trucks has broken down. The engineers now need to reschedule the work of the broken-down truck. The engineers review the schedules of the trucks, find an available truck, reschedule the de-icing work, and inform the truck depot.

Part of the requirements process calls for us to study the work related to this business eventthe business use caseand determine how much of the work is done by the product and how much by the user. We looked at this issue in Chapter 4, when we discussed event-driven use cases and ways to determine the product scope. The part of the business use case done by the product is the product use case.

When we determined how much of the work should be done by the IceBreaker product, we came up with the following product use case:

Product Use Case 10:Amend de-icing Schedule whose user is the Truck Depot Engineer.

Here we have created another traceability need because we fragmented the business use case by partitioning it into work to be done by the product and work to be done by the business. We need to be able to trace the product use case to the business use case, and vice versa. To do so, we can assign a unique identifier to each business use case and to each product use case, and then create a connection between them. Bear in mind that more than one product use case might be associated with a particular business use case. Also, the same product use case might be related to more than one business use case.

Traceability need: to trace a product use case to the business use case, and vice versa.

The requirements specification for the product contains detailed specifications (functional and nonfunctional) for all requirements related to the product use case. For example:

Requirement 81: The product shall record when a truck has gone out of service.

This requirement might turn out to be related to more than one product use case, which leads us to another traceability need: We must be able to trace all product use cases that are affected by a requirement, and vice versa. To do so, we decide to tag each requirement with the identifier of all relevant product use cases.

Traceability need: to trace all product use cases that are affected by a requirement, and vice versa.

When you design the product, you decide which implementation technology will be used for each requirement. Several types of technology might be used to implement the product use cases within the product. In addition, several types of technology might be used to implement the parts of the business use case that are outside the boundaries of the product.

Figure 15.2 identifies the technological raw material we can use to implement the response to business event 10, "Truck depot reports problem with truck." Some of this solution technology (e.g., the Weather Station, Truck Driver, Engineer, Road Section, and Truck) might have been specified as a requirements constraint in section 4 of the specification. In other words, whatever solution is chosen must use this technology. Other parts of the technology (e.g., the Autoscheduling Software, Computer, Database, and Satellite) have been selected by the designer taking into account the constraints such as the budget.

Figure 15.2.

Looking at the technology available to us, including anything we can buy, we find these items are useful for implementing the business use case.

When the designer decides which parts of the business use case will be carried out by which pieces of technology, he allocates all parts of the business use case to achieve the best-fit implementation. The complete design defines how all parts of the business use case are implemented.

The requirements for the response to the event "Truck depot reports problem with truck" are allocated to a variety of technologies (Figure 15.3). When a truck breaks down, the truck driver communicates this fact to the engineers using the radio transmitter in his truck. Then, to activate the product use case, the engineer uses a scheduling dialog on the computer to reschedule the work of the broken-down truck. The requirements within the product use case are implemented using software written for the computer, the purchased autoscheduling software, and the database system. The engineer communicates the amended de-icing schedule to the appropriate trucks via radio.

Figure 15.3.

The event response for The event response for "Truck depot reports problem with truck"is allocated to a variety of technology. "Truck depot reports problem with truck" is allocated to a variety of technology.

Traceability need: to keep track of which requirements, or parts of requirements, are implemented by which pieces of technology.

We need to keep track of which requirementsor parts of requirements are implemented by which pieces of technology. This traceability enables us to verify that the requirements specified are the ones implemented. To do so, we might decide to maintain up-to-date allocated business use case models that are cross-referenced to individual requirements and product use cases.