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.

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.

Scenario

One way to write the scenario is as a single paragraph, 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.
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.

One common example would be a precondition that must be true to begin the use case. 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.

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.

Use case diagram

The use case diagram is another diagram that comes from UML, but the name can be a bit misleading. It sounds like a diagram of a use case, but in actuality, it’s a diagram of several use cases and multiple actors at the same time. It shows the relationship between the actors and the different use cases in which they’re involved. Now, this is not a substitution for written use cases. We definitely still need those. Use case diagrams and written use cases are two distinct products that show different perspectives and compliment one another.

Also, this diagram is not referring to a specific sequence that the use cases need to be executed in, so there’s no order that they need to be listed. It’s meant to be a simple overview of the relationships between multiple use cases and multiple actors at the same time, without the details of each particular written use case. It can be useful as a communication tool, even with business users, because it’s not particularly technical. It can be helpful to figure out if something is missing from the picture.

User Story

Also, this diagram is not referring to a specific sequence that the use cases need to be executed in, so there’s no order that they need to be listed. It’s meant to be a simple overview of the relationships between multiple use cases and multiple actors at the same time, without the details of each particular written use case. It can be useful as a communication tool, even with business users, because it’s not particularly technical. It can be helpful to figure out if something is missing from the picture.

Even though they’re concise, user stories generally follow a format that looks something like this. As a, type of user or role, I want, here you describe the goal, so that, the reason or the benefit. The final part, the so that, is optional, but it’s very useful to provide context on how this application will be used.

These are intended to be quick, readable summaries of a specific goal and why the user wants it. They can be done very early on, often right at the start of a project and they serve as a placeholder for deeper conversations that you need to have.