Software Requirements Specification for Dots and Boxes

Transcription

1 Software Requirements Specification for Dots and Boxes Reviewed by: Nhlakanipho Shabane (517475) Rethabile Mokoena ( x) Sonja Van Der Westhuizen ( T) Steven Faber (417265) Tsholofelo Moitsheki (463642) Project Source and Documentation: Course: ELEN Software Technologies and Techniques Date: 22 April 2010 Version: 1.0 Revision History Name Date Reason for Version Changes S Faber Initial Draft 0.1 S van der Added all use 0.2 Westhuizen / Tsholofelo Moitsheki cases S van der Document 0.3 Westhuizen S van der Westhuizen Formatting Added final text 1.0

2 Contents 1. Introduction Purpose Project Scope Client / Customer Stakeholders Naming Conventions and Definitions Overall Description Product Perspective User Classes and characteristics Operating Environment Mandated Constraints User Documentation Assumptions and Dependencies Functional Requirements Start Game Start game use case Start game sequence diagram Play Game Use case Sequence diagram End Game Use case Sequence diagram Getting Help Use case Sequence diagram Communicating over Internet setting up game Use case Sequence diagram Communicating over Internet playing game Use case Sequence diagram External interface requirements...16

3 4.1 User Interface Hardware Interface Software Interface Communication Interface Non-Functional Requirements Other Requirements License agreement...17 Appendix A: References...18

4 1. Introduction 1.1 Purpose This SRS describes the software functional and nonfunctional requirements of the Dots and boxes mobile phone software game. This document is intended to be used by the members of the project team that will implement and verify the correct functioning of the system. 1.2 Project Scope The scope of this product is to allow at least two players to compete against each other using their mobile phone over an appropriate networked connection. The primary goal of this product is to develop a new and improved version of the game for use on a mobile phone. 1.3 Client / Customer The target customer is the general public who owns a mobile phone. 1.4 Stakeholders Person Role Responsibility Viv Crone Client Represents customer interest Actor (Game Player Host) Customer Product user Actor (Game Player Guest) Customer Product user 1.5 Naming Conventions and Definitions The dictionary included below contains all important names that will be used by the project. Terminology Key users J.M.E. M.I.D.P. G.U.I. O.S. Definition These are critical to the continued success of the product. Give greater importance to requirements generated by this category of user. Java Micro Edition Mobile Information Device Profile Graphical user interface Operating System

5 Web Service Application available on the internet for relaying game information 2. Overall Description 2.1 Product Perspective «uses» Top Package::Game Player (host) <<System>> Dots And Boxes Game «uses» <<Actor>> MIDP «uses» Top Package::Game Player (Guest) Figure 1 Dots and Boxes Context diagram The Dots and boxes mobile phone game will be a newly developed software application which will implement the classic pencil and paper game where at least two players can compete for territory on a grid of dots against each other using their mobile phone over an appropriate 'networked' connection. The context diagram in Figure 1 shows the external entities and system interfaces. 2.2 User Classes and characteristics User Role Required Business Experience Game Player (Host) Game Player (Guest) M.I.D.P Person who hosts a dots and boxes game on their device and the participates in the game Person who joins the dots and boxes game created by the host player on their device and then participates in the game Interface system to the mobile device Required Technology experience User Priority None Novice Key User None Novice Key User None None Key Interface

6 2.3 Operating Environment The Dots and Boxes game shall be capable of operating on all mobile devices that supports the M.I.D.P. version of the J.M.E platform. 2.4 Mandated Constraints The application must make use of a GUI. The application must allow users to compete against each other over a networked connection. A simple and easy to use installation procedure must be provided for the end-user. A Formal software process must be used during development. The design of the application must be modular to allow improved functionality to be easily added. An appropriate Project management system must be used to submit comprehensive project timesheets of both estimated and actual time spent at the end of the project. 2.5 User Documentation The game shall provide a help system that will explain all functions available on the user interface. The game shall provide the user with a tutorial that will explain the principles of the Dots and Boxes game. 2.6 Assumptions and Dependencies The end-user must have a mobile phone. The mobile phone used by the end-user must have access to the internet. The end-user shall be a subscriber of a mobile service provider which shall allow the user access to the internet.

7 3. Functional Requirements 3.1 Start Game This use case describes how the game player starts the Dots and Boxes game. Use Case ID: 1 Use Case Name: Start Game Actors: Game Player Preconditions: Game needs to be installed Internet is available Game needs to be available on mobile phone menu Post conditions: Game grid is setup and available to play Normal Flow: Join Game 1 This use case starts when the user selects the join game option 2 View list of games (from internet) 3 Select game (return selection to internet) 4 Grid is displayed with status message 5 Wait for game host to make move, but poll (internet) to see acceptance Alternate Flow: Host Game 1 This use case starts when the user select to host a game 2 Create game (on internet) 3 Wait for user to join, poll (internet) to see user 4 Approve user (return value to internet) 5 Make move (send move to internet) Exceptions: If no internet available notify user If Game Player is waiting for a user to join, give ability to exit game, or timeout after 5 minutes If application gives error, notify user. Stimulus: Play a game on mobile phone Response: Ready to play game against opponent Comments: For communication over the internet see use case 3.5 and 3.6 Game AI is for phase 2 The game can only play via the internet, the Bluetooth option is in phase 2 Game options i.e. Grid size and game level is for future releases Start game use case

