Online Chess Game

Online Game Chess
Software Requirements Specification
Version 1.0
Student Id:
BC100400197
Group Id:
F130284421
Supervisor Name:
Sir Tanweer Arshad

Revision History
Date Version Description Author

(dd/mm/yyyy)
21/11/2013 1.0 SRS for Online Game Chess.BC100400197
Chess is a two-player game which
is played on a chessboard. Chess
comprises on 64 squares arranged
by eight rows and eight columns. It
is very popular games played
internationally by millions of
people
Table of Contents
1. Scope (of the project)
2. Functional Requirements Non Functional requirements
3. Use Case Diagram
4. Usage Scenarios
5. Adopted Methodology
6. Work Plan (Use MS Project to create Schedule/Work Plan)
SRS Document
Scope of Project:
Chess is a two-player game which is played on a chessboard. Chess comprises on 64 squares arranged by
eight rows and eight columns. It is very popular games played internationally by millions of people. This
document explains all features, functions, and constraints of this program. This Chess game is built to allow
remote users to play each other in chess. Its main focus is just to let people play; as users log into the system they
are paired with the first available player and can proceed. The program needs to be intuitive, reliable, and easy to
use. The scope of this project is to provide chess game that is intuitive and entertaining for players of all skill
levels. The game also provides some useful features, such as the ability to save a game and return to it later. In
general, it focuses on providing a simple, streamlined playing experience.
Functional and non Functional Requirements:

Functional requirement define the software functionality of product from the system’s perspective that the
developer must build to enable the users to accomplish their task stated in the user requirement. Non-functional
requirement describe services provide by system along with constraints under which the system operate.
Functional Requirements:-
For defining the requirement in terms of system’s perspective I divide the players into three categories, which are
given below:
 Guest
 Registered user
 Administrator
I describe functional requirement of all user as given below:
Guest:
 System facilitates the user the Guest player to create new account.
Registered User:
 System facilitates the registered user to sign in.
 Registers user select competitor from the available list of competitor and send him/her request to play.
 Register user should play the game in the fix time control (maximum 30 minute for each game).
 User start game, make moves, capture pieces, save games rules for them are given as
Movement:-
Bishop: Bishops shall move diagonally any number of spaces unless impeded by another piece.
Rook: Rooks shall move vertically or horizontally any number of spaces unless impeded by another piece.
Queen: Queens shall move vertically, horizontally, or diagonally any number of spaces unless impeded by another
piece.
When making these moves the bishop, rook or queen may not move over any intervening pieces.
Pawn: Pawns shall move one space forward, optionally two spaces forward on their opening move. The pawn
may move forward to the unoccupied square immediately in front of it on the same file, or alternatively it may
advance two squares along the same file provided both squares are unoccupied, or the pawn may move to a square
occupied by an opponent’s piece, which is diagonally in front of it on an adjacent file, capturing that piece. A pawn
attacking a square crossed by an opponent’s pawn which has advanced two squares in one move from its original
square may capture this opponent’s pawn as though the latter had been moved only one square. This capture is
only legal on the move following this advance and is called an ‘en passant’ capture. When a pawn reaches the rank
furthest from its starting position it must be exchanged as part of the same move on the same square for a new
queen, rook, bishop or knight of the same color. The player’s choice is not restricted to pieces that have been
captured previously. This exchange of a pawn for another piece is called ‘promotion’ and the effect of the new
piece is immediate.
Knight: Knights shall move two spaces either vertically or horizontally followed by one space perpendicularly.
King: Kings shall move one space in any direction. The king can move to any adjoining square not attacked by
one or more of the opponent’s pieces.
Castling: When requirements are met for castling, kings may move two spaces towards a rook, with the rook
moving onto the space crossed over by the king.
Capturing:-
General Capture: If a piece other than a pawn, moving in its normal fashion, may move into a square occupied
by an opposing piece, the friendly piece may capture the opposing piece.
Pawn: Pawns shall capture by moving forward one space diagonally into an opposing piece.
En Passant: When requirements are met for en passant capture, a pawn may capture as above into a space
crossed, but no longer occupied by an opposing piece.
Promotion:-
Promotion: A pawn, having entered the rank opposite where it started, shall be promoted to a piece of its
controller's choosing.
Move Legality
Legality: A move shall be deemed illegal if it does not follow the above rules or would cause the moving player's
king to become in check.
Game Saving/Loading
 A user shall be able to save his/her game.
 He shall be able to load his game from a save file, even if he/she is on a different computer than the one
