Subordinate and Superordinate Use Cases

pyramid

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.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

3 thoughts on “Subordinate and Superordinate Use Cases

  1. The idea of “hyperlinking to other use cases” to explain how a certain step in a UC is performed can be very powerful. This is particularly true with nice tool-support so that readers can click their way through the UCs if they want more information on a certain step. There is also a danger here, though.

    It can be very tempting (especially for beginning authors) to adopt a functional-decomposition approach to UC-writing. I.e., one UC must logically follow another UC which must logically follow… etcetera. I recently reviewd a UC specification of a fairly large system with a large number of use cases and this is exactly what went wrong :-( In this case a bit of re-writing and re-arranging made the UCs a lot more readable. We adopted the Cockburn-approach and defined some “summary level UCs” as a table of contents for the user-goal-level UCs.

    In short: composing UCs can be a good idea… just be very careful.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.