Use Case Analysis — A Case Study

Table of Contents hide

What are use cases?

A use case is a requirements capture and documentation technique that can be written in plain text to describe in a narrative manner the actions and interactions of participants using the system. Finally, the functionality of the system should satisfy the purpose for which stakeholders use the system.

Before using text to document a use-case description, we can first use a use-case diagram to highlight the purpose of the actor using the system. With graphical representation, you can quickly understand the whole picture from a bird’s eye view. Define the scope of the system (system boundaries) and identify the primary goals of the actors (called use cases) that support the use of system functionalities or services.

Use-case diagrams are good for team communication, and it’s a human nature: using graphics is often better than communicating through words.

After the team has an initial understanding and consensus on the overall look and feel of the system, the requirements analyst opens the oval — use case and describes the dialogue process between the actors and the system in a correct and easy-to-read format.

Gradually increase the precision of use cases from simple to complex. Don’t get bogged down in complicated details at first, lest you invest too much spirit in the wrong design and description. Use case diagrams help move from simple to complex and reduce unnecessary fallacies.

As can be seen from the figure, the design scope of this system is “online book ordering system”, one of the main participants using this system is “Online customer”, the purpose of the participants using this system is “order books”.

The “order books” is the use case for the system, and the actor is the “online customer.” After determining the purpose of the participants, we will record the details of the purpose in the text narrative, that is, record the interaction between the participants and the system operation to achieve the purpose. This is called use case description.

The following table describes a simple “Order books” use case.

Origin of Use Case

The use case was first published by software giant Jacobson in 1992, which had a considerable impact on modern object-oriented technology. In addition, the UML (Unified Modeling Language) specifications jointly formulated by the so-called “the 3 Amigos” — Booch, Jacobson, and Rumbaugh and have been reviewed by OMG have been included as an important part of the main standard specifications.

Here are the definitions of use cases by several software giants.

“A use case is a narrative document that describes the process sequence of an actor using the system to complete an event” [Jacobson92].
“A use case is a set of scenarios (flow of events), which are related to the common use purpose of the system” [Fowler97].
“A use case is a sequence of actions that an actor(usually a person, but perhaps an external entity, such as another system) performs within a system to achieve a particular goal” [Rosenberg99].
“A use case is an actor (usually a user, but perhaps an external entity, such as another external system), a series of actions to achieve a specific goal in the interaction with the internal system” .

In the book “The Unified Modeling Language User Guide”, the definition of Use Case is given:

“A use case describes a set of sequence, in which each sequence represents the interaction of the things outside the system(its actors) with the system itself (and its key abstractions)”.
“The use case describes a series of sequences, each of which expresses the interaction between things outside the system (participants) and the system itself (and its key abstractions).”

From the above discussion, we can get the characteristics related to the use case:

A use case is a narrative document described in natural language (such as narrative in English). Generally speaking, a use case does not involve graphics or programming language grammar (such as java) to describe.
The scenario described in the use case is exactly what the actors expect to accomplish (get) their goal (Goal) from the interaction and communication with the system.
For example, “Buy Items” is exactly the purpose of consumer consumption:
“Consumers check out the purchased goods, and the cashier records the purchased goods and collects the payment. Once completed, the consumer leaves with the goods.”
A use case can have a normal scenario and with multiple exception scenarios. The normal scenario describes the normal process of interaction between the participants and the system; while in the process of interaction with the system, if the occurrence of exceptions is taken into account, depending on the complexity of the situation, it can be described in the “alternative path” in the normal scenario” or it can be described in another scenario for complex exceptions.
The system will provide a series of functions to interact with the participants, but the participants do not need to know what is going on in the system or how to do it, the system only needs to send the results back to the participants. Therefore, for participants, the system is (or a group of use cases) a black box.
The description of the use case emphasizes what the system should do (what to do), not how to do it (how to do). Therefore, the details of the implementation should not be described in the description of the use case.
The actor directly comes to the operating system. In the use case diagram, although the actor is represented as a “stick figure” icon, the participant may not necessarily be a real person . The participant may also be an external system, and it may need to get some information from this system.

Use Case Analysis — A Case Study

What are use cases?

Origin of Use Case

Other UML Diagrams

Leave a Reply Anuluj pisanie odpowiedzi