Software Requirements Specification - Software Engineering | CS 451, Lab Reports of Software Engineering

Download Software Requirements Specification - Software Engineering | CS 451 and more Lab Reports Software Engineering in PDF only on Docsity!

Dragon Chess

Software

Requirements

Specification

For Chess Game Project – Version 1. Prepared by: Adedamola Mabogunje 1/27/

Table of Contents

January 27, 2009

Revision History

Name Date Change Version

Adedamola Mabogunje Jan 29 2009 Updated Introduction Removed Index Added Feature List

Alexander Gerveshi Feb 05 2009 Updated Specific Requirements

Dimitrios Yantsios Feb 05 2009 Numbered All Sections 0. Adedamola Mabogunje Feb 09 2009 Updated Sections: 1.3, 3.1, Appendix B, Issues List

Adedamola Mabogunje Feb 10 2009 Updated Sections: 2

January 27, 2009

1 Introduction

1.1 Purpose This requirements specification document is for the first release of our “Chess Game Project” version 1.0. The term “our” as used here refers to all members of Group 4 for the Software Engineering Course (C.S 451) in the winter class of 2009. The final product shall be a chess game for 2 players supporting game-play features as defined in “Let’s Play Chess.” The goal of the project is to create a customized cross-platform Chess game using the Java programming language such that it meets the specific needs of our clients. 1.2 Scope This document covers in detail all the feature requirements of the product, as well as all software and hardware specifications pertaining to what systems and in which contexts this product can be used. While more emphasis will be placed on feature, software and hardware specifications, all constraints and assumptions that affect or may potentially impact said specifications will be covered within this document as well. The document will not cover any specs outside of those defined above as this product is considered to be standalone. That is to say, it is neither part of a larger project, nor is future development planned for it beyond the completion of this particular version. 1.3 Definitions, Acronyms & Abbreviations There will be several terms and abbreviations used which assume that the reader has some expertise in the subject matter. There shall also be some acronyms used in order to save time and minimize wordiness of the document itself. Please find these listed below.  MVC: Model-View-Controller Architecture  PGN: Portable Game Notation  UML: Unified Modeling Language  GUI: Graphical User Interface  Specs: Specifications  Docs: Documentation  2D: 2 Dimensional 1.4 References  Let’s Play Chess: https://www.cs.drexel.edu/~yfcai/CS451/projects/ChessGame.pdf  Design Patterns: http://java.sun.com/blueprints/patterns/MVC.html  PGN Specification: http://www.very-best.de/pgn-spec.htm  Java 6 Reference: http://java.sun.com/javase/6/docs/

January 27, 2009

2 Overall Description

2 .1 Product Perspective This product is the first version of “Dragon Chess.” It is a standard Chess game that can be played over a network and supports Human VS Human chess matches. It is intended to be a standalone application and has not been designed to be a part of a larger game system. However, the system does incorporate a third party PGN parser library for the purpose of saving and loading data. Further information on the interfaces between the system and the parser can be found in sections 3.1.3 and 3.2. 2.2 Product Functions The final 2-player chess game product beyond the standard features as described in “Let’s Play Chess” shall support several standard game play features. Some of the key features shall be the ability to undo, draw, choose between multiple game types and also have support for saving and loading games. 2 player games shall be played over a network connection and shall support only human vs. human game play. While this document shall not cover the various stages in the development process, it is worth mention that the client has placed emphasis on certain features and these shall be identified in section 3.2. 2.3 User Characteristics This game is intended for use by everyone. The term “everyone” includes but is not limited to chess players of medium and beginner level. We focus primarily on medium and beginner levels because the game does not currently support some of the rules as used in tournament level chess or by expert/professional players such as the 50 move draw rule or a fixed time per turn. However, the game can still be played by such players and it is expected that it might be used by them. 2.4 Constraints This project’s development has the following constraints:  The design pattern is to follow the MVC model as defined by class policy.  Product development is to follow the “Agile Process Model” according to class policy. 2.5 Assumptions & Dependencies It is currently still an assumption that our current choice for a 3rd^ party PGN parser can support fully the PGN notation functionality. While research has been done on the notation itself to establish its applicability, range and ease of use, and limitations, we are still developing a prototype for using the parser. As of the time of edit of this document, this is the main assumption and dependency that will impact greatly on the save and load feature should we need to adopt another parser.

January 27, 2009

3 Specific Requirements

3.1 External Interface Requirements 3.1.1 User Interfaces The user interface shall primarily be a 2D representation of the Chess board. In addition to the chess board, there shall be a “for display only” log of moves made by both the black and white players. Interaction with the displayed Chess board shall be supported via both the mouse and keyboard. However, control of the movement of pieces shall be primarily delegated to the mouse with the keyboard being an optional form of input for players who prefer to use text based commands. Please refer to the Appendices for a preliminary mock-up of proposed user interface 3.1.3 Software Interfaces This product shall be interfaced with 2 other entities. The first is a 3rd^ party PGN parser that shall be used to support the save and load feature which will be described in the “System Features” portion of this document. While the parser shall be integrated into the very fabric of the system, as it is nonetheless an external component, it is worth mention here. The parser shall accept as input our pre-formatted PGN output as generated by the system. This preformatted output shall follow standard PGN notation without any deviations or modifications as described in the PGN Specs. The output of the parser shall be the current game state (as described in the file it loaded) and our system shall utilize this to build the game view. The second is the backend server using the network server communication method which is mentioned in the section below titled “Communication Interfaces.” 3.1.4 Communication Interfaces As the game allows for Human VS Human network play, the main communication interface shall be over a network. Input and Output shall be passed and received using Java’s built in Object Input/output Streams. Please refer to http://java.sun.com/javase/6/docs/api/java/io/ObjectInputStream.html under the Java 6 Docs for a more detailed description.

January 27, 2009 Time per Game Option

• The game shall always be of a fixed length. This length will be specified by the user
• If the time limit is reached, ??? Performance Requirements To do Design Constraints To do Software System Attributes To do Other Requirements To do

January 27, 2009

Appendixes

A: Glossary To do B: Analysis Models B.1 Preliminary UI

January 27, 2009 C: Issues List  This document remains highly incomplete however high priority updates include o Formalize & Complete Section 3.2: System Features o Add Use Case diagram to Appendices o Resolve exception cases for Timed games feature