Write case document

Creating a use case diagram is only the basic and simplest step to complete case modeling. The core of case modeling is to write case documents, also known as case conventions or case descriptions. As the name suggests, the use case document is a document used to describe the use case. Each use case corresponds to a use case document. In the use case document, you must describe the execution process of the use case in text, that is, the interaction process between the performer and the system.

The use case document must be easy to understand. Not only can the project developers understand it, but also system users and customers can understand the use case document. A complete Use Case document includes the use case number, use case name, performer, preconditions, post conditions, stakeholder benefits, basic paths, extension paths, field lists, business rules, non-functional requirements, and design constraints.

Generally, a unified and standardized serial number is required for all use cases in the system. For example, in the inventory management system, the use cases can be numbered by stockuc001 and stockuc002. Each use case must provide a clear and easy-to-understand Use Case name, generally in the form of "Verb + noun, for example, "view Inventory Report", "add employee information", and "add product information" can be abbreviated, such as "login", "Registration", "warehouse receiving", and "warehouse picking.

The prerequisite is the status of the system before the use case is executed. It must be a status that can be recognized by the software system. For example, the prerequisite for the use case "Warehouse administrator" is that the Warehouse administrator has successfully logged on to the database ", instead, it cannot be "the Warehouse administrator has already turned on the computer", because the inventory management system of "turn on the computer" cannot be identified; the post condition is the status that the system should have after the case is executed, it must also be recognized by the system. For example, the post-condition of the case "warehouse receiving" is "the system stores warehouse receiving information and updates the inventory of related goods ", instead, it cannot be "User exits from the system", because "User exits the system" is not the system status achieved by the "warehouse receiving" operation.

Stakeholder interests are those who are very concerned about the use case execution process and results but do not directly operate on the use case. For example, when the Warehouse administrator warehouse receiving and warehouse picking, although the manager does not directly store the data in the warehouse, however, they are very concerned about the process and results. For example, when buying tickets at the railway station, the ticket seller directly uses the ticket sales system, but the passengers are very concerned about the execution results of the use cases, the customer is concerned about whether the wrong time and number of times will be wrong. Executors are the people who directly execute the use cases. They use the use cases to directly execute the functions provided by the system. Stakeholders are the audience who operate the use cases. They are very concerned about the execution process and results of the use cases, because it involves their interests.

The path is also known as a "process", which refers to the process in which the performer interacts with the system. The most important part in the case document is the basic path, which is also known as the "normal path" or "happy path, is the core of case modeling. There are several steps in the path. These steps constitute a complete interaction process. When describing the basic path, each step generally takes the performer or system as the subject, for example, "the Warehouse administrator enters the information of the commodities to be imported into the warehouse", and "The system verifies whether the inventory of the commodities has reached the upper limit. Note the following when writing a path:

 

(1) steps need to be numbered. Generally, Arabic numerals 1, 2, 3 ,... Number, indicating the order of the steps.

(2) There is no professional term, because the use case document must be understood by both the system's customers and users. Therefore, there cannot be professional terms such as JDBC and SQL.

(3) Use the active statement whenever possible. Each step takes the performer or system as the subject.

(4) do not involve Interface Details. For example, you cannot see sentences such as "enter an account in the text box of the Warehouse administrator" or "enter a password in the password box of the Warehouse administrator, instead, use "enter account number and password as the repository administrator.

(5) If a large amount of data is input or processed, put the data into the "Field List". For example, when the system administrator adds employee information, you need to add information such as employee account, employee password, employee's department, employee's phone number, and employee's email address. You can use "System Administrator input employee information" in the case document, the detailed description of "employee information" can be detailed in the "Field List" of the case document.

(6) Pay attention to the processing of branches and loops. In the case document, the branches can be placed in the extension process to be introduced next, and the loops can be directly placed in the step description, for example, you can import the data of multiple commodities at a time during warehouse receiving, some steps are as follows: "2. the Warehouse administrator enters the information of the goods to be imported. 3. the system verifies whether the inventory of the product has reached the upper limit. 4. the system prompts that the product warehouse receiving information has been added successfully. "If you need to repeat these steps, you can use the following statement in the basic path:" If there are other products that need to be checked in, repeat Step 2-4 ".

 

The basic path is the core of the use case document. You can use the path to clearly understand how the performer can use the use case to implement the corresponding functions. Therefore, when writing the use case document, you must carefully write the basic path, ensure that non-professionals can understand the interaction process between executors and the system after reading the basic path.

