Subordinate and Superordinate Use Cases

Use Cases can be built up by combining other use cases. When a use case is made up of other use cases, the component use cases are known as subordinate use cases. The “parent” use case is referred to as the superordinate use case. This is known as composition. See an example of how composition works for use cases.

Composition In Use Cases

One of our regulars was reading an early article on composite requirements, and wanted to know how to approach the same thing with use cases. In our earlier article, we showed how to use composition to organize related, possibly interdependent requirements to better manage delivery. We used composition to assure that each requirement remains atomic.

Since that time, we’ve proposed managing the delivery of software with use cases. We face the same challenge – delivering sufficiently valuable use cases (read: having a large enough scope), without building overly complex and redundant use cases. We also want to re-use use cases (or portions of use cases) when possible.

Cockburn On Sub Use Cases

Alistair Cockburn writes:

An action step can be a simple step or the name of another use case.

Writing Effective Use Cases

He goes on to explain that a single use case consists of multiple steps. Each step may be either a single step, or an entire use case. His article on use case fundamentals goes into a little more detail about subordinate use cases (the steps) and superordinate use cases (the combination).

Normal Use Case Example

Use Case: UC1: Perform Annual Car Maintenance

1. Change the Oil
2. Change the Brake Pads
3. Wash the Car
4. Renew State Inspection

Each step within UC1 is a simple step. This represents a normal formal use case.

Superordinate Use Case Sample

Use Case: UC1: Perform Annual Car Maintenance

1. UC2: Change the Oil
2. UC3: Change the Brake Pads
3. Wash the Car
4. Renew State Inspection

By identifying that the first two steps are actually other use cases, we have turned our normal use case into a superordinate use case.

Subordinate Use Case Sample

Use Case: UC3: Change the Brake Pads

1. Purchase New Brake Pads
2. Raise Car On Jack
3. Remove Wheel
4. Replace Pads
5. Restore Wheel
6. Lower Car
7. Repeat Steps 2-6 on Other Wheels

This use case is a normal use case, but since it is also used within the superordinate use case (UC1: Perform Annual Car Maintenance), it is also a subordinate use case.

Benefits of Composite Use Cases

There are two main benefits of this approach. First, we leverage our documentation to maximize re-use. UC3: Change the Brake Pads can be done independently (for example, if the brakes start to squeal), or it can be done as part of the annual maintenance use case. We have only documented the use case in one place.

Second, we can communicate the delivery of our functionality as UC1: Perform Annual Car Maintenance, while managing the requirements and development of the subordinate use cases independently. This also helps with prioritization. The value of UC3 is more than just the value of performing UC3 when the brakes start to squeal – it is also the value of UC3 when performing our annual maintenance procedure. This helps assure that we do the most important stuff first.

Summary

Subordinate use cases are normal use cases that are re-used as steps within a superordinate use case. Re-use helps to reduce work while properly tracing and prioritizing.