Iteration 1 User Stories

(Approximate point values indicated in [square brackets])

Project: Co-operative Goals for Competitive Games You are implementing an Android app to provide achievement goals to turn some competitive board games into a more co-operative experience. At the end of a playing a game, the combined score of all players is used to calculate a combined achievement level, with a higher total score earning a better achievement.

Use Cases

As a user, I want to...

Game Configurations

  • [10] Create a new game configuration (such as for the game "Via Magica" or "Monopoly") so that I can play new competitive games with a co-operative goal. Each game configuration will have a name (like "Via Magica"), and the per-player expected scores (poor score, great score). The "poor score" is a score (a whole number) that a poor player might earn. Likewise a "great score" would be what a very skilled played might earn (as a rough guess).
  • [10] View the achievement levels for an existing game configuration, likely shown as a list so that I can check if the achievement levels are reasonable.
    • To see the achievement levels, I will enter the number of players
    • It will show me a list of achievement level names, and the minimum score required to earn that achievement level
    • The lowest expected level is (poor-score * num-players); highest expected level is (great-score * num-players).
    • Have 8+ different achievement levels such as "Goofy Goblins", "Majestic Unicorns", "Fabulous Dragons", "Brilliant Pixies", ... (use your creativity!)
    • Add an "achievement" level for scores less than the expected lowest level to capture even the worst fo games
  • [5] Edit a game configuration to change its name or per-player expected scores so that when I realize an error, or need to recalibrate poor/great scores for a game, it is easy to do so.
  • [5] Delete a game configuration so that I can cleanup the application when I no longer play a game, such as when I have sold it.
  • [10] Persist game configuration data between application launches so that I can close the application and when I come back the same game configurations are saved.
  • [5] See some helpful and inviting information when I first launch the application and it has no game configurations yet. I need this "empty state" to help me see how to start using the application to create my first game configuration.

Game plays

  • [15] Record that I have played one of the game configurations and see the achievement level we earned so that I can use the app to provide a co-operative goal for a competitive board game.
    • To record a new game play, I will select a game configuration, enter the number of players, and the combined score of all players playing
    • Application will display the achievement level we earned
  • [5] View all of the game plays for any game configuration so that I can see how we have done in the past. I want to see information about each game play, such as when it was played, how many players, combined score, and the achievement we earned.
  • [5] See some helpful and inviting information when I open a game configuration which has no game plays yet. I need this "empty state" to help me see how to create a game play.
  • [10] Persist game plays between launches of the application so that the history of our games, and our successes, can be saved for the future.

General Requirements

  • [10] Overall
    • App must have a min SDK version of 27 (or lower)
    • App must have a target SDK version of 30 (or higher)
    • Add a back button on the tool-bar (app-bar) at top when appropriate.
    • From any screen, the Android back button must do the "reasonable" thing.
    • Application flows smoothly.
    • Nice UI layouts; resizes to different size screens reasonably well (ex: 5", 6", 10")
    • Every group must have a coding style guide checked into your repo (RM suggest it; team discusses it; team has final approval)
  • [10] Correct use of Git and GitLab
    • Using GitLab Issues to track features to work on.
    • Use Git/GitLab branches and GitLab merge requests
    • Correctly builds when cloned from GitLab.
    • Each team member must do 2 code reviews of merge requests (MRs)
  • [0] Must have good quality code (Up to 20 point deduction)
    • Good class, method, variable names.
    • Perfectly formatted code.
    • Comments on all classes (not needed inside classes, just on the class level)
    • All strings which end user may see on UI (not LogCat) are in strings.xml
    • Model classes must be in a separate package from the UI (activities)

Constraints (for all iterations of project)

  • All development must be in the GitLab repository creating for your group.
  • Use the GitLab workflow, as discussed in class:
    • Start feature with a GitLab issue
    • Create a feature branch
    • Commit code to feature branch often
    • Merge Master to feature branch once feature completed.
    • Submit Merge Request
    • Code review, fix, and merge.
  • Good commit comments on (almost) all commits and merge requests.
  • Well built UI, including:
    • Well laid-out usable screens.
    • Works on different sized screens. Example tests on 4", 6", 10".
    • Use of icons and images where possible.
  • Simple OOD supporting not much more (if anything) than the current set of requirements.