Use case analysis

A lot of people in the analysis of demand, the use of the East pull gourd West pull Scoop way, listed a lot of demand points, but when you read, you still do not know what to do!! ----written in front.

Use cases, English names using case, English and Chinese are very good understanding, because everyone is so used, we will not pursue the name of the problem, as long as we know "use cases are used to describe the requirements of the process", that is: describe how in the 5w1h.

It seems that use cases should be very well written, because use cases are the process of describing requirements, and the process of demand is usually summed up by customers according to their own business, and then told to us. It's easy and easy to keep a record of what the customer describes.

But there is always a gap between the reality and ideals, you may encounter a business is not very familiar with the customer, or you communicate with the person is a temporary customer, and you may communicate with the person immediately to Hugh marriage leave, he will not be quick to finish this boring thing ... In short, a variety of situations can occur, that is, the perfect situation will not appear!

In this case, how can we do a perfect analysis? How do we know if our analysis is correct, whether we have missed it, or is it enough?

In general, the company responsible for demand analysis personnel are senior staff, on the field, the system has a certain accumulation and experience, even in the face of these situations, can also be made up through their own experience.

But for a rookie, what should you do when you encounter this situation? Can't the rookie do the demand analysis?

Don't panic, rookie. Although there is no experience, but as long as the correct method, the same can make a good demand analysis, this is my summary of Use Case trilogy method, or called Nea method.

I summed up the use case method of the three-segment method (Nea method):

1) Normal processing: Communicate with customers and analyze the normal flow of requirements;

2) exception Handling (Exception): In the normal process steps, analysis of each step of the various anomalies and corresponding processing;

3) Alternative Treatment (alternative): In the normal process steps, analyze each step to see if there are alternative methods, and how to do the alternative method;

After this simple three-step, how can be said that the analysis is sorta.

"Specific wording of use cases"

Before we learned 518 requirements analysis method, and a complete use case, just reflects the 518 requirements analysis method involved in the content.

A complete use case should contain the following sections:

"Use case name"

In general, the name of the use case is the name of the requirement.

Scene

The scenario is the context in which the use case occurs, which corresponds to 3 w:who, Where, when in 5W

"Use case description"

Describe the detailed use case content, corresponding to what and how in 5W, what the user should do, and the output in each step. But does not require each step must have the output, can have or can not, also can have multiple.

"Use case value"

Describe the customer value of the use case corresponding to why in 5W.

"Constraints and Restrictions"

The constraint and constraints associated with the entire requirements process, corresponding to 8 C in the 518 method.

Let's look at a simple example: a pos machine.

"First step: normal handling"

"Use case name" Pay Scene Who: Customer, cashier Where: The cashier at the store When: Opening hours "Use case description" 1. The customer carries the selected goods to the cashier; 2. The cashier scans the barcode of goods one by one, and the system inquires the commodity information according to bar code; 3. After scanning, the system displays the total merchandise, the cashier tells the customer the total merchandise; 4. The customer gives money to the cashier; 5. The cashier counts the money, enters the amount received, and the system gives the number of change; 6. The cashier will return the change money to the customer, and print the small ticket; 7. The purchase is completed, the customer carries the goods and the small ticket leaves; "Use case value" After customers buy a single, they can carry the goods away, and supermarkets will receive income; "Constraints and Restrictions" 1. POS machine must comply with GB XXX; 2. The keyboard uses Chinese, because the cashier is Chinese; 3. The amount of one purchase cannot exceed 99999RMB; 4. POS Confidential is very stable, at least one day do not fail;

"Step Two: Exception handling"

On the basis of the first step, we increase the exception description and processing of the relevant steps, such as the following boldface characters:

"Use case name" Pay "scene" Who: Customer, cashier Where: Shop cashier When: Business hours "Use case description" 1.  the customer carries the selected goods to the cashier; (This step is no exception) 2.  The cashier scans the barcode of the product one by one, and the system inquires the product information according to the barcode; 2.1  scanner is broken, you must support manual barcode entry; 2.2  the barcode of the product cannot be scanned and must support manual barcode entry; 2.3  Barcode can scan, but no information, need to communicate with the cashier and customers, to abandon the purchase of this product 3.  Scan completed, the system displays the total amount of goods, the cashier told customers the total amount of goods; (This step is not an exception) 4.   customer to the cashier; 4.1  customer is not enough money, customer and cashier to communicate, delete a product ; 4.2  customer's money is not enough, customer and cashier communication , delete one or more of a class of goods (for example, buy 5 packs of cigarettes, remove two packets) 4.3  customers feel that a commodity is too expensive to delete a product; 5.  The cashier counts the money, enters the amount received, and the system gives the number of change; (no exception for this step) 6.  The cashier returns the change to the customer and prints the small ticket; 7.  The bill is completed, the customer carries the goods and the small ticket leaves; Use case value When the customer buys the order, they can leave the goods and the supermarket will receive the income; "Constraints and Restrictions" 1. pos machine must comply with GB XXX; 2.  The keyboard uses Chinese, because the cashier is Chinese; 3.  The amount of the purchase should not exceed 99999RMB; 4. pos is very stable, at least one day do not fail;

