MG.tex

\documentclass[12pt, titlepage]{article}

\usepackage{fullpage}
\usepackage[round]{natbib}
\usepackage{multirow}
\usepackage{booktabs}
\usepackage{tabularx}
\usepackage{graphicx}
\usepackage{float}
\usepackage{hyperref}
\hypersetup{
    colorlinks,
    citecolor=black,
    filecolor=black,
    linkcolor=black,
    urlcolor=blue
}
\usepackage[round]{natbib}
\usepackage{verbatim}

\newcounter{acnum}
\newcommand{\actheacnum}{AC\theacnum}
\newcommand{\acref}[1]{AC\ref{#1}}

\newcounter{ucnum}
\newcommand{\uctheucnum}{UC\theucnum}
\newcommand{\uref}[1]{UC\ref{#1}}

\newcounter{mnum}
\newcommand{\mthemnum}{M\themnum}
\newcommand{\mref}[1]{M\ref{#1}}

\title{SE 3XA3: Software Requirements Specification\\Snake 2.o}

\author{Team 30, VUA30
		\\ Andy Hameed | Hameea1
		\\ Usman Irfan | Irfanm7
		\\ Vaibhav Chadha | Chadhav
}

\date{\today}

\begin{document}

\maketitle

\pagenumbering{roman}
\tableofcontents
\listoftables
\listoffigures

\begin{table}[bp]
\caption{\bf Revision History}
\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
\midrule
2018 -11-09 & 1.0 & Andy added section 1, 7 and 5.3, Vaibhav added section 2,3 and 5.1, Usman added section 4,5.2 and 6\\
Date 2 & 1.1 & Notes\\
\bottomrule
\end{tabularx}
\end{table}

\newpage

\pagenumbering{arabic}

\section{Introduction}

\subsection{Overview}
Almost everyone nowadays relies on a computer as a multipurpose tool for research, video streaming, gaming and many other tasks. With the emergence of fast computing, gaming has become a popular pastime activity and a source of entertainment for many. However, not everyone has a device powerful enough to support extensive game applications. A simple, memory-effecient application of the Snake game allows it to be accessible for gamers without the need for extensive hardware or a high-performance computer. Our team, VUA30, will be creating a desktop application for the well-known “Snake” game with new enhancements and features. This competitive and addictive game can allow the user to play at their own pace and challenge their own high score. 

\subsection{Scope}
The scope of the project will cover the reimplementation of the game as well as enhancements to the game, in particular, changes that pertain to gameplay themes, different modes/ difficulties and so on. Due to the time constraints of the project, not all enhancements will be implemented but at least one enhancement will be implemented to differentiate Snake 2.o from previous remakes of the game.

\subsection{Relevance of Module Guide}
The Module Guide (MG) document will outline the structure of the reimplementation through modular programming. It highlights the components of the system such that each component can easily be identified by project members, whether they are maintaining or designing the software. Among the list of internal stakeholders that may make use of this document, any new members that are added to the team will also be able to use the MG as a convenient reference to specific modules that they are concerned with or working on~\citep{ParnasEtAl1984}. 

\subsection{SRS,MIS and MG}
In the SRS, functional and non-functional requirements were specified along with testing methods. In this document, we will be covering the modules that will implement the functional requirements specified in the SRS. The MIS will outline the module attributes and methods that are needed to meet the functional requirements as well as descriptions of these attributes and methods and their purpose.

The document will have the following structure:
\begin{enumerate}
\item Introduction: Connecting the relevance of the MIS, SRS and the MG along with the scope and a reiteration of the project overview
\item Anticipated changes: This includes changes that will be made to this document including the addition and removal of modules and othe module-related
changes that can come about in the future.
\item Module Heirarchy: Will list the modules that will be implemented, giving an overview of the module structure.
\item Traceability Matrix: Shows the connection between modules and how errors could be traced back to each module
\item Use Heirarchy: a visual of the modules and their working relationship between each other. an arrow from A to B explains that 
module A uses module B
\end{enumerate}


\begin{comment}
Decomposing a system into modules is a commonly accepted approach to developing
software.  A module is a work assignment for a programmer or programming
team~\citep{ParnasEtAl1984}.  We advocate a decomposition
based on the principle of information hiding~\citep{Parnas1972a}.  This
principle supports design for change, because the ``secrets'' that each module
hides represent likely future changes.  Design for change is valuable in SC,
where modifications are frequent, especially during initial development as the
solution space is explored.  

Our design follows the rules layed out by \citet{ParnasEtAl1984}, as follows:
\begin{itemize}
\item System details that are likely to change independently should be the
  secrets of separate modules.
\item Each data structure is used in only one module.
\item Any other program that requires information stored in a module's data
  structures must obtain it by calling access programs belonging to that module.
\end{itemize}

After completing the first stage of the design, the Software Requirements
Specification (SRS), the Module Guide (MG) is developed~\citep{ParnasEtAl1984}. The MG
specifies the modular structure of the system and is intended to allow both
designers and maintainers to easily identify the parts of the software.  The
potential readers of this document are as follows:

\begin{itemize}
\item New project members: This document can be a guide for a new project member
  to easily understand the overall structure and quickly find the
  relevant modules they are searching for.
\item Maintainers: The hierarchical structure of the module guide improves the
  maintainers' understanding when they need to make changes to the system. It is
  important for a maintainer to update the relevant sections of the document
  after changes have been made.
\item Designers: Once the module guide has been written, it can be used to
  check for consistency, feasibility and flexibility. Designers can verify the
  system in various ways, such as consistency among modules, feasibility of the
  decomposition, and flexibility of the design.
\end{itemize}

The rest of the document is organized as follows. Section
\ref{SecChange} lists the anticipated and unlikely changes of the software
requirements. Section \ref{SecMH} summarizes the module decomposition that
was constructed according to the likely changes. Section \ref{SecConnection}
specifies the connections between the software requirements and the
modules. Section \ref{SecMD} gives a detailed description of the
modules. Section \ref{SecTM} includes two traceability matrices. One checks
the completeness of the design against the requirements provided in the SRS. The
other shows the relation between anticipated changes and the modules. Section
\ref{SecUse} describes the use relation between modules.
\end{comment}

\section{Anticipated and Unlikely Changes} \label{SecChange}

This section lists possible changes to the system. According to the likeliness
of the change, the possible changes are classified into two
categories. Anticipated changes are listed in Section \ref{SecAchange}, and
unlikely changes are listed in Section \ref{SecUchange}.

\subsection{Anticipated Changes} \label{SecAchange}

Anticipated changes are the source of the information that is to be hidden
inside the modules. Ideally, changing one of the anticipated changes will only
require changing the one module that hides the associated decision. The approach
adapted here is called design for
change.

\begin{description}
\item[\refstepcounter{acnum} \actheacnum \label{acHardware}:] The specific
  hardware on which the software is running.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The Operating System of which the software interfaces with.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The new High Score after any previous record is broken.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The speed of the snake when the user changes the difficulty level.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] Storing the score to the text file after each game is played.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The theme of the playground is changed whenever the user decides changes the theme mode.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:]Default settings for inputs.

\end{description}

\subsection{Unlikely Changes} \label{SecUchange}


\begin{description}
\item[\refstepcounter{ucnum} \uctheucnum \label{ucIO}:] Input/Output devices
  (The system assumes mouse, keyboard and screen are available).
\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] The snake is responsive to the directions button under any circumstances.
\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] The goal of the system: To provide user with entertainment and a fun game to play. 
\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] There will always be a source of input data external to the software.
\end{description}

\section{Module Hierarchy} \label{SecMH}

This section provides an overview of the module design. Modules are summarized
in a hierarchy decomposed by secrets in Table \ref{TblMH}. The modules listed
below, which are leaves in the hierarchy tree, are the modules that will
actually be implemented.

\begin{description}
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Hardware-Hiding Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Interface Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Snake Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Food Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Themes Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Software Design Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] init Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] highscore Module
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Gameplay Module
\end{description}


