UseCase Event Flow Description specification

Wen/fasiondog

Compile specification of requirement use case, share part of UseCase event Flow description specification. Among them, the guideline 5~10, 12来 from "Writing Effective Use Cases" ([US] Alistair Cockburn) book, others for their own practice and requirements.

The flow of events includes normal event flow, optional event flow, exception event flow, and the essence of the aforementioned three is the process of text description. The event flow consists of the steps described in the text, and the following guidelines should be followed in the writing process, summarizing common problems and best practices in the use case writing process. In the following specification, if there is no special description, the event stream refers to the normal event stream, the optional event stream, and the exception event stream.

Guideline 1: Text description is consistent with flowchart

The essence of event flow is actually the flow of text description. Therefore, the flowchart that is complemented by the use case should be consistent with the flow of the text representation of the event. In fact, the use case is based on text description, flowchart supplemented. Writing a use case should develop the habit of "drawing before writing". Consistency means:

• The number of actions (including judgments) in the flowchart is consistent with the number of steps in the event stream (due to the limitations of different graphical representations, the minimum should be guaranteed to coincide with the number of steps in the normal event flow)
• The action in the flowchart (including judgment) is consistent with the step description in the event flow

Guideline 2: Step description follows "Master + predicate + bin" structure

The structure of the sentence should be simple and clear: "Subject + predicate verb + direct object", supplemented by necessary modifier words.

Guideline 3: Only one subject is included in a step description

Only one subject is included in a step, which means that a step description can be performed by a performer, or a performer can perform multiple coherent actions, but not multiple performers performing several different tasks. For example:

Description of the error: 1. "User" Enter the order number, "system" found that this number matches the winning number of the month, the user and the order number registered as the winner of the month, email the sales manager, congratulate the customer, and tell them how to collect the prize right description Form 1:1. "User" Enter the order number. 2. The system finds that this number matches the winning number of the month, registers the user and subscription number as the winner of the month, sends an email to the Sales manager, congratulates the customer, and tells them how to collect the bonus. correct description of form 2: 1. "User" Enter the order number. 2. "System" found this number matches the winning number of this month. 3. The system registers the user and the subscription number as the winner of the current month. 4. The "system" sends an email to the sales manager. 5. "System" congratulates the customer and tells them how to collect the bonus.

When you write a use case, you can make a reasonable merger of more lengthy steps based on this guideline. The so-called reasonable, refers to the combined steps, should not affect the optional event stream, the exception event stream insertion point.

Guideline 4: Identify participants clearly in the steps

By explicitly identifying the participant (Actor) in the step by using "participant", prevent the omission of the subject (and part of the object) and make the reader unaware of who is the performer of the activity. Example:

"User" inserts the ATM card and enters the PIN. ”

Guideline 5: Writing use cases from the perspective of the outside of the system

Inexperienced use case writers, especially those who know something about the internal implementation of the system, often intentionally or unintentionally implement the internal structure of the system and attempt to describe the system from within the system when describing the use case scenario. They may write the sentence "read the ATM card and PIN number and deduct a certain amount from the account balance." ”

To write a use case from outside the system is:

1. "User" Insert the ATM card and enter the PIN number; 2. "System" deducts a certain amount from the account balance.

Guideline 6: Show the process moving forward

Selecting a step that is too small will cause the use case to be too long. If a use case has a 13~17 step, it means that each step is done with too little work. If you combine some small steps, you can use the example to be more readable, clearer, and keep the original basic information. In general, the number of steps in a use case should be controlled within 7.

To effectively combine use case steps, you should find steps that have a higher level of goal. The question can be raised, "Why do participants need to do this?" ”。 It is possible to ask this question multiple times to get a satisfactory answer, and the answer to this question is the goal of step fulfillment. Here is an example of how to raise the target level by asking "why".

The user presses the TAB key

Why do users press the TAB key? is to move the focus to the Address box. Why does she want to move the focus to the Address box? Because she wants to enter a username and address before the system starts working. She wants the system to do some work, and in order for the system to work, she must enter her username and address.

Thus, an active voice sentence that clearly describes the process moving forward is:

"User" Enter name and address "

Guideline 7: Show participants ' intentions rather than actions

By manipulating the user interface to describe the user's actions, which is a common serious mistake in writing a use case, it puts the writing target at a very low level. The interface detail description makes the requirement document quality worse, mainly reflected in:

