P1: Feedback

[lmorenoc]

Good job! Next are a few comments to consider in the next iterations:

1. Use case diagram a. Association names are not necessary (unless they are special associations) b. The inheritance relationship between registered user and user indicates that a registered user can register c. System is not an actor d. There is no system boundary and name
2. General comments for use case documentation a. The system is not a stakeholder b. Present tense is preferred to describe steps in the flows c. Use case IDs are desirable
3. Register user a. A better name for this use case would be "Register" (the user starts this use case) b. Step 5 describes an alternate (extension) flow c. The user should be informed about the success (failure) of the transaction d. The extension should be also a numbered list, showing in which step the flow differs
4. Create game a. Use cases shouldn't refer to elements of the UI at this early stage b. Step 4 describes two different flows c. This extension is a postcondition
5. Invite user a. What does it mean that "all user must be properly registered"? b. The success guarantee section is including the success guarantee of "Create game" c. The user won't be added to the game unless he accepts the invitation. Maybe another use case is necessary? d. The extension scenarios are not alternate flows but scenarios that must not happen.
6. Accept game a. Since the use case handles both accept and reject invitation, a better name would be "Respond invitation" b. Success guaranteed must be revised c. The invitation sender must be notified about the receiver's response d. Stakeholders must be revised. The purpose of user 2 is to play a game he has been invited to.
7. Reject game a. Maybe it should be merged with "Accept Game" b. See 6
8. Quit game a. Extensions must be revised b. Shouldn't it include "Record history"?
9. Unregister from system a. Similar to 3a b. Similar to 3c c. If the user information is totally removed from the system, what would happen with the game history of his opponents? Maybe it's not the best option to completely remove the user from the system
10. Record history a. Main success scenario should list the information to be logged b. This use case c. Similar to 5d
11. View profile a. Must be revised
12. Start game a. Steps in main success scenario include steps from other use cases, and are redundant with respect to the preconditions b. This use case must be revised. Is it really necessary? The game can start as soon as soon as the invitation to join the game has been accepted. The same applies to the notification about the start of the game
13. Play game a. There's no mention about who starts the game or allowed moved b. The "Record history" should be included when the game is over c. Extensions must be revised
14. Save game a. Must be revised

[jayzym]

Hi Laura, we've implemented your suggestions. I'm going to mark this as closed