Author: Donna Stidolph

1 Introduction *

2 Overall Description *

3 Specific Requirements *

Figure 1-1 - Definitions, Abbreviations and Acronyms *

Figure 2-1 - Dots & Boxes State Transition Diagram *

Figure 3-1 - Initialization Sequence Diagram *

Figure 3-2 - Restart, Quit, Help Sequence Diagram *

Figure 3-3 - Line Select Sequence Diagrams *

Figure 3-4 - Invalid Line Selection Sequence Diagram *

Figure 3-5 - Win Game Sequence Diagram *

1. Introduction
1. Purpose

This document provides all the requirements for the Dots & Boxes computer game. Parts 1 and 2 primarily describe the behavior of the game from the user's perspective. Part 3 allocates the required behaviors to software requirements.

 

2. Scope

This document covers the requirements for release 1.0 of Dots & Boxes. Throughout the document, requirements will be identified as defining and distinguishing. The purpose of this is to guide designers in developing an architecture that can accommodate planned enhancements.

3. Definitions, Acronyms and Abbeviations

Term	Definition
Defining requirement	A requirement describing a behavior of the application such that if the behavior is absent, the problem is not solved. In Dots & Boxes, the baseline consists of defining requirements only.
Distinguishing requirement	A requirement that offers additional functionality that sets this particular implementation apart from other possible implementations.
Dot	Denotes an intersection point on an 8 x 8 grid of dots and lines.
Boxes	Denotes "ownership" of a box formed by connecting dots.
N/A	Not Applicable
TBD	To Be Determined - decision that must be made eventually, but hasn't been made yet.
TBS	To Be Supplied - Missing item that hasn't been created yet, but will eventually be included.
OBE	Overcome By Events - no longer applicable due to some technical or programmatic action.
SRS	Software Requirements Specification
o/s	Operating system

Figure -1 - Definitions, Abbreviations and Acronyms

4. References

Dots & Boxes User Manual, version 1.0 - TBS.

Dots & Boxes Navigation Diagrams, version 1.0 - TBS

5. Overview of Effort

This program will be written in Java 2, version 1.3. Its primary target platform will be a Windows machine, running NT or Windows 95, 98 or ME. It will act as rule interpreter for the game of Dots and Boxes , for 2 people. The user interface will be point and click on graphical objects representing the dots. The boxes will be constructed of lines between the dots, and the "owner" of the lines and boxes will be indicated by color. Minimal help will be provided, in the form of a short description of the game, available via a pull down menu.

2. Overall Description

Dots & Boxes is a paper and pencil game that we propose to migrate to a computer form. Given a square or rectangular array of dots, two players take turns joining two adjacent dots with a horizontal or vertical line. When such a move adds the fourth side of a box, the player who did the deed claims the box (marking it with his or her initial) and must take an extra turn. If the same move closes two boxes, the player claims both boxes but still gets only one bonus move. A player who can complete a box is not obliged to do so. The game ends when all the boxes are taken. The player who closed more boxes wins.

We propose to develop a computer-based version of the game, which will support two humans playing each other. There is no intent to immediately implement a computer opponent in the game, since the strategy can be quite involved.

Dots and Boxes is currently in vogue among mathematician's and game theorists - a book about Dots and Boxes strategy was not only published this year, it was reviewed in Scientific American

1. Product Perspective

Dots and Boxes is most frequently used as a "time passing" game, but has been used by scientists and economists in strategic gaming and algorithmic development. Our implementation will automate the board creation and scoring process. The design of the game is intended to support expansion to include a computer opponent, to automate testing of various gaming strategies.

1. Concept of Operations

See Figure 2.1, Dots and Boxes State Transition Diagram, and Dots & Boxes Navigation Diagrams - TBS.



Figure -1 - Dots & Boxes State Transition Diagram

Dots & Boxes can be in one of the following states:

Game Board Set Up: The Game Board is being set up by the player. At this point, there are no player options, although planned enhancements include size of the grid, choice of colors and input of player names for scoring.