• Lengthy delays in documentation make reading difficult and costly to maintain.
• Any changes to the user interface will cause the use case document to expire

Typically, when data from successive steps are moving in the same direction, these steps can be combined into one step (as appropriate, with reasonable consolidation). As in the following example and modifications to it:

before modification : 1. "System" requires the user to enter the name 2. "User" Enter the name 3. "System" requires the user to enter address 4. "User" input address 5. "User" click "OK" 6. "System" shows the user's introduction modified:1. "User" Enter your name and Address 2. "System" shows the user's profile

Guideline 8: "Confirm" instead of "check if"

You will often encounter steps that describe the system checking for a condition. In the step description, the use of the verb "check" is not good, so it does not allow the process to develop clearly, it is not the real purpose, and it makes the results of the examination is uncertain. So why should the system check the conditions? The answer is to confirm, verify, or ensure certain things. These are good verbs that can represent a goal. For example, you can replace the "system check password is correct" with:

"System" verifies that the password is correct "

Guideline 9: Idioms: "Users have system a interact with system B"

When you write a use case, you may encounter situations in which system a you are designing needs to obtain information from System B or have an interaction with system B. You can typically use two steps to describe:

1. "User" informs "system a" to obtain data from "System B" 2. "System A" obtains background data from "System B".

While this is acceptable, it is awkward and redundant in some cases, especially when use cases are more complex. A better wording is as follows:

1. "User" command "system a" obtains background data from "System B"

Guideline 10: Idioms: "Loop through steps x through Y until conditions are met"

Sometimes we encounter steps that need to be repeated. For only one step needs to be repeated, you can describe it directly in the steps, such as: "User" in a variety of product catalogs to find, until the discovery of the required products. ”

For multiple steps that require duplication, you can put statements that repeat themselves in front of or behind these repeating steps. For example:

1. "Customer" provides account number or name and Address 2. "System" to find out the customer's hobby information 3. "Customer" selects a product and makes a purchase Mark 4. "System" adds the item to the customer's "Shopping Cart" by  repeating steps 3 and 4 until the customer indicates that they have completed the purchase steps 3, 4 can be executed repeatedly 3. "Customer" Select a product and make a purchase Mark 4. The "system" adds the item to the customer's "Shopping cart" 5. "Customer" buys all items in the "Shopping cart"

Note: You do not need to add a sequence number before expressing a repeating statement.

Guideline 11: Naming optional and exception event flow branches

The appropriate naming of the branches in an optional event stream, the exception event stream, is useful for testing and understanding. By simply naming it, it is advantageous to examine the coverage of the branch and ensure that all branches are processed. For example, an exception event stream when a system is logged on:

5a. ( failed to enter password Authentication ) If the password authentication fails, return to step 35b. ( continuous input password error limit ) if the output password error is 3 consecutive times, the login is locked and the use case ends. 5c. ( input fingerprint authentication failed ) If the fingerprint authentication method fails, return to step 3a

Guideline 12: How to Indent conditional processing

Indent the execution steps that indicate how the condition is handled, and start with the letter numbering 1, followed by the preceding guidelines. Example:

5a. If you enter a password error:  5a1. (bad password) if the password is incorrect, the system prompts for an error message and returns to step 4.  5a2. (Continuous password error limit) If you enter the password incorrectly for 3 consecutive times, the account is locked and the use case ends.  5a3. (Cumulative password error limit) If the password error reaches 10 times, the account is locked and the use case ends.

Guideline 13: Branches with the same condition should be together

The reason for this criterion is that in some conditional processing branches, they are placed in both the optional event stream and the exception event stream, which affects reading and understanding, and is not conducive to detecting errors.

examples of errors are as follows: Normal event Flow:... 3. The cabinet face through the core system inspection account withdrawal method for the reserved password; Optional Event stream:3a. The cabinet face through the core system inspection account withdrawal method for the seal-  3a1. Cabinet Tip "Please check the seal"  3a2. After the teller checks the seal, click on any key to submit, return 6 after the modification, put it in the optional event stream: Optional event flow:3a. (Seal withdrawal) If the account is drawn by the seal:  3a1. "System" prompt the customer to check the seal;  3a2. "Teller" After checking the seal, submit system confirmation, perform step 6. 3b. (non-printing or with valid document withdrawal) if the account is drawn in a non-printing or with a valid document withdrawal, "The system" indicates that "no printing account does not support the bank account opening", the use case ends.

UseCase Event Flow Description specification