A Use Case example of yesterday's User Story

In my Use Case quality article yesterday I wrote about a "User Story" for a fictional "User Logs In" requirement. To complete that article, I promised to write a Use Case version of that same user story. Here then is that sample "User Logs In" Use Case, which you can compare to yesterday's User Story.

User Logs In

Note: In the following use case scenarios, the word "user" is used to refer to both (a) a Website Visitor, and (b) a person who has logged into our system (an Authenticated User). If this is a problem I can change this, but I find the use cases are easier to read this way.

Primary scenario

This is the primary scenario for the "User Logs In" use case.

1. The Website Visitor ("user") navigates to the user login page, where the system prompts the user for their username and password.
2. The user enters their username and password, and submits the form.
3. The system validates the username and password against our ACME external user's LDAP system.
4. If the username and password match an entry in the LDAP system, the user's roles are also retrieved. (For instance, the roles may be 'author', 'editor', and so on.)
5. The system forwards the user to their home page. Panels are shown on the home page that correspond to the user's role(s).

Alternate scenario - Invalid username or password

An alternate scenario occurs when the user attempts to log in to the system, but the login process fails.

1. The Website Visitor ("user") navigates to the user login page, where the system prompts the user for their username and password.
2. The user enters their username and password, and submits the form.
3. The system attempts to validate the username and password against our ACME external user's LDAP system, but can't find a match.
4. The system redirects the user back to the login page, displaying an error message stating that "The username and/or password are invalid".
5. The user may attempt to log in again. (See the Requirements section below for any restrictions on login attempts.)
6. The user may use the "Forgot password" or "Forgot username" use cases. (See those use cases for more information.)

Alternate scenario - User logs in from an Add, Edit, or Delete URL

This alternate scenario occurs when the user attempts to access one of the system's Add, Edit, or Delete URLs. They may do this because their browser is showing these URLs, even though their session has timed out; they may have the URL bookmarked; they may know the URL from using the system; they may be attempting to hack into the system.

1. A Website Visitor directly accesses one of the system's Add, Edit, or Delete URLs.
2. The system detects that a user who is not authenticated is attempting to access this URL.
3. The system redirects the user to the User Login page.

Requirements

This is a list of requirements related to this use case that do not fall neatly into one of the scenarios shown above, or they may be easier to find here.

1. The system will not limit the number of times a user may attempt to log in.
2. The system will not attempt to throttle user login attempts.

Discussion of this Use Case

As you can see, the Use Case style is much more formal and slightly more detailed than the "user story" format shown in yesterday's Use Case quality article. A User Story is often referred to as "a promise for future discussion", while a Use Case attempts to completely and accurately detail the interactions between a computer system and the user of that computer system.

About that Requirements section

For many "pure" Use Case practitioners, the Requirements section I show in my Use Case documentation is blasphemy. Surely that can be stated in the Use Case prose.

To that I answer yes, this is true, but as a programmer, it is a thousand times easier to find the requirements this way, and that benefit outweighs any other concerns. Also, I have never had a reviewer complain when I pull specific items out of the Use Case text like this, especially when it makes the Use Case much easier to read.

Yesterday's quality question is irrelevant

I won't add too much to this discussion unless there are any questions, but I will say one thing: The Use Case format eliminates the need for one of my requirements quality questions I posed yesterday, specifically:

What are they key points about this business process that I need to make sure the reviewers really agree with?

Because the Use Case format is so specific and detailed, that question is essentially irrelevant. By documenting the step-by-step interaction between a user and a computer system, these "key points" will come up naturally in the writing. As a business analyst, you should know as soon as you write something like the "Invalid username or password" scenario that the following issues need to be documented:

• The user forgot their username.
• The user forgot their password.
• The user may attempt to log in an infinite number of times; how should we account for this?

Summary

I hope this Use Case example has been helpful, especially when compared to yesterday's very similar User Story. I think the combination of these two articles makes for a nice contrast between these two requirements documentation approaches.