Before a project is undertaken, it is important to understand what is the use. One of my favourite quotes in IT is “Don’t pave the cow’s path”
What is a Use Case?
A use case is system responding to user’s needs. Think of it a user asking the system to do something. Think about the time when you praise or complain of a system’s functionality. That – is a use case.
An example of simplified use cases:
- User needs to access online banking (Online Banking System)
- User needs to look-up member information (Membership Look-Up System)
- User needs to process payments to vendors (EFT Payment System)
The simplest way to find out the system’s use case is to ask for User Stories.
What is a User Story?
A User Story is a one liner that describes a user’s work. It describes their goal of what they want to accomplish.
“As a teller, I want to look-up member information, so I can verify the member in front of me.”
Once the user story, the analyst can implement 2 techniques to fully understand the user’s needs. These techniques are: User Goal Technique and the Event Decomposition Technique
User Goal Technique
| User | User Goal and Resulting Use Case |
| Teller | Search Member |
| Look-Up Balance | |
| Process Bill Payments | |
| Admin Personnel | Generate Documents for Signing |
| Update Member Personal Information | |
| Track Signed Documents | |
| Mortgage Broker | Underwrite Loans |
| Submit Loans to the Credit Department | |
| Look-Up Interest Rates |
The purpose of the user goal technique is to understand user’s goals for using the new system. Basically, an expanded version of the user story.
The analyst identifies the users, categorizes the goals, and create a list to help guide in creating the system. It involves a structured interview with the different users.
User Cases and Event Decomposition Technique
Here, the analyst understands the user’s goal as usual. After that, the analyst will brainstorm what are the events leading up to it that involves the system. Once created, the analyst can narrow down the use case. Below is an example I’ve created for a billing system
| Event Name | Event Type | Use Case Name |
| Member sets up billing information | External | Update banking information |
| System charges member account based on member usage | State | Charge banking information |
| Member receive monthly billing statement | Temporal | Generate monthly invoice |
| Member’s payment declined | State | System prompts member to update banking information |
| Member makes late payment | External | Record late payment |
| Arrears exceed for more than 30 days | State | Suspend membership privileges ` |
| Member brings account to current | External | Return membership privileges |
3 Types of Events
An event is basically drives or triggers the system to do something. It can be broken in 3 types:
- External Event: It is initiated by an external actor. Think of it that a system remains in status quo, until an external force prompts the system to do something.
- A client placing an order
- A client making an advance payment
- Client booking a ride in Uber
- Temporal Event: Basically, the system is triggered in time. Think about the time you set a recurring reminder in your calendar. That is the same state event.
- Payroll processes EFT payments every 2 weeks
- Monthly reports being generated
- Credit card statements generated
- State Event: This event happens when something in the system triggers it. This can also be considered as internal event. Think of it as consequence of external events, but it cannot be defined a point in time.
- Adjusting available vehicles (Consequence of user ordering a ride)
- Adjusting inventory items (Consequence of user placing an order)
- Updating member balance (User paid)
Takeaway:
Understanding a use case will save so much time with building a program or a system. Without the end goal, the program runs a risk of wasting time and resources. Plus – the goal of any system is to better current process, and what better way to do that than talking to the people using it?
The Ouroboros Archive 
Leave a comment