diff --git a/BlankProjectTemplate/Doc_Revision1/DevelopmentPlan/DevelopmentPlan.pdf b/BlankProjectTemplate/Doc_Revision1/DevelopmentPlan/DevelopmentPlan.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..336594df6cdf95dccbb28f7ba9a8c4c87a44da2e
Binary files /dev/null and b/BlankProjectTemplate/Doc_Revision1/DevelopmentPlan/DevelopmentPlan.pdf differ
diff --git a/BlankProjectTemplate/Doc_Revision1/DevelopmentPlan/DevelopmentPlan.tex b/BlankProjectTemplate/Doc_Revision1/DevelopmentPlan/DevelopmentPlan.tex
new file mode 100644
index 0000000000000000000000000000000000000000..8329b5fe06efe68d36be56fa24b33f082c2efd2c
--- /dev/null
+++ b/BlankProjectTemplate/Doc_Revision1/DevelopmentPlan/DevelopmentPlan.tex
@@ -0,0 +1,137 @@
+\documentclass{article}
+
+\usepackage{pdfpages}
+\usepackage{booktabs}
+\usepackage{tabularx}
+\usepackage{hyperref}
+
+
+\title{SE 3XA3: Development Plan\\Snake 2.o}
+
+\author{Team \# 30, VUA30
+		\\ Vaibhav Chadha , chadhav
+		\\ Usman Irfan , irfanm7
+		\\ Andy Hameed , hameea1
+}
+
+\date{}
+
+
+
+\begin{document}
+
+\begin{table}[hp]
+\caption{Revision History} \label{TblRevisionHistory}
+\begin{tabularx}{\textwidth}{llX}
+\toprule
+\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
+\midrule
+Sept 25, 2018 & Vaibhav, Usman, Andy & Worked on part 1 to 4\\
+Sept 27, 2018 & Vaibhav, Usman, Andy & Worked on part 4 to 8\\
+Sept 27, 2018 & Vaibhav & Added the information from the meeting documents to the LaTeX file\\
+Sept 28, 2018 & Andy & Proof of concept, Git workflow, Final editing and formatting\\
+Sept 28, 2018 & Usman & Updated proof of concept\\
+Oct 12, 2018 & Andy & Made changes according to feedback on development plan and added section on POC demo\\
+\bottomrule
+\end{tabularx}
+\end{table}
+
+\newpage
+
+\maketitle
+
+
+\section{Team Meeting Plan}
+Meetings will be held \textbf{twice a week} at the following times:
+\begin{itemize}
+\item Mondays 5:30 - 6:30 pm at KTH Computer Labs
+\item  Wednesdays 12:30 to 2:00pm at Health science library
+\end{itemize}
+
+\subsection{Roles and Agenda}
+
+\textbf{Chair}: Andy Hameed
+\begin{itemize}
+	\item Responsible for creating the agenda and selecting topics that pertain to all team members
+	\item Agenda items will be listed as questions\\
+\end{itemize}
+\textbf{Notettaker}: Usman Irfan
+\begin{itemize}
+	\item Responsible for taking meeting minutes
+	\item Meeting decisions will be summarized in a statement at the end of the meeting
+\end{itemize}
+\textbf{Timekeeper}: Vaibhav Chadha
+\begin{itemize}
+	\item Keeps track of time in case we are spending too much time on one topic
+\end{itemize}
+
+\section{Team Communication Plan}
+
+Main source of communication is \textbf{Facebook Messenger}, it will be used for general inquiries, updates, reminders of team meetings, any links to useful resources and so on. Phone and texting will be used as a backup in case of urgent matters, for example not being able to get in contact with a team member through messenger.
+
+Aside from these, the team will be using Workflowy to assign small tasks that are promptly due or ones that may not necessarily fit on the gantt chart because they are minor - this tool will be used to delegate a small to-do list for each team member . 
+
+\section{Team Member Roles}
+
+Vaibhav Chadha:
+\begin{itemize}
+\item Latex Documentation
+\item Analyst - makes sure the requirements of the clients are met through the software
+\item gantt chart management\\
+\end{itemize}
+Usman Irfan: 
+\begin{itemize}
+\item Scribe
+\item Technology Research
+\item operation manager -ensures project development is running smoothly and software is being developed according to milestones \\
+\end{itemize}
+Andy Hameed:
+
+\begin{itemize}
+\item Final editing
+\item latex documentation
+\item team leader\\
+\end{itemize}
+
+All: 
+\begin{itemize}
+\item GIT project management
+\end{itemize}
+
+\section{Git Workflow Plan}
+We will be using the Git Feature Branch Workflow to manage the software development. Using branches, each team member is capable of 
+working on different modules or sections of the software at the same time in localized branches, before pushing their changes to the master branch.
+
+The following procedures will be followed:
+\begin{itemize}
+\item Vaibhav will be tagging any major milestones for final submission. This makes the submission process consistent. Otherwise, Andy or Usman will agree on one person to tag and submit for final submission.
+\item Any major changes can be placed in a branch to avoid merging conflicts and overwriting existing work. They can be merged later on upon team agreement.
+\end{itemize}
+
+\section{Proof of Concept Demonstration Plan}
+The original project is built using Javascript, HTML and CSS in contrast to our development plan using python and the Pygame library. Since we are using an OOP language, we will be able to create classes for different components of the snake game such as the snake unit block, snake body, and snake bate. The hardest part of the implementation will be the movement of the snake according to the user's keyboard inputs, and second to that would be the process of expanding the snake once a food item is captured. Besides that, the interface may be difficult to implement in python but could be simple with the use of a python framework such as PyQT5.\\
+	Once our game application has been developed the next part would be to test the project and for that we will be using Pytest, since our backend language is python this will help us test all possible functions and aspects. The functions that will be difficult to test would be to see if the snake eats the food, does the food appear at random locations after eaten by the snake and if the snake tries to leave the borders, will the game end. Portability will have to be taken into consideration since the application is being built for windows. However, it can be compiled and run on any system as long as the necessary files and libraries are download.
+
+\subsection{POC Demo}
+The team will be demonstrating the movement of a snake around the screen using unit blocks for the body of the snake. Lengthening the snake body, scoring and eating the bate will not be demonstrated in the demo. This POC should demonstrate that with the movement of the snake, which is the main component of the game, the team will be able to develop classes to represent other components of the game such as the score, food bate, and lengthening of the snake body.
+
+\section{Technology}
+
+Coding Language: Python, Kivy for GUI\\
+IDE: IDLE scripting\\
+Testing: PyUnit testing\\
+Documentation: Doxygen\\
+
+\section{Coding Style}
+
+We will be using the \href{https://github.com/google/styleguide/blob/gh-pages/pyguide.md}{Google Python Style Guide}
+for our coding style. It encompasses all the necessary naming conventions and standards required for the project development.
+
+\section{Project Schedule}
+Please see the following pages for the project schedule in the form of a gantt chart.
+
+\includepdf[page=-]{../../ProjectSchedule/Team_Gantt}
+
+\section{Project Review}
+
+\end{document}
\ No newline at end of file
diff --git a/BlankProjectTemplate/Doc_Revision1/ProblemStatement/ProblemStatement.pdf b/BlankProjectTemplate/Doc_Revision1/ProblemStatement/ProblemStatement.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..a1c299d18cc89d9fa4bcc549b9fe6e73f9d3d4c7
Binary files /dev/null and b/BlankProjectTemplate/Doc_Revision1/ProblemStatement/ProblemStatement.pdf differ
diff --git a/BlankProjectTemplate/Doc_Revision1/ProblemStatement/ProblemStatement.tex b/BlankProjectTemplate/Doc_Revision1/ProblemStatement/ProblemStatement.tex
new file mode 100644
index 0000000000000000000000000000000000000000..783eb300bbdebf91b30760c059f7525e173c55d6
--- /dev/null
+++ b/BlankProjectTemplate/Doc_Revision1/ProblemStatement/ProblemStatement.tex
@@ -0,0 +1,51 @@
+\documentclass{article}
+
+\usepackage{tabularx}
+\usepackage{booktabs}
+
+\title{SE 3XA3: Problem Statement\\ \textbf{Snake Game}}
+
+\author{Team \#30, VUA30
+		\\ Usman Irfan - irfanm7
+		\\ Andy Hameed - hameea1
+		\\ Vaibhav Chadha - chadhav
+}
+
+\date{2018-09-21}
+
+\usepackage[left=2cm, right=5cm, top=2cm]{geometry}
+
+\begin{document}
+
+\begin{table}[hp]
+\caption{Revision History} \label{TblRevisionHistory}
+\begin{tabularx}{\textwidth}{llX}
+\toprule
+\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
+\midrule
+2018-09-20 & Vaibhav & Made the LaTeX file and wrote the section with what the Problem is\\
+2018-09-20 & Usman & Added the Importance of Problem section while formatting the LaTeX\\
+2018-09-21 & Andy Hameed & Formatted LaTeX file and added Context section, giving the final editing to the document\\
+2018-10-09 & Andy Hameed & Edited doc to reflect web app to desktop app decision change\\
+\bottomrule
+\end{tabularx}
+\end{table}
+
+\newpage
+
+\maketitle
+
+\subsection*{The Problem}
+
+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*{Importance of the Problem}
+
+Buying a computing device with high storage and faster performance can be out of budget. Complicated software covers up all the storage and the user is bound to use these applications as opposed to downloading other software. The importance of the redevelopment of The Snake is to save computing devices' personal storage and allow the user to play a game 24/7 with strong performance, even offline. Creating a desktop version of the snake game can fit into the category of downloadable calssical games such as the solitaire suite. The recreation of this game will allow the user to enjoy the classical game anytime and anywhere as long as they have installed the application. Improving aspects such as graphics and custom speed will also make the game more interesting. We would like to add more features to the game to make it more customizable and help people enjoy the classical game in an exciting and new way.
+
+
+\subsection*{Context}
+The stakeholders are mainly the gaming audience, the older generation of game enthusiasts, youth and teens. Some other stakeholders that Although the game can be played by anyone, it is targeted towards the audience mentioned above who are most invested in the game. The environment is native app development using Python. This provides provides less flexibility than web API's but there still exists many useful libraries which can be used such as Pygame for example.
+
+\end{document}
+
diff --git a/BlankProjectTemplate/Doc_Revision1/ProblemStatement/README.md b/BlankProjectTemplate/Doc_Revision1/ProblemStatement/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..e5c5ef46a45f7a6781c1695470be05c20fa59570
--- /dev/null
+++ b/BlankProjectTemplate/Doc_Revision1/ProblemStatement/README.md
@@ -0,0 +1,5 @@
+# Problem Statement
+
+The folders and files for this folder are as follows:
+
+Describe ...
diff --git a/BlankProjectTemplate/Doc_Revision1/SRS/README.md b/BlankProjectTemplate/Doc_Revision1/SRS/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..67ed341730f1e0be598fb7655254e1e0924994d4
--- /dev/null
+++ b/BlankProjectTemplate/Doc_Revision1/SRS/README.md
@@ -0,0 +1,5 @@
+# Software Requirements Specification
+
+The folders and files for this folder are as follows:
+
+Describe ...
diff --git a/BlankProjectTemplate/Doc_Revision1/SRS/SRS.pdf b/BlankProjectTemplate/Doc_Revision1/SRS/SRS.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..3112fbd7b5268db17453e1aa3a0a77bad541390b
Binary files /dev/null and b/BlankProjectTemplate/Doc_Revision1/SRS/SRS.pdf differ
diff --git a/BlankProjectTemplate/Doc_Revision1/SRS/SRS.tex b/BlankProjectTemplate/Doc_Revision1/SRS/SRS.tex
new file mode 100644
index 0000000000000000000000000000000000000000..887ca368a976f931e668b039b51883623f007021
--- /dev/null
+++ b/BlankProjectTemplate/Doc_Revision1/SRS/SRS.tex
@@ -0,0 +1,428 @@
+\documentclass[12pt, titlepage]{article}
+
+\usepackage{booktabs}
+\usepackage{tabularx}
+\usepackage{hyperref}
+\hypersetup{
+    colorlinks,
+    citecolor=black,
+    filecolor=black,
+    linkcolor=black,
+    urlcolor=blue
+}
+\usepackage[round]{natbib}
+
+\title{SE 3XA3: Software Requirements Specification\\Title of Project}
+
+\author{Team 30, VUA
+		\\ Andy Hameed and hameea1
+		\\ Usman Irfan and irfanm7
+		\\ Vaibhav Chadah and 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
+Oct 5, 2018 & 1.0 & Andy worked on Project Drivers and Project Issues. Usman worked on Functional requirements. Vaibhav worked on Non-Functional Requirements\\
+Date 2 & 1.1 & Notes\\
+\bottomrule
+\end{tabularx}
+\end{table}
+
+\newpage
+
+\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}
+
+\subsection{The Purpose of the Project}
+
+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. 
+
+Buying a computing device with high storage and faster performance can be out of budget. Complicated software covers up all the storage and the user is bound to use these applications as opposed to downloading other software. The importance of the redevelopment of “The Snake” is to save computing device’s personal storage and allow the user to play a game 24/7 with strong performance, even offline. Creating a desktop version of the snake game can fit into the category of downloadable calssical games such as the solitaire suite. The recreation of this game will allow the user to enjoy the classical game anytime and anywhere as long as they have installed the application. Improving aspects such as graphics and custom speed will also make the game more interesting. We would like to add more features to the game to make it more customizable and help people enjoy the classical game in an exciting and new way. 
+
+\subsection{The Stakeholders}
+
+Stakeholders involved will be contained within the gaming community, more specifically the desktop gaming community and casual PC owners who are 
+looking for a fun reliever for boredom or quick game to play.This also includes members invested in the project which are mentioned in the subsesctions below.
+
+\subsubsection{The Client}
+
+Since this game is a separate entity, the clients are the designers in this project team. In further developments and upon increase in game popularity, the clients 
+could be a desktop gaming distribution service such as steam, google play or apple store. Otherwise, the main client would be Dr. Bokhari who has assigned the project.
+
+\subsubsection{The Customers}
+
+The main users or customers  are desktop gamers, older generation of game enthusiasts, youth and teens. However, the client can be anyone with a PC and an interest in classical gaming or a sudden craving for playing the classical Snake game. Often times, these games are a quick fix to boredom for those who are casually browing their PC's, so the game will be designed to provide enough stimulus and excitmement for regular computer users, similar to the solitaire suite.
+
+\subsubsection{Other Stakeholders}
+
+Aside from the clients and customers, other stakeholder include 3rd party Desktop game distribution stores and open source project banks which may make use of this project for development purposes:
+
+\begin{itemize}
+\item 3rd party desktop game distribution stores.
+\item Game Testers.
+\item Technology Experts [Part of Project Team].
+\item Usability experts.
+\item Dr. Bokhari.
+\item Project Development Experts: This can include teaching assistants, the professor, experienced peers and so on.
+\end{itemize}
+
+
+\subsection{Mandated Constraints}
+
+Some constraints that apply to the project include the following:
+
+\begin{itemize}
+\item No project budget provided; Project cannot use costly API memberships or resources.
+\item Application should take less than 400MB of storage space to meet requirements.
+\item The project must be completed within a 4-month period.
+\item Limited resources in terms of domain experts, specifically in graphic design.
+\item Application will be developed for one OS due to time constraint.
+\item open source project must be translated to Python due to development language and scope.
+\end{itemize}
+
+\subsection{Naming Conventions and Terminology}
+
+The naming conventions listed below will be used to clearly define words and termiology that will come up in the project development process. Below is a list
+of naming conventions, terms, and special vocabularly and their meaning. Since the desktop application is straighforward, there is not much terminology being
+used as of now:
+
+\begin{itemize}
+\item DDS: Digital Distribution Service such as play store, microsoft play, etc.
+\item OS: Operating System.
+\item Python: The programming language used for application development.
+\item Pygame: Computer graphics Python library.
+\item Snake 2.o: The desktop application being developed in Python.
+\item The interface: The graphics developed using Pygame.
+\item The source game: The open source original Python snake game being used for this project.
+\end{itemize}
+
+\subsection{Relevant Facts and Assumptions}
+
+Some factors that might affect the outcome of the product are listed as follows:
+\begin{itemize}
+\item DDS contribution will be necessary for the public release of the game.
+\item Contribution of  the development team will affect the outcome of the product.
+\item Feedback from game testers.
+\item Availability of resources from pygame library to replicate front-end design in HTML,CSS and JS.
+\item Time remaining once initial objectives and goals are met. This could affect which additional functionality is added.
+\end{itemize}
+
+ There are also assumptions that pertain to the intended operational environment and anything affecting the product:
+\begin{itemize}
+\item Pygame library offers enough functionality to recreate the web app graphics in Python.
+\item The user is using Windows for game execution otherwise they must compile the source code to run the application.
+\item The application will not be an exact replica of the source game. Added functionality and a change of graphics is expected.
+\item The game application will prioritize the completion of the snake game as the central attraction.
+\end{itemize}
+
+Some user characteristics will affect the final deisgn and written requirements:
+\begin{itemize}
+\item Users expect the game to be responsive and timely due to the nature of wanting quick stimulus .
+\item The game should have an attractive user inteface due to the nature of the users expectations. It is mainly used for entertainment and should
+have a smooth user-interface.
+\end{itemize}
+
+\section{Functional Requirements}
+
+\subsection{The Scope of the Work and the Product}
+% Summarize Gantt Chart
+
+\subsubsection{The Context of the Work}
+%
+The scope of the project is deliver a Product that has the requirement documentation, and a desktop application that can be installed on a user's system.\\
+\\To achieve the goals of the Product, the following are decided to be the deadlines of the goal to be on the track:\\
+$\bullet$ Development Plan \date{28/09/18}\\
+\\$\bullet$ Requirements Document Revision \date{05/10/18}\\
+\\$\bullet$ Proof of Concept Demonstration \date{16/10/18}\\
+\\$\bullet$ Test Plan Revision \date{26/10/19}\\
+\\$\bullet$ Design \& Document Revision \date{09/11/18}\\
+\\$\bullet$ Revise all the Documentation \date{13/11/18}\\
+\\$\bullet$ Final Documentation \date{06/12/18}\\
+
+\subsubsection{Work Partitioning}
+%breakdown your task into sub-task e.g. break logic and user interface
+The desktop application involves different processes to successfully run: making a user-interface so the user can interact with the application, the logic behind the user-interface that can handle all the inputs given by the user and outputs the result according to the requirements.
+These tasks can be divided into sub-task. For example, the system uses the microphone as an input, so whenever the sake completes a functional requirement (the requirements are described below) it will output an audio to make the game much more interesting.  Another example would be, the movement of the snake and it get larger would be done by the logic at the back-end and its output will be displayed on the screen so the user can continue playing. 
+Tasks such as displaying the food, making snake appear at random locations in the beginning, etc. should all be divided and can be worked individually as this would more efficient to complete and the developer would know how to test these functions.
+\subsubsection{Individual Product Use Cases}
+%
+The user can use the system-to-be (the desktop application) to entertain themselves when they are bored. They can use the system to improve their response time, with playing the game in difficulty modes it can be more challenging and the user has to be fast. In addition, the desktop application would be a fun means of entertainment between friends as they can play turn-by-turn and challenge each other.
+\subsection{Functional Requirements}
+
+
+$\bullet$ Requirement number: FR(Functional Requirement)1\\
+When the user sees the interface it can start the game by pressing any button key.\\
+Rationale: If the user presses any button and the game does not work as it is expected to be.\\
+
+$\bullet$ Requirement number: FR2 \\
+User's can press F11 key to play the desktop application in Full screen mode.\\
+
+$\bullet$ Requirement number: FR3\\
+The user can press the UP key to move the snake's direction in the upwards direction.\\
+
+$\bullet$ Requirement number: FR4\\
+The user can press the DOWN key to move the snake's direction in the downwards direction.\\
+
+$\bullet$ Requirement number: FR5\\
+The user can press the LEFT key to move the snake's direction in the left direction.\\
+
+$\bullet$ Requirement number: FR6\\
+The user can press the LEFT key to move the snake's direction in the right direction.\\
+
+$\bullet$ Requirement number: FR7\\
+The game should display the user's highest score.\\
+
+$\bullet$ Requirement number: FR8\\
+The initial location of the snake should be random whenever the user starts the game or when it restarts.\\
+
+$\bullet$ Requirement number: FR9\\
+The user has the option to play in three different modes: easy, medium and hard.\\
+
+$\bullet$ Requirement number: FR10\\
+The game should display the user's highest score.\\
+
+$\bullet$ Requirement number: FR11\\
+The desktop application provides a facility to toggle in different themes, e.g. Dark to Light.\\
+
+$\bullet$ Requirement number: FR12\\
+The desktop application provides a facility to toggle in different themes, e.g. Dark to Light.\\
+
+$\bullet$ Requirement number: FR13\\
+When the snake eats its food its length should be increased by 5 units. For instance, when the game is started and the snake's length is only 1 unit, but after eating a block of food its new length should be 6 units.\\
+
+$\bullet$ Requirement number: FR14\\
+By pressing the spacebar key the game should be paused.\\
+
+$\bullet$ Requirement number: FR15\\
+By pressing the spacebar key the game should be resumed, only if the game was paused initially.\\
+
+$\bullet$ Requirement number: FR16\\
+Snake's food should be randomly placed on the screen in the beginning of the game, once the snake eats its food, the food should reappear on the screen.\\
+
+$\bullet$ Requirement number: FR17\\
+The snake is allowed to move around in a certain space, if the snake crosses that space it should die and a message should prompt on the screen to restart the game.\\
+
+$\bullet$ Requirement number: FR18\\
+If the snake bites itself, the game should be over and a message should prompt on the screen to restart the game.\\
+
+$\bullet$ Requirement number: FR19\\
+If the user is successful in making the snake eat 10 food units consecutively, a food unit with more value should be displayed on the screen that would give the snake more points but will increase its length with the same amount, as previously stated.\\
+
+$\bullet$ Requirement number: FR20\\
+The snake should change its colour when it dies.\\
+
+\section{Non-functional Requirements}
+
+\subsection{Look and Feel Requirements}
+
+\subsubsection{Appearance Requirements}
+
+The final product shall be a desktop application which will contain a playground with a snake in it. It shall have different theme options and buttons to customize the speed of the snake. Also, it shall show the highest score made on the specific device.
+
+\subsubsection{Style Requirements}
+
+The product should be given a modern style by adding a nice background to it with a user-friendly interface.
+
+\subsection{Usability and Humanity Requirements}
+
+The application must be simple for a person aged 10 or above. It should be understandable by any person within the age group who is familiar to the technology. No feature should restrict the player to a non-knowledgeable outcome.
+
+\subsection{Performance Requirements}
+
+\subsubsection{Speed Requirements}
+
+\begin{description}
+	
+	\item[$\bullet$] All valid interaction should have a maximum response time of half a second.
+	
+	\item[$\bullet$] The speed for snake should be customizable by the user and should not increase or decrease by itself.
+	
+	
+\end{description}
+
+\subsubsection{Safety Critical requirements}
+
+The game shall not consume any private data from the user's device. 
+
+\subsubsection{Precision Requirements}
+\begin{description}
+	\item[$\bullet$] The speed of the snake should be consumed through integer values.
+	
+	\item[$\bullet$] The turn for snake should match with the users key and should be done as precisely as possible.
+\end{description}
+
+\subsubsection{Reliability and Availability Requirements}
+
+The game should be available 24 hours, 365 days per year to the user.
+
+\subsubsection{Capacity Requirements}
+
+The game shall not overload the clients device's memory. 
+
+\subsection{Operational and Environmental Requirements}
+
+\subsubsection{Expected Physcial environment}
+
+The application is intended to be used anywhere, at any desktop device. It can be used in any climatic condition from harsh summers to chilly winter( given that the device is working as well).
+
+\subsubsection{Expected Technological environment}
+
+This application should work on any desktop device as long as the device is working.
+
+\subsection{Maintainability and Support Requirements}
+
+\subsubsection{Maintainability}
+
+The application shall require minimum maintenance. Also, the application shall be revised every year.
+
+\subsubsection{Portability}
+
+The application is expected to run on Windows, Mac OS and Linux environment.
+
+\subsection{Security Requirements}
+
+This is an open-ended application. However, the application must not break the privacy policy by interfering with files stored on the desktop. Authors credits must be given when used by another party for any kind of development.
+
+\subsection{Cultural Requirements}
+
+The application will not use any kind of communicating data that will offend any religion, country or user in any way. The product will give a detailed explanation in case of use of any cultural or political symbol.
+
+\subsection{Legal Requirements}
+
+The application shall comply with all national and federal laws. In addition, the application must agree to the MIT Open License.
+
+\subsection{Health and Safety Requirements}
+
+This section is not in the original Volere template, but health and safety are
+issues that should be considered for every engineering project.
+
+\section{Project Issues}
+
+\subsection{Open Issues}
+Below is a list of open issues pertaining to the project scope:
+\begin{itemize}
+\item Investigating and understanding the capabilities of the Pygame library is yet to be completed.
+\item Integrating additional features is not decided on as of yet. It is dependant on time constraints.
+\item snake-game multiplayer mode is an open issue on the open source project which we may or may not choose to implement as time permits.
+\end{itemize}
+\subsection{Off-the-Shelf Solutions}
+
+Although there are available solutions on developing such a game, the project team is aiming to enhance the game by producing a desktop version with 
+added functionality.
+
+Ready-made simple implementations of the projects are available and can be used as reference but otherwise, enhanced features will have to be created from scratch (light/ dark theme, custom player settings, high scores and so on).
+
+\subsection{New Problems}
+
+\subsubsection{Effects on the Current Environment}
+
+The Microsoft Store contains the "250k snake" app for windows, an implementation of the old-school snake game. Aside from this application, other applications that appear when searching "snake" or "snake game" do not reflect the classical snake game. By developing the snake game as a desktop app, we will be able to provide game shoppers with more options to pick from. 
+
+\subsubsection{Effects on the Installed Systems}
+
+The existance of the 250k snake will make it difficult to push the project team's implementation of the game, Snake 2.o, into the microsoft store market successfully. However, the new snake game will fill a niche for cutsomizability by allowing users to pick from many different settings. 
+
+\subsection{Tasks}
+
+An article on linkedIn by Sumit Jain summarizes the steps involved in the game development process [ ~\cite{devArticle} ]. In his article, he outlines 6 main steps to the game development cycle: Idea \& Story, Conceptualize \& Design, Technical Analysis, Development, Testing, Deployment. Considering the project scope and the redevelopment of the snake game, the main three steps involved in the developement cycle are the following:
+\begin{itemize}
+\item Technical Analysis: Use reverse engineering to understand how the game was originally built and analyze the main modules/ framework used to develop the game.
+\item Development: Using Python and Pygame to develop the source code for the game; Analysis from the previous step will be necessary to break down the developement process.
+\item Testing: Test using unittest in python and principles of white box and black box testing. In further developments, this would also include intergation testing with the user interface and the collection of modules created for the application. 
+\end{itemize}
+
+Project members should expect the development cycle to resemble the previously mentioned framework. Once the cycle has been iterated until completion of Snake 2.o, the team will move on to the deployment stage, considering options for making the game available on a DDS such as the Microsoft Store.   
+
+\subsection{Migration to the New Product}
+
+Snake 2.o will be require the following conversion tasks:
+\begin{itemize}
+\item Converting JS,HTML and CSS graphics and animations to Pygame graphics.
+\item Comverting the source project into modularized step-based tasks.
+\item Converting from JS,HTML and CSS source code to Python source code.
+\end{itemize}
+
+The source project will be run with Snake 2.o for performance comparison and visual feedback on the accuracy of the redevelopment as well as the enhance features that were added to snake 2.o. 
+
+\subsection{Risks}
+
+Snake 2.o will be a classical desktop application and therefore does not present many risks to the user or any stakeholders involved. In terms of taking risk to advance the project, there is risk in striving for the completion of a multiplayer mode for the game since it may take substantial time and effort. However, this risk is low since the project requirements have already been met and other features of the game have been enhanced, aside from the addition of a multiplayer mode. 
+
+In the case that more risks are perceived in the future, the project team will take the following course of action to come up with early warnings:
+\begin{itemize}
+\item If the development is taking place 1 week prior to the project deadline, an early warning will be issued and the group must decide to continue or dismiss the development.
+\item If the development is currently taking place with 2 weeks left until the project deadline and less than 50\% of the development is in place, it will be dismissed.
+\item If the main project is missing any component (testing, code modularization, documentation, commenting, etc.) no development will proceed until the main requirements (minimum requirements) are met.
+\item If any of the main project components are deemed to have lower quality, a warning is issued and the team members must discuss whether to continue with further development or improving the existing product.
+\end{itemize}
+
+\subsection{Costs}
+As mentioned in the development plan document, team members will be dedicating 2 hours outside of lab time for team meetings and discussions along with 5 hours of individual work on the project itself. Since the project is open source and uses open libraries such as Pygame, the monetary cost is \$0. However, there may be additional costs to publishing Snake 2.o with a DDS.
+
+\subsection{User Documentation and Training}
+
+The user will be provided with the following documentation and training:
+\begin{itemize}
+\item Snake 2.o User Manual: The document will explain the basic permisses of the game, user settings, graphic themes, menu headings, and any other information necessary for the user to understand the features of the game.
+\item Snake 2.o Installation Manual: Provided that the user will not be using Windows or the native OS that is decided on, this document will provide simple installation instructions for compiling the code on different OS's.
+\end{itemize}
+
+\subsection{Waiting Room}
+In future releases of the project, the following requirements might be included in the revised requirements document:
+\begin{itemize}
+\item Snake 2.o User Manual - Multiplayer Mode: A section explaining how to connect and play the snake game with friends
+\item additional 'multiplayer mode' module: A separate module to encapsulate the multiplayer mode
+\item additional 'themes' module - a module encapsulating the different graphic themes available for the game
+\end{itemize}
+
+
+\subsection{Ideas for Solutions}
+
+Some rudimentary ideas for project modules and solutions have been mentioned down below:
+\begin{itemize}
+\item Classes/modules for individual objects like the snake, food block, the frame, the menu bar, the settings bar and so on.
+\item import graphics developed in adobe illustrator into the game as characters, props and so on.
+\item the snake class can have method that correspond to the snakes functionality such as moveLeft, moveRight, moveUp, moveDown, and Lengthen.
+\item the food item can have a randomPlacement method for when being placed at random around the window.
+\item UI: a custom header section can contain the entry fields for custom speed and other important parameters.
+\end{itemize}
+
+\bibliographystyle{plainnat}
+
+\bibliography{SRS}
+
+\newpage
+
+\section{Appendix}
+
+This section has been added to the Volere template.  This is where you can place
+additional information.
+
+\subsection{Symbolic Parameters}
+
+The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
+Their values are defined in this section for easy maintenance.
+
+
+\end{document}
\ No newline at end of file