Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
When we describe a use case scenario, we're typically looking at describing a goal that an actor can accomplish in a single encounter, and we're trying to stay focused on the user's goal, on their intention. So, for example, log in to application might first sound like a use case. It has an active verb, it typically has multiple steps, multiple conditions, you could forget the password or be required to register and so on. But if we emphasize the users focus their goal, we realized that their goal with our system is not to log in, the reason they want to log in is to do something.
So what is that something in your system? We're looking for something like Purchase items, Create new document, Balance accounts, these are user-focused goals, each with several steps that could be accomplished in one encounter. Logging in might be part of one of these use cases, part of one of these goals, but it's not a use case in itself. On the other side of the equation, a goal on the level of Write book or Merge organizations would be too broad. Those would involve multiple encounters with whatever application is used.
Now it is true that some people do define these broader and smaller use cases as a way of tying things together, but at least initially. You want to focus on the true user goal use cases, emphasizing the goal of one encounter. Now a simple casual use case can still have multiple scenarios. We've talked about the main successful scenario, that's the one you want to focus on. This is something referred to as the sunny day use case. What happens when everything goes right? But when necessary we describe the alternate paths or extensions.
So in the case of purchasing items we might have a couple of options for what happens when something is out of stock? What happens if the customer payment method is rejected? But you're not trying to envision all the bizarrely unlikely but technically possible events, just the typical situations that would occur and what you want to do with those situations. Again, you could write these as paragraphs, you could write these as numbered steps. We're going for readability and ease of use and ease of creation over formality.
When you're writing, use active voice, omit needless words, omit needless detail. It's very common to see sentences like the system is provided with the payments information and shipping information by the customer, but you could just as easily say customer provides payment and shipping information. Active voice, easier to read, short readable, concise. Another very common thing you'll see, particularly from programmers is there's too much detail. So the system connects to the external payment processor over HTTPS and uses JSON to submit the provided payment information to be validated.
Then waits for the delegated callback response. We're not trying to write pseudocode. This is too much detail. We need this System validates payment information. For a use case, that's absolutely fine. That's more than enough. When you're doing this focus on intention, keep the user interface out of it. A little earlier I had shown a numbered example of a purchase items use case, and even on the first two steps of the scenario, customer chooses to enter the checkout process, and customer is shown a confirmation page for the order allowing them to change quantities, remove items, or cancel.
Who does system administration? If this is a system that needs to be started and stopped or backed up at the weekend or have software updates applied, who does that and how do they interact with the application? Who manages users and security, particularly if you have role-based actors? What happens if the system fails? While the person who reacts to this may not be a classic user, they're certainly an actor. Is anyone looking at performance metrics or system activity or logs? And you will often find that these questions will actually prompt a couple of fairly obvious actors for your application, particularly if it's being developed internal to a company.
And if you're focusing on the actor's goal, the user's intention using active voice, writing short succinct descriptions of the scenarios, that's more than enough to move forward. Once you have a few use cases written, you may find it useful to look at a use case diagram to tie that together, and we'll cover that next.
Get unlimited access to all courses for just $25/month.Become a member
82 Video lessons · 103149 Viewers
61 Video lessons · 89816 Viewers
71 Video lessons · 73436 Viewers
56 Video lessons · 104986 Viewers
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.
Your file was successfully uploaded.