where the game was originally saved.
 A save game shall contain the following information:
 The positions of each user's pieces.
 Whose turn it is.
 The most recent move made.
Administrator
 System allows the administrator to sign in.
 System allows the administrator to allow/reject new player request.
 System allows the administrator to manage records of each individual player.
 System provides access to administrator to delete account of the registered user.
 System facilitates the administrator to sign out.
Non Functional Requirements:

 Base and pieces must not be overly large.
 User interface must be comparable to computer/game console chess games
 Pieces controlled and piece movement system must move seemingly magically.
 The game will have no more than a 3 second lag between user input and response.
 The various validations to test whether a move is valid have to be performed within a time constraint to
allow acceptable game play.
Use Case Diagram(s):

Usage Scenarios:
Guest:
Use Case Title Create Account

Use Case Id UC01
Actor Guest
Desecration :
The Guest wants to create an account in Online Chess Game to become a Registered User.
Pre Conditions:
The Guest has properly turned on the system and connected to Chess Game.
Task Sequence Exceptions

1. The use case starts when the user opens the Chess game and wants to None.
create an account in Chess game.
2. User press the create account tab in page.
3. System response giving empty spaces for information.
4. The user fills needed information.
5. After filling all needed information the user press button submit.
6. System response message is your account has been made. If user feed
incorrect / missing information system identifies and account page
reopen and the process repeated until account made successfully.
7. The use case end.
Alternate Scenarios:
3-a: The user closes the logon page.
Post Conditions:
New account has been created in the Chess game and does all the authorized operations to which he / she
HAVE rights.
Modification history: November 27,2013
Registered User:
Use Case Title Sign in

Use Case Id UC02
Actor Registered User, Administrator
Desecration :
The Registered user wants to log on to the Chess game
Pre Conditions:
The user has properly turned on the system and connected to the Chess game.

1. The use case starts when the user comes and wants to log in to Chess 1. The user enters
game wrong ID or
2. The system asks the registered user to enter his /her ID and Password Password. Then the
to log in. system will generate
3. The user enter his/ her ID and password and click appropriate button an error message and
4. The system verifies the User ID and password and logs the user to asks again for User
his /her personal account. Exception 1 ID and password.
1- Go to step 2
Post Conditions:
The Registered user has logged on to the Chess game and does all the authorized operations to which he /
she HAVE rights.
Use Case Title New game

Use Case Id UC03
Actor Registered User
Desecration :
The Registered User wants to play a new game of Chess on the website.
Pre Conditions:
The User has properly turned on the system and log in to the Chess Game website.

1. The use case starts when the user log in to Chess game and wants to none
play a new game of Chess
2. The User click on New Game tab.
3. The system responds by asking about wants to play new game.
4. The User confirms and system start new game.
Post Conditions:
The user selected a new game and does all the authorized operations to which he / she HAVE rights.
Modification history: November 27, 2013
Use Case Title Choose Player

Use Case Id UC04
Desecration :
The Registered User wants to choose player for the Chess game.
Pre Conditions:
The user has properly turned on the system and log in to the Chess Game website.

1. The use case started when user want to choose player for chess game. None
2. Player click on the choose player tag.
3. The system respond by giving list of competitor based on rating from
which user select person which he /she want to play.
4. User selects the player and click ok.
5. This use case ends
Post Conditions:
The competitor has been selected by the player.
Use Case Title Send Request

Use Case Id UC05
Desecration :
The Registered User wants to send request to competitor.
Pre Conditions:
The User has properly turned on the system and log on into chess game.

1. The use case started when user want to send request to the selected None
competitor.
2. User clicks on the send request tag.
3. The system responds that the request has been accepted by the
competitor.
Post Conditions:
The user has successfully sent request to competitor.
Use Case Title Play game

Use Case Id UC06
Desecration :
The Registered User wants to play Chess game.
Pre Conditions:
The user has properly turned on the system and log in to the Chess Game website.

