Techniques for Identifying Use Cases
/A use case can be defined as an activity performed by the system in response to an event. How can the analyst ensure that all the use cases (system functionalities) are captured? An interesting approach by Alistair Cockburn suggests that analysts identify use cases with the “coffee-break test”. That is, once the user has completed a use case, s/he can take a coffee-break without feeling guilty... Beyond the coffee-break test, there are 3 recommended techniques for identifying use cases. They are discussed below:
User Goal Technique
This is a rather obvious approach that involves talking to users and getting them to discuss their goals for the new system. The analyst would typically list all the stakeholders who are likely to interact with the system, think through their roles and identify what they would need to get their work done.
By analyzing existing systems and asking users how they would like to use the new system, the analyst can come up with an array of use cases. Use cases are thus, a combination of existing system functions and newly requested functions.
**Check out Laura Brandenburg's training course on Use Cases and Wireframes.**
CRUD Technique
Another technique used for identifying use cases is CRUD, an acronym for Create, Read or Report, Update and Delete. Here, the analyst identifies all the data elements to be processed by the system and creates use cases that create, report on, update, and delete the data items. Here’s a guide to using the CRUD technique, using an online ordering website as an example:
- Identify the data items to be handled by the system. The data items involved relate to customer, order, inventory item and shipment.
- Examine each data item and state the use cases that create the data; read or report on the data; update the data; and delete the data.
Here's the CRUD analysis:
In order to come up with a use case diagram,
link each resulting use case to its corresponding actor and show the association between
the use cases.
Event
Decomposition Technique
This technique focuses on identifying (by brainstorming) the events that a system is required to respond to and then determining how the system must respond. Here are the steps for using this technique:
1. Think of the system as a black box - what events would it be required to respond to? This step allows you to examine the scope of the system without considering its internal workings. Let's take a recruitment system and identify the events that can happen outside it.
An Applicant (external) could trigger the following events:
- Create profile
- Search for vacancies
- Submit application
For the applicant to carry out the above tasks, the system must have the following functionalities (use cases):
- Record applicant profile information
- Record vacancies
- Accept submitted application
2. Consider events triggered inside the system. Still using the recruitment system as an example, temporal events could be:
- Time to update vacancies
- Time to count the number of applications received
- Time to filter applications received
- Time to forward received applications to their respective departments
- Time to produce summary reports.
The system must be able to respond with the following functionalities (use cases):
- Update Vacancies
- Count Applications
- Filter Applications
- Forward Applications
- Produce Summary Report
The analyst should focus on 2 separate events: those triggered externally and those triggered internally.
For all types of use cases, it's best to focus on the appropriate level of detail, based on elementary business processes (EBP) - An EBP is a value-adding task performed by one person in one place in response to a business event; it leaves the system in a consistent state after completion.
Though different techniques have been proposed, the list of use cases that can be identified would be much more comprehensive if all techniques were combined.
Download the CRUD Analysis Template in Excel