Some people may think that the 3rd, 5th and 6th steps should be abnormal, such as the system is bad how to deal with.

But in fact, we do not need to write this, because the purpose of use case analysis is to analyze in detail in order to achieve customer value, the system should do, if the system itself is bad, this is not a use case to focus on the content.

It is important to note that "exception" in use case analysis refers to the exception of the process, not the exception of the system itself.

"Step Three: Alternative handling"

On the basis of the second step, we add alternative treatment. That is, some steps can be implemented in a different way. For example, the following use cases in the payment method, you can have credit card payment, membership card payment, shopping card payment and so on.

"Use case name" Pay Scene Who: Customer, cashier Where: The cashier at the store When: Opening hours "Use case description" 1. The customer carries the selected goods to the cashier; (This step is not an exception) 2. The cashier scans the barcode of goods one by one, and the system inquires the commodity information according to bar code; 2.1 The scanner is broken, you must support manual barcode entry; 2.2 The barcode of the product cannot be scanned, must support manual input barcode; 2.3 Barcode can scan, but cannot query information, need cashier and customer communication, give up buying this product 3. After scanning, the system displays the total merchandise, the cashier tells the customer the total merchandise; (This step is not an exception) 4. The customer gives money to the cashier; 4.1 Customer's money is not enough, customer and cashier communicate, delete a product; 4.2 The customer is not enough money, the customer and the cashier to communicate, delete one or several of the goods (for example, buy 5 packs of cigarettes, remove two bags) 4.3 Customers feel that the price of a commodity is too high to delete a product; 4-a: customer pays with credit card 4-a.1 Credit Card Payment process (please think the reader self-improvement, can be written here, if too much, you can also write a sub-use case) 4-b: customers use shopping cards to pay 4-b.1 Shopping Card Payment process 4-C: Customers use loyalty card points to pay 4-C.1 Membership Card points payment process 5. The cashier counts the money, enters the amount received, and the system gives the number of change; (This step is not an exception) 6. The cashier will return the change money to the customer, and print the small ticket; 7. The purchase is completed, the customer carries the goods and the small ticket leaves; "Use case value" After customers buy a single, they can carry the goods away, and supermarkets will receive income; "Constraints and Restrictions" 1. POS machine must comply with GB XXX; 2. The keyboard uses Chinese, because the cashier is Chinese; 3. The amount of one purchase cannot exceed 99999RMB; 4. POS Confidential is very stable, at least one day do not fail;

Through the above steps, gradually refine and refinement, we have been a relatively perfect demand, the process is not advanced skills, nor involves the need for rich experience.

Some readers may have questions: how do I know if the 4th step has those anomalies, the alternatives?

Actually very simple: ask your customer! The customer is the clearest, but if you don't ask, hehe, the customer will not necessarily tell you:)

But as long as we have mastered the NEA use case analysis method, even if the customer forgets, or does not realize, we will also dig out the demand, so that the demand will not be missed.

"To draw?" 】

As you can see, we did not see any graphs, but plain text, when we used the use case analysis in front of us!

For those UML fanatics, this may be unacceptable, how can it be without a diagram? Is the use case diagram in UML not just for analyzing requirements?

We certainly do not doubt the authority of UML, but everything has its limitations, and UML is no exception. The limitation of UML is that UML is a modeling language, just like Chinese, English, is only a form of expression, rather than a way of analysis and creation.

For example, you can speak Chinese, but it doesn't mean you can write a novel, you can draw UML use case diagram, but it doesn't mean that you can do the requirement analysis. Instead, there must be a use case diagram after the requirement and use case, and plainly, the use case diagram is a graphical description of the use case, but it does not replace the use case.

In addition to the limitations of UML itself, there is another more important reason: Use cases are customers and companies about the product of a common understanding! In general, market personnel and customers to communicate, understand customer needs, and then one by one confirmed with the customer, and finally form the requirements of the document. In this process, customers and market participants are involved, and no research and development personnel are involved.

For the customer, he must be natural language, and not use UML to describe the requirements, for the market personnel, he may be ignorant of UML, and even he may have been selling medical equipment, or even may be dogskin plaster, he also control you what software engineering, what UML?

So, when we use use-case methods to analyze requirements, we use plain text to describe requirements, without using use-case diagrams to analyze requirements.

Use case analysis