Process that technicians can understand (2) -- Case Model

A process that allows technicians to understand (2)

-- Use Case Model

The general management process divides software projects into "requirements-> analysis-> Design-> Implementation-> maintenance". The corresponding technical process must first clarify the requirements, the "Use Case Model" is used to obtain and analyze requirements.

Simply put, the use case model is to write down the customer's requirements. The "requirement" is not very well understood. The more common way is to say "story )". I think the word "story" is very good, very vivid, and easy to understand! Let's take a look at why "Stories" are more suitable for explaining customer requirements:

(1) There are many roles in the story, and there are also many roles in demand;

(2) The story goes through, starts, proceeds, and ends. The requirement is also a complete process, including input, processing, and output.

(3) The story must be meaningful, and the demand must also be meaningful to the customer;

 

The specific use case format is not described in detail here. You can search for it online, how to better grasp the needs can refer to my blog post "Demand Analysis story-how to train the eye of demand analysis? ", The following describes the mistakes that are easy to make in the use case model stage.

1) "Requirement" and "function" are mixed

Many friends confuse "functions" with "requirements" when analyzing requirements, leading to unreasonable requirements or inability to grasp key demands, I have summarized a simple differentiation method:"Demand is something of value to the customer, and the function is to achieve the demand.".

Taking poser as an example: for customers, "buy" is a valuable thing, because customers can take the goods after buying the order; the "read commodity barcode", "Calculate commodity total amount", and "Print shopping list" functions in the payment process, because any of these independent functions have no value for customers (you won't go to the supermarket to "read commodity bar codes"), just to "pay.

2) System Decomposition in the case model phase

In addition to obfuscation of "functions" and "requirements", there is also a common mistake in the case model phase: decomposing the System in the case model phase.

Taking the POS machine as an example, some people describe the requirements as: scanning machines to scan the product barcode information, and then sending the information to the inventory system. The inventory system returns the detailed product information to the transaction system ...... This is wrong in the case model phase, because it transfers our attention from focusing on user needs to system analysis.

Remember:The Use Case model focuses on user requirements and does not need to be decomposed by the system. Simply treat the system as a black box..

 

The following is a simple use case snippet for the POs server. If you are interested, you can write a complete one (this complete one is not simple, at least three pages can be written ):

1) The customer carries the goods to the cashier;

2) The cashier scans the product barcode;

3) The system obtains and displays product information based on the barcode;

4) Cashier Repeat 2 ~ Step 3 until all products are scanned;

5) The system calculates the total amount of goods;

....................

N) The system generates a commodity list to complete the transaction.