A use case is NOT a user story. Let me just repeat that one more time. A use case is NOT a user story. Many will confuse the two, they are similar, but a use case has all the extra information that could ever be thought of and a user story is just that, a user with one story to tell. It is a many to one relationship. A user story is one and a use case is many relationships. I like to look at these items the same way that I view a tree. A user story is just the trunk of the tree and a use case is the trunk of the tree and the many branches that the story could become.

Use cases begin with defining the title, description and properties: actor(s), pre and post conditions. A use case title is a single function or action to be completed. Example: “Login.” A use case description describes the function or action to be completed in more detail. Example: “Login to the application to gain access to the application.” Now let’s get into the use case properties. Who are the actors that I will need to do this thing called, “Login?” Obviously you will need one human body with access to a computer and internet to login to the application. The computer could be considered an actor as well as the internet. The database that connects the application and the server that the application and database reside on could also be considered actors. Do you see the possibility of all actors? There isn’t a right and wrong answer here, it is just best practices based on the company and type of application that we are writing a use case for. For our use case, we will use the one human body (user/customer) as one actor and system (application, internet, database, server,etc.) as the other actor. We have two actors, the user and the system. What are the pre-conditions? What has to happen or be currently happening in order for our one user actor to login? The system must be available. That means I can’t have no internet connection, a server with missing parts, a database that is corrupt, or an application that is broken or I am never going to be able to login. That is what makes it a pre-condition. All of these things need to be in place and working properly for my case of login to work. What about my human user? What are his/her pre-conditions? They should be able to use a computer and have basic computer skills right? So we have defined two pre-conditions:

1. System must be available and functioning as expected.

2. User must have basic computer knowledge and know how to use a computer.

What about our post conditions? What is the end result of our use case? To login, the post condition closes out the case for the actor:

1. User is logged into the application.

Now we get into the basic flow or the meat of the use case. Our system is available, functioning, and our user actor has basic computer knowledge. How do we login? How do we get the user logged into the application? What is the point/action between the pre and post conditions? We need to enter a valid user name and a valid password and click the Submit button. This is how our user gets logged into the system. This is the successful path, also known as the happy path.

What about all of the not so happy paths; the unsuccessful roads; or the other tree branches? These are considered alternative flows. This is when the thinking cap really needs to be put on here, because this is where we think about the infinity of the universe. Okay, not so much, but after we are done, it may feel like it. What if? What if? What if? Sit with your eyes on this login page and ask yourself over and over again, what if? What if I enter an invalid username? What if I enter an invalid password? What if I put in 5,000 characters for my username or password? What if I click on this shiny little help link I see in the top right hand corner of the page? What happens if I click the X and close my browser? What happens if I enter a username, walk away for a three hour break and then come back and try to login? What if my Submit button doesn’t work, because I am using an AOL browser? What if I click the “forgot my password” link? What if I click the “forgot my username” link? How many times can I attempt logging in? Do I have an unlimited amount of chances, or do I only have three chances and I am locked out and now have to call the support help-desk number that was just provided to me? What happens if I use a valid username and password, but it isn’t mine, I randomly guessed someone else’s account? Does it matter for security reasons for this application?

Can you think of a not so happy path that I am missing?

Other items that could be listed on a Use Case are:
The associated business requirement.
Triggers.
Application.
Frequency of Use.
Status.
Owner.
Priority.

Below is our Use Case:

Use Case #1 : Login

Description:

Login page – The page the user will use to login into the application.

Properties:

Basic Flow:

Alternative Flows: