Organizations applying traditional system development techniques use business scenarios to describe user interactions with the system. Consequently, organizations applying object-oriented techniques in software development create use cases. Use case analysis explain the interaction between the user and the system in order to accomplish the user’s task.
In the requirements we show what the system should do. Additionally, use cases help us understand and clarify the users’ interactions with the system, or the system’s functionality in specific.
Instead of taking a traditional approach and ask users what they want the new system to do, use cases include drawing process models and data models which will help users understand what the system could do. Why we say could do?
Users may not know what is and what is not possible for the system to do. They are not likely to truly and fully understand the capabilities of information systems, especially when talking about new advances in technology. With use cases done successfully, they can understand all the tasks that they need to or should perform with the system.
Why use case analysis?
- They reveal detailed information about the functional requirements of the new system.
- They reveal exceptions and errors handling requirements in the new system.
Text-based use cases are easy for the users to understand and they also flow easily into the creation of process models and data models.
Each use case describes how an external user triggers an event to which the system must respond. Therefore, this is called event-driven modeling. Therefore, you should think of everything in the system as a response to some trigger event. Simple use cases may have only one path through them, while complex use cases may have several possible paths.
What elements does a use case have?
- Name and number: for identification;
- Priority: to indicate the relative significance of the use case in the overall system;
- Actor (user role): a person, software system, or a hardware device that interacts with the system;
- Events:that cause the use case to begin;
- A trigger (external trigger, or temporal trigger): cause for the event to happen.
Additional Use Case Issues
- Frequency of use;
- Business rules;
- Special requirements;
- Notes and issues.
Building Use Cases
In order to gather information for use cases you first have to set specific steps. Then write the activities which will help you achieve those steps.
- Identify the use cases.
- Set the major steps within each use case.
- Identify elements in each step.
- Confirm the use case.
The user–system interactions should be outlined as a series of steps. Also, each step should be about the same size as the others.
A word on events
The events suggest the primary things the users must accomplish with the system. The responses to that event describe the final results of the activities performed when the event occurs. You can group events logically in packages, such as: all use cases for sales, all use cases for customers, etc.
- Customer orders a new product;
- Expert assigns on a new project;
- Payment delivery is processed;
Before discussing about the steps, the analyst should ask the users what tasks need to be completed before the use case steps can begin. This helps clarify the necessary preconditions for the use case. It also defines the starting state of the system.
After use cases are done, process modeling can start. Read more about process modeling here.