UML: Business Use Cases

A Business Use Case defines a group of business use case instances. The business use case has a name.

A Business Use Case instance is a series of actions performed in the business. These actions generate visible and valuable results for the individual protagonists of the business.
 
A business process is defined as several different business use cases. Each business use case represents a specific workflow in the business. Business Use Cases determine what will happen when the business is executed. They describe the execution of a series of actions that will generate valuable results for specific business leaders. Business processes generate value for businesses or reduce business costs.

Visitors can travel alone or with the tour group's tour guide. When traveling with a tour group, tourists will be guided by tour guides.

Business Use Cases describe "a series of actions executed in the business, which generate visible results for the individual protagonists of the business ". Therefore, from the perspective of individual protagonists, Business Use Cases determine a complete workflow that can produce expected results. This is similar to what we often call "business process", but "Business Use Cases" have more precise definitions.

The definition of the business case concept includes many keywords that are very important to understanding the business case:

Business Case instance-the above definition is actually a specific business workflow, that is, an instance. In fact, there are a lot of possible workflows, and many of them are very similar.
To make the business case model easy to understand, a similar workflow can be formed into a business case (a "class" according to the object model "). Determining and describing business use cases refers to determining and describing Business Use Cases with class characteristics, rather than a single use case instance.

The individual protagonist-the main character may be the key to finding the right business case. Starting from the individual protagonist (actually starting from the master instance) can help us avoid too large or too complex business use cases.
When determining the appropriate role, first specify at least two or three persons who can take the role discussed, and then strictly assess what support each person needs. For example, assume that you have initially identified a main character named "customer. Then, as you carefully examine the support required by each customer, you may find three different customers: General "users", "purchasers", and "evaluators" of the product ", they can compare products with other similar products. Each customer needs a separate business use case because they represent different roles acting on the business.

Result with visible value-this expression is very important for determining the scope of the correct business case. The scope cannot be too small or too large. Specify that the business use case should give a result with visible value (that is, it can be felt and can be evaluated), which can help you find the complete process and prevent the business use case from being too small.
A good business use case can help the main character to execute tasks with identifiable values. It may determine a price for successfully executed Business Use Cases. A small business case is less likely to be rebuilt due to limited scope.

In the business-"actions performed in the business" means that the business provides the business use cases to the main character, and the Business Use Cases only include the actions actually executed in the business. The support work conducted elsewhere is not included.

Action-an action is a request sent by the main character to the business, or called at a specific time. Actions include internal activities and decisions, as well as requests to the called main character or other main character.

Business services are described using different business use cases. Each business use case has its own task. A collection of these business cases makes up all possible methods for using the business. For more information, see Guide: Business Case model.

I. Business Use Cases and Business Use Cases

In a case-driven business modeling project, you create two business views.

The business use case itself shows the external view of the business, which determines what the key is to be executed in order to deliver the expected results to the main character. At the same time, it also determines the interaction between the business and the main character when executing the business case. This view must be created when you determine and agree to the work of each business case. This series of business use cases describe the overview of the business and are useful for employees to understand which different parts of the business are executed and the expected results.

On the other hand, the business case implementation provides an internal view of the business case, which determines how to organize and execute the work to obtain the expected results. The implementation includes the Business Roles and business-oriented entities, which involve the execution of business cases and the relationship between the business roles and business-oriented entities required to carry out the work. This view must be created to determine and agree on how to organize work in each business use case to get the expected results.

The two business case views are oriented to the personnel-External view in the business for the use of exceptional personnel, while the internal view for the personnel in the business case.

Ii. class and business case instances

As the business goes on, you will find that the number of separate workflows that can be determined is almost unlimited. A Use Case instance is only a specific workflow (scenario ). It corresponds to (executed by a large number of cooperative business members according to the roles defined in the object model), rather than a specific business member, or the role played by the members.

Business Use Cases are usually used to use the case model for ease of understanding, while avoiding excessive details. It represents a group of business case instances that have similar but not identical workflows.

Generally, an employee who can assume a specific role plays a role in multiple business use case instances.

Example:
At the airport registry, individual registration (individual check-in) and group registration (Group Check-in) business use cases have the same requirements on the competence of registry employees, in addition, the two service cases access the same departure information. Therefore, two use cases can and should use the check-in agent role and departure entity of the same registry.

Iii. Scope of Business Use Cases

Sometimes it is difficult to determine whether a service is a business case or multiple business cases. Apply the definition of business cases in the airport registration process. A passenger handed the air ticket and luggage to the registry service personnel. He found a seat for the passenger, printed the boarding pass, and started to process the luggage. If a passenger carries normal luggage, the Registry Service personnel will print the luggage tag and the pick-up card of the passenger's luggage, attach the luggage tag to the baggage, and finally hand the luggage receiving card and boarding pass together with the passenger, to complete the business use case. If the luggage is in a special shape or is loaded and cannot be transported by normal luggage, the passenger must send the luggage to the special luggage Desk. In case of heavy luggage, passengers must go to the airport ticket service to pay the fee because the registry service personnel are not responsible for the fee.

Do you want to set up a business case for the Registry, special luggage Desk, and ticket office? Or you only need one business use case? Indeed, this process involves three different operations. But the question is, is each operation meaningful to passengers carrying special luggage? Of course not. It makes sense only for a passenger to complete the whole process (from arriving at the registry until he has paid the extra baggage fee. Therefore, the entire process involving three different Counters is a complete Use Case.

In addition to this standard, another practical method is to put together descriptions of closely related services so that you can review, modify, and test them at the same time and write a manual for them, and manage them as a unit.

It is worth noting that two independent business use cases may have similar beginnings.

Example:
In an insurance company, both the "claim processing" and "warranty handling" business cases start with the contact between someone (the main character) and the Application handler. The application handler exchanges information with the main character to determine whether the other party needs compensation or insurance consultation. Then, only at this time can you determine which business use case should be executed. Although two business cases have similar beginnings, they are independent of each other.

Iv. Name

The name of the business case should be able to describe the situation that occurs when the business case instance is executed. Therefore, the form of name should be active, usually using the verb's dynamic noun form (checking-in) or simultaneously using the verb and noun.

The name can also be used to describe the activities in the business case from an external or internal perspective, such as "order" and "receive order ". Although Business Use Cases describe what happens in a business, they often name business use cases from the perspective of the main character. Once the naming method to be used is determined, the same rules must be followed for all business use cases in the business model.

V. Objectives

The purpose of the business use case should be explained in at least two aspects:

Specify the value (external goal) They expect for business leaders that interact with business processes ).
From the perspective of the organization that uses the business process, clarify the purpose of developing the business process and the goal (internal goal) to be achieved through the process ).

