Use cases

- After hashing out the feature focused requirements that say what the system or application must do, it's time to shift focus towards the user and how they accomplish a particular goal, and one way to capture that is as a use case. There isn't a single right way to write use cases, and they could be written at several levels of formality. But at the very least, a use case needs three essential things: a title that describes a goal, the person who will interact with the application to achieve that goal, referred to as a primary actor, and the execution flow, or steps needed to accomplish the goal, the success scenario here.

The title for a use case should be a short phrase with an active verb that describes a goal. - Well, as an astronaut, my first goal would be to heat up a delicious meal package. - A title for that use case could simply be Heat Meal. - What if I want to set a timer to heat that meal package later so it'll be ready when I return from my space walk? - I'd call that Heat Delayed Meal. We want to keep titles short and simple. Both of those examples could be separate use cases, separate distinct goals for the application.

Now, in regards to the actor, the reason that we say actor rather than generic user is because we often need to identify exactly who is having this interaction. It could be a user, but it could also be someone more specific, customer, employee, or administrator. - So the actors are all of the humans that could interact with and use the program. - Not just humans, any external entity that acts on the system is an actor, including other computer systems. Now, the real meat of each use case lies in the scenario, the details for accomplishing the goal.

One way to write the scenario is as a single paragraph, like this one for the Heat Meal use case. It starts with the astronaut inserting the meal package, the system identifying the package, heating it up for the correct amount of time, notifying the astronaut that it's ready via space pager, and finally, the astronaut returning to remove the hot meal package. The aim is to write this so it's short and succinct, using everyday, non-technical language so it can be understood by a typical user of the application.

Another way to format this scenario is as a numbered list of individual steps. So, step one, the astronaut inserts the meal package. Step two, the system identifies the type of meal, and so on. There's not a hard and fast way to write these. I can use different phrasing or different levels of detail. Really, it's whatever makes sense for the situation. - That example describes a normal successful scenario where everything works as expected, but I know if something can go wrong, it will.

So how do you capture that in a use case? - Well, use cases are typically written to describe successful operations. But depending on the situation, you can also add extensions or steps for alternative flows, for what happens when things go wrong, like when the system can't identify the meal package, or it has trouble accessing the space pager system. And if it's more useful, you can add other specific details about the scenario. One common example would be a precondition that must be true to begin the use case.

Here, to heat a meal, our precondition would be that an astronaut has identified at least one package to cook. That's the only way this use case makes sense. Now, you can take it all the way to what's called a fully dressed use case by adding even more fields for post-conditions, secondary actors, stakeholders, and so on. These often exist as a PDF or Word template that you can fill in. - That just went from simple to complicated real quick. - And that's something to watch out for.

Formality often sounds like a good idea, but requiring that level of detail can kill progress. If you're managing a large, formal project with team members spread across the globe, then maybe you need fully dressed use cases. But for most projects, it's much better to have a set of readable, casual use cases than a collection of super formal, multi-page templates that never get completed. - It sounds like you could easily get bogged down writing use cases. - As a rule of thumb, you shouldn't spend more than a few days working on use cases in any iteration of a project.

Get 'em done so you can move forward onto the next phase. You may have to make some assumptions if you don't have all the information at this point, and that's okay. The use cases may evolve or change. If you're interested in diving deeper into the world of use cases, Alistair Cockburn's Writing Effective Use Cases is the book on the subject, with terrific examples, common mistakes to watch out for, and discussions on writing style.