This article will define a candidate use case and how to identify use cases.
It will identify the resources you can use as the source material to identify your use cases. It will also explain what techniques you can apply to generate source material.
Finally it will explain how you can validate your candidate use cases.
Some readers may be interested in a recommended use case training course
.
Table of Contents
Candidate Use Case Definition
A candidate use case is nothing more than a first guess at a use case that is relevant in the problem domain. It may ultimately remain or be rejected in consultation with the stakeholder(s).
You’ll also need to identify the actors alongside the use cases.
Candidate Use Case Context
The business analyst may be identifying candidate use cases in a number of different contexts:
- Existing business process is being changed for some benefit (e.g. cost reduction);
- Brand new system is being created in support of a new business or new business unit;
- New business process to satisfy regulatory changes;
- New business process to exploit an opportunity (e.g. provides an opportunity for profit);
- Existing system is being replaced by new technology platform.
This list is not exhaustive but should cover the majority of scenarios.
Source Material for Identifying Candidate Use Cases
There will be different source materials available depending on the scenario above:
- As is (current) business process and To be (future) business process;
- To be business process only;
- Existing system – training material, operational manuals.
In addition, in the absence of process documentation, and as a further aid in identifying candidate use cases:
- Scope document including high level functions or capabilities;
- Regulatory documentation;
- Marketing material describing opportunity.
As a general rule, larger organisations will have more source materials (sometimes too much!) and smaller organisations will have less. You may have next to nothing to work with – just a request from your boss to start working on a project.
Even if there is nothing immediately available, you must investigate to find source material that wasn’t immediately obvious. Talk to everyone who might know before you assume there is no more material.
Techniques for Generating Source Material
There are a number of techniques you can apply if you don’t have enough source material which describes the system:
- Interview users of existing system.
- Ensure you put the interviewee at ease – explain the impact of the proposed system. Ask open questions initially to understand behaviour at a high level. Ask more specific, closed questions to get more detail. Ask about activities that are undertaken to identify use cases and ask about the parties responsible to identify the actors.
- Observation of user(s) of existing system
- Interview subject matter expert for new business process
As you will have some information to start with, your questions may be more specific if the business process is quite detailed. - Workshop
Not recommended for generating source material as it can be hard work. Workshops are always best when you have a straw man or initial use case model that you can walk through
For all of these techniques, think about support activities (or use cases) – these involve anything that doesn’t involve the customer directly or involve problem resolution.
What happens when the customer calls to complain about the service/product?
What activities are necessary to monitor the service/product?
What happens when the service/product fails?
Are their activities which indirectly impact the product? (e.g. change in business policy)
Don’t forget to ask questions in these areas.
How To Identify Use Cases
Once you have your source material, it is relatively easy and to identify use cases for the use case model. You should always remember that a use case yields a result of observable value to a user. Either identify the actor and look for activities for which he/she is responsible or identify activities and then determine who is responsible.
The following details how you should search for candidate use cases and actors:
- Business process
Business processes consist of manual steps and automated steps – use cases will support automated business steps. The actor should be the individual executing the step (may be customer, may be employee). - Scope document, results of interview or observation
Capabilities or ‘functions’ may well be listed which suggest use cases. - Marketing material
Look for active phrases referring to individuals. e.g. You can receive SMS alerts from your bank at a time and frequency to suit you. - Training material/operational manuals for existing system.
Verifying Candidate Use Cases
The best method for verifying candidate use cases is a workshop where all interested parties (or stakeholders) are brought together and you walk through your candidate use case model. The use case model does not need to be complete at this stage as we are only trying to determine that we have all the use cases.
You will need the following:
- Use case diagram(s)
There may be several if it is too complex to show on one diagram. Try to group them in a logical way that is meaningful to the stakeholders; - Use case narrative for each use case;
- Use case narrative needs a name, brief description and basic flow at this stage. The basic flow need only illustrate the purpose of the use case – it does not need to be complete.
Conclusion
