Users and any other systems that may interact with the system are the protagonists. Since the protagonists represent the users of the system, they help to define the system and provide a very clear description of its purpose. Write use cases according to the needs of the protagonist. This ensures that the system becomes the system that users expect. The protagonists and use cases are all found by taking customer needs and potential users as important information. After you find these use cases and protagonists, you should briefly explain them. Before detailing these use cases, the customer should review the use case model to verify that all the use cases and protagonists have been found and that they can provide what the customer needs.

in an iterative development environment, you can select a subset of use cases to describe in detail in each iteration. See also Activity: Prioritizing Use Cases.

after the protagonists and use cases are found, the event flow of each use case needs to be explained in detail. These instructions point out the way the system interacts with the protagonist and the related operations performed by the system in each independent use case.

Finally, the completed use case model (including use case description) is reviewed, and developers and customers use this model to reach an agreement on the operation that the system should perform. It is not uncommon that the degradation of use case model leads to the decomposition of system functions. In order to avoid this situation, we must pay attention to the following fault phenomena:

"small" use cases, that is, there are only one or a few sentences explaining the event flow. "Many" use cases, that is, the number of use cases is hundreds, not dozens. The construction of the use case name is similar to "perform this operation according to this specific data" or "perform this function with this data". For example, "inputting personal identification number into ATM" should not be modeled as a separate use case of ATM, because no one will use the system to only perform this operation. A use case is a complete event stream, which can produce something valuable to the protagonist.

To avoid functional decomposition, you need to ensure that the use case model helps to answer questions such as:

What is the environment of the system? Why build a system? What do users want when using the system? What value will the system create for users? It is not difficult to find that use cases are a good way to obtain the functional requirements of the system. But what about non-functional requirements? What are nonfunctional requirements and where can I get them?

non-functional requirements are usually divided into usability requirements, reliability requirements, performance requirements and replaceable requirements (see also concept: requirements). They usually specify requirements that need to meet any legal and regulatory requirements. They can also be design constraints caused by the operating system used, environmental platform, compatibility or any application standards adopted. Generally, any requirement that does not allow more than one design option can be considered as a design constraint.

many non-functional requirements are applicable to a single use case and can be obtained within the characteristics of the use case. In this case, these requirements can be obtained within the event flow of the use case, or as a special requirement of the use case (see Guide: Use Cases).

Example:

In the recycling machine system, a specific non-functional requirement for the use case of returning storage items is that the reliability of the machine in identifying storage items must be higher than 95%.

in general, functional requirements apply to the whole system. Such requirements can be obtained in supplementary specifications (see Workpiece: Supplementary Specifications). Example:

In the recycling machine system, a non-functional regulation applicable to the whole system is:

Only one user is allowed to use the machine at a time. It is difficult to learn how to determine at which level of detail use cases should "start and end". Where do features and use cases begin, and where do use cases end and design begin? We usually say that use cases or software requirements should specify the "what" of the system rather than the "how" to do it. Take the following picture as an example:

One person's destination is another person's starting point.

depending on your personal background, you can use different environments to determine your understanding of "what" and "how". When deciding whether a detail should be excluded from the use case model, it needs to be carefully considered. There is a difference between concrete use cases and abstract use cases. The specific use case is started by the protagonist and constitutes a complete event flow. "Complete" means that an instance of the use case performs all the operations called by the protagonist. The abstract use case itself is never instantiated. The abstract use case is included in (see guide: inclusion relation) other use cases, and extended to (see guide: extension relation) or generalization relation (see guide: use case generalization relation) other use cases. When a specific use case is started, an instance of the use case is created. This example also shows the activities specified by the abstract use case of its relationship. Therefore, individual instances cannot be created from abstract use cases.

Because the protagonist "sees" and starts specific use cases in the system, the difference between the two use cases is very important.

when indicating that a use case is abstract, you can format its name in italics. Example:

The "Create Task" use case is included in the "Registration Form" use case. The "Create Task" use case is an abstract use case.

