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, 

• Revision History.......................................................................................................................................
• 1 Introduction
  • 1.1 Purpose
  • 1.2 Scope
  • 1.3 Definitions, Acronyms & Abbreviations
  • 1.4 References
  • 1.5 Intended Audience & Reading Suggestions
  • 1.6 Overview
• 2 Overall Description
  • 2.1 Product Perspective
  • 2.2 Product Functions
  • 2.3 User Characteristics
  • 2.4 Constraints
  • 2.5 Assumptions & Dependencies
• 3 Specific Requirements
  • 3.1 External Interface Requirements
    • 3.1.1 User Interfaces
    • 3.1.3 Software Interfaces
    • 3.1.4 Communication Interfaces
  • 3.2 System Features
    • 3.2.1 Save & Load
    • 3.2.2 Undo
    • 3.2.3 Highlight Moves
    • 3.2.4 Move Logging..........................................................................................................................
    • 3.2.5 Resign/Draw Option
    • Time per Game Option
  • Performance Requirements
  • Design Constraints
  • Software System Attributes
  • Other Requirements - January 27,
• Appendixes
  • A: Glossary
  • B: Analysis Models
    • B.1 Preliminary UI
    • B.2 Preliminary UML
  • C: Issues List

January 27, 2009

Revision History

Name Date Change Version

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

0.

Alexander Gerveshi Feb 05 2009 Updated Specific Requirements

0.

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

0.

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 1.5 Intended Audience & Reading Suggestions This documented is intended for any Java developer, tester, and other documentation writers who will be using or modifying these specifications. Should you fall into the category of a tester or developer, it is recommended that you read the Specific Requirements section first followed by the Overall description in order to give context to the features you may be developing or testing. Documentation writers however, are recommended to extensively use the Table of Contents and Appendices in order to skip right to the relevant information. It is also suggested you read the Purpose, Overview & Scope sections to get a grasp of the document contents and how they relate to each other. 1.6 Overview This document is divided into 3 major sections:

1. Overall Description

The Overall Description section shall cover general use cases and a top-level view of major features of the game. Also included in this section shall be mention of constraints, assumptions and the operating environment for this game. In addition to this, there shall be mention of any coding, testing, and management conventions and/or processes that will be applied in the development process

2. Specific Requirements

In this section, all the requirements of the game shall be covered in full detail. All feature requests shall be fully documented here. Priority will be given to client requests according to the necessity and dependencies of the specific request. Also included in this section shall other requirements not directly specified by the user but required to meet the user needs and/or specified by the project manager/group leader/company head.

3. Appendices

In the appendices can be found all other non-text based documentation such as class UML designs, workflow charts and GUI representations. Also included is a glossary of terms used throughout this document and an Issues list. The issues list shall cover all requirements listed in this document for which still need to reach a resolution due to conflicts, ambiguity, or other factors.

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 3.2 System Features Please find the priority key below High Priority Normal Low Priority 3.2.1 Save & Load Either player should be able to save the current game state to be continued at a later stated. The player is expected to enter the filename (w/out extension) for the game to be saved to. Should a file already exist with that name, the player shall be notified and asked if it is ok to overwrite. Should the save fail for any reason, the player shall be shown an error message and asked if they would like to save to another location. Similarly, a player should be able to load a saved game state and continue play. The game does not necessarily need to be continued with the same player and may be continued with any other player as who chooses to join in on such a game. Should a load from file fail due to a File not found error, the user shall be asked to reenter the filename. Should a load fail for any other reason, the user shall be notified and asked if they want to load from a different file or start a new game. 3.2.2 Undo At any point during the game, a player may choose to undo a previously executed move. However, this comes with a precondition that the opponent player has agreed to the undo. As such, the player will request and undo and the opponent may allow or disallow it. In the case of an allow, the undo is executed and in the case of a disallow, the player requesting the undo is notified of the opponents disagreement and game play proceeds. Undo’s may be executed for as long as the opponent player agrees to them. 3.2.3 Highlight Moves

• Highlight all valid moves that the selected piece can make.
• Use different colors to specify moves that would result in taking an opposing piece.
• Notify user when piece cannot be moved because their King is in check. 3.2.4 Move Logging
• The program shall keep a list of all of the moves that each player has made during the current game. 3.2.5 Resign/Draw Option
• The current user shall have an option to resign from the game.
• The current user shall have an option to draw the game. The decision to draw is then verified by the opposing player.

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 B.2 Preliminary UML

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