Testing Traceability

Remember the old story of the World War I general who needed to get a message back to headquarters? He gave the message to his next in command: "Send reinforcements; we're going to advance." The message was passed between runners and shouted to other messengers until at last it reached headquarters. There an exhausted messenger blurted out, "Send three and fourpence; we're going to a dance." The same sort of thing happens when too many transitions separate the origin of a message and its final delivery point.

The path followed in the story is very much the same as that a requirement goes through in its many stages before it is finally delivered as a working product. Each stage is a transformation, fraught with the possibility that the requirement may become misunderstood, applied wrongly, or somehow scrambled in the translation by any of the people involved in the development of the product.

It is vital for future maintenance that you are able to connect the original requirement to the part of the delivered product that implements the requirement. In other words, the beginning of the development process must somehow be connected to the end of it. You need to ensure the specified requirement is actually the requirement that is implemented. Figure 11.4 illustrates the connections between requirements components and their implementation.

Figure 11.4.

This partial requirements knowledge model shows the connections between the components of the requirements specification. The connections are necessary for tracing the components through their development. For example, the Product Scope is delineated by a number of Product Use Cases (the asterisk at an end of the connection means "many"), and each Product Use Case is a cluster of many Requirements. An atomic Requirement can be either a Constraint, a Functional Requirement, or a Nonfunctional Requirement. The Work Context is the subject of a number of Business Events, each of which responds with a Business Use Case. These can be implemented in the product as one or more Product Use Cases. (Chapter 4, Event-Driven Use Cases, discusses this relationship.) To maintain traceability, you need to know which requirements belong to which product use cases, which business events are implemented with which business and product use cases, and so on.

To make sure it is traceable, each of your requirements must have the following characteristics:

• A unique identifier

• An indicator of the type of requirement or constraint (we use the section number of the template in which the requirement appears)

• References to all of the business use cases or product use cases that contain the requirement

• References to the stakeholder who is the originator of the requirement

• Consistent use of terminology

You can find a more complete requirements knowledge model in Chapter 10, Writing the Requirements.

If the requirements are traceable, then when changes happen, it is far easier to find the parts of the product affected by the change and to assess the impact of the change on the rest of the product. Keep in mind that the requirements can and will change at any stage during the product's life. Keeping your requirements traceable means that you can design the most effective way to accommodate the change.

Is the requirement uniquely identifiable and cross-referenced to business use cases, product use cases, dependent requirements, and conflicting requirements?