Waiting: The game is waiting for an input from the player. Possible inputs are "Quit", "Restart", "Help", or a line selection.

Line Processing: The game processes a line selection for validity and, if valid, to show correct player "ownership". If the line is valid, Box Detection & Processing is invoked. If the line is invalid, Input Error is invoked.

Box Detection and Processing: As each valid line is placed, the game looks to see if any boxes have been created by the addition of the line. If one or more boxes were created, the display is updated to show them, and Scoring is invoked. If all the boxes on the grid are filled, a "Game Over!, Player X wins" message is displayed. If no boxes are found, Player Selection is invoked.

Scoring: If new boxes are detected, the current player's score is incremented one point for each box created. After the score is updated, the new score is displayed and Player Selection is invoked.

Player Selection: Alternates line selection between two players.

Input Error: Displays error message, waits for operator acknowledgement.

Help: Displays game rules and computer game use directions. Help can stay active while other events are also active.

Quit: Causes orderly shut down of game.

Restart: Scores are returned to zero, all selected lines and boxes are cleared from the game board.

Pass: Passes the turn to the next player.

2. User Interface Concepts

The appearance of the game board will have an appearance similar to that shown in Figure 2.2. See Dots & Boxes Navigation Diagram (TBS). All interaction with the user will be through use of a mouse. The game board will be initialized with a grid consisting of dots and lines. Players will click the mouse on lines to select them. "Ownership" of the selected lines and any boxes that result from the line selection will be shown by color, with different colors for unselected, Player 1 and Player 2.

3. Hardware Interfaces

The computer must have a mouse.

4. Software Interfaces

Dots & Boxes must run under the Windows NT and Solaris operating systems.

5. Communications Interfaces

None. No networked extension of Dots & Boxes is envisioned.

6. Memory Constraints

TBD

7. Operations

None identified.

8. Site Adaptation Requirements

None identified at this point, although due to the requirement to run under two operating systems, there may be o/s specific activities required.

2. Product Functions
1. Initialize Use Case

Actor: Player

1. Player invokes Dots & Boxes from command line window.
2. Dots & Boxes displays Game Board with no lines selected, puts all controls in a "ready" position (Quit, Restart, Help, Pass are all available) and waits for player input.

1. Select Line Use Case

Actor: Player

1. Player selects line between two dots.
2. Dots & Boxes displays line in Player's color.
3. Dots & Boxes checks to see if the line completes a box.
4. If a box was not completed, Dots & Boxes makes it the other player's turn to select lines.
5. If a box was completed, the box is colored to show ownership, the scores are updated and the game board is checked for completion.
6. If the board is not complete, the original player continues to select lines until he/she cannot make any more boxes or he/she elects not to select a line (Pass).

1. Win Game Use Case

Actor: Player

1. Player selects line that causes all the boxes on the grid to be filled.
2. Dots & Boxes detects board complete state, displays "Game Over" message.

1. Help Use Case

Actor: Player

1. Player selects "Help."
2. Dots & Boxes displays game rules and computer game controls in separate area. Help can remain visible during play of the game.

1. Quit Game Use Case

Actor: Player

1. Player selects "Quit."
2. Dots & Boxes displays confirmation window.
3. Dots & Boxes closes all open windows and exits.

1. Restart Game Use Case

Actor: Player

1. Player selects "Restart."
2. Dots & Boxes returns game board to initial state: score is cleared, all selected lines and boxes are returned to their original state.

1. User Characteristics
1. Favored Users

Favored users are those users for whom the game was developed. Favored users are those users who

1. know enough about computers to invoke Dots & Boxes from the command line and to use the mouse with no instruction,
2. are able to read English, the language of the Help displays,
3. are familiar with the Windows GUI conventions so they will understand the use of the various controls.

1. Ignored Users

The needs of the following user communities have not been and will not be considered in setting the requirements for Dots & Boxes:

1. disabled users unable to use a mouse,
2. non-English speakers,
3. non-computer literate users

1. Disfavored Users

Disfavored users are those who may use Dots & Boxes to gain inappropriate or illegal access to a computer system. No action is currently being taken to discourage disfavored users.

