Software Requirement Specification. Chess. for. Prepared by: Mayra Aguas, Alfred Blackman, George D'Andrea, Paul Vu, and Gurvinder Singh.

Transcription

1 Software Requirement Specification for Chess Prepared by: Mayra Aguas, Alfred Blackman, George D'Andrea, Paul Vu, and Gurvinder Singh.

2 Contents: 1 INTRODUCTION Purpose Scope Definitions Overview 2 2 OVERALL DESCRIPTION Product perspective System interfaces User interfaces Hardware interfaces Software interfaces Communications interfaces Memory constraints Operations Product functions User characteristics Constraints Assumptions & dependencies Requirements Apportioning 4 3 SPECIFIC REQUIREMENTS User interface. 5 4 USE CASES Connect Move Redo Resign Save Log 15

3 1 INTRODUCTION 1.1 Purpose This document specifies all the requirements for the Chess game software. These requirements relate to the functionality, constraints, performance, attribute and the system interface. The Chess program is a program used to play game. First goal is to allow two users or players to play the game interactively from remote locations. And the second goal will be that the program should be working and allow the users to play the game. 1.2 Scope This document describes the software requirements for the Chess program. This document will be used by the end-users, tester, and developers of the game. 1.3 Definitions Bishop: one of two pieces of the same color that may be moved any number squares diagonally, as long as no other piece blocks its way. One piece always remains on White squares and the other always on Black. Castling: to move the king two squares horizontally and bring the appropriate rook to the square the king has passed over. Check: To make a move that puts the opponents King under direct attack. Checkmate: a situation in which an opponent s king is in check and it cannot avoid being captured. This then brings the game to a victorious result. Chess Board: A board you need to play Chess. Have 64 black and white square. Chess: A game played by 2 people on a chessboard with 16 pieces each. En Passant: a method by which a pawn that is moved two squares can be captured by an opponent's pawn commanding the square that was passed King: The main piece of the game, checkmating this piece is the object of the game. It can move 1 space in any direction. Knight: This piece can move 1 space vertically and 2 spaces horizontally or 2 spaces vertically and 1 space horizontally. This piece looks like a horse. This piece can also jump over other pieces. Pawn: One of eight men of one color and of the lowest value usually moved one square at a time vertically and capturing diagonally. Player or user: A user or a player will be the person that is playing the chess game.

4 Queen: This piece can move in any number of spaces in any direction as long as no other piece is in its way. Rook: one of two pieces of the same color that may be moved any number squares horizontally or vertically, as long as no other piece blocks its way. Stalemate: A situation in which a player s king is not in check, but that player can make no move. This then results is a stalemate, which is a draw. 1.4 Overview The rest of this document describes the system requirements for the Chess program.

5 2 OVERALL DESCRIPTIONS 2.1 Product perspective University students need an entertainment tool to enjoy and play with friends over the network. As described in section 1.2, of this document, CHESS intend to fill this need by providing a software allows entertainment with friends and over the network. Some software games allow playing games with people that you may not know, and often times require a monthly fee for the service System interfaces CHESS software integrates two internal systems to provide functionality Client CHESS software has an interface to the user s client to receiver user input and moves selections for the game Network CHESS software has an interface to the network in order to transmit information and connect players User interfaces CHESS includes an interface resembling a common chessboard. CHESS require Java 5 installed, memory space and storage space on the user computer to save data. Furthermore, the computer will need memory space because CHESS is only accessible to computers what had installed the application. However, CHESS is not portable and the clients will need to install one time the chess application on each computer that will be used to play. Connect interface is used by game players and display player information.as players make moves, the screen is updated to reflect the moves made in the game Hardware interfaces CHESS runs on any computer hardware meeting the following criteria: Capable to use TCP connections Includes Memory Storage Includes a mouse Includes a keyboard Software interfaces CHESS software integrates some external software to provide functionality Client CHESS software interfaces with the user computer and expect that it have java 5 environment installed

6 Network CHESS software interfaces with the user computer and expect that it is capable of use TCP connections Communications interfaces Communication between the clients is facilitated by common network protocols using TCP/IP Memory constraints CHESS software requires 1 gigabyte of RAM memory Operations CHESS not provide backup or recovery operations. 2.2 Product functions CHESS system will provide the following functions: 1 Record of Move timers 2 Records of moves made in this game so far. 3 Records of pieces that each player killed. 4 Records of valid moves around selected pieces. 2.3 User characteristics The user of CHESS need experience and be able to play chess at least a basic level. Furthermore, users needs to be very familiar and the comprehended chess rules. 2.4 Constraints CHESS may experience hardware limitations constrain for graphics and Java language requirements if installed in a not compatible computer. 2.5 Assumptions and dependencies CHESS is not platform dependence and can be installed in any operating system capable to run Java 5 environment. 2.6 Requirements Apportioning The priority levels for the requirements are: Priority 1 Highest priority. All items of this level must be implemented and verified

