Lecture Notes for Revisiting Use Case Descriptions

Use Case Description 1.Enter user name and password. 2.User name and password are validated. 3.System displays main member menu.

Use Case Description 1.Enter user name and password. What is wrong with this step in the normal scenario? No subject (don’t know who is “kicking the ball”) Correct version: 1.The member enters user name and password. Rule: Always have a subject in your sentence. Know who is doing the action in the sentence.

Use Case Description 2.User name and password are validated. What is wrong with this step in the normal scenario? “are validated” is a passive verb; we want to use action verbs only Correct version: 1.The system validates user name and password. Rule: Always have an action verb in your sentence.

Use Case Description 3.System displays main member menu. What is wrong with this step in the normal scenario?

Use Case Description 1.Member enters user name and password. 2.Member clicks the Submit button. 3.System validates user name and password and displays main member menu.

Use Case Description 1.Member enters user name and password. What is wrong with this step in the normal scenario?

Use Case Description 2.Member clicks the Submit button. What is wrong with this step in the normal scenario? Do not show keystroke movement (i.e., don’t use “click”) Implies a particular implementation approach Correct version: None; step not needed because step 1 shows the actor’s intent. Rule: Show the actor’s intent, not the movements.

Use Case Description 3.System validates user name and password and displays main member menu. What is wrong with this step in the normal scenario? 2 actions are combined into 1 step Correct version: 3.System validates user name and password. 4.System displays main member menu. Rule: Avoid compound sentences.

Use Case Description 1.System prompts for the user name. 2.Member enters user name. 3.System prompts for the password. 4.Member enters password. 5.System checks whether user name and password are correct. 6.If the user name and password are correct, the system displays main member menu. 7.If the user name and password are incorrect, the system displays an error message.

Use Case Description 1.Member enters user name and password. 2.System validates user name and password. 3.System displays main member menu.

Use Case Description 1.Member Login to the system. 2.Member enters the user name and password. 3.System validates user name and password. 4.Member Searches video selection.

Use Case Description 1.Student logs into system and is provided with a menu. 2.The student should then select “Track Student Progress” 3.Based on this the system should be able to access Student info to check matriculation date and student major to check applicable student Flowchart for their program and year. 4.The system will then generate a flowchart in a method that mimics Use Case ID 2, but with the major and year already filled in. 5.Once the information is generated the student may select an output type of either show only remaining requirements, or show all requirements. 6.In the case of remaining requirements information about what the student has left to take will be shown. In the case of show all requirements all requirements for that degree/year combination will be shown, but with some sort of graphical indication that a student has already completed part of the curriculum.

Use Case Description Rules for normal scenario: –Have a subject and action verb. –Don’t have more than one verb (i.e., no compound sentences). –Show the actor’s intent, not the movement (i.e., no “click”, “submit, “prompt”) –Write from the correct perspective (this rule is normally followed if you have a subject and action verb). –Do not use “check whether” but use “validate.” –Do not include steps from other use cases.