1. The use case starts when the user wants to play Chess game. None
2. The user click on the Play button to start the game.
3. The system draw chess board so that each player has his/ her pieces at
the bottom of her display.
4. This use case ends.
Post Conditions:
The game has been started and board has been made.
Use Case Title Select color

Use Case Id UC07
Desecration :
The Registered User wants to select color of piece in Chess game
Pre Conditions:
The user has properly turned on the system and log in to Chess game.

1. The use case starts when the user wants to select color of piece. None
2. The user select black or white colour of piece from the options.
Post Conditions:
The color of piece has been selected.
Use Case Title Select piece

Use Case Id UC08
Desecration :
The Registered User wants to select a piece in Chess game
Pre Conditions:

1. The use case starts when the user wants to select a piece. None
2. The player clicks a piece to select it.

Post Conditions:
The piece has been selected.
Use Case Title Make move

Use Case Id UC09
Desecration :
The Registered User wants to make move of the selected piece in the Chess game.
Pre Conditions:

1. The use case starts when the user wants to move the selected piece. The piece is no longer
2. The user clicks a piece to move it. The game displays the positions being there in the place
it can move to.
from where the piece is
3. The player selects the new destination by clicking. The piece is
moved. moved.
Post Conditions:
The piece has been moved and no longer be their in that place from where it is moved.

Use Case Title Checkmate
Use Case Id UC10
Desecration :
The Check for checkmate in the Chess game.
Pre Conditions:

None
1. The use case starts when the user wants to check for checkmate.
2. The system runs to check to determine if the player king is under check
from any enemy pieces. If so, the system shall examine whether there is
a check-mate and if not the system shall proceed to displaying the
results of the examination.
3. The system runs to check if the local player king can move to any square
that is not under check. The system shall then display the results of the
examination.
4. The system shall display a dialog box that the player has lost the game.
5. The system shall transmit a message to the opponent, stating the
outcome of the game.
6. The system shall allow the player to create a new game per the Start
Game use case.
Post Conditions:
The piece has been check for checkmate.
Use Case Title Next turn

Use Case Id UC11
Desecration :
The Registered User wants to make next turn in the Chess game.
Pre Conditions:

1. The use case starts when the user wants to make next turn.
2. If there is no checkmate the system allows the player can make a next None
move.
Post Conditions:
The player made a next turn.
Use Case Title End Game

Use Case Id UC12
Desecration :
The Chess game ends.
Pre Conditions:
1. The use case starts when the game ends. None
2. The system checks if the player king is under check from any enemy
pieces. If so, the system shall examine whether there is a check-mate
and if so the system ends game and display the result.
Post Conditions:
The game ends.
Use Case Title Save Game

Use Case Id UC13
Desecration :
The Registered User wants to save the Chess running game.
Pre Conditions:

1. The use case starts when the user wants to save the running game. None
2. The user clicks a save game option.
3. The system responds by asking about wants to save this game.
4. The Player confirms and system saves game.
5. The use case ends
Post Conditions:
The game is saved
Use Case Title Chat with player

Use Case Id UC14
Desecration :
The Registered User wants to chat with the competitor in the Chess game.
Pre Conditions:

1. The use case starts when the user wants chat with the competitor in the None
chess game.
2. The user clicks on the chat button.
3. The system responds by displaying chat dialog box.
4. The user write chat in the dialog box and press send button to send it to
competitor.
5. The use case ends.
Post Conditions:
The user will chat with his/her competitor.
Use Case Title Exit Game

Use Case Id UC15
Desecration :
The Registered User wants to exit the Chess game.
Pre Conditions:

1. The use case starts when the user wants to exit the chess game. None
2. The user clicks on the exit game button.
3. The system responds by asking about wants to exit from the game page.
4. The user confirms and system exit game.
5. The use case ends.
Post Conditions:
The game exit.
Use Case Title Sign out

Use Case Id UC16
Actor Registered User ,Administrator
Desecration :
The Registered User wants to log out of the Chess game
Pre Conditions:
The user has properly turned on the system and connected to the Chess game.

