Software Requirements Specification
Version 1
Revision History
| Date | Version | Description | Author |
| 12/03/03 | v1 | Most of section 1. | Paul |
| 15/03/03 | v1 | Most of section 2. | Andrew, Danny, Jon & Paul |
| 18/03/03 | v1 | Neatened HTML & CSS (so we'll be able to use Dreamweaver). | Andrew |
| 19/03/03 | v1 | Added to section 3 & made srs_interface.htm | Andrew |
| 21/03/03 | v1 | Talked about unresolved issues. | Andrew, Danny, Jon & Paul |
| 22/03/03 | v1 | Added changes | Paul |
| 23/03/03 | v1 | Reviewed changes | Andrew |
| 23/03/03 | v1 | Added changes | Jon |
| 23/03/03 | v1 | Reviewed changes | Jon |
| 04/03/03 | v1 | Wrote content for rules (as requested by Dmitry) | Paul |
| 05/04/03 | v1 | Made minor changes based on Dmitry's feedback & added srs_rules.htm | Andrew |
NOTE: This is an outdated version of the SRS (kept only for record-keeping purposes) - srs_v2.htm is the newer version.
Table of Contents
Software Requirements Specification
NOT REQUIRED.
| Title | Report number | Date | Publishing organization | Sources references obtained |
| Pure Java2 | null | 1999 | SAMS | sockets, jdbc |
| Core Java V1 Fundamentals | null | 2001 | Sun Microsystems Press | coding |
| Core Java V2 | null | 2000 | Sun Microsystems Press | coding |
| Jupiters Blackjack manual | null | 1998 | Jupiters Ltd. | blackjack rules |
| Mastering XML | null | 1998 | Sybex | understand XML |
| Java 1.4: | null | null | null | java.sun.com |
NOT REQUIRED.
Product Perspective:
- A casino game (playing against the house for money)(V1) (8 points)
Product Functions:
- Multi-threaded server: separate thread is created for each game(V1) (2 points)
- Multi-threaded client: communication with a server is in a separate thread(V1) (2 points)
- Client-to-Client cha(V1) (1 point)
- Server based chat room(V1) (2 points)
- Saving and replaying game/recent transaction history to/from a file/database (V2) (5 points)
- Feature total = (20 points)
User Characteristics
- A user will have a persistent virtual personality consisting of a name, password and a bank roll.
- NOTE: This will be stored online in a database.
Constraints:
- a casino game (playing against the house for money)
- All coding must be done in JAVA 1.4
- 3-4 students per group
- Client-server architecture
- Server supported by a database (SQL)
- Multithreading (client or server or both)
Assumptions and Dependencies:
- A user is to only register one online virtual player
- local machine should have a Java Runtime environment
- network connection is required for more than one player.
Requirements Subsets:
- Using XML encoding/decoding of objects passed through tcp/ip sockets as base for client-server architecture
The functionality requirements of this game have been broken into four features:
- 3.1.1 - Creation of virtual players.
- 3.1.2 - Logging into the virtual casino and getting assigned to a table.
- 3.1.3 - Playing blackjack at a table.
- 3.1.4 - Online chat feature within the game environment.
Note that, all these requirements relate to version 1.01, and were used as a guideline for creating the user interface.
3.1.1 - Create New Virtual Player
A new user, at the startup screen, should be able to:
- 3.1.1.1) Create a new virtual player - user enters a unique player ID and a password.
- 3.1.2.1.1) The playerID entered by the user must be unique and the password must be between five and ten characters long. If so, a new virtual player is created (in the database) with a starting bankroll of $25,000 and the user is logged directly into the virtual casino. If not, an appropriate message appears, and the user can try again.
- NOTE: there is nothing stopping a single user from having more than one virtual player.
3.1.2 - User logs into virtual casino and gets assigned to a table
If a user has already created a virtual player, they should be able to:
- 3.1.2.1) Log into the main 'virtual casino' environment using their unique player ID and password.
- 3.1.2.1.1) The playerID and password must be valid. If so, the player is logged in the casino environment and his/her bankroll is retrieved. If not, error messages appear and the user must re-enter his player ID and password.
- 3.1.2.2) For version 1.01 the 'virtual casino' is just a decorative screen where the player has two options: to "view rules" (which merely hyperlinks to the complete rules) or "join a table". When the user clicks "join a table", he is automatically assigned to a table. The player may or may not be alone at this table depending on the number of vacancies at other tables.
- 3.1.2.2.1) NOTE: In a later version, each player may be given some option as to which table he/she join.
3.1.3 - User plays blackjack at a table
Once the player has been assigned to a table (thread), he/she should be able to play in the very next round of blackjack:
- A set of blackjack rules are available in Appendix A: Game Rules. Gameplay should follow these rules quite accurately, with a few noticeable exceptions:
- Each table will have only 4 boxes.
- Each player will only be allowed to split once.
The basic sequence of the game is as follows:
- 3.1.3.1) A player enters a bet (between min and max bets for that particular table) and the bet is submitted when a 10 second timer expires.
- NOTE: The interface will be designed such that it is impossible for the user to bet outside of the min and max bets or exceed his/her bankroll.
- Effectively, a player is forced to bet every round (and that amount is immediately deducted from his/her bankroll), unless he/she leaves the table.
- NOTE: A player who is away from his/her keyboard must either leave the table, or else risk losing money each round.
- 3.1.3.2) An initial set of cards are deal out (two cards for each player and one card for the dealer).
- 3.1.3.3) Next, each player (in sequence) takes turns.
- If it's the user's turn, he is presented with a set of options. Depending on the values of the user's cards and the dealer's cards, these options may include a combination of:
- hit
- stay
- split
- double
- insurance
- The user will keep taking turns until he/she decides to stay (on his/her last hand), or goes bust (on his/her last hand).
- NOTE: If a player splits, he/she will have two hands, and plays one hand after the other. Due to the amount of space on a screen, this blackjack game will only ever let a player split once - i.e. a player will never have more than two hands.
- If the user fails to make a decision before a 10 second timer runs out (and is therefore delaying the game for other players), he will be forced to stay on that hand.
- If it's not the users turn, he/she waits and watches as another players undergoes the same process.
- 3.1.3.4) The dealer takes its turn
- NOTE: Rules for the dealer are fixed. The dealer's turn is over when its hand goes bust, or totals seventeen or greater (see Appendix A).
- 3.1.3.5) The outcome of the game is then calculated.
- For each hand, the end result is one of the following:
- win - the player gets back twice the money he/she bet.
- NOTE: If a player's hand wins with a blackjack (i.e. two cards totaling twenty one), he/she gets back 2.5 times what he/she bet.
- lose - the player loses his/her money.
- push - the player gets his money back.
- The results of the round will update the players bankroll and this will be securely stored (in the database).
- If a players bankroll decreases to $0, he/she will see a message (along the lines of "you're bankrupt") and is forced to leave the table - he/she goes straight back to the virtual casino environment.
- his/her bankroll is then reset back to the starting bankroll (to save him from having to create a new virtual player).
- 3.1.3.6) All cards are removed from the table and the next round starts.
Other in-game options:
- 3.1.3.7) At any time a player can hit "leave table".
- If the player leaves the table while he has an outstanding bet, he/she will instantly forfeit that money.
3.1.4 - Online chat feature within the game environment
- 3.1.4.1) While a player is assigned to a table he/she should be able to chat to all of the other players at that table.
- 3.1.4.1.1) At any stage of the game the user can type a message into a text box, and when he/she hits enter (or presses send), and the other players at that table will see the message appear.
- 3.1.4.2.2) A user should also have the option to send a private message to a particular player by clicking his/her name on the list and clicking "private message".
3.2.2 Foolproof use
- 3.2.2.1) This program should be able to deal gracefully with:
- 3.2.2.1.1) Players who get disconnected suddenly (without logging off)
- 3.2.2.1.2) Players who take too long to make their turn.
3.3.1 Client-side
3.3.2 Server-side
3.4.1 Client-side Program Requirements
- 3.4.1.1) Should be able to run on any PC that supports 800 x 600 pixel resolution in more than 256 colours.
- 3.4.1.1.1) Estimated min. requirements: 200MHz, 32MB RAM computer.
- 3.4.1.1.2) Most of the in-game calculations should be done by the server - all the client computer needs to do is repaint the images.
- 3.4.1.2) Will need an average speed Internet connection (or better).
- 3.4.1.2.1) Estimated min. requirements: 28 kbps modem Internet connection.
- 3.4.1.2.2) NOTE: the initial testing platform of this game will probably be client-to-server via a university's Ethernet LAN, and single PC acting as both client and server.
3.4.2 Server-side Program Requirements
- 3.4.2.1) Should run on an average PC (i.e. approx. 500MHz, 128MB RAM).
- 3.4.2.1.1) However, the performance of the server-side program depends on the client-generated traffic. If too many clients are playing blackjack simultaneously on our server, a mid-range PC would be unable to maintain the required number of table threads.
- 3.4.2.1.2) Conservative estimate: a 500MHz with 128MB RAM computer should be able to support up to ten clients (two or three table threads) quite comfortably. This will be benchmarked during project development.
- 3.4.2.2) Should be connected to the Internet (or which-ever the clients reside) via a fast connection, or at least a TCP/IP network.
- 3.4.2.2.1) A slow (28kbps) modem connection to the Internet, may serve as a bottleneck.
- 3.4.2.2.2) Conservative estimate: a 56kbps modem connection (from the server to the nearest ISP) would mean any more than four clients would make the game too slow to play
N/A
3.9.1 User Interfaces
- 3.6.1.1) See screen shots.
3.9.2 Hardware Interfaces
N/A
3.9.3 Software Interfaces
N/A
3.9.4 Communications Interfaces
N/A