In the world of use cases, there's this thing called an include relationship. It's an advanced technique that is avoided as often as it is misused - which is to say, a lot. But the include relationship can make you more productive - so it's good to have in your toolkit of use case writing skills.
What Is It?
As the name implies, the include relationship is a relationship that can exist between two use cases. It allows you to insert the behavior from one use case into another. In other words, at some point in Use Case A, you'd jump over to Use Case B, move through those steps, then return back to where you left off in Use Case A.
When Do You Use It?
When writing use cases, you’ll find situations where you have the same exact steps in two or more use cases. For example, in a hotel reservation system, you might find that both the Cancel Reservation use case and the CheckIn Reservation use case need to perform the same steps to find a reservation.
When this happens, you could just write the identical behavior in each use case. Yes, you'd have a bit of redundancy and if the common behavior changes, you'll have to update it in two places. If there are just a few shared steps (say, three or less), then this is the right approach. The cost of creating the include relationship probably won't outweigh the benefits.
If, however, you have more than a few shared steps between two use cases, the redundancy becomes a waste of effort and you'll run the risk of forgetting to keep the duplicate steps synchronized. In this situation, employ the include relationship: Take the steps that are common, move them into their own use case, then include this use case in the place where the steps originally appeared.
Notation and Terms
The use case diagram below shows the UML notation to indicate when one use case includes another. In this example, Find Reservation is the included use case; CheckIn a Reservation and Cancel Reservation are the including use cases.
What's the Downside?
An important benefit of the use case approach is that it makes your requirements easier to comprehend. But the include relationship scatters behavior between multiple use cases - a practice you should avoid as best you can. Requiring your readers to look in more than one place to understand a use case makes the use cases harder to follow. It’s faster and easier to understand a use case if it's all in one place.
In short, the include relationship benefits the author at the expense of the reader. So like any useful technique, it should be applied judiciously.
A Final Pitfall
Do not use the include relationship to simply separate one big use case into a sequence of smaller use cases. If you do, you'll force your readers to look in multiple places just to understand a single use case. This misses the point of making requirements easier to understand. Your use case is just too big. Rethink its scope and rewrite it.
The include relationship is a great technique to have in your toolkit of use case writing skills. Are you using it to remove redundancy from your use cases? Are you encountering any challenges? Tell me about it by leaving a comment here.