\begin{table}[h!]
\centering
\begin{tabular}{p{0.3\textwidth} p{0.6\textwidth}}
\toprule
\textbf{Level 1} & \textbf{Level 2}\\
\midrule

{Hardware-Hiding Module} & ~ \\
\midrule

\multirow{4}{0.3\textwidth}{Behaviour-Hiding Module} &  Input Format Module\\
& Snake Module\\
& Food Module\\
& Themes Module\\
\midrule

\multirow{1}{0.3\textwidth}{Software Decision Module} & HighScore Module\\
\bottomrule

\end{tabular}
\caption{Module Hierarchy}
\label{TblMH}
\end{table}

\section{Connection Between Requirements and Design} \label{SecConnection}
The Design of the software product was designed to meet the functional and non-functional 
requirements. The user-interference file displays the game interface that allows the user to either start
the game or to select different modes, themes or even check the high score. The design was kept to 
keep the interface simple and easy to use. When the user runs the main file, it opens a title page
which has multiple options from which a user can select options. To meet the functional requirement 
of outputting high score, the main interface file has a button which when pressed open a new window 
displaying the highest score of the game so far. A quit button and a Main Menu button has been 
added in the high score window so the user can either go back or end the game. In the Main Menu, 
there are different themes combined that the user can select letting us meet another requirement. 
The principal part of the design was to open a new window which begins the snake game. It was 
created by adding a new button ``Game Time" in the Main Menu window. The design of the snake 
game is kept simple where a snake and food appears randomly on the window, upon pressing the 
Arrow direction keys the snake moves to the respective location proceeding the game smoothly and 
connecting our requirement to its design. The current score of the game displays on the top which 
keeps updating as the snake eats the food, and a quit button will be added on the bottom of the 
screen so the user can quit the game whenever they feel like.\\
To enhance our design, in the future the group has planned to add radio buttons, drop-down menus or 
use a slider to make the game interactive. The radio buttons would be installed where the user can 
select the difficulty modes of the game, the drop-down menus would be helpful in selecting the theme 
and the slider would work to alter the speed of the snake.

\section{Module Decomposition} \label{SecMD}

