Use Cases
Our previous blog posts made a case for gathering project requirements, identified three core requirements types, focused on busienss objectives, and strategies for eliciting user input.
Our focus is going to shift towards determining and defining specific things an application must do to provide value to users.
A use case is a description of how an external actor will interact with a system and state the acceptable outcome. The following paragraphs will provide you with an overview of use cases and how they enable developers to create software that meets your business objectives.
Define the Objective with a User Story
User stories are a useful tool to simply state the objective of a use case. The following template is commonly used to generate user stories:
[User Role]: I need [insert goal] in order [state desired outcome.]
Here is an example from a recent project:
[Shift Leader]: I need to look at prior shift data quickly in order make the shift change or handoff go more smoothly.
Users and Actors
It is important to note that users and actors are different. A user is a person who interacts with software. It is possible for a user to use the software in different actor roles.
For example, Manager Marlene is filling in for Scheduler Sam this morning. When she interacts with the software, she is a user, but she is interacting with the software as a Scheduling Actor. Later that morning when she runs an accounting report, she is using the software as an Accounting Manager Actor.
To complicate things further, an actor doesn’t have to be a user. An actor is anything that interacts with a software application.
Preconditions and Postconditions
A precondition states the conditions that must be met before the application executes a specific use case.
The postcondition depicts the outcome of a successfully executed use case.
Most of the time, users only care about what they need to do to have a specific need addressed. They don’t care what goes on under the hood to meet their needs.
This is where an experienced Business Analyst (BA) is a great asset to stakeholders, users, and developers. They can communicate effectively with all involved parties to make sure that needs, wants, and expectations are available and discussed.
Flows
Flows denote series of steps the use case will execute. Each step in the flow indicates the task performed and which actor performs it.
The primary flow for each use case is called the normal flow. There are instances in which a different series of steps occurs. Such instances are called alternate flows. While the series of steps may be different in kind or order, the outcome of the use case is the same as if the normal flow were executed.
Exceptions
Potential disruptors to a use case are called exceptions. Exceptions include anything that could cause a use cause to fail. It is very important to identify potential exceptions as soon as possible.
Failure to do so will result in developers creating workarounds once they become aware of the exception or system failures. Either of these situations will ultimately cost the business additional time and money to remedy the situation.
Putting the Pieces Together
The BA will compile the information gathered during the requirements elicitation process and send a use case candidate to the product champion(s), product owner(s), and other decision makers for review and approval.
A well-crafted use case will include all of the information presented above along with business rules, functional requirements, and other technical details the developers need to know before they begin crafting the software. Visual depictions of the use case, flows, and other relationships help users and developers see how the use case functions from a high level.
A use case template is a helpful tool to make sure that the right information is collected during the elicitation process. Send me a message and I will share a our case template that will help you gather the necessary information.
Give me a call at 502.495.3936 or send me a message with your input or to schedule a complimentary consultation.
Up Next: Document Requirements
Reference: Software Requirements 3rd Edition – Karl Wiegers and Joy Beatty