In addition to the basic path, many use cases have some replacement paths and exception paths. Generally, the replacement path and exception path can be collectively referred to as the extension path. It is not difficult to identify the basic path of a use case, but it is hard to find all the extension paths. A good system analyst should carefully analyze the business process and try to find the possible extension methods in each step in the basic path to find all possible extension paths. For example, the Warehouse administrator may encounter some exceptions during warehouse receiving, such as "the supplier does not exist", "the goods to be imported do not exist", and "the goods to be imported exceed the inventory limit, you need to use the extension path to clearly describe these situations. For example, if "the supplier does not exist", you need to set an extension point. First execute the "add supplier information" use case, and then select the supplier number, in the expansion process, it can be like this: "1A. the supplier does not exist. extension Point 1: Execution case -- stockuc003 add supplier information; 2. the repository administrator selects the supplier ID. ". Pay attention to the extension path number here. If it is the extension path of step 1 in the basic path, it can be expressed by 1A, 1B, 1C, etc, and then use 1, 2, 3 ,... Number. In Step 1st of the sub-path, it indicates that this is an extension point. The extension name is "extension point 1". At this time, you need to execute another use case stockuc003 "add supplier information ", there is an extended Relationship Between the use case "warehouse receiving" and the use case "add supplier information", and the "add supplier information" is an extension of the "warehouse receiving" operation. If there is no extension point, write the step directly, which is consistent with the basic path step.

The Field List, business rules, non-functional requirements, and design constraints are complementary descriptions of the use case. The field list contains some data fields involved in certain steps, for example, in the "add product information" Use Case, you can list the product information in detail in its "field list", such as "product information includes: product number, product name, product model, product category, product unit price, product quantity, inventory upper limit, inventory lower limit, and field list provide great help for subsequent database design; business Rules are used to describe the conditions that the performer or system must meet when performing certain operations in the step, for example, in the "add product information" case, its "Business Rules" include "the commodity number cannot be blank, the commodity quantity must be an integer greater than or equal to 0, and the lower limit of inventory must be lower than the upper limit of inventory; non-functional requirements are used to describe the reliability, security, availability, portability, and other requirements of use cases, for example, "the system response time cannot exceed 30 seconds" and "100 users can be accessed online at the same time". design constraints refer to some issues to be solved during the design process, for example, "Product Code problems" and "how to quickly enter product numbers.

 

In the actual software development process, the use case number, use case name, performer, pre-condition, post-condition, and basic path are essential components of a use case, the other parts can be determined based on the actual situation. The following is a case document for "warehouse receiving" in the inventory management system for your reference:

 

Case name	Warehouse receiving
Case No.	Stockuc006
Performer	Repository Administrator
Stakeholder benefits	MANAGER: Understand inventory information of various commodities and warehouse receiving information each time. System Administrator: Check whether the warehouse receiving operation can be executed normally, and whether the system correctly records the warehouse receiving information and updates the product inventory.
Prerequisites	The repository administrator has successfully logged on.
Post Condition	The system saves the warehouse receiving information and updates the inventory of related products.
Basic path	1. Select the supplier ID as the repository administrator; 2. The Warehouse administrator enters the warehouse receiving item information; 3. Check whether the inventory of the product has reached the upper limit; 4. The system prompts that the product warehouse receiving information has been added successfully; If there are other products that need to be imported into the database, repeat Step 2-4. 5. The repository Administrator submits the warehouse receiving information; 6. The system prompts that the storage is successful.
Extension path	1A. The supplier does not exist. 1. Extension Point 1: Execution case -- stockuc003 add supplier information; 2. Select the supplier ID as the repository administrator. 2a. The item to be imported does not exist. 1. Extension Point 2: Execution case -- stockuc005 to add product information; 2. The Warehouse administrator enters the information of the imported goods. 4A. failed to add 1. The system prompts an error occurred while adding the product. The inventory limit is exceeded; 2. The Warehouse administrator enters the item quantity again; 3. The system checks whether the inventory of the product has reached the upper limit until the inventory information of the product has been added.
Field List	Warehouse receiving commodity information includes: Commodity number, warehouse receiving quantity, and commodity discount.
Business Rules	Supplier ID cannot be blank; The product ID cannot be blank; The number of incoming records must be a positive integer and cannot be blank; The product discount is a decimal point (which can contain 0 and 1) between 0 and 1, and cannot be blank.
Non-functional requirements	The system response time cannot exceed 30 seconds.
Design Constraints	How to quickly enter the product number?

Write case document