8 3.1.2 Start game sequence diagram 3.2 Play Game This use case describes how the game player starts the Dots and Boxes game. Use Case ID: 2 Use Case Name: Play Game

9 Actors: Preconditions: Post conditions: Game Player Game grid set up and both players are ready to be play Game rules successfully implemented, by either just drawing line or drawing line and completing block Normal Flow: 1 User selects a line and waits turn 2 User selects line 3 Game logic returns with response 4 Internet is notified 5 UI is updated and locked, waiting for other players turn Alternate Flow: 1 User selects a line and completes a block 2 User selects line 3 Game logic returns with confirmation 4 Internet is notified 5 UI is updated 6 Repeat until no more blocks can be completed Exceptions: Handle network issues Game Players can exit any time Game Play must stay within game borders Stimulus: Playing game Response: Grid and score updated Comments: Game Players each have their own color on the grid, their blocks will have the same color. Game Players can only select lines which haven t been selected yet On each successful block completed, block needs to be colored in Game player gets another turn if block was completed With each block completed, score gets updated Game player can only make a selection if its his/her turn Repeat steps until all blocks are completed and game is over Use case Sequence diagram

10 3.3 End Game Use Case ID: 3 Use Case Name: End Game Actors: Game Player Preconditions: Game has already started Post conditions: Game completed Normal Flow: 1 User completes game 2 All blocks are selected 3 Scores are updated 4 Exit game 5 Go to game menu Alternate Flow: 1 User exits game before game completion 2 Notify opponent (internet) 3 Go to game menu Exceptions: Handle network issues Game info should be cleared on all exits When exit selected should be challenged to confirm exit Stimulus: User finished playing the game Response: Return to the game menu Comments: When the Game players have completed the game they should be presented with the final score and highlighting the winner s details The exit button should be available and should send them to the game menu From the game menu they can exit the game or start a new game.

11 3.3.1 Use case Sequence diagram 3.4 Getting Help Use Case ID: 4 Use Case Name: Getting help Actors: Game player Preconditions: Help button was selected Post conditions: Help text is displayed Normal Flow: 1 User selects help button available at all times during Game setup and Game play 2 An exit button will be available to go back to the previous screen Alternate Flow: none Exceptions: When selecting help during a game the user should return to the game state as it was before help was selected Stimulus: User needs assistance

12 Response: Return to previous game state Comments: The help file should contain the rules for the game The help file should contain setup and uninstall instructions The help file should indicate where else to go to get more information Use case Sequence diagram 3.5 Communicating over Internet setting up game Use Case ID: 5 Use Case Name: Communicating over the internet setting up the game Actors: Game Manager Preconditions: Game is requesting to join or start a game Post conditions: Game is set up and ready to be played by both players Normal Flow: 1 The game engine will make a call to set up the game info 2 The game engine will poll frequently to see if a user has joined the game 3 The game engine will make a call to accept or decline a user requesting to join the game

13 4 After accepting the user the game engine will make a call to make the first move Alternate Flow: 1 The game engine will make a call to get a list of games available 2 The game engine will poll frequently to see if a user has been accepted to play the game Exceptions: Handle network issues Game info should be cleared on all exits When exit selected should be challenged to confirm exit Stimulus: The Game Engine needs to set up the game to be played Response: The Game grid is set up and ready to be played Comments: The internet portion needs to be available at all times The game play moves need to be stored for a period of time Use case Sequence diagram

14 3.6 Communicating over Internet playing game Use Case ID: Use Case Name: Actors: Preconditions: Post conditions: Normal Flow: Alternate Flow: Exceptions: 6 Make Move Communicating over the internet playing the game Game Manager Game determined that a valid move was made and need to communicate and store value Data is saved on the internet for the next player to retrieve User makes a valid move None Handle network issues

15 Stimulus: A valid move was made Response: Game UI and state is updated accordingly Comments: The game engine is responsible for implementing the game rules. The internet only stores the game and game move values Use Case ID: 6 - Get latest move Use Case Name: Communicating over the internet playing the game Actors: Game Manager Preconditions: Game Manager is waiting turn and polling for the latest move from opponent Post conditions: Game needs to be updated accordingly Normal Flow: User requests latest move by opponent Alternate Flow: None Exceptions: Handle network issues Stimulus: Polling for latest move when waiting for turn Response: Game UI and state is updated accordingly Comments: The game engine is responsible for implementing the game rules. The internet only stores the game and game move values Use case Sequence diagram

16 4 External interface requirements 4.1 User Interface The Dots and Boxes game must make use of a Graphical User Interface. 4.2 Hardware Interface The Dots and Boxes application must cater for the following types of hardware interfaces on a mobile phone Key pad. Arrow keys. Touch Screen. Track ball or smart button. 4.3 Software Interface The software will be determined by the operating system it runs on. The requirement is for the game to function on a standard Nokia E72 device. 4.4 Communication Interface The software will require internet access in order to play the game. A Webservice will be used to facilitate that communication.

17 5 Non-Functional Requirements These requirements are all discussed in the architecture document. Refer to Appendix A for the information. 6 Other Requirements 6.1 License agreement The application will be provided under the Berkeley software distribution license (BSDL). The software and source code are provided as is for users to make use off as they wish. We do not take any responsibility for the software.

18 Appendix A: References These documents are all found under eport Document Name Architecture Document Location on Kenai DAB5_Architecture.pdf