Vi. performance objectives

The most common classification indicators are:

Time-the approximate time required to execute a workflow or part of a workflow.
Cost-the approximate cost required to execute a workflow or part of a workflow.

It is difficult to understand which scenarios (business case instances) are related to evaluation. The criteria can be the frequency of use of the scenario, or the business relevance of the scenario. If you can determine the important part of the workflow, you only need to evaluate the cost or time of the branch stream, which can reduce a lot of workload.

VII. Workflow-structure

Most workflows can be viewed as composed of multiple branch streams, which constitute the entire process. Sometimes, multiple business use cases in a business have a common branch stream, or different sections of the same branch that flow out of a business use case. If such common behaviors occur frequently, the same role should execute them.

If a branch stream has actual content and is public to multiple business use cases and forms an independent part of a natural demarcation, this behavior should be separated as an independent business use case, this will make the model clearer. In this case, the new business use case is either included in the original use case (see Guide: include relationships in the Business Use Case Model) or extended original use case (see Guide: the extended relationship in the business case model) is either the parent case of the original case (see Guide: General Relationship of Use Cases in the business case model ).

Example:
In the airport registry, individual registration and group registration use cases use the same process to process the luggage of individual passengers. Because the branch stream is logically associated with ticket handling, the branch stream is modeled separately in the baggage handling business case.

