Procedure for creating a case model

Generally, the steps for creating a case model are as follows:

(1) determine who will use the system directly, that is, the participant (Actor). To discover the participants, we can try to ask the following questions:

A. WHO/What system is used?

B. WHO/what information is obtained from the system?

C. WHO/what information should be provided to the system?

D. WHO/what support and maintenance system?

E. Which other systems use this system?

F. Which department of the company uses the system?

...

(2) select one of the participants;

(3) define what the participant wants the system to do and everything the participant wants the system to do is a use case. To discover the use case, we can try to ask the following questions:

A. Why does the participant want to use this system?

B. Do participants need to create, save, change, move, or read system data? If so, why?

C. Should the participant notify the system of external events or changes?

D. Do the participants need to know specific events in the system?

...

(4) for each case, when the participants will use the system, what usually happens is the basic process of the case;

(5) describes the basic process of the case;

(6) Consider some variable situations and create them as extension cases;

(7) Review the descriptions of different use cases, identify the similarities among them, and extract the similarities as common use cases;

(8) Repeat steps 2-7 to find each use case.

The reference criteria for participants are as follows:

(1) Have you found all participants? That is to say, have you explained and modeled all the participants in the system environment?

(2) Does each participant involve at least one use case?

(3) Can you list at least two persons who can serve as specific participants?

(4) Are there similar system-related participants? If yes, you should merge them into one participant.

The reference criteria for case check are as follows:

(1) The introduction section of the case model provides a brief and clear overview of the purpose and functions of the system;

(2) All use cases have been determined, and these use cases jointly describe all necessary actions;

(3) All functional requirements must be mapped to at least one use case;

(4) the use case model does not include redundant behaviors. All use cases can be traced back to a functional requirement to prove its rationality.

The use case diagram roughly describes the various services that the system can provide. This gives us a general understanding of the functions of the system, we also need to describe the details of each use case, that is, the use case specification. The Use Case Model consists of the use case diagram and the detailed description of each use case-the use case specification. The Use Case specification template is provided in the RUP, including the following:

(1) Brief Description: briefly introduces the role and purpose of this case;

(2) Event stream (Flow of Event): includes basic streams and alternative streams. The Event stream should represent all scenarios;

(3) Use Case Scenario (Use-Case Scenario): includes the success and failure scenarios, which are mainly composed of the basic stream and the alternative stream;

(4) Special requirements (Special Requirement): Describe the non-functional requirements related to the case (including performance, reliability, availability and scalability) and design constraints (the operating system and development tools used );

(5) Pre-Condition: the state that the system must be in before the case is executed;

(6) Post-Condition: a group of states that the system may be in after the use case is executed.

The Use Case conventions are basically expressed in text. To better describe the event stream, you can also use a status chart, activity diagram, or sequence diagram to help describe the system behavior related to the status. The activity diagram helps describe the complex decision-making process, the sequence diagram is suitable for describing time-order-based message transmission ). In addition, as long as it is helpful for the concise and clear expression of the use case, We can paste the user interface, the graphical display mode of the process, and other graphics in the use case.