Use cases: The ultimate guide

A use case is a tool that helps model user-system interactions. They are often misunderstood when they are used due to a lacking of understanding about how to implement them step-by-step. We tend to be broader in words when writing them which results in poor-software products. In this article, we will answer what a use case is, when to use it and when not to, how to use it step-by-step and give an example taken from Don Hussey’s website. Then, we give pieces of advice about common doubts. With that, I hope to enlighten the topic. Let’s begin.

What is it?

It’s a tool that allows us to describe interactions between users and systems.

When to use it?

✅ To model process-driven systems that are goal-centric and user-focused.
❌ Not suitable for data-driven products (you might use data-flow modeling).

For example, we might want to create software to automatize the application process students from X university go through for international exchange. We might find different actors like students, the head of the faculty that needs to sign your request after having been approved by a special commitee, the secretary that needs to send your data to the head of the faculty, the administrative that needs to update the offerings, and so on. Uffff, there are a lot of processes going on. Besides, each actor has specific goals that drive him/her to use the system so we must be focused on them to offer a valuable, useful, and usable product.

How?

Let’s recap. Before using the tool, we should have already defined our problem (the gap between the actual and desired state), the solution, the business requirements (what the business achieves from the solution), user requirements (needs from the user perspective), and functional requirements (specific things the system must do. You can use user requirements to derive it [see this]). Now, you are with your functional requirements ready to write your use case. Steps:

1. Identify the title (verb+noun) and its ID. Example: log in to the system, send forms, and so on.
2. Write a description of the title and its scope.
3. Define the actors involved. It’s someone/something that takes part in the use case.
4. Describe the simplest set of steps taken by the actors to achieve their goal (Basic Flow)
5. Indicate the alternate flow (alternative path for the actor to accomplish the goal). It always comes back to the basic flow.
6. Indicate the exception flows (paths where the actor’s goal is not met). The last line indicates the end of the use case.
7. Write pre-conditions. Describe the states that must be in place for the use case to begin
8. Write post-conditions. Describe the state that will be in place after the use case has finished.
9. Write triggers. Triggers are events that start the use case. Example: Secretary wants to sign up, it’s 1 am on Monday so the system must do a backup of all documents, students want to submit their documents for the application.

Example

The following is an example elaborated by Norwalk Aberdeen called Sample Use Case: Create User (find it here).

Use case: Create a user.

UC-7 is another use case that BF-1 is referencing so we don’t have to write all the steps to log into the system.

Alternate flows. Note that they always return to the basic flow

Exception flows. They always impede users from achieving their goal stated by the post-condition (create User)

Warning

💡The steps given, from 1 to 9, are a logical way to build your use cases, but the template might look different in terms of order. You might want to find your own order.
💡Your business rules shall be included in a different document. You can reference them by their ID in your use cases.
💡If you need to write something else that can not fit in the template, feel free to create a new section for it. After all, it’s just a template

Summary

A use case is a tool, just a tool, that allows us to model process-driven, goal-centered, and user-focused systems. I recommend focusing on those use cases that are truly important and necessary for the project. If you don’t have an idea where to start, prompt chatGPT to give you ideas about already existing systems where you can learn a lot. You don’t have to invent the wheel! Be pragmatic.

What’s next

Formulate your non-functional requirements. Be as specific as you can be while you have your requirement fresh. If you have many use cases, you can opt for drawing a use-case diagram to show the scope of your project which can guide you through the testing process. Besides, you shall draw an activity diagram per use case based on the flow specified. Afterward, you design your class diagrams, and your entity-relationship diagram for your database…