Use cases provide a roadmap to accomplish the following:
• Improve communication within your development team
• Establish common agreement about functionality
• Uncover conflicts and alternative designs
• Build knowledge developers need about the business objectives
• Prioritize the work
• Ensure the delivered software works properly
Use cases describe the interactions between users and system processes. They list the actions or steps that a user will take, along with the step-by-step results of those actions.
The users in use cases are often called “actors,” because a single user can play several roles. For example, if we were describing how you use your computer to write an article, such as this one, the use case would describe turning on the computer, logging in, launching the editor, opening the file and typing the words. I’ve deliberately left out the many other steps, but actual use cases should be very detailed.
Keeping with the analogy, writing an article is not the only way you use your computer. You might also surf the web or send an email. For each of these actions, you’re taking on a different role. Use cases break down the roles and actions a user takes in order to accomplish a task.
In order to develop good use cases, you have to know what kinds of users are going to use your software and exactly what they need to accomplish. Each combination of roles generates a new use case. You will have numerous cases as you talk with users to understand all the steps that go into each role and transaction.
When developing use cases expect a fair amount of back and forth among your team about how the automation should work. Many companies bring in end users to get their opinions about what the use cases describe. Many software developers are surprised at how differently people think on the other side of the screen!
Working through the use cases, you invariably come across contradictions in the behaviors you are documenting. This requires additional communication about how to resolve the conflict in a way that ensures your design meets the project goals. Sometimes you have to make hard decisions that will satisfy only some of your users. When this happens, it’s useful to have a strong knowledge of the business goals that your software helps accomplish.
Understanding the business side is typically easier for the conceptualizers on your team – the people who have ideas about how the software should work. It can be more difficult for software coders. They may not know the business as thoroughly. Use cases describe to coders how the software should work, without them necessarily having to understand how the business operates.
Ultimately, we want software that does what we have described it will do.
Use cases become templates for testing the finished product. In our article example described, the software should allow me to scroll through my article to proofread it, edit anything that doesn’t look right, save it to an array of places (desktop, shared drive, cloud, jump drive, etc.), and send it to be published. This is how use cases make it simpler for developers to decide what can be done within scope and for coders to follow the steps needed to program the software.
In Part 5, I’ll talk about software design and coding, where we get a glimpse of the fruits of our labor!