1. The use case started when user want to log out from Chess game. None
2. User clicks on the log out tab.
3. System log out the user from Chess game.
1- Go to step 2
Post Conditions:
The Registered user has logged out of the Chess game and does all the authorized operations to which he /
she HAVE rights.
Administrator Use cases:

Use Case Title Sign in
Use Case Id UC02
Actor Registered User, Administrator
Desecration :
The Registered User wants to log on to the Chess game
Pre Conditions:
The administrator has properly turned on the system and connected to the Chess game.

1. The use case starts when the administrator comes and wants to 2. The administrator
log in to Chess game enters wrong ID or
2. The system asks the administrator to enter his /her ID and Password. Then the
Password to log in. system will generate
3. The administrator enter his/ her ID and password and click an error message and
appropriate button asks again for
4. The system verifies the administrator ID and password and logs administrator ID and
the administrator to his /her personal account. Exception 2 password.
Post Conditions:
The Administrator has logged on to the Chess game and does all the authorized operations to which he / she
HAVE rights.
Use Case Title Accept Player request

Use Case Id UC17
Actor Administrator
Desecration :
The Administrator wants to Accept Player request from registered user in the Chess game.
Pre Conditions:
The administrator has properly turned on the system and connected to the Chess game site, user log in to Chess
game.

1. The use case starts when the administrator log in to Chess and wants to None
accept the user request from registered user.
2. Administrator accept button to accept the user request.
3. System responds by accepting the user request and shows the message
of accepting the user request.
Post Conditions:
The player request accepted in the Chess and does all the authorized operations to which team HAVE rights.

Use Case Title Reject Player Request
Use Case Id UC18
Actor Administrator
Desecration :
The Administrator wants to reject player request in Chess game
Pre Conditions:
The administrator has properly turned on the system and log in to the Chess game.

1. The use case starts when the administrator log in to Chess and wants to None
reject the user request from registered user
2. Administrator press reject button to reject the user request.
3. System responds by accepting the user request and shows the message
of rejection of the user request.
Post Conditions:
The team requested rejected.
Use Case Title Manage Record

Use Case Id UC19
Actor Administrator
Desecration :
The Administrator has to manage record.
Pre Conditions:
The Administrator has properly turned on the system and log in to the Chess.

1. The use case starts with the Administrator manage record. None
2. The Administrator has to update the list of rating of each player after
each game.
3. The Administrator has to manage the scores of each player after the
game.
1- Go to step 2
Post Conditions:
The record of the player has been managed.
Use Case Title Delete account

Use Case Id UC20
Actor Administrator
Desecration :
The Administrator wants to delete an account in Chess
Pre Conditions:
The Administrator has properly turned on the system and log in to the Chess.

1. The use case starts when the Administrator wants to delete an None
account.
2. The Administrator selects the account that he/she would like to
delete and directs the system to delete the information.
3. The system responds by asking the Administrator to confirm
deleting an account.
4. The Administrator confirms deletion.
5. Alternative Path: Cancel Action
6. A system responds by deleting account and notifying the
Administrator that the information was deleted from the system.
7. Uses: Record Transaction
Post Conditions:
The account has been deleted and no longer be there for use.
Use Case Title Sign out

Use Case Id UC16
Actor Administrator, Registered User
Desecration :
The Administrator wants to log out of the Chess game
Pre Conditions:
The Administrator has properly turned on the system and connected to the Chess game.

1. The use case started when Administrator want to log out from CFSS. None
2. Administrator click on the log out tab.
3. System log out the Administrator from Chess game.
Post Conditions:
The Administrator has logged out from the Chess game and does all the authorized operations to which he
/ she HAVE rights after log out.
Methodologies:
A software development methodology or System development in software engineering is a framework that is
used to structure, plan and control the process of developing the information system. Software engineering is the
practice of using selected process techniques to improve the quality of a software development effort. This is
based on the assumption, subject to endless debate and supported by patient experience, that a methodical
approach to software development results in fewer defects and, therefore, ultimately provides shorter delivery
times and better value. The documented collection of policies, processes and procedures used by a development
team or organization to practice software engineering is called its software development methodology (SDM) or
system development life cycle (SDLC).
I categorized this section into three parts which is as follows:

