Core Use Cases
In this series, we are focusing on creating a software system. This has many steps. We created a mental model. Next, we got an overview of the project. Then, we gathered requirements and built an epic-level backlog.
In this step, we are going to take those artifacts and break them down into core use cases for a system.
Why is this important?
When designing the project, we want to design for what truly makes this project unique. We usually don’t want to factor common things into the core design, such as authentication.
What are the core use cases?
The core use cases are what the system must do to differentiate it from other systems. A list of the core use cases should describe the system in a nutshell, almost the elevator pitch version of the backlog.
It can be difficult to describe things in the abstract. Often, it is easier to provide an example. If we are thinking about building an eCommerce solution, we would have a series of core functions to an eCommerce System, such as:
- View Products
- Edit Shopping Cart
- Submit an Order
- Fulfill an Order
- Process a remittance
- Process a return
Each core use case above would be unique to an eCommerce solution. An online Contact Relationship Management (CRM) probably wouldn’t have a core use case of “Submit an Order”. During this process, we try to identify the business’s unique and essential requirements.
Both an eCommerce solution and a CRM would have “Authenticate a User”. That use case is essential for the product. But that use case is pretty standard. We can probably build that feature using an off-the-shelf component. If we do authentication well, it probably won’t enable more sales on the eCommerce platform or more CRM system usage.
The core use cases are the things we want to make shine on this system. The parts that will enable the system to differentiate itself in the marketplace.
Questions will arise while doing this: When am I done? How do I know I have done enough?
My best advice is to avoid spending too much time on this phase. Spend an hour and make your best guess. Just be open to changing these as you develop your other artifacts. When working through your system design, you will realize that some of your core use cases were wrong or you missed some.
That is fine. Design is iterative.
