Business Analysis Training – Use Case Diagrams – Part III

0

Use Case Diagrams – Part III

 

In a previous blog, I walked us through the process of creating a simple Use Case Diagram based on the requirement for a Content Management System for my martial art organization (AmerROSS). Here was that requirement:

Requirement A.1

The Content Management System (CMS) will allow an administrator to create a new blog account, provided the personal details of the new blogger are verified using the AmerROSS Member Database.

Here’s what the Use Case Diagram looked like:

In addition to the Use Case Diagram, we also created the Use Case Narrative. In this blog entry, let’s build on this Use Case Diagram with additional requirements and other relationship types. Let’s add another requirement that is related to the first requirement and add it to the diagram:

Requirement A.2

The Content Management System will allow an administrator to create a new personal Wiki, provided the personal details of the applying author are verified using the AmerROSS Member Database.

 

Here’s what the new Use Case Diagram would look like:

 

As I am sure you remember from the previous blog entry, we also need a narrative for this Use Case Diagram. Here is what it might look like:

Use Case Name: Create a new Personal Wiki
Related Requirements Requirement A.2
Goal In Context A new or existing author requests a new personal Wiki from the Administrator.
Preconditions The author has appropriate proof of identity.
Successful End Condition A new personal Wiki is created for the author.
Failed End Condition The application for a new personal Wiki is rejected.
Primary Actors Administrator.
Secondary Actors AmerROSS Member Database.
Trigger The Administrator asks the CMS to create a new personal Wiki.
Main Flow Step Action
1 The Administrator asks the system to create a new personal Wiki.
2 The Administrator enters the author’s details.
3 The author’s details are verified using the AmerROSS Member Database.
4 The new personal Wiki is created.
5 A summary of the new personal Wiki’s details are emailed to the author.
Exception Flow Step Branching Action
3.1 The AmerROSS Member Database does not verify the author’s details.
3.2 The author’s new personal Wiki application is rejected.

Have you noticed the repetition in the two Use Cases? They both have to check credentials! Instead of repeating this over and over again for as many Use Cases as we might come up with, we could just create a new Use Case that can be used by the others. Let’s add another Use Case called “Check Identity.”

That new Use Case needs to be connected to the Author Credential Database (and the prior associations deleted).  And we need a special way to connect our other two Use Cases to this one. That requires an <<include>> stereotype. Let’s add those two now…

To show the <<include>> relationship in your Use Case narrative, you need to remove the redundant steps from the Create a new Blog Account and Create new Personal Wiki Use Case narratives and instead use the Included Cases field and include::<use case name> syntax to indicate the use case where the reused steps reside.

Use Case Name: Create a new Blog Account
Related Requirements Requirement A.1
Goal In Context A new or existing author requests a new blog account from the Administrator.
Preconditions The author has appropriate proof of identity.
Successful End Condition A new blog account is created for the author.
Failed End Condition The application for a new blog account is rejected.
Primary Actors Administrator
Secondary Actors None
Trigger The Administrator asks the CMS to create a new blog account.
Included Cases Check Identity
Main Flow Step Action
1 The Administrator asks the system to create a new blog account.
2 The Administrator selects an account type.
3 The Administrator enters the author’s details.
4

include::Check Identity

The author’s details are checked.
5 The new account is created.
6 A summary of the new blog account’s details are emailed to the author.
Use Case Name: Create a new Personal Wiki
Related Requirements Requirement A.2
Goal In Context A new or existing author requests a new personal Wiki from the Administrator.
Preconditions The author has appropriate proof of identity.
Successful End Condition A new personal Wiki is created for the author.
Failed End Condition The application for a new personal Wiki is rejected.
Primary Actors Administrator
Secondary Actors None
Trigger The Administrator asks the CMS to create a new personal Wiki.
Included Cases Check Identity
Main Flow Step Action
1 The Administrator asks the system to create a new personal Wiki.
2 The Administrator enters the author’s details.
3

include::Check Identity

The author’s details are checked.
5 The new personal Wiki is created.
6 A summary of the new personal Wiki’s details are emailed to the author.

Now you can create a use case description for the reusable steps within the Check Identity use case.

Use Case Name Check Identity
Related Requirements Requirement A.1, Requirement A.2.
Goal In Context An author’s details need to be checked and verified as accurate.
Preconditions The author being checked has appropriate proof of identity.
Successful End Condition The details are verified.
Failed End Condition The details are not verified.
Primary Actors AmerROSS Member Database.
Secondary Actors None.
Trigger An author’s credentials are provided to the system for verification.
Main Flow Step Action
1 The details are provided to the system.
2 The AmerROSS Member Database verifies the details.
3 The details are returned as verified by the AmerROSS Member Database.
Exception Flow Step Branching Action
2.1 The AmerROSS Member Database does not verify the details.
2.2 The details are returned as unverified.

Finally, you might also want to extend your Use Cases to another Use Case if a certain event occurred. For example, you could extend your two Uses Cases with a new Use Case called “Record Application Failure” and draw two <<extend>> associations FROM the new Use Case.

So, there you have it! We have updated our Use Case Diagram with two special types of relationships (include and extend). Coming up in a future blog entry, we’ll continue our study of UML Diagrams with the Activity Diagram.

P.S. – For those of you who are curious, these diagrams were created using Poseidon for UML Community Edition 8.0. Support the community: http://www.gentleware.com/.

 

Share.

About Author

Scott Fabel is a senior corporate training consultant with Computer Aid, Inc. He has over 18 years of experience working with various Fortune 1000 companies on Help Desk Implementations, Microsoft Technologies, Business Analysis, and Project Management. This includes both consultative services and customized training programs. He is HDI certified, PMP certified, CBAP certified, and a MCT. Scott has been teaching others business skills, professional skills, and technical skills for more than 13 years. He is a faculty fellow at the University of Delaware and is currently pursuing his doctorate in education for which his dissertation will focus on the benefits of corporate training and mobile learning. He speaks three languages and was recently inducted into the International Martial Arts Hall of Fame. His communication skills, combined with his martial art skills, provide him with a unique combination for keeping his sessions informative, lively, and interactive.

Comments are closed.