Table of Contents
Introduction
Use cases are one of the documents that a Business Analyst might produce during the course of developing a piece of software. As business analysts perform requirement analysis (determining what you actually need to be able to do with a given program or piece of software), the use case helps you accomplish this by making sure you understand the interaction between yourself and the program.
Use cases don’t just have to be used by software engineers, though. Nonprofit program managers can use the same process to document their client interactions with staff – to make sure they have captured all the moving parts. This might be useful if you’re creating a Logic Model or a Theory of Change, or if you’re considering general process improvements that will save time, effort, or make things easier for your clients.
Use Case
A use case will describe all of the interactions that a specific piece of functionality or specific action will involve. It is usually written in a structured way so that you can work through an entire software program, one feature or action at a time.
Use Case Format
Each heading below will indicate what content will go under that heading of the use case. Many programs will not use all of these headings – simply select the ones that make the most sense. The important thing is that you are consistent – if you’re using any of these headings at least once, they should appear in every use case for that same program. Simply indicate “Not applicable” if, for example, Success Guarantees or Level isn’t relevant.
Title
The name of the use case will be a verb phrase that describes a particular task. For example, “Entering a new client.”
Primary Actor
The primary actor is the person using the system. For example, “Intake Worker.”
Goal in Context
Goal in Context is similar to what might be called the Rationale of a policy. It explains the goal with more description to allow you to understand how it fits with other items.
Scope
What part of the system does this use case refer to?
Level
Sometimes use cases are written at a very high level, to describe business requirements. Other times, they are written at a low level, describing the specific functionality behind-the-scenes and detailed technical pieces. You can indicate that level here.
Stakeholders and Interests
Who is affected by the use case (the stakeholders) and how are they affected? These do not have to be actors or users of your system. For example, a stakeholder of a DMV driver’s license system might be the police, who will never use any of the DMV technology but merely enter DMV data into their own databases.
Precondition
What things need to have happened in order for this use case to occur? You can’t open an email program if your computer is turned off. For example, the precondition is that the computer is turned on and the user has been logged in before they click the icon for the email program.
Minimal Guarantees
What is the lowest level of guarantee that you can give for your use case, whether or not any scenarios succeeded? For example, if your printer is supposed to print something but it doesn’t, you would be left with the document in the word processor still appearing on the screen.
Success Guarantees
What happens after your use case has completed its intended function? These are your success guarantees. For example, the document is printed, the information is recorded or the process has completed successfully.
Trigger
What actions do you need to take to trigger the use case? If you click a button, or complete an action that then triggers the use case that will be recorded here.
Main Success Scenario
The main success scenario is also called the “happy path.” This describes the process that must occur when your process works perfectly.
The difference between the success scenario and the success guarantee is that the scenario describes all of the actions and processes that occur on the way to success, while the success guarantee only describes what must be true at the end of the success scenario.
Alternate Paths
Alternate paths or Error Paths are used to describe when things do not work perfectly. You might go to print a document and find out the printer is not connected. Or perhaps no printer is installed or the printer throws an error. Each of these alternate paths may be documented so that you have a complete understanding of all the potential options.
Extensions
Extensions are used like alternate paths. Some BAs may use one or the other, or both. Basically extensions describe different forks that may apply depending on specific situations. Those are documented here to keep them out of the main Success Situation/Happy Path.
Technology & Data Variations List
The technology and data variations list is used to document the way technology may influence the use case and how data might differ in a way that would affect the use case.
If a certain model of printer changes the way printing is completed, then you might document that in this part of the use case.
Conclusion
Use cases are a useful tool for Business Analysts to document programs and how they change over time, especially as part of a requirements analysis procedure.
Good luck with your use cases.