What is a Use Case?
Working in IT or systems engineering requires some disciple and structure. Have you ever had a chat with a programmer, for instance? Their mind is a combination of complex code and nodes, where a certain request drives a certain response. Try it. That pretty much what happens with Use Cases.
A Use Case is a textual description of the interactions – presented as a flow of plain steps – between a role (aka ‘actor’) and a system (think of a website, as an example), with the purpose of allowing the role to accomplish a certain goal (e.g. submit a comment). Use Cases are a common technique for gathering functional requirements in the Business Analysis world where, by ensuring that all interactions are captured, the project team can build confidence that a seamless user experience and fully functional product will be delivered according to the needs of the customer.
Benefits of Use Case
The benefits of writing requirements as Use Cases include:
Easier understanding of the requirement:
By breaking down the requirement into a series of simple steps, this technique allows even non-technical people to easily understand what the requirement is about. You can understand the techie-talk this time!
You may be surprised with this one but failing as early as possible is actually a very valuable benefit since it saves time later and allows the team to prevent and correct any defects immediately.
Finding unexplored opportunities:
By exploring different routes and behaviours (‘alternate flows’), the team may find additional valuable functionality never considered before. The expected behaviour (‘basic flow’) is your baseline but it’s when things go wrong that the distinction between a successful and an unsuccessful product are clear.
Smoother customer journey:
It’s easy to become too immersed in technical details and forget what the user really wants to achieve. By decomposing requirements as Use Cases, the team put themselves in the user’s shoes, perceiving the user experience as by their eyes.
How to Write a Use Case Template?
Use Cases can be as sophisticated as you want them to be but, as a minimum, should contain the following elements:
- ID: a unique identifier to represent the Use Case.
- Name: what it says on the tin; should be a clear and short name.
- Description: a brief description (not War and Peace!) of the Use Case.
- Primary Roles / Actors: the type of primary users that the Use Case relates to.
- Pre-conditions: what conditions/assumptions need to be in place for the Use Case to start.
- Trigger: what event will trigger the start of the Use Case.
- Basic Flow: illustrates the set of steps the role will take to accomplish the objective of the Use Case, as well as the responses from the system. The Basic Flow represents the ‘perfect scenario’, where there are no errors or exceptions in the user’s experience.
- Alternate Flows: illustrates the ‘unbeaten path’, that is, the less common user and system interactions, as well as exceptions preventing the user from achieving their goal.
- Post-conditions: what conditions/assumptions need to be in place when the Use Case is complete.
Hints and Tips to Write Good Use Case Template
However, what really makes a good Use Case is not much what fields it contains but mostly the quality of the content. Therefore, pay special attention to the following hints and tips:
Keep it simple:
You must have heard of the KISS acronym, right? Use it! The purpose of a Use Case is, above all, to simplify what is by nature complex.
Just enough information:
Closely related to the previous, it’s important to find the right balance between sufficient detail and too many fields to understand what’s expected. At the end of the day, if the team is still not clear on what the requirement is, you have a problem to solve.
Actors, not job titles:
When building the Use Case, don’t think of job titles – these can vary much and change over time. Instead, think of actors – what role is that user performing?
A picture is worth a thousand words:
Some things are easy to understand in pictures and complementing the Use Case with a diagram representing each interaction can prove very helpful, particularly if your audience like visuals.
Validate the Use Case:
For maximum value to be captured and to ensure that no interaction falls between the bricks, review the Use Case with the team and with the user’s representatives.
Regarding format, Use Cases can be represented as a document, spreadsheet, or even produced via specialist software solutions. Check out our Word template and example and Excel template and example to learn how Use Cases are used.
Is Use Case relevant in Agile?
If you work in an Agile environment, you may have seen already something similar to Use Cases. Does ‘User Story’ ring a bell?
User Stories are very helpful in collecting and sorting the priorities of high level features of a product but, no, they are not the same. The main difference lies on their focus: while User Stories focus on the needs of the customer, Use Cases focus on the interactions between that customer and a system. Following, whereas a User Story may be especially valuable for the client to elicit their requirements, from a technical perspective a Use Case is a more complete solution.
One feeds the other so, yes, both are useful and relevant in Agile.