You can use the activity diagram to visualize the workflow of the Business Use Case. See the activity diagram in the Business Use Case model.

For more information about how to build and describe the workflow of a business use case, see the "event stream" discussion in the use case.

8. Workflow-Example

An organization sells a specially configured solution to a single customer. The following describes the workflow in its "bidding process" business case. In the "examples of use" section of the activity diagram in the business case model, you can find an activity diagram example that visually shows the structure of the workflow:

1. Basic Workflow

1.1. Initial Contact

This process begins with initial contact between the customer and the company. Initial contact may take one of the following methods:

The customer contacts the company to ask questions or make a series of demands.
The company determines that its products can create value for customers and generate revenue for the company.
 
The company contacted the customer to determine:

Customer contact,
Company contact,
Whether the customer is a new customer of the company,
All bidding competition information related to this agreement.

1.2. Initial job opportunities

This part of work has two main purposes:

Collect customer requirements,
Determine further actions on this opportunity.
Initial collection of customer requirements, development of sales plans (optional), opportunity analysis steps can be performed in an iterative manner, and sometimes in parallel.

1.2.1 Collect customer requirements

Collect product requirements and customer business requirements using the following methods:

Ask the customer
Consider all customer input
Conduct preliminary on-site investigation (optional)
Study all available customer information

A set of requirements should include:

Technical options (customers may have multiple options if they want to study multiple alternatives)
All product preferences
Functional requirements (Market Analysis)
Build structure and environment features
Count statistics
Mobility/Capacity
Network growth prediction
Basic Information
Timeline
Service requirements
Price demand

1.2.2 prepare a sales plan (optional)

The company cooperates with the customer to determine how to propose a solution to meet the customer's needs. Develop sales plans, including the current network of potential solutions and conversion features. We also need to discuss the company's strategic positioning and network conditions so that we can prepare for further needs.
Then, review the sales plan with the customer to ensure its accuracy and completeness. This plan will play a guiding role throughout the bidding process to help identify the product, market packaging or product category items to be recommended, and to sort out the assumptions to be made in the bidding documents.

1.2.3 opportunity analysis

The company will obtain information about the high price and cost of potential solutions. This is done to understand the potential value of this opportunity, rather than providing a precise quotation for the customer.
Then the company considers the customer's needs to determine:

Risks in opportunities (product availability, competition, customer risks)
Cost and income comparison
Opportunity Type (simple and complex)
Sales possibilities
Approximate sales volume
Approximate timetable
 
Based on these estimates, the company makes a decision on whether to continue this opportunity.

1.3. Formulate the bidding project plan

The company will develop a plan to develop and submit bids. The plan should include the assignment of work in each part of the bidding.

1.4. Develop Delivery Project Plan

Based on the following information, the company will develop a tentative project plan for delivering the solution:

Deadline in customer demand
Resource availability
Production capacity
Availability of New Products
Availability of third-party products
This project plan will be used to prepare future production plans.

In addition, this project will be updated and modified in the "quotation process.

1.5. Prepare the quotation

This step is described in detail in the "quotation process" of the business case.
A well-designed solution should be provided at the end of the "quotation process. This solution may have different levels of certainty and offer prices.

1.6. Edit Other information

The company edits information to answer all customer inquiries (these inquiries usually involve future product development, which may be part of the customer's business needs ). This information also includes information that the company deems the customer to be aware. Queries are generally divided into the following types:

Technology
Current Performance
Future Performance
Compliant with standards
Meets future standards
Current Service
Services to be provided in the future.
 
1.7. Analyze and complete the bidding documents

The company has edited the bidding documents, including the following information:

Quotation
Existing market Materials)
Product Information (existing)
Financial Terms
Progress Information
Financial analysis and summary based on the bidding documents
Responsibilities and penalties of customers and companies
Legal "environment" Statement
All assumptions made when formulating the solution in the tender documents
The company edits the information as a tender document to be presented to the customer.

1.8. submit a tender document

