Notes on the use cases
- All ovals (use cases) in the diagram should have a corresponding description in text
- All User Classes (from section 2 in SRS) should be present in Use Cases. If they aren't, why are they in your system?
- Use case names are typically verbs, not "Account", use "Create Account"
- Put in your unique identifier at the first part of the description
- If
you say "Includes: U3 - View Credits", then in the basic or alternate
flows you MUST have a step that says "Execute use case U3". If not,
then do not "include" that use case
- Post condition is a single outcome, not multiple possible outcomes:
- Not correct: You either created a user account or you did not
- Correct: A new user account has been created
- The
post-condition is for the basic flow only, if an alternate or exception
flow happens it is possible that the post-condition will not be true,
but for most executions of the use case, it will be true.
- In a basic flow step, don't use "and"... that means you need another step:
- Example:
The user clicks an object, and a trivia question is presented to the
user. A correctly answered question scores a point. After all questions
have been answered the "boss" level appears, and must be defeated.
- 1. User clicks an object
- 2. A trivia question is displayed
- 3. User correctly answers the question
- 4. Score is updated
- 5. System repeats step 1-4 until all questions are answered
- 6. System displays "boss" level
- 7. << show multiple steps to defeat the boss >>
- Alternate flows:
- wrong answer?
- user quits?
- too many wrong answers?
- boss not defeated?
- user pauses?
- In
a basic flow don't use "or", or "if" that means you need an alternate
flow. Make the basic flow the most common thing, and then add alternate
flows for less common things.
- What does this mean for a menu?
- It
means a menu should be it's own use case with the post-condition that
the menu is displayed. Then the options (like "Load game") should
be individual use cases with the precondition that the menu was
displayed, and the first step being: User chooses "load game" from the
menu.
-
Users should have different functions, not simply different difficulty
levels. User class: newbie and User class: experienced aren't two user
classes if the only difference is the game is faster for "experienced".
They need to have noticeably different functionality.
- Fix header/footer of the SRS document
- Use includes to group a single user goal.
- Incorrect: Login includes Actions which includes Play, Edit Profile, View Stats
- Correct: Login, Play Game, Edit Profile and view Stats are separate user goals. Don't link them.
- DO NOT EVER REMOVE ANYTHING FROM BINDER