Master the Use Case Include Relationship

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.

IncludedUseCase

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.

Include Use Case Diagram

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.

Bad Use Of Include

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.



Comments (4)

1/16/2009 6:50:34 AM #

Adam Bradley

With "system" type use cases I use the following logic  
when using include relationships and am wondering if this
is OK?

(UC-ADP-1 - "Including" Use Case)

Main success scenario:

1      step 1
2      step 2
3      System Validates Invoice Completion (UC-ADP-4)
       3.1 System receives "success" return code from Validate Invoice  Completion (UC-ADP-4)
4.  step 4
5.      step 5

Extensions:

3.1.a  System receives "Fail" return code from UC-ADP-4:
1.  Continue at main step 5


(UC-ADP-4 - "Included" Use Case)

Main success scenario:

1      step 1
2      step 2
3      Use Case ends passing "success" return code back to Step_3.1 of calling Use Case (UC-ADP-1).

Extensions:

2.1.a  Some failure condition:
1. Use Case ends passing "fail" return code back to Step_3.1 of calling Use Case (UC-ADP-1)

Thanks

Adam

Adam Bradley Australia


1/23/2009 2:19:45 PM #

Matt Terski

Adam,

That's close, but I'd make a few changes.

Specifically, I would not include the concept of return codes (you’re writing requirements, not pseudo code for a program). Second, you could simplify the conditional logic to assume success in your main success scenario. Then just state the exceptional conditions with the extensions. It might look something like this:

Including use case (UC-ADP-1):
1.  Step 1
2.  Step 2
3.  System Validates Invoice Completion (UC-ADP-4)
4.  Step 4
5.  Step 5

Extensions:
3.1.a Invoice Validation Failed
      1. …

Included use case (UC-ADP-4):
Main success scenario:
1.  Step 1
2.  Step 2

Extensions:
2.1a. Some failure condition
      1.

Matt Terski


1/29/2009 4:21:44 AM #

Adam Bradley

Matt,

Brilliant! So simple I'm kicking myself for not thinking of doing it the way you've described. Much simpler. Much cleaner. And as you stated a use case should be all about writing requirements not pseudo code.

Thanks for pointing this out to me!

Adam

Adam Bradley Australia


5/27/2009 1:46:31 AM #

nikki

what could be the two different user roles for this site and user role map that summarises the way these two user roles fit together in defining who will use the system and how???

what is the perona for each user role

nikki New Zealand


Pingbacks and trackbacks (3)

Comments are closed