KWAME NKRUMAH UNIVERSITY OF SCIENCE AND TECHNOLOGY

COLLEGE OF SCIENCE

DEPARTMENT OF COMPUTER SCIENCE

PROJECT TOPIC
SMART-CROSSING GAME

PROJECT SUPERVISOR
DR (MRS). KATE TAKYI

SUPERVISEE
MISS. RITA YEBOAH
MR. OSEI SYLVESTER

3.2.1-Functional requirements of the system

 Displaying a 3*3 grid: This grid is required to play the Tic-Tac-Toe game. It
is on this grid that the two players take turns marking the spaces as X and
O.

 Alternating between X and O players: This game requires two players

one playing as X and one playing as O (with X usually starting). To ensure
that a player does not play twice, switching between them is required.
 Determining the Winner of the Game: Once a player wins the game, the
message should displayed which player won. If no one won the game,
then it is a draw.

 Displaying Score Details: There must be three (3) columns for maintaining
the scores. One for each player and one for the games which were a
draw.

 Providing Option to Play Again: The game must provide an option either
to play again or to exit the game.

3.2.2 – Non-Functional requirements of the system

 Usability
Standard Graphic User Interface (GUI) builders are employed for the Smart-
Crossing Game clients. All code is written using Java to ensure that both the
clients and the servers of Smart-Crossing Game can execute on MacOS,
Linux, Un*x, Solaris and windows systems.

 Reliability
If the Smart-Crossing Game tournament server fails, all connected Smart-
Crossing Game clients are informed immediately about the situation, and
the Game is cancelled. The clients can elect to reconnect (but the server
may be permanently affected).

 There is no guarantee of continued service if a Smart-Crossing Game fails.

If a Smart-Crossing Game client fails, then the Game become forfeited. If a
disconnected client reconnects to the Game, he will only be able to
participate once all rounds in the tournament have completed.

 Performance
 The target measure for average round-trip communication between Smart-
Crossing Game clients and servers is 250ms. The performance measure is
not relevant to the initial start-up time. Given that the information content
of individual Games is quite small, we expect to be able to support 100s of
concurrent users within an individual tournament (we restrict our initial set
of users to more than 64).

 Supportability
New Smart-Crossing Game variations should be easily integrated into the
Smart-Crossing Game tournament code, regardless of the state of an active
tournament. Variations that are integrated after a tournament has started
are only available once the tournament completes all of it’s rounds, and
resets.

 Implementation
Java JDK 1 .5, together with the CMI implementation (tutorial to be made
available soon).

 Architectural Design of the Proposed System

Action
Controller

Player State Action

Logic
State
View

State
3.2- Requirements specification

 User interfaces
The user interface for the Smart-Crossing Game application is the Game
board. It is from this board that a user plays the game. On winning a
Game, it should a dialog box showing who the winner is.

 Hardware interfaces
Music system is interfaced to our game application.
 Software interfaces
An interface game board containing blocks for X and O’s for the player to
play the game is provided.