What is the difference between use cases and business use cases?

There are two important concepts in RUP, use case and business use case. People who are new to RUP often ask what a use case is and what is the difference between a use case and a business use case. The following is a brief description of use cases and the difference between use cases and business use cases. Use case, also known as system use case, is a method or form of software requirements definition. Compared with other requirements definition methods, the use case-based requirements definition method has the following characteristics: First, use cases define requirements from the perspective of users (actors) and emphasize users' goals, so it is easy for users to understand. Traditionally, requirements are defined according to characteristics or functions, which often means that the system must be this way or that way. For example, when describing an online bookstore system, the feature-based method will be described as: 1, and the system should provide search function; 2. The system must have classified browsing function; 3. The system must be able to calculate the final price according to the discount. System requirements are expressed in the form of isolated characteristics. If the system is relatively complex, users may ask the following questions: "What can the system do for me and how can it help me?" . The use case just answers this question. Define requirements in the form of use cases, and care about what users want to do with the system and how to do it. For example, what does the user do with the online bookstore system in the above example? Buy books! Well, buying books is one of the use cases Then, in the use case of book purchase, how users interact with the system and finally complete the book purchase process will be described in detail. The basic event flow is as follows: 1. The user wants to go to the online bookstore to buy books, and the use case begins. 2. Users browse the book classification and find books. The system displays books by category, subcategory and subcategory. 3. The user selects the books to buy and adds them to the shopping cart. The system records the books that have been added to the shopping cart and calculates the price. 4. When the user is ready to check out, the system prompts to confirm the shopping list, and prompts to enter key information such as bank account number and delivery address. 5. The user enters the above information and confirms it. The system completes the transaction and displays the transaction information. End of use case. Second, use cases are neither functions nor features, and use cases cannot be decomposed into smaller use cases layer by layer. The value of use cases is to show what the system can ultimately help users and how to do it. If we try to decompose the use case, who will take the responsibility? What are the advantages of the end result compared with defining requirements in a characteristic way? In FDD method, it is advocated to improve the feature-based requirement description method, and describe the requirements in the way of feature set, that is, to organize the features with strong task correlation together. In XP, requirements are described in the form of user stories, that is, how users use the system to complete tasks in a relatively random way. It can be seen that paying attention to the integrity of user tasks is not unique to use cases. It's just that the use case method is more formal.

Third, use cases mainly define requirements in the form of event flow, but it is not the only way. Use cases are highly formalized.

In addition to the main event flow, participants also describe who will use this use case. Preconditions describe the conditions or states that must be met to execute a use case. Postconditions describe what state the user should be in after successful execution. Special requirements will describe other functional or non-functional requirements related to use cases in a unique way, and general non-functional requirements are mostly. Compared with XP, FDD and other agile methods, the use case is more formal, the definition requirements are more rigorous, and of course it will take more time.

4. Use cases can only have one main participant at a time.

1. Students are ready to apply for financial aid, and the system prompts students to input information such as academic performance and family conditions.

2. Students submit the above information for approval.

3. The student financial aid approver examines the student financial aid application, decides to approve it, and the system prompts the examination and approval opinions.

4. Authorize the approver to enter the reason and confirm.

So where is the collaboration between participants described? We really need it. In fact, this is the responsibility of business use case implementation.

5. Use cases are not the only definition forms of requirements, they need to define complete requirements together with other definition forms of requirements.

Use cases have advantages over other requirements methods, but only using use cases can not effectively define complete requirements. Use cases mainly define functional and behavioral requirements, and the system still has many non-functional requirements to define, such as usability, performance, supportability and so on. It is not feasible to define these requirements in the form of use cases, and the best definition form should be characteristics.

In addition, some functional requirements may not be defined by use cases, such as service interfaces provided by the system. However, for a large number of requirements in middleware products that do not interact with participants, it is especially unsuitable to use use case definitions. Its requirements are defined in a way that uses features more appropriately.

What are the use cases described above and what are their characteristics? In practice, there are always people who can't distinguish use cases from business use cases. Business use case is a continuation of the use case idea, but it changes the usage situation. Use case is to define the requirements of "software system" from the user's point of view. Business use cases do not study the requirements of "software systems", but care about what services a "business organization" provides to the outside world. If the housing provident fund center is a business organization, you may be a business participant (if you are going to apply for a housing provident fund loan). Then handling housing provident fund loans is a business use case. What will this business meeting describe? It will describe something similar to the following (for illustration only due to its complexity):

1. Employees prepare relevant materials and apply for payment at the housing provident fund center. The business use case begins.

2. The employee submits the loan preparation related materials to the center, and the center staff conducts a preliminary review of the materials.

3. If approved, the employee is ready to handle the mortgage contract, and the center staff entrusts the guarantee company to sign the mortgage contract with the employee.

4. After the guarantee is completed, the employee signs a loan contract with the center, and the center staff requires the employee to apply for a bank card and provide the card number.

5. After the loan contract is signed, the staff of the center requires that the loan contract must be notarized, and the staff and the center should notarize it together.

6. After the employee completes notarization, the center issues loans. End of business use case.

It can be seen that the business use case here describes the process of how business participants (employees) use the services provided by business organizations (centers). So a business use case is actually a business process. It defines the services provided by a business organization from the perspective of business participants outside the business organization. Of course, business use cases also include some internal processes, which may not be initiated by business participants, such as purchasing processes. Therefore, business use cases only use the ideas and forms of use cases, and the research topics are completely different. Use cases study software systems and define software system requirements with the help of use cases. Business use cases study the target organization, and with the help of business use cases, define what business processes the target organization should have and what these processes should look like.