2.1. Existing Methodologies:
2.2 Adopted Methodology
2.3 Reason for choosing the Methodology
2.1 Existing Methodologies:

Following are the existing methodologies that are commonly used in software development projects
now days in IT industry,
I. Waterfall methodology
II. Spiral. methodology
III. Incremental methodology
IV. Rapid Application Development (RAD)
V. Extreme Programming
I. Waterfall methodology:
The Waterfall model suggest a systematic sequential development approach, in which development
is seen as flowing steadily downwards like a waterfall through the phases of requirements analysis, design,
implementation, testing or validation, integration, and maintenance. The water fall divide the project into
sequential phases with some overlap and splash reverse acceptable between phases. Emphasis is on planning, time
schedules, target dates, budgets and implementation of an entire system at one time. It is mostly use when project
is large and expensive having a clear objective and solution.
The modal of water fall methodology is given below:
II. Spiral Methodology:
This model was developed by Barry Boehm. The main idea of this model is to avert risk as there is always
an element of risk in development of software. Its frame type is combination of iterative and linear.
Spiral methodology is the combination of both design and prototyping-in-stages, in an effort to combine
advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral
development), it is a systems development method (SDM) used in information technology (IT). These approaches
basically focus on risk assessment during the project for this.
Purpose it divide the project into smaller groups. The four things during the project
 Determine the requirement.
 Design the system.
 Build in stages.
 Test and evaluation.
The spiral methodology reflects the relationship of task with rapid prototyping it has concurrency in design and
builds activities. The modal for spiral methodology is given below:
Determine Identify and

objectives, resolve risks
alternatives,
constraints
Develop
and verify
Plan Next next-level
Phase product
III. Incremental methodology:
This methodology is simply reducing the risk of project by breaking down the project into smaller
segments. Actually this methodology is opposed to the waterfall model; a series of mini project is performed
where all phases of waterfall development are completed before the next iteration. It uses both approaches water
fall and iterative.
IV. Rapid Application Development (RAD):

This modal mainly focuses on the understanding and capturing the user requirements. It is the software
development methodology which involves iterative development and construction of prototypes. This
methodology was first used by James martin in 1991.It has the following basic principles fast development and
deliver of high development system with low investment cost, it uses the iterative prototyping, active user
interface, and computerized development tools; it generally involve the joint application development; produce the
document for future development and maintenance.
V. Extreme Programming:
It is software development methodology which is responsive to customer requirement and intended to
use to improve in software quality. This methodology was created by Kent Beck during his work on the Chrysler
Comprehensive Compensation System (C3) payroll project. In this approach user requirements are captured.
Duration and cost estimate of the story then carried out. Stories for next build are selected. Then next step is
division of each build into tasks. Testing which is most important part of any software development methodology
is carried out task wise and drawn up first before and development and continues testing is performed through life
development process. Extreme Programming emphasizes teamwork. Managers, customers, and developers are all
equal partners. Extreme Programming improves a software project in five essential ways; communication,
simplicity, feedback, respect, and courage The important elements of XP includes programming in pair, doing the
extensive code review, unit testing of code, flat management system, simplicity and clarity in codes, expected
changes in code as per customer requirement. XP important feature is that its design based on cycle with customer
attachment through meeting so the change in customer requirement during the project is reduced as compared to
other traditional methodologies in which all requirements are specified at the start of project. In that way change in
customer stage may have great impact on cost of project. Some controversial aspects of XP are requirements are
define incrementally and express as automated acceptance tests, required to work in pairs (Pair programming).
Criticism on XP are as follows lack of defining the deliverables, it require senior level developer, impossible to
estimate the real work effort at the start of project it can increase in scope creep due to lack of detail requirement
documentation.
The modal for XP is given below:
Architectural User stories

spike
Release Iteration Acceptance

Planning test
Spike Small release
2.2 Adopted Methodology