in the warehouse management system, the abstract use case of "Create Task" is included in the use case of "Registration Form". After starting the use case of Registration Form, an instance of registration form will be created. In addition to the event flow of the registration form, this instance also follows the event flow described in the included use case "Create Task". The Create Task itself is never executed, but it is always a part of the Registration Form (or any other use case that contains the Create Task). Therefore, "create task" is an abstract use case. There are three main reasons for building a use case model:

Use cases are easier to understand. Separate the public behaviors described in many use cases. The use case model is easier to maintain.

however, building a model is not the first thing to do. Never build a use case until you have a deeper understanding of its behavior (rather than a brief explanation in one sentence). At least you need to establish a step-by-step description outline for the event flow of this use case to ensure that your decision is based on an accurate and sufficient understanding of the behavior.

there are three relationships that can be used to build use cases. You can use these relationships to analyze use case parts, which can be reused in other use cases or used as special cases or options for this use case. Use cases that represent modifications are called additional use cases. The modified use case is called the basic use case.

if there are some functions in the basic use case, whether the use case is executed or not is determined only by its result, rather than by the method of producing the result, then this part of functions can be separated and put into an additional use case. With the inclusion relation, additional use cases can be explicitly inserted into the basic use cases. See also Guide: Inclusion Relationships.

if a part of the basic use case is optional or unnecessary to understand the main purpose of the use case, you can separate this part to form an additional use case to simplify the structure of the basic use case. Using extended relations, additional use cases can be implicitly inserted into the basic use cases. See also Guide: Extending Relationships.

if use cases have similarities in behavior and structure and are similar in purpose, they can be separated from each other to form a basic use case (parent use case). Additional use cases (child use cases) can inherit the parent use case. A child use case can insert new behaviors or modify existing behaviors in the structure inherited from the parent use case. See also Guide: Use Case Generalization Relationships.

you can use the protagonist generalization relationship to show the specialization between protagonists. See also Guide: The Generalization Relationship of the Protagonist.

Example:

Take the use case model of the order management system as an example.

because they have slightly different characteristics, it is very useful to separate ordinary customers from Internet customers. However, because Internet customers do show all the characteristics of a customer, you can say that Internet customers are a special case of customers and can be indicated by the protagonist's generalization relationship.

in this diagram, the specific use cases are "telephone subscription" (issued by the customer protagonist) and "Internet subscription" (issued by the Internet customer). These use cases are all more common? An abstract use case. The "Request Directory" use case represents an optional behavior segment, which is not part of the main goal of the "Order" use case. It has been separated to form an abstract use case to simplify the "order" use case. The use case of "providing customer data" is a separated behavior segment. It is separated because it is an independent function, and only its result can affect the "order" use case. The "Supply Customer Data" use case can also be reused in other use cases. The "Request Directory" use case and the "Supply Customer Data" use case are both abstract use cases in this example.

this use case diagram shows the user model part of the order management system.

The following table shows a more detailed comparison among three different use case relationships:

Another way to organize the use case model is to group the use cases into multiple packages for easier understanding. The use case model can be organized as a hierarchical use case package structure, and the protagonist or use case is the "leaf" in this structure. See also Guide: Use Case Packages. This diagram shows the hierarchical structure of the use case model. Arrows indicate that there may be ownership relations. The investigation description of the use case model should: state which are the main use cases of the system (the reasons for the establishment of the system). Summarize the important technical actual situation of the system. Indicates system demarcation-the operation that the system will not perform. Outline the environment of the system, such as the target platform and existing software. Describe any sequence of use cases that are normally executed in this system. Explain in detail the functions not handled by the use case model. Example: The following is an example of the investigation on the use case model of recycling machine: This model includes three protagonists and three use cases. The main use case is "recycling item", which explains the main purpose of recycling machine. Support use cases are: "Print Daily Report", which can be used by operators to obtain reports on how many items have been recycled. Manage Storage Items, which can be used by operators to change the refund amount of a storage item type or add a new storage item type.