Modules are decomposed according to the principle of ``information hiding''
proposed by \citet{ParnasEtAl1984}. The \emph{Secrets} field in a module
decomposition is a brief statement of the design decision hidden by the
module. The \emph{Services} field specifies \emph{what} the module will do
without documenting \emph{how} to do it. For each module, a suggestion for the
implementing software is given under the \emph{Implemented By} title. If the
entry is \emph{OS}, this means that the module is provided by the operating
system or by standard programming language libraries.  Also indicate if the
module will be implemented specifically for the software.

Only the leaf modules in the
hierarchy have to be implemented. If a dash (\emph{--}) is shown, this means
that the module is not a leaf and will not have to be implemented. Whether or
not this module is implemented depends on the programming language
selected.

\subsection{Hardware Hiding Modules }

\begin{description}
\item[Secrets:] user controls
\item[Services:] Serves as a virtual hardware used by the rest of the
  system. This module provides the interface between the hardware and the
  software. So, the system can take inputs from the keyboard and mouse, and then further output it on the screen.
\item[Implemented By:] Pygame library and OS
\end{description}

\subsection{Behaviour-Hiding Module}

\begin{description}
\item[Secrets:]The contents of the required behaviours.
\item[Services:] Includes programs that provide externally visible behaviour of
  the system as specified in the software requirements specification (SRS)
  documents. This module serves as a communication layer between the
  hardware-hiding module and the software decision module. The programs in this
  module will need to change if there are changes in the SRS.
\item[Implemented By:] --

\end{description}

\subsubsection{Interface Module}

\begin{description}
\item[Secrets:] Input Data
\item[Services:] Collects data on customized fields in the game
such as speed, theme, difficulty and other important variables.
\item[Implemented By:] Pygame library
\end{description}

\subsubsection{Snake Module}

\begin{description}
\item[Secrets:] Snake 
\item[Services:] Defines the snake class and its attributes and behaviours. This 
includes the movement of the snake depending on its attributes and its interaction with
user events.
\item[Implemented By:] Pygame library
\end{description}


\subsubsection{Food Module}

\begin{description}
\item[Secrets:] Food 
\item[Services:] Defines the food item class for spawning the food item during gameplay.
\item[Implemented By:] Pygame library
\end{description}

\subsubsection{Themes Module}

\begin{description}
\item[Secrets:] Themes 
\item[Services:] Allows the user to choose different themes of the snake game.
\item[Implemented By:] Pygame library
\end{description}

\subsubsection{Gameplay Module}

\begin{description}
\item[Secrets:] gameplay 
\item[Services:] connects different modules to the Pygame event functionality and 
creates movement of snake around window.
\item[Implemented By:] Pygame library
\end{description}

\subsubsection{highscore Module}

\begin{description}
\item[Secrets:]  highscore
\item[Services:] provides highscore of player on a separate menu
after initial start menu.
\item[Implemented By:] Pygame library
\end{description}

\subsection{Software Decision Module}

\begin{description}
\item[Secrets:] Text files
\item[Services:] Creates a text file which stores the game score 
  % Changes in these modules are more likely to be motivated by a desire to
  % improve performance than by externally imposed changes.
\item[Implemented By:] N/A
\end{description}

%\subsubsection{Etc.}

\section{Traceability Matrix} \label{SecTM}

This section shows two traceability matrices: between the modules and the
requirements and between the modules and the anticipated changes.

% the table should use mref, the requirements should be named, use something
% like fref
\begin{table}[H]
\centering
\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
\toprule
\textbf{Req.} & \textbf{Modules}\\
\midrule
FR1 & M2, M3\\
FR2 & M2, M3\\
FR3 & M2, M3\\
FR4 & M2, M3\\
FR5 & M2, M3\\
FR6 & M2, M3\\
FR7 & M6\\
FR8 & M3\\
FR9 & M2, M5\\
FR10 & M6\\
FR11 & M5\\
FR12 & M3\\
FR13 & M3\\
FR14 & M3\\
FR15 & M4\\
FR16 & M3\\
FR17 & M3\\
FR18 & M4\\
FR19 & M6\\

\bottomrule
\end{tabular}
\caption{Trace Between Requirements and Modules}
\label{TblRT}
\end{table}

\begin{table}[H]
\centering
\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
\toprule
\textbf{AC} & \textbf{Modules}\\
\midrule
AC1 & M1\\
AC2 & M2, M6\\
AC3 & M6\\
AC4 & M5,M6\\
AC5 & M6\\
AC6 & M5\\
AC7 & M2\\
\bottomrule
\end{tabular}
\caption{Trace Between Anticipated Changes and Modules}
\label{TblACT}
\end{table}

\section{Use Hierarchy Between Modules} \label{SecUse}


\begin{figure}[H]
\centering
%\includegraphics[width=0.7\textwidth]{Use_Hierarchy.png}
\caption{Use hierarchy among modules}
\includegraphics{Use_Heirarchy}
\label{FigUH}
\end{figure}

%\section*{References}

\bibliographystyle {plainnat}
\bibliography {MG}

\end{document}