For my project i adopt the methodology which is combination of Water fall and spiral models. This modal is
known as VU Process modal. It takes advantages of both approaches to minimize the drawback of both
approaches. As we know that waterfall methodology offers an orderly structure for software development,
demands for reduced time-to-market make its series steps inappropriate and it has linear approach while the spiral
giving the frame work iterative and linear. The spiral methodology reflects the relationship of tasks with rapid
prototyping, increased parallelism, and concurrency in design and builds activities. It is a meta-model, a model
that can be used by other models. Focus is on risk estimation and on minimizing project risk by breaking a
project into smaller segments and providing more ease of change during the development process, as well as
providing the opportunity to evaluate risks consideration of project maintenance throughout the life cycle. The
spiral method should still be planned methodically, with tasks and deliverables identified for each step in the
spiral. The Waterfall model is a sequential development approach, in which development is seen as flowing
steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation,
testing (validation), integration, and maintenance. The other idea of this model is to avert risk as there is always
an element of risk in development of software. We define steps to see the VU process modal in ordered way.
Steps are given below
Step 1: Defining problem opportunities and objectives
In the first step we define problems and objectives which are in this project. We define problems which are
arise in creating the project and also define objective of the project. The project is Online Game Chess. The
objective of this project is to share the board between two players.
Step 2: Analyzing system needs
In this step we analyze what are the system needs. We analyze what tools are required for preparation of this
project.
Step 3: Designing the recommended system
In this step we design Chess game system with the help of that information which we collect in earlier steps.
Step 4: Developing and documenting software
In this step we develop Chess game system.
Step 5: Testing and maintaining the system
In this step we test the system before it can use. If there are some problems arise in the system then we solve
these problems before implementing.
Step 6: Implementing and evaluating the system
In this last step we implement the whole project in our case Online Game Chess system with the help of this
information which we collect in earlier stages.
2.3 Reason for choosing the Methodology

In this modal we focus on risks, not meeting the user requirement and missing of schedule targets.
Requirement exists for strong approval and documentation control. Emphasis is on planning, time schedules,
target dates, budgets and implementation of an entire system at one time. It has an orderly sequence steps in the
project. This approach provides more room for iteration due to spiral methodology. It enhances the high risk
avoidance. Functionality and implementation has equal priority. This modal is document driven modal due to
waterfall modal. It generates documentation which is complete and comprehensive documentation and hence it
makes maintenance task much easier. This modal can only be used for large scale software development but for
internal software this method can also be used.
Work Plan (Use MS Project to create Schedule/work Plan)

Online Chess Game

Uploaded by

Copyright:

Available Formats

Online Chess Game

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online Chess Game

Uploaded by

Copyright:

Available Formats

Online Game Chess

Software Requirements Specification

Sir Tanweer Arshad

Date Version Description Author

1. Scope (of the project)

2. Functional Requirements Non Functional requirements

3. Use Case Diagram

6. Work Plan (Use MS Project to create Schedule/Work Plan)

Functional and non Functional Requirements:

Non Functional Requirements:

Use Case Diagram(s):

Use Case Title Create Account

Task Sequence Exceptions

Modification history: November 27,2013

Use Case Title Sign in

Task Sequence Exceptions

Use Case Title New game

Task Sequence Exceptions

Modification history: November 27, 2013

Use Case Title Choose Player

Task Sequence Exceptions

Modification history: November 27, 2013

Use Case Title Send Request

Task Sequence Exceptions

Modification history: November 27,2013

Use Case Title Play game

Task Sequence Exceptions

Use Case Title Select color

Task Sequence Exceptions

Modification history: November 27,2013

Use Case Title Select piece

Task Sequence Exceptions

2. The player clicks a piece to select it.

Modification history: November 27,2013

Use Case Title Make move

Task Sequence Exceptions

Modification history: November 27,2013

Task Sequence Exceptions

Modification history: November 27,2013

Use Case Title Next turn

Task Sequence Exceptions

Modification history: November 27,2013

Use Case Title End Game

Modification history: November 27,2013

Use Case Title Save Game

Task Sequence Exceptions

Modification history: November 27,2013

Use Case Title Chat with player

Task Sequence Exceptions

Modification history: November 27,2013

Use Case Title Exit Game

Task Sequence Exceptions

Modification history: November 27,2013

Use Case Title Sign out

Task Sequence Exceptions

Modification history: November 27,2013

Administrator Use cases:

Task Sequence Exceptions

Use Case Title Accept Player request