7 or the program is unacceptable! Priority 2 Priority 3 Requirements of this priority are expected to be implemented, but their omission will not result in an unacceptable program; so long as their omission does not affect higher priority components. Lowest priority and not expected to be implemented in the current release Users shall be able to connect via IP address. Priority 1 3 SPECIFIC REQUIREMENTS 0110 Users shall be able to start a game once two users are connected. Priority Users shall be given the choice of who plays black and white. Priority Each user is to have their pieces start at the bottom of the board on their display. Priority The player playing white is first to move. Priority A player may forfeit at any time during gameplay. Priority A player must be given a confirm dialog before forfeiting. Priority Forfeiting shall end the game immediately. Priority The active player shall select a piece by clicking it. Priority When a piece is selected, all legal moves for that piece are highlighted. Priority When a piece is selected, the active player may select another piece by clicking it. Priority A selected piece must always belong to the active player. Priority The active player shall move the selected piece by clicking on any legal square. Priority The active player shall capture a piece by moving onto a legal square containing an opposing piece. Priority Captured pieces shall be displayed in a captured pieces box. Priority The inactive player may request to undo the prior move. Priority There shall be no more than one undo request per turn. Priority 2

8 0270 An undo request shall be ratified by the active player. Priority When an undo request is accepted the game is reverted to the state of the board prior to the request. Priority A player shall be able to save a log of the moves at any time. Priority User Interface Figure 1 is the default state connected or just loaded, it will show the same default screen with chess pieces in their starting positions. Figure 2 depicts the dialog that appears when New Game is pressed and the user is to enter an IP address. Figure 3 shows the screen that users see when either of two conditions are met: the user presses Forfeit or the player loses by the definitions of the game. Figure 4 shows one white piece captured and the piece appears in the black capture box to the left. Figure 5 shows the game partially in progress with pawn pieces moved. User Interface is subject to change while in development

9 Figure 1. Default screen

10 Figure 2. User Connection

11 Figure 3. User lost screen

12 Figure 4. Chess piece captured

13 Figure 5. In the middle of a game

14 4 Use Cases Connect Preconditions: None Main Flow: User opens program and specifies the IP address of the user to whom she wants to connect (i). If the connection attempt is successful the players start a new game (ii). The players choose who will play black and who will play white (iii). The board is drawn so that each player has her pieces at the bottom of her display (iv). The game moves to the play game state with the white player as the active player (v). SubFlows: I. User opens program and connects to an opponent's IP address. II. Once there is a successful connection a new game is started. III. The players argue over color. IV. Each player sees the game board from the appropriate perspective. V. The game moves into the play game state with the white player as the active player Move

15 Precondition: During the Play Game state Main Flow: The active player clicks a piece to select it. The game displays the positions it can move to. The player selects the new destination by clicking. The piece is moved there if it is a valid move. Their opponent becomes the active player. Alternate Flow: The active player may decide to select a different piece by clicking one of their own. If there are no valid moves and the active player is not in check the game ends as a stalemate. If there are no valid moves and the active player is in check the inactive player wins Redo Precondition: During play game state, and an undo hasn't been requested this turn. Main Flow: The inactive player may request to undo their prior move(i). The active player is asked to accept(ii). If accepted the last move is reversed and the inactive player becomes the active player(iii). Sub Flows: I. The inactive player requests a redo.

16 II. The active player accepts. III. The prior turn is reverted and the inactive player becomes the active player. Alternative Flows: The active player does not accept the undo, play is resumed as usual Resign Preconditions: During the Play Game state Main Flow: At any time during gameplay, a player selects the forfeit option (i). The player then confirms their forfeit (ii). The game is immediately ended with the forfeiting player as loser (iii). Sub Flows: I. A player chooses to forfeit II. The same player confirms their forfeit III. That player loses and the game is over. Alternative Flow: The player decides not to confirm the forfeit. Game player resumes as usual.

17 3.2.5 Save Log Precondition: During play game state. Main Flow: At any time either player may save a copy of the move log (i). They are asked for a file location (ii). The move log is then saved using algebraic notation (iii). Sub Flows: I. User attempts to save. II. The user is asked to specify a file name and location. III. The log is saved at the specified location using algebraic location.

18 SRS Terms and Agreement We Group 1 and Group 4 agree to the terms and requirements that the other have set forth and will complete them to the best of our abilities by the end of this 10-week term. So say we all. Group 4 Mayra Aguas Alfred Blackman George D'Andrea Gurvinder Singh Paul Vu Group 1 Jason Economou Timothy McJilton Gabriel Schwartz Andrew Sherman Chaitra Chandapillai