locked
Use Case RRS feed

  • Question

  • I am trying to decide on a couple of use cases for a simple tic tac toe game.  When the user double clicks this app the game will prompt for 1 or 2 player game, names and it will assign either an X or an O and prompt the user to make their move.

    I've already identified a use case Make Move.

    My query is, should I have a start game usecase even though really the user does not start a game just runs the application? 

    Also, at the end of the game the user can select to have another with the same players, start a new game with different players or quit the application.

    Again my query is should I have usecase's to model the replay with same players, start fresh game and quit application?

    My view is to only have the one usecase MakeMove.  If I was to have a usecase for say start fresh game the usecase would in essence walk through the entire game.

    I have a tendancy to overthink and feel thats what I'm doing here.

    Would like to hear thoughts of others on this as my research has pulled up mixed views.

    Thanks,

    Sunday, October 23, 2011 12:05 PM

Answers

  • Hi RedKMan,

    You need to have use cases for every possible task a user might want to do.  And don't think about the buttons and interface when you're thinking of the use case.  Simply think of "what is the intention of the primary actor and what must be done to fulfill his or her immediate goal".

    And yes, it sounds like the user will have a need to start a new game, replay a game with different players, and quit.  All of those are candidates for being use cases.

    You said having a "start fresh game" use case would walk through the entire game.  Actually it wouldn't, because you need to focus just on that small task.  For example a use case for "start new game" might be:

    Primary Actor:  Player

    Supporting Actor:  Computer, online opponent

    Preconditions:  primary actor had already played a previous game.

    Description:  User has an intent to start a new game.  The system should create an environment for the player so he/she can choose a new opponent and start a new game.

    Basic flow:

    1.  user selects he/she wanst to start a fresh game.

    2.  system responds with clean play board.

    3.  user selects his/her type of opponent (computer or online player)

    4.  system responds with list of online players.  Or if computer was selected, starts the game.

    5.  user selects the online opponent, and starts the game.

    6.  User has now started a fresh game with his or her desired opponent type, so this use case has been fulfilled.

    Alternative Flows:

    3.1 User selects wrong option.  For example he or she wanted to play the computer but accidently selected an online opponent.

         a.  The system should  prompt the user to confirm his or her selection and allow the user to go back and re-select if needed.

    5.1  User selects the wrong online opponent that he/she meant to select.

         a.  The system allows the user to confirm that he/she wants to play with the selected opponent so the user can cancel and select a new online opponent if needed.

     

     

    Anyway, this is just a sample of how I think you need to think about all your possible "use cases" and the granularity that each should have.


    Tom Overton
    • Marked as answer by RedKMan818 Sunday, October 23, 2011 3:27 PM
    Sunday, October 23, 2011 12:42 PM

All replies

  • Hi RedKMan,

    You need to have use cases for every possible task a user might want to do.  And don't think about the buttons and interface when you're thinking of the use case.  Simply think of "what is the intention of the primary actor and what must be done to fulfill his or her immediate goal".

    And yes, it sounds like the user will have a need to start a new game, replay a game with different players, and quit.  All of those are candidates for being use cases.

    You said having a "start fresh game" use case would walk through the entire game.  Actually it wouldn't, because you need to focus just on that small task.  For example a use case for "start new game" might be:

    Primary Actor:  Player

    Supporting Actor:  Computer, online opponent

    Preconditions:  primary actor had already played a previous game.

    Description:  User has an intent to start a new game.  The system should create an environment for the player so he/she can choose a new opponent and start a new game.

    Basic flow:

    1.  user selects he/she wanst to start a fresh game.

    2.  system responds with clean play board.

    3.  user selects his/her type of opponent (computer or online player)

    4.  system responds with list of online players.  Or if computer was selected, starts the game.

    5.  user selects the online opponent, and starts the game.

    6.  User has now started a fresh game with his or her desired opponent type, so this use case has been fulfilled.

    Alternative Flows:

    3.1 User selects wrong option.  For example he or she wanted to play the computer but accidently selected an online opponent.

         a.  The system should  prompt the user to confirm his or her selection and allow the user to go back and re-select if needed.

    5.1  User selects the wrong online opponent that he/she meant to select.

         a.  The system allows the user to confirm that he/she wants to play with the selected opponent so the user can cancel and select a new online opponent if needed.

     

     

    Anyway, this is just a sample of how I think you need to think about all your possible "use cases" and the granularity that each should have.


    Tom Overton
    • Marked as answer by RedKMan818 Sunday, October 23, 2011 3:27 PM
    Sunday, October 23, 2011 12:42 PM
  • Hi Tom,

    Thanks for the post, its helped a great deal :).

     

    Sunday, October 23, 2011 3:27 PM