The company submits or submits the above information to the customer.

1.9. Obtain Customer Decision-Making Information

The customer will provide feedback on the bidding documents. The company is recognized by the customer for the quotation in the bidding documents. According to the characteristics of customers and solutions, such recognition can be in a variety of forms.
It may be:

A signed purchase order
Verbal agreement that a customer will issue a purchase order
A signed contract
A verbal agreement

If no decision is made within the validity period, it is deemed as a rejection

2. Alternative Workflow

2.1. Discard business opportunities

In section 1.2, If you discard the business opportunity, you can take the following measures:

Give up
Try to work with other suppliers
Redirect to other fields
Forward requests to other dealers/suppliers
Try to change customer requirements
 
2.2. Unable to meet customer needs

If the company cannot propose a solution to the customer's needs during lead analysis or quotation preparation, the following measures may be taken:

We recommend that you use a device from another vendor.
Reevaluate customer requirements
Contact the company for information about future products
Try to change customer requirements
Decide to develop new products
Seeking joint venture partners or suppliers
Seek other financing methods
Different discount Methods

2.3. Unknown key information

If the company finds that some key information is unknown or cannot be obtained in the bidding process, the following measures can be taken:

Obtain this information
Make assumptions and continue

If assumptions are made, the assumptions must be recorded and handed over to the customer as a document attached to the bidding documents.

2.4. New, incomplete or incorrect General customer profile

If the company determines that the general customer profile is inaccurate due to some reasons, the following measures can be taken:

If it is a new customer, negotiate with it to reach an agreement
Include/determine customer preferences
Determine the installed information library
Request to update the record

IX. Possibility

The possibility of business use cases should reflect the potential for improvement in the process and scale of business use cases. Refer to the business case indicators you specified.

10. Expansion points

The expansion point makes it possible to expand business use cases. It has a name and a group of references to one or more locations in the workflow of a business case.

For more information, see Guide: extended relationships in the business case model.

11. Features of Good Business Use Cases

Its name and brief description are clear and easy to understand, even for people outside the business modeling team.
From the external (that is, the main character) perspective, each business use case is complete. For example, an insurance company's "claim processing" business case starts when a customer submits a claim. If it does not include a notification from the insurance company to the customer regarding the decision to handle the claim or (where compensation is agreed) the payment of insurance compensation, then, the "claim processing" business case is incomplete.
Each business use case generally involves at least one leading role. Business Use Cases are started by the main character, and activities are completed and results are delivered through interaction with the main character.
The supported use cases may not interact with the main character, but this is not common. If the business use case is started by an internal event and does not have to interact with the main character to complete the activity, the preceding situation may occur.

12. Features of good workflow description
 
The description must be clear and understandable, even for people outside the business modeling team.
Describe the workflow, rather than simply describing the purpose of the Business Use Case.
Only describe internal activities of the business.
Describes all possible activities in a business use case. For example, what happens when a condition is met or not met.
Do not mention those protagonists that do not communicate with each other. If other leading roles are mentioned, the description is more difficult to understand and maintain.
It only describes activities that belong to this workflow and does not involve activities in other parallel Business Use Cases.
Unrelated business use cases are not mentioned. If a business case requires that a certain result must exist in the business before the business starts, it should be described as a precondition. However, the pre-condition description should not involve the business case that generates the result.
If the activity sequence in the business case is not fixed, this point should be pointed out in the description.
It is easy to read and understand.
The description clearly describes the start and end of the workflow.
Clearly describe each extension relationship, so that the method and time for inserting business cases are obvious.

13. Features of good abstract Business Use Cases

Substantive. Remember that the specific business use cases and their abstract business use cases must be easy to understand. Therefore, an abstract business use case should not be too small. If an abstract business use case is not substantive, you should delete it, and its activities should be described in the affected business use cases.
It contains logically related activities.
It exists for a specific reason. An abstract business use case should include any of the following three types of activities: activities commonly used by multiple business use cases; optional activities; or activities that are very important and need to be emphasized in the model.