\author{\large Checkmate Engineering - L02 Group 18
\\Student 1 name and macid
\\Mihail Serafimovski, serafimm
\\Student 2 name and macid
\\Aidan Mariglia, mariglia
\\Student 3 name and macid
\\Benjamin Dubois, duboisb
}
}
\date{\today}
\date{\today}
\input{../Comments}
\begin{document}
\begin{document}
\maketitle
\maketitle
...
@@ -48,87 +48,226 @@ Date 2 & 1.1 & Notes\\
...
@@ -48,87 +48,226 @@ Date 2 & 1.1 & Notes\\
\pagenumbering{arabic}
\pagenumbering{arabic}
This document describes the requirements for .... The template for the Software
Requirements Specification (SRS) is a subset of the Volere
template~\citep{RobertsonAndRobertson2012}. If you make further modifications
to the template, you should explicity state what modifications were made.
\section{Project Drivers}
\section{Project Drivers}
\subsection{The Purpose of the Project}
\subsection{The Purpose of the Project}
The intention of this project is to extend the functionality of the python-chess module with various quality of life features, including a user interface. An emphasis will be place on rigorous documentation and creation of highly modular code.
\subsection{The Stakeholders}
\subsection{The Stakeholders}
\subsubsection{The Client}
\subsubsection{The Client}
As this is a self motivated project, the developers are the client.
\subsubsection{The Customers}
\subsubsection{The Customers}
The customers include any individual who wishes to play chess.
\subsubsection{Other Stakeholders}
\subsubsection{Other Stakeholders}
Due to the academic nature of this project the other stakeholders include the teaching staff of 3XA3.
\subsection{Mandated Constraints}
\subsection{Mandated Constraints}
The project must be completed before April 12. The project must not make use of closed source software or specialized hardware. The project is developed in and will be extended in python, so the final product should be able to run on any machine which python supports.
\subsection{Naming Conventions and Terminology}
\subsection{Naming Conventions and Terminology}
\subsection{Relevant Facts and Assumptions}
\begin{itemize}
\item WHITE: The player controlling the lighter colored pieces
\item BLACK: The player controlling the darker colored pieces
\item Valid Move: A move which does not violate the rules of chess
\item Board position: A piece of data representing the location of each piece currently on the board.
\item Opposing piece: A piece of the opposite color of the players
\item Rank: A horizontal row of squares on the chess board
\item File: A vertical column of squares on the chess board
\item Threefold repetition: A condition that occurs when a player makes the same move three times in a row
\item Insufficient Material: A condition that occurs when neither player has the required pieces to checkmate their opponent.
\item Stalemate: A condition that occurs when a player has no valid moves available
\item Castling: A move where the king and a rook move so as to place the king in a more defensive position. See the rules of chess for more detail.
\end{itemize}
User characteristics should go under assumptions.
\subsection{Relevant Facts and Assumptions}
Assumptions: It is assumed users know the rules of chess. It is also assumed the game is played with a single player against a computer or two players sharing the same computer and input/output devices.
\section{Functional Requirements}
\section{Functional Requirements}
\subsection{The Scope of the Work and the Product}
\subsection{The Scope of the Work and the Product}
\subsubsection{The Context of the Work}
\subsubsection{The Context of the Work}
This work extends the python-chess module, and requires a thorough understand of the existing module before it is extended. The development of the GUI relies heavily on another software module, pygame. Satisfactory understanding of pygame is a prerequisite for the development of the specified GUI.
\subsubsection{Work Partitioning}
\subsubsection{Work Partitioning}
Due to the nature of the game, only one type of business event needs to be considered, a user entering a move. This input will be handled by the main game loop in the core software module.
\subsubsection{Individual Product Use Cases}
\subsubsection{Individual Product Use Cases}
There are two main use cases for the product, a chess match with one player playing against the computer, and two players playing against each other alternating control of the computers I/O devices. Additional game specific use cases include:
\begin{itemize}
\item User
\begin{itemize}
\item Moving a chess piece to an empty space on the board
\item Moving a chess piece to a space occupied by an opponent and capturing it
\end{itemize}
\item System
\begin{itemize}
\item Check if a user move results in checkmate
\item Check is a user move results in check
\item Check is the draw conditions have been reached
\item End the game
\item Create new game board
\item Switch turn
\end{itemize}
\end{itemize}
Below is a use case diagram that illustrates the relationships between these use cases:
\item Requirement number: FR1 \\ The system shall alternate control from white to black or from black to white after a move is made. \\ Rationale: The rules of chess dictate that players alternate turns, making one move per turn.
\item Requirement number: FR2 \\ The system shall always give white the first move. \\ Rationale: The rules of chess dictate that white is always first to move.
\item Requirement number: FR3 \\ The system shall load the standard board position at the start of each new game. \\ Rationale: The rules of chess dictate that a standard starting position be used.
\item Requirement number: FR4 \\ The system shall no longer render pieces that have been captured by the opposing player. \\ The rules of chess dictate that captured pieces are removed from the board, this will be represented in the system by captured pieces no longer being rendered.
\item Requirement number: FR5 \\ The system shall display the valid moves for a selected piece \\ Rationale: Displaying the valid moves of a selected piece allows the player to better understand where the piece may be moved preventing a non responsive experience.
\item Requirement number: FR6 \\ The system shall allow the capture of an opposing piece \\ Rationale: In order to satisfy the rules of chess capture of pieces must be allowed.
\item Requirement number: FR7 \\ The system must randomly assign which player is white and which is black \\ Rationale: White has an inherent advantage due to the fact that it makes the first move, to remove this advantage when playing against a computer a random piece color will be assigned
\item Requirement number: FR8 \\ The system must allow a pawn which has reached the opposite rank to be upgraded to a rook, bishop, knight or queen \\ Rationale: This is a standard rule in chess.
\item Requirement number: FR9 \\ The system must end the game when a player is placed in checkmate \\ Rationale: Checkmate is the standard win condition in chess signifying the end of the game
\item Requirement number: FR10 \\ The system must end the game with a draw when a threefold repetition occurs, insufficient material occurs or fifty moves has passed without a piece being captured or a pawn being moved \\ Rationale: These are the standard conditions for a chess match to end in a draw
\item Requirement number: FR11 \\ The system must end the game with a stalemate when a player has no valid moves. \\ Rationale: This is the standard condition for a chess match to end in a stalemate.
\item Requirement number: FR12 \\ The system must allow for the 'castling' move to be performed. \\ Rationale: This is a move allowed in the rules of chess.
\item Requirement number: FR13 \\ The system must update the GUI when a piece is moved so as to show the updated position of the piece. \\ Rationale: The player(s) should always be able to see the most recent version of the board.
\item Requirement number: FR14 \\ The system must update the GUI when one of the game ending conditions is met (checkmate or stalemate), indicating the result of the game. \\ Rationale: The player(s) of the game should be able to visually see the results of the game after it's over.
\end{itemize}
\section{Non-functional Requirements}
\section{Non-functional Requirements}
\subsection{Look and Feel Requirements}
\subsection{Look and Feel Requirements}
\begin{itemize}
\item
The product shall use simple colours for visibility.
\item
The product shall use symbols that are understandable by the chess community.
\item The product's look and feel should not differ significantly from the look and feel of other currently popular chess applications.
\end{itemize}
\subsection{Usability and Humanity Requirements}
\subsection{Usability and Humanity Requirements}
\begin{itemize}
\item
The product shall be usable by people with no training.
\item
The product shall be usable by people with no understanding of English.
\item
The product shall be usable by people with colour blindness.
\end{itemize}
\subsection{Performance Requirements}
\subsection{Performance Requirements}
\begin{itemize}
\item
The product shall respond within 1 second of user input.
\item
The product shall switch users after a move fast enough that no user's turn is being interrupted.
\end{itemize}
\subsection{Operational and Environmental Requirements}
\subsection{Operational and Environmental Requirements}
\begin{itemize}
\item The product is expected to run on Windows and Linux.
\end{itemize}
\subsection{Maintainability and Support Requirements}
\subsection{Maintainability and Support Requirements}
\begin{itemize}
\item
The product shall allow for images to be easily removed and replaced.
\end{itemize}
\subsection{Security Requirements}
\subsection{Security Requirements}
\begin{itemize}
\item
The product shall only allow project managers to make changes.
\item
The product shall not collect any information from users.
\item
The product shall prevent sensitive data from being introduced.
\end{itemize}
\subsection{Cultural Requirements}
\subsection{Cultural Requirements}
\begin{itemize}
\item
The product shall include the names of chess pieces from various cultures.
\end{itemize}
\subsection{Legal Requirements}
\subsection{Legal Requirements}
\begin{itemize}
\item The product shall not store any user data (as stated in section 3.6), so as to not have to be concerned with regional privacy laws.
\item The product shall not use any depictions, imagery, or other assets which are protected under any form of copyright law.
\end{itemize}
\subsection{Health and Safety Requirements}
\subsection{Health and Safety Requirements}
\begin{itemize}
\item The product shall not use any flashing imagery so as to not raise epilepsy concerns.
\item The product shall not pose any form of health threat to the user.
\end{itemize}
This section is not in the original Volere template, but health and safety are
This section is not in the original Volere template, but health and safety are
issues that should be considered for every engineering project.
issues that should be considered for every engineering project.
\section{Project Issues}
\section{Project Issues}
\subsection{Open Issues}
\subsection{Open Issues}
\begin{itemize}
\item
The code that our project is based on has not been tested by our team, so we can't be certain that there are no errors or incorrect moves that will cause our GUI to be incorrect.
\item
The software Pygame has limited tools for creating a GUI and this could limit what is possible to implement.
\end{itemize}
\subsection{Off-the-Shelf Solutions}
\subsection{Off-the-Shelf Solutions}
\begin{itemize}
\item
There are many games and websites that have implemented a GUI for their chess game. One example is the popular website chess.com.
\end{itemize}
\subsection{New Problems}
\subsection{New Problems}
\begin{itemize}
\item
The GUI will need to be connected to the existing python code and this could lead to errors within the code.
\item
This implementation will adversely affect users that prefer to use their keyboard over their mouse when playing this chess game as you will no longer be able to use a keyboard to perform moves.
\end{itemize}
\subsection{Tasks}
\subsection{Tasks}
The 3XA3 deliverable guideline details the tasks required for this project. Additionally, our team has provided a Gantt chart that details the start date and end date of critical milestones in the development of this project. As our project does not have multiple parts and is simply one big implementation, achieving the requirements and making the use cases functional will take the entire time specified for the project.
\subsection{Migration to the New Product}
\subsection{Migration to the New Product}
Phased implementation will be used for this product in order to fully implement it. The major implementation phases are as follows:
\begin{itemize}
\item
Creating the physical board that the game of chess is played on.
\item
Creating the physical chess pieces that are placed on the board.
\item
Placing each chess piece in the correct position for the start of a chess game.
\item
Adding the correct movement to each piece such that it can only move in the correct way.
\item
Adding a indicator when a piece is clicked that shows where the piece is eligible to move.
\end{itemize}
Changes will need to be made to the existing product as the new product runs in parallel with the existing product and depends on it.
\subsection{Risks}
\subsection{Risks}
The large size ($\sim$ 100 000 loc) of the existing project reduces the amount of modification that can be performed to the existing codebase in a timely manner. To subvert this an emphasis will be placed on writing code that easily integrates into the existing codebase rather than modifying the existing codebase to match the style of the new code.
\subsection{Costs}
\subsection{Costs}
As all of the code being used is open source and does not require specialized hardware in order to run there are no costs associated with this project.
\subsection{User Documentation and Training}
\subsection{User Documentation and Training}
The GUI is being developed with being intuitive in mind, any user who has played a physical game of chess will be able to identify how to use the program. A simple readme will be provided detailing how to run and use the software.
\subsection{Waiting Room}
\subsection{Waiting Room}
\begin{itemize}
\item
The system shall display a timer that counts down while player's are making moves.
\item
The system shall end the current game if a player's timer reaches 0.00s.
\end{itemize}
\subsection{Ideas for Solutions}
\subsection{Ideas for Solutions}
\begin{itemize}
\item To solve the issue of the source code not being tested, we can write tests using \verb|pytest| to check if the source code has any major bugs.
\item The project will need keyboard support in order to solve the issue of affecting users who prefer playing with keyboard.
\end{itemize}
\bibliographystyle{plainnat}
\bibliographystyle{plainnat}
...
@@ -138,13 +277,12 @@ issues that should be considered for every engineering project.
...
@@ -138,13 +277,12 @@ issues that should be considered for every engineering project.
\section{Appendix}
\section{Appendix}
This section has been added to the Volere template. This is where you can place
N/A
additional information.
\subsection{Symbolic Parameters}
\subsection{Symbolic Parameters}
The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
N/A
Their values are defined in this section for easy maintenance.
