Use Case Diagrams – Part II
In a previous blog, I presented four of the key elements of Use Case Diagrams. Do you remember them? They were actors, use cases, system boundaries, and relationships. In this entry, I want to expand on that a bit by giving you some actual examples with requirements.
For those of you who do not already know, I am the Director and Head Trainer of the American Annex to the Russian Federation of Russian Martial Art. (For more information about my organization, please see http://www.AmerROSS.com.) Let’s imagine that I have hired you as a business analyst for my organization, and I am interested in implementing a Content Management System (CMS) that will enable individuals registered with my organization to blog about their Russian martial art training experience. Let’s call it the AmerROSS Blog.
As a good business analyst, you want to get my requirements. Here is my first requirement:
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.
Let’s start by looking for the actors. Remember, actors are entities that interact with our system. So, who and what are the actors in this requirement?
- AmerROSS Member Database
We’ll draw these two actors as stick figures in our Use Case Diagram. Next, let’s look for the use cases. Remember, use cases represent business functionality. What is the business functionality in this requirement?
- Create Blog Account
This will be created as an oval on our Use Case Diagram. We already know the system boundary, right? That’s the AmerROSS Blog (our Content Management System). The last piece of the puzzle is to connect the actors and the Use Cases with lines that show their relationships.
Here’s an example of what the Use Case Diagram might look like so far:
Now, it would be great if we could just give this image to our system designers and have them create the perfect system from it; however, that is highly unlikely. In addition to the Use Case, a good business analyst will also create a Use Case Narrative (or Use Case Scenario). The narrative provides more data to support the diagram and to help the designers understand the flow of the system. Here is what the Use Case Narrative might look like for our diagram:
|Use Case Name:||Create New Blog Account|
|Related Requirements||Requirement A.1.|
|Goal In Context||A new or existing Russian martial artist requests a new blog account from the Administrator.|
|Preconditions||The system is limited to recognized authors and so the author needs to have appropriate proof of identity in the AmerROSS Member Database.|
|Successful End Condition||A new blog account is created for the author.|
|Failed End Condition||The application for a new blog account is rejected.|
|Secondary Actors||AmerROSS Member Database.|
|Trigger||The Administrator asks the CMS to create a new blog account.|
|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||The author’s details are verified using the AmerROSS Member Database.|
|5||The new blog account is created.|
|6||A summary of the new blog account’s details are emailed to the author.|
|Exception Flow||Step||Branching Action|
|4.1||The AmerROSS Member Database does not verify the author’s details.|
|4.2||The author’s new blog account application is rejected.|
So, there you have it! We have created a Use Case Diagram from a requirement and ensured that we have a matching Use Case Narrative. Coming up in future blog entry, we’ll build on this Use Case Diagram with additional requirements and other relationship types.
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/.