2. User Inclusion Strategy

The users will be included by limited interaction, that is, we will ask representatives from the favored user group to periodically run our game. While they are using the game, we will watch their behavior to notice things that appear to be unclear or incorrect. At the end of the game session, we will ask for their comments on the game.

1. Constraints

Dots & Boxes must run on both the Sun and Windows machines in Baskin 105 and 213. Operating system and hardware details TBD.

All work; analysis, design and implementation; must be accomplished by end of quarter.

 

2. Assumptions and Dependencies

None identified.

3. Apportioning of Requirements

The requirements described in Sections 1 and 2 of this SRS are referred to as "C" requirements; those in section 3 are referred to as "D" requirements. The primary audience for the C requirements is the customer (Linda Werner) and primary audience for the D requirements is the developer. The C and D requirements are intended to be consistent, and inconsistencies that are noted are defects. If a conflict arises between C and D requirements, C requirement will take precedence since they are ones that have formed the basis of customer understanding.

Requirements are designated as "defining" or "distinguishing" in Section 3. All defining requirements will be implemented in release 1. As many distinguishing requirements will be implemented as time allows. However, the architectural design will include all requirements, both defining and distinguishing to promote ease of future extensability.

1. Specific Requirements
1. External Interface Requirements
1. User Interface

See Dots & Boxes User Manual and Dots & Boxes Navigation Diagrams. TBS

2. Hardware Interfaces

Interface is through a mouse.

3. Software Interfaces

Dots & Boxes must operate under both Window NT and Solaris operating systems. Details TBS.

4. Communication Interfaces

None.

2. Specific Requirements
1. Sequence Diagrams

Figure -1 - Initialization Sequence Diagram



Figure -2 - Restart, Quit, Help Sequence Diagram

 



Figure -3 - Line Select Sequence Diagrams

 



 

Figure -4 - Invalid Line Selection Sequence Diagram

 



Figure -5 - Win Game Sequence Diagram

2. Classes for Classification of Requirements

The following classes will be used for partitioning requirements:

1. GameBoard
2. Line
3. Box

The requirements allocated to each of the classes are described in detail in the following paragraphs.

The GameBoard manages the entire game. The lines are the active elements that players select to form the squares and score points. The boxes are the result of line selection.

The GameBoard "holds" the entire game: the dot grid on which the game is played, the controls, the score boxes, the lines that connect the dot grid and the boxes that are created when four lines form a box. There is only one GameBoard for the game.

3.2.GB Attributes

The GameBoard shall have the following attributes:

1. Active Player
2. Controls: Restart, Pass, Quit, Help
3. Game Grid
4. Dots image
5. Player 1 Score
6. Player 2 Score

The GameBoard shall display on start up a grid of dots. The default value will be 8 x 8.

GB 1a Dot Grid [Distinguishing]

At initiation, the GameBoard shall query the user for a square grid size and create a grid based on the player input.

3.2.GB 2 Dot Image [Distinguishing]

The dots will be inactive graphical objects contained in a gif file called "dot.gif". The image used for representation of the dots can be changed by changing the contents of the dot.gif file.

3.2.GB 3 GameBoard Initial State [Defining]

On initialization, the GameBoard shall display the following:

1. A dot grid, with the dots connected by Line objects (see below for definition of Lines).
2. Restart control
3. Pass control
4. Quit control
5. Help control
6. Player 1 score box, score set to 0.
7. Player 2 score box, score set to 0
8. Status message directing Player 1 to begin play

See User Manual for sample display.

On initialization, the GameBoard will display a Restart control. The Restart control can be activated at any time. Invoking the Restart control will have the following effects:

1. Both player's scores will be set to zero.
2. No boxes will be displayed on the grid.
3. The colors of the grid lines will all be one color, and the color will not be that that indicates "ownership" of the line by a player.
4. See Dots & Boxes User Manual for general display format.

On initialization, the GameBoard will display a Help control. The Help control can be activated at any time. Invoking the Help control will cause the display of a text display containing the rules of the game and effect of the Dots & Boxes controls on the state of the game.

