Use Case

A use case is a named series of steps defining what the user needs to do with the system to achieve some goal. The main purpose of use cases is to understand how the user intends to use the system - what are the main goals. Unlike other types of requirements, use case is not an abstract stakeholder need - it defines a concrete user goal to be achieved using software, so it is always related to a particular system.

EXAMPLE

UC Evaluate Alert On Contract

Description: Back office employee evaluates whether the automatically raised contract conditions violation is valid or not
System: Contract Management System
Actor: Back Office Employee

Main Scenario:

User selects alert from the queue and opens it

System displays detailed alert information and conditions which were not met and which raised the alert

User goes through the conditions one by one and manually confirms or rejects the violation

User saves the changes

If all conditions were marked rejected, system deletes the alert and marks it ready for approval. If not, the contract is assigned back to the front-desk employee who has to solve the problem with the client.

The use case steps, which are usually called a scenario, consist of user actions performed in the system, followed by the system responses. Since the steps must be implemented in the software, they actually represent functional requirements (the step System displays detailed alert information is a use case step, but it is also a functional requirement). The great benefit of use cases is, they encapsulate all related functional requirements. The requirements are then well organized, which helps manage them and track them more easily.

Although some simple use cases might represent functional requirements themselves (for example, "Delete Item"), the purpose of use cases is not to list functional requirements but to provide a concise overview of the main system capabilities presented from the user's perspective. This implies that the granularity of use cases should be kept at the level, which will not lead to having dozens of use cases.
Use cases are a great "research" method to find out the basic usages of the system, being most beneficial in the very early stages of the analysis when it is important to discover the user goals. But use cases themselves do not provide all necessary information for development and need to be supplemented by other types of requirements.

Finally, since use cases form the skeleton of what the system must be capable of, they are used to structure project management data such as release dates, teams, priorities, and development status.

Use Case Components

The vital part of the use case is Scenario. It is the core component which describes how the user interacts with the system:

SCENARIO

User enters search criteria and requests plane tickets

System displays found plane tickets

User selects a ticket and enters delivery and payment details

User pays for the tickets

System sends a confirmation email to customer's email address

This scenario presents a basic (main) flow, sometimes called a happy path or a happy day scenario. It is the use case flow, which is the most likely to happen and which is applied in case no exception occurs. Besides the main flow, use case can include one or more alternate and exception flows. The difference between the two is that while the alternate flow still delivers the result to the user, the exception flow is an error flow and going this way means that the value will not be delivered:

To make the management of the use cases easier, each use case has a Name and a Description, which provides a short overview of the purpose of the use case. Since not all users perform all use cases, each use case is associated with an Actor. An actor represents a particular user class that could execute the use case. Associating actors with use cases helps the analyst to manage which use cases should be discussed with which stakeholders and provides a baseline for setting user roles in the further system design activities. The last part of the use case, which is very often omitted, is a System boundary. It does not provide much benefit if the use cases are stored just in the text, but when the use case diagram is used, the boundary clearly shows which use cases are part of the analyzed system and which are not.

The mentioned Use case diagram is an optional part of the use case specification, and its only purpose is to visualize the use cases. Use case diagram is just a supplementary component, and without scenarios, the diagram itself does not provide any additional value. It was created and became popular because use cases are part of the UML notation, and it was natural to have also a diagram for use cases.

Preconditions and Postconditions

A use case precondition is anything the solution can assume to be true before the use case starts. You can imagine a precondition like a switch which tells whether a button which starts the use case should be enabled or disabled:

Only if "There is a conflict between the country in which the customer was born and the customer's address ", the use case "Resolve conflict" can start
Only if "At least one customer has more than 1000 credits", the use case "Delete all high-value customers" can start.

Despite the simple definition, defining preconditions properly might be tricky. Following aspects should be taken into consideration:

Preconditions are not triggers. "User selected to create a request " is obviously true before the use case starts, but it is not a precondition, it is a trigger. The same applies to "It's first Monday in month ".
Preconditions are not checked by the use case, they are true before the use case starts. There is a difference between the use case step stating "System checks whether a user has enough credits to buy the tickets" and the precondition "User has enough credit to buy tickets ". While the former is checked by the use case, the latter must be guaranteed to let the use case start.
Avoid repetitive preconditions. If the whole system is available only to authenticated users, what is the point in repeating "User is signed in " in all use cases?

A use case postconditions indicate what will be true after the use case finishes. As for the preconditions, there are several potential traps:

Postconditions should not describe use case steps (avoid "System sends confirmation email")
Postconditions should not duplicate scenario steps (including the step "System creates customer and displays success message to the user" and the postcondition "Customer was created" is duplication)
Postconditions should not include implementation details (avoid "Customer was created in database")

Where They Fit

