In an iterative development environment, you can select a subset of use cases and describe them in detail in each iteration. See Activity: Prioritizing Use Cases.
After finding the protagonist and use case, you need to explain the event flow of each use case in detail. These instructions indicate the way the system interacts with the protagonist and the related operations that the system performs in each independent use case.
Finally, review the completed use-case model (including use-case description), which developers and customers use to agree on what the system should do. 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:
The "small" use case, that is, the explanation of the event flow, has only one or a few sentences. "Multi" use cases, that is, the number of use cases is hundreds, not dozens. The construction of use case names 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 that can produce something valuable to the protagonist.
To avoid functional decomposition, you need to ensure that the use case model helps to answer the following questions:
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 system functional requirements. 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 concept: requirements). They usually specify requirements that need to meet any legal and regulatory requirements. They may also be design constraints caused by the operating system used, environmental platform, compatibility or any application standards adopted. Generally speaking, 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 from the characteristics of the use case. In this case, these requirements can be obtained in the event flow of the use case, or as special requirements of the use case (see Guide: Use Cases).
Example:
In the recycling machine system, a specific non-functional requirement for returning the use case of stored items is that the reliability of machine identification of stored items must be higher than 95%.
Usually, 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, the non-functional protocols applicable to the whole system are:
Only one user is allowed to use this machine at a time. It is difficult to learn how to determine at which level of detail a use case should "start and end". Where do functions and use cases start, where do use cases end, and where does design start? We usually say that use cases or software requirements should specify "what" of the system rather than "how" to do it. Take the following figure as an example:
One person's destination is another's starting point.
According to 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, which constitutes a complete event flow. "Finish" means that an instance of the use case performs all the operations called by the protagonist. The abstract use case itself has never been instantiated. The abstract use case is contained in other use cases (see guide: inclusion relation) and extended to other use cases (see guide: extension relation) or generalization relation (see guide: use case generalization relation). When a specific use case starts, an instance of the use case is created. This example also shows the activities specified by the abstract use case of the relationship. Therefore, individual instances cannot be created from abstract use cases.
Because the protagonist "sees" and starts a specific use case in the system, the difference between the two use cases is very important.
When pointing out that a use case is abstract, you can display its name in italic format. Example:
Create a task use case that is included in the registration form use case. Creating a 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 the registration form, an instance of the registration form will be created. In addition to registering the event flow of the 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 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 common behaviors described in many use cases. The use case model is easier to maintain.
However, modeling 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 full 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 use 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, and the execution of the use case is only determined by its result, not by the method of producing the result, then these functions can be separated and put into an additional use case. With the inclusion relationship, additional use cases can be explicitly inserted into the basic use case. 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, then this part can be separated 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 are similar in behavior and structure and in purpose, they can be separated 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.
The generalization relationship of protagonists can be used to express the specialization between protagonists. See also Guide: Generalization of the protagonist.
Example:
Take the use case model of order management system as an example to illustrate.
Because their characteristics are slightly different, it is very useful to distinguish ordinary customers from internet customers. But because Internet customers do show all the characteristics of a customer, you can say that Internet customers are a special case of customers, which can be expressed by the generalization relationship of the protagonist.
In this diagram, the specific use cases are "telephone subscription" (published by the customer protagonist) and "Internet subscription" (published by the Internet customer). These use cases are common "abstract use cases". The "Request Directory" use case represents an optional behavior part, 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 an independent behavior part. It is separated because it is an independent function, and only its result can affect the "order" use case. The use case of "providing customer data" can also be reused in other use cases. In this example, the "Request Directory" use case and the "Provide Customer Data" use case are both abstract use cases.
This use case diagram shows the user model part of the order management system.
The following table shows a more detailed comparison between three different use case relationships:
To make it easier to understand, another way to organize the use case model is to group use cases into multiple packages. The use case model can be organized into a hierarchical use case package structure, and the protagonist or use case is the "leaf" in this structure. See Guide: Use Case Packages. This diagram shows the hierarchy of the use case model. Arrows indicate that there may be ownership relations. The investigation description of the use case model should: state the main use cases of the system (the reasons for the establishment of the system). Summarize the important technical actual situation of the system. Represents a system boundary-an operation that the system will not perform. Outline the environment of the system, such as the target platform and existing software. Describe any use case sequence that is usually executed in the system. Explain in detail the functions that the use case model does not handle. Example: The following is an example of an investigation on the use case model of recycling machine: this model includes three protagonists and three use cases. The main use case is "recycling goods", which explains the main purpose of the recycling machine. Support use cases are: "Print Daily Report", which the operator can use to get a report on how many items have been recovered. Manage storage items, which can be used by operators to change the refund amount of storage item types or add new storage item types.