The Help narrative will continue to be displayed until a player closes the display. Game play can continue in the presence of the Help narrative.

On initialization, the GameBoard will display a Quit control. The Quit control can be activated at any time. Invoking the Quit control will cause a confirmation control to be displayed. If a player uses the confirmation control to reaffirm the decision to quit the game, the game will shut down.

On initialization, the GameBoard will display a Pass control. The Pass control can be activated at any time. Invoking the Pass control will cause the turn to be passed to the other player.

On initialization, the GameBoard will display two score boxes, one for each player. The score boxes will be labeled with the player number. The player number will appear in the same color used to indicate that player's select lines on the game grid. The score boxes will initially be set to zero for both players.

If player id has been implemented, the score boxes will be labeled with the initial, in the color used for that player's lines.

When a box is detected, the score for the player whose turn it is will be incremented.

When a line selection does not result in a box, the GameBoard will change the active player status so that the next line will be selected by the other player.

When a line selection results in a box, the GameBoard will not change the active player status.

When a player invokes the Pass control, active player status will change to the other player.

The game will continue until all the squares in the grid are filled. The GameBoard will detect this condition and display an end of game message in the status area and identify the winner of the game.

If player identifications are known, the end of game message will identify the winner by initial.

3.2.GB 13 Status Display [Distinguishing]

The status display can display one of three messages:

1. Current player (normal state)
2. Game Winning message
3. Error message - line selected has already been selected, player must select an unselected line.

Each instance of a Line object will have the following attributes:

1. Color
2. Size
3. Horizontal location
4. Vertical location

Lines will be capable of detecting a mouse click. If a mouse is clicked on an un-selected line, the event will cause the line to turn the color corresponding to the player whose turn it is currently.

If a mouse is clicked on an already selected line (a line previously selected by the other player), the event will cause an error message to be displayed.

If line selection processing results in an error message, the GameBoard will be notified. The only error condition identified is a player attempting to select an already selected line.

Lines will be capable of coloring themselves in three colors. One color will represent lines that are unselected. At initialization or after restart, all lines will be this color. The second color will indicate that the line was selected by Player 1. The third color will indicate that the line was selected by Player 2. The colors are TBD.

Line size will be TBD x TBD

Each instance of a Box object will have the following attributes:

1. Color
2. Size
3. Horizontal location
4. Vertical location

Boxes will become visible to the players after all four lines surrounding a grid area have been selected by the same player.

Boxes will be capable of coloring themselves in two colors. One color will indicate that the box was made by Player 1. The second color will indicate that the box was made by Player 2. The colors will be the same as the colors selected for the Lines.

Box size will be TBD x TBD.

1. Performance Requirements
1. Usability

Dots & Boxes will be easy to use. This will be demonstrated by having a first-time user who meets the Favored User description play the game to completion, or until he/she elects to quit, with no interventions by the game developers, only use of the on-line help facility. The game will be initialized when the user begins the interaction.

2. Load Time

Dots & Boxes will take less than one minute to load and display the initialized game board, both at game initialization and restart.

3. Processing Time

Dots & Boxes will take less than 30 seconds to process any operator input. The worst case for this is believed to be the case in which line selection results in a box completion and a game completion.

2. Design Constraints/Decisions

Because of the requirements to run under multiple operating systems and because of the graphical nature of the game, Dots & Boxes will be programmed in Java and run as a Java application. Because the decision has been made to use Java, implementation details that might be deferred to design time have been incorporated into the requirements, i.e. use of JButtons for controls, selection of active components, etc.

3. Software System Attributes
1. Reliability

Dots & Boxes shall not fail in such a fashion as to require a restart (definition of "restart" is machine and o/s dependent) in three iterations of the System Test Procedure (TBS).

2. Availability

Dots & Boxes is designed to run as the only active application. The game is not required to shut down other applications on initialization, but Dots & Boxes' behavior is not guaranteed when running with other applications active.

3. Security

Not applicable

4. Maintainability

The Dots & Boxes design goal is that addition of a computer opponent will be possible.