Defining a use case as a sequence of interactions between the user and the system causes a lot of confusion, not only among junior analysts, but it surprisingly has shown to be confusing for the experienced analysts too. The problem is, that each level of abstraction has its own form of "use case". Let's take a look at an example:

The tricky part is that the scenario can be a representation of a long-running process, a user goal, or a low-level system function. For that reason, not every sequence of steps could be considered a use case, because otherwise, we would end up with a mix of business processes, use cases, and system functions, all on one heap, which would not provide the expected value.

Let's add some constraints to the use case definition then:

Actor starting a use case is the only actor performing tasks within the use case (so it is not a process)
Actor starting a use case interacts only with a single system. The system can call other systems, but this is not visible to the user (use case is a capability provided to the user by a single system)
Actor can finish the use case in 2-20 minutes (this eliminates administrative/service use cases and long-running processes)
Actor benefits from the use case even if it is performed many times in a row (this eliminates use cases not bringing much value to user)

QUICK HINT

You found a use case, if it is worth turning on the computer to complete it.
For example, Adding customer to invoice is not a use case because without printing the invoice or sending it out, you did not get any benefit. The same applies to Sign in, Sort items by name, Add note to a contract or Search customers which all could be considered system functions.

User Goal Level

Use cases are placed at the user goal level, where they effectively describe the main behavior the stakeholders expect from the system. Use cases on the higher levels are too abstract for analysts to understand what are the main user goals, and they are very likely to describe the behavior of the other systems too. Identifying the low-level system function is also important, yet it cannot a part of the use case analysis. For complex systems, it would mean describing hundreds of mini use cases, which would make the final specification hard to review.

REMEMEBER

Not every user-system interaction desribed by scenario is a use case

Keeping use cases at the appropriate level of abstraction lets analysts

have an overview of the main user goals the system must be able to satisfy
will make use cases immune to frequent rework as it will not be needed to change them every time some low-level requirement changes

Sub-Use Cases And System Functions

As the analysis proceeds, use case steps need to be elaborated in more detail to discover concrete system functions. Each use case step can represent another "sub-use case" such as Add customer to invoice or a system function, for example, System retrieves the newest deals. They could be identified using these common characteristics:

They are very simple - usually, they cannot be described using a scenario (Mark email read, Filter contact list)
Mostly, they are not independent and are rather part of another use case (Find customer)
They include implementation details or calls an internal function or a service ("Validate Address")

Although we have seen teams creating "sub-use cases" to specify individual use case steps, in Effective Analysis, there is only one kind of use case - "user goal" use case. Everything else should be modeled using other artifacts such as activities. It has a reason. The practice has proven that placing use cases into hierarchies always attracts analysts to misuse use cases for a functional decomposition instead of focusing on the user goals. They simply start breaking down use cases to smaller and smaller sub-use cases because they want to capture the information somewhere but do not know how and where:

The purpose of the use case analysis is to outline basic usages in a very streamline form which is understandable for any stakeholder so

avoid including, sharing or inheriting use cases despite these techniques are an official part of the standard
for modeling the low-level aspects, use other techniques such as activities which could be shared, decomposed and could be of any level of detail

Secondary Use Cases

In each set of identified use cases, there are always some which are "different" in some sense. These use cases meet all use case requirements, but they are still secondary in some way:

They are invoked rarely - they are not the main system functions which user would use every day (Reset forgotten password)
If you removed them from the system, it would remain functional yet limited
They are simple CRUD (Create, Read, Update, Delete) operations (Create product, Update product, ...)
They are service/administrative functions such as Update settings

There is nothing wrong about capturing user requirements as use cases, they just should be separated from the core primary use cases and analysts should not spend much time documenting them in detail.

Use Cases and Other Requirements

Despite the use cases are a beneficial method for capturing the system behavior, they alone are not sufficient for describing all aspects of the modeled system. They will not tell how the screens will look, what are the core algorithms and calculations, how well the system should perform, or what are the security constraints. But it has one big advantage: it can tight all these facts together, serving as a "hub" keeping other information coherently together which helps organize and structure requirements in a very convenient way:

The "hub" means that the related information is only linked to the use case and it is not included in its scenario directly. Otherwise, the use cases would become enormously big. Besides, linking the artifacts to the use case enables sharing them between multiple use cases, which is very common.

Use Cases and Post-release Documentation

Since use cases are a form of requirements, they will not typically be part of the documentation which describes an already implemented and deployed solution. Including all use cases in the system documentation would mean updating all information twice, every time some part of the system changes - in the use case and in the corresponding artifact such as screen, function, etc. This does not mean use cases have no place in the post-release documentation. Even the legacy systems need an overview, listing the basic user goals and scenarios, which is when use cases are handy. However, the overview should outline only the most important features, so definitely not all use cases should be included, and the form of use cases should be altered for the needs of the documentation.