Methods for identifying use cases

Lecture




  Methods for identifying use cases Methods for identifying use cases

The use case can be defined as the activity of the system in response to an event. If so, how can the analyst ensure that all possible uses are covered? According to the approach of world-renowned IT guru Elister Coburn, the analyst identifies use cases with a test called “coffee break”. This means that as soon as the user has completed the precedent, he or she can enjoy the coffee break in silence without feeling remorse. However, in addition to this test, there are three more proven methods for identifying use cases. They are listed below.

Custom target method

This is a fairly obvious approach, which includes a dialogue with users, aimed at identifying their goals when working with the new system. As a rule, the analyst compiles a list of all interested parties (stakeholders) who will work with the given system with a sufficient degree of probability, then he carefully considers their roles and determines what they may need to perform their tasks.

By analyzing existing systems and polling users about how they would like to use the new system, the analyst can find a lot of precedents. Thus, use cases are both existing system functions and the first requested.

CRUD method

Another method for identifying use cases is the CRUD method (Create - Create, Read or Report - read or inform, Update - Update and Delete - Delete). In this case, the analyst identifies all the data elements that need to be processed by the system, and creates use cases related to creating, reading, updating, and deleting information elements. Below is a guide to using the CRUD method for an example of a site with the possibility of online ordering:

  1. Determine the data items to be processed by the system. They include information about the buyer, order, product and delivery terms.
  2. Examine each item and identify use cases that create data, read or inform about data, update and delete it.

CRUD analysis is as follows:

  Methods for identifying use cases

To create a use case diagram, associate each final use case with the appropriate actor and demonstrate the associations between them.

Event decomposition method

This method is based on identifying events (during a brainstorming session) to which the system should respond, and on determining exactly how the system should respond to the event. Here are some guidelines for using this method:

1. Present the system as a black box: what events should it respond to? This step will allow you to explore the capabilities of the system, without delving into its internal mechanism. Let's look at the recruitment system and identify events that can happen outside the system.

The candidate (external factor) can cause the following events:

  • Create a profile
  • Search for jobs
  • Fill out an application

In order for a candidate to perform the above tasks, the system must have the following functionality (use cases):

  • Recording Candidate Profile Information
  • Record existing vacancies
  • Reception of the filled application

2. Consider events triggered inside the system. If you go back to the above situation of hiring employees, you can cite the following examples of temporary events:

  • Time to update job list
  • Time to count bids received
  • Time to select received applications
  • Time to send the received applications to the relevant departments
  • Time to create summary posts.

The system should be able to respond with the following functionality (use cases):

  • Job List Update
  • Counting applications
  • Selection of applications
  • Sending applications
  • Creating a summary message

The analyst should focus on two distinct categories of events: caused by external factors and caused by internal factors .

For all types of use cases, it is best to focus on an appropriate level of detail based on the underlying business processes (elementary business processes). A business process is a task aimed at creating value for consumers, performed by one person at one point in response to a business event. Upon completion, the business process leaves the system in a consistent state. Although various methods have been proposed in this article, the list of use cases will be much more complete if you combine all the above methods.


Comments


To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

System modeling

Terms: System modeling