A simple example UML Use Case diagram

UML Use Case FAQ: Can you share an example of a Use Case diagram?

As I've been preparing to let other writers write on the devdaily.com website, I started to think about what different things (processes) an author would need to do on the website. As I thought about this, I started realizing that I was once again thinking like a business analyst, and then I thought I'd create an example UML Use Case diagram to show these processes.

Example UML Use Case diagram

Here then is a simple example UML Use Case diagram, demonstrating the use cases (or processes) that a writer/author will have on this website:

As you can see from this Use Case diagram, the role named "Author" will have the use cases shown in the "bubbles" in this diagram. After identifying each of these use cases, what I'd normally do next either write (a) some use case text or (b) user stories for each use case shown here. For instance, a simple "Log In" user story might be written like this:

The Author logs into the system using the username and password that were assigned when his account was created.

The Author will typically log in by going to the main user login page, but they can also be redirected to the login page any time they try to create new content, or edit existing content.

If the Author attempts to edit or delete content they aren't authorized to change, they will still be redirected to the login page, but they will not be allowed to edit or delete the content after the login.

If the user credentials can't be confirmed against the "users" data store, they will be redirected to the user login page for another login attempt, and the user may attempt to log in an unlimited number of times.

If the user's credentials are confirmed against the system's "users" data store (and assuming the user is assigned the Author role), they will be assigned the permissions of the Author role. Note that a user may have multiple roles, so the user may actually be an Author and Editor, and they will inherit all the permissions associated with all of these roles.

Conveys important information

As you can see, a User Story like this is simple, but still attempts to convey important information to all the reviewers of the story:

1. The username and password were assigned to the Author at some earlier time, all of which implies that an Author is a User who has a special Author account in the system.
2. There is a standard user login web page.
3. There are alternate ways to get redirected to the login page.
4. Login attempts are unlimited.
5. Users may have multiple roles, and permissions associated with all those roles.

The designers of the website must agree to all these design decisions, and the system must be programmed to match these decisions.

In contrast to a simple User Story like this, more traditional Use Case text would be more formal, typically written as "The user does X", followed by "The system does Y" prose, with other sections added, such as Preconditions, Postconditions, and additional details.

Benefits of a UML Use Case diagram

The thing I like about a Use Case diagram like this is that, if you write your use case bubble text well, most people can understand a lot of what you mean by looking at the diagram.

Over the years a lot of customers and developers have made fun of my "stick figures", but I know that these Use Case diagrams helped us in many ways, including:

• Serving as a "talking point" diagram to keep meetings on track
• Finding missing use cases
• Identifying missing (and misunderstood) actors (user roles)
• Kicking off discussions of what each bubble really means

On that last bullet item in particular, a simple Use Case diagram like this can serve as the starting point for a discussion. In fact, when I'm meeting a new customer, or working on a new project, I'll either bring a diagram like this to the table, or we'll draw use case diagrams like these on a whiteboard. Of course we don't call them use case diagrams, we call them "Al's stick figures", but that doesn't matter, because we're talking about our software system in a language that everyone easily understands.

Using Use Case diagrams in requirements specifications

I typically write my software requirements specifications as a series of use cases, or possibly as XP "user stories" (if I know the customer well enough). I organize the use cases according to user roles (the "actors"), and begin each section with a summary diagram, like the Use Case diagram shown above. I think a figure like this serves as a nice introduction to what the requirements specification reader/reviewer is about to read.

A second idea is to include all these figures in a separate document, so users can "check off" each bubble after they've reviewed that use case. I mention this is that I see reviewers check off these bubbles so often, I'm tempted to say this is a "best practice".

As a final note, please don't read into this that all you have to do is create a bunch of stick figures and bubbles and call that a software requirements specification. The devil is in the details, and the text you'll write in your use cases (or user stories) will really bring out the discussions. Agreement on a Use Case diagram is one thing, but agreement on the step by step detail of use case text is a completely different story.

Example UML Use Case diagram - summary

In my opinion, Use Case diagrams can be very helpful as a communication tool, in the ways I've discussed in this article. And because communication is all about the role a business analyst performs, using Use Case diagrams wherever they enhance communication is a good thing.

If you have an example Use Case diagram you'd like to share, just use the contact form above to send it to me, and I'll add it here, or create a new web page for it. Alternatively, I can create a user account for you, and let you write your own "Use Case diagram" article here.