You are on page 1of 18

Software Requirement


Prepared by:
Mayra Aguas , Alfred Blackman, George D'Andrea,
Paul Vu, and Gurvinder Singh.

1.1 Purpose 1
1.2 Scope
1.3 Definitions.... 1
1.4 Overview 2
2.1 Product perspective
2.1.1 System interfaces
2.1.2 User interfaces
2.1.3 Hardware interfaces
2.1.4 Software interfaces
2.1.5 Communications interfaces 4
2.1.6 Memory constraints
2.1.7 Operations
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions & dependencies 4
2.6 Requirements Apportioning 4
. 5
3.2 User interface
. 5
. 12
4.2.1 Connect 12
4.2.2 Move
4.2.3 Redo
4.2.4 Resign
4.2.5 Save Log 15

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
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 opponents 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.

Queen: This piece can move in any number of spaces in any direction as long as no other piece is in its
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 players 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.

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.

2.1.1 System interfaces

CHESS software integrates two internal systems to provide functionality
Client CHESS software has an interface to the users 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

2.1.2 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.

2.1.3 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

2.1.4 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

Network CHESS software interfaces with the user computer and expect that it is capable of use TCP

2.1.5 Communications interfaces

Communication between the clients is facilitated by common network protocols using TCP/IP.

2.1.6 Memory constraints

CHESS software requires 1 gigabyte of RAM memory.

2.1.7 Operations
CHESS not provide backup or recovery operations.

2.2 Product functions

CHESS system will provide the following functions:

Record of Move timers

Records of moves made in this game so far.

Records of pieces that each player killed.

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

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

or the program is unacceptable!

Priority 2

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.

Priority 3

Lowest priority and not expected to be implemented in the current release.

0100 Users shall be able to connect via IP address. Priority 1
0110 Users shall be able to start a game once two users are connected. Priority 1
0120 Users shall be given the choice of who plays black and white. Priority 1
0130 Each user is to have their pieces start at the bottom of the board on their display. Priority 1
0140 The player playing white is first to move. Priority 1
0150 A player may forfeit at any time during gameplay. Priority 1
0160 A player must be given a confirm dialog before forfeiting. Priority 2
0170 Forfeiting shall end the game immediately. Priority 1
0180 The active player shall select a piece by clicking it. Priority 1
0190 When a piece is selected, all legal moves for that piece are highlighted. Priority 1
0200 When a piece is selected, the active player may select another piece by clicking it. Priority 1
0210 A selected piece must always belong to the active player. Priority 1
0220 The active player shall move the selected piece by clicking on any legal square. Priority 1
0230 The active player shall capture a piece by moving onto a legal square containing an opposing piece.
Priority 1
0240 Captured pieces shall be displayed in a captured pieces box. Priority 2
0250 The inactive player may request to undo the prior move. Priority 2
0260 There shall be no more than one undo request per turn. Priority 2

0270 An undo request shall be ratified by the active player. Priority 1

0280 When an undo request is accepted the game is reverted to the state of the board prior to the request.
Priority 1
0290 A player shall be able to save a log of the moves at any time. Priority 2

3.2 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
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

Figure 1. Default screen

Figure 2. User Connection

Figure 3. User lost screen

Figure 4. Chess piece captured

Figure 5. In the middle of a game

4 Use Cases
3.2.1 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).
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.

3.2.2 Move

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.

3.2.3 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.

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.

3.2.4 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.

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.

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