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.
2.
3.
4.
5.
System prompts for the user name.
Member enters user name.
System prompts for the password.
Member enters password.
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.