Added more topics and filled in problem definition

1 files changed, 53 insertions, 12 deletions

diff --git a/plan.tex b/plan.tex
index 69a28ae..19f7aac 100644
--- a/plan.tex
+++ b/plan.tex
@@ -8,6 +8,47 @@
 \tablestables
 \newpage
 
+\section{Problem Definition}
+The assignment is part of a fourth-year minor. The assignments are not set in stone to give the team an opportunity to discuss with the project supervisor on specifics for this project 
+
+\subsection{Problem Analysis}
+CodedFun Games is a small, single-person game company looking to scale up. The owner, who is also a game programmer, graphical artist, and the client, has received government funding, which he wants to invest in a custom-built game engine. The owner has no interest in developing or maintaining a game engine himself, so he has hired a part-time engine programmer. This programmer does not have time to create an entire engine but is willing to maintain or expand an existing engine one day per week.
+
+The client seeks a custom game engine that is easy to maintain, extend, and user-friendly. Additionally, the engine should be well-documented, which is considered an essential aspect of being user-friendly.
+
+So far, the client has made all his games in Unity and is very fond of the structure. Therefore, he wants the new engine to adhere to a similar structure. A simple requirements document is defined to specify how strictly this structure should be followed.
+
+Finally, because the client does not want to dive deeply into the engine himself, he wants a secondary application (preferably a game) that can be used to test the engine's features. This is referred to as the `Validation App.'
+
+\subsection{Goal}
+The goal is to develop a custom game engine that meets the client's requirements for maintainability, extensibility, user-friendliness, and adherence to a Unity-like structure. In addition, a validation application should be created to test the engine's features.
+
+\subsection{Result}
+The expected result is a well-documented, custom game engine that follows a structure similar to Unity. Additionally, a validation application should be provided to test and showcase the engine's capabilities.
+
+\newpage
+
+\section{Planning}
+% todo add table of deliverables 
+week 4: sprint oplevering, project plan
+week 7: sprint oplevering
+week 10: sprint oplevering, POC and design
+week 17: eind oplevering
+
+\newpage
+
+\section{Risks}
+\subsection{Techincal Risks}
+%  todo add technical risks
+\subsection{Project Management Risks}
+Scope Expansion: There is a risk of creating a scope that is bigger than the requirements.
+Lack of Team Collaboration: Insufficient collaboration among team members 
+may hinder progress.
+\subsection{Measures}
+Scope Expansion: By writing detailed requirements and having weekly team meeting to check if the progress is within the scope should be sufficient to decrease the risk.
+Lack of Team Collaboration: Weekly team meetings will result is collaboration among team members and discussing what each other tasks is will decease this risk.
+\newpage
+
 % Documentation Standard is described here
 \section{Documentation}
 
@@ -32,18 +73,18 @@ This project consists of five main documents:\noparbreak
 	\item[Api referenece]  
 \end{description}
 
-\subsection{Documentation standard}
-
+\subsection{Documentation Standard}
+%  todo add link to contributing in this repo
 \newpage
 
-\section{Work agreements}
+\section{Work Agreements}
 Work agreements are the expectations and commitments made by the team members. 
 This section includes details on roles and responsibilities, documentation of 
 work hours, protocols for handling absences or delays, guidelines for addressing
  inconsistent participation, and procedures for weekly updates and meetings. All
   team members reviewed and agreed to these terms.
 
-\subsection{Project roles}
+\subsection{Project Roles}
 \begin{itemize}
 	\item \textbf{Loek Le Blansch}: Integrator
 	\item \textbf{Wouter Boerenkamps}: Project Member
@@ -53,11 +94,11 @@ work hours, protocols for handling absences or delays, guidelines for addressing
 \end{itemize}
 
 
-\subsection{Work hours}
+\subsection{Work Hours}
 Each project member will keep track of their own working hours and 
 add them to the `file'.
 
-\subsection{Absence or delay}
+\subsection{Absence Or Delay}
 If a project member is going to be absent or delayed, they are required to 
 notify the team through either WhatsApp or Outlook. Additionally, the teacher 
 should be informed of the absence as well.
@@ -86,7 +127,7 @@ without valid reasons. It is essential that any concerns regarding a team
 member's performance be resolved through unanimous agreement within the team.
 
 
-\subsection{Weekly update}
+\subsection{Weekly Update}
 Each team member is required to send their technical weekly update to Jaro 
 Rutjes before 12:00 on Friday. Personal updates may also be included and will be
  confidential between the team member, the Team Leader, and/or the teacher, if 
@@ -97,7 +138,7 @@ van der Putten, also by Friday. This update will include technical information
 on what has been accomplished, plans for upcoming work, and an overview of the 
 team's overall progress.
 
-\subsection{Weekly meetings}
+\subsection{Weekly Meetings}
 The project team will hold at least two meetings each week, with each meeting 
 lasting a maximum of 30 minutes. Following these meetings, an additional one 
 hour will be scheduled for discussions on the topics covered.
@@ -111,7 +152,7 @@ issues or project needs.
 % Information about how and when Scrum will be used in this project (using Miro).
 \section{Scrum (Miro)}
 
-The team will start using scrum after the inital fase of sructering the project is over.This fase is over when proof of concepts are being made.
+The team will start using scrum after the initial fase of structering the project is over. This fase is over when proof of concepts are being made.
 
 \subsection{Scrum Board}
 The \href{https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}{Scrum board} will consist of the following tabs:
@@ -138,7 +179,7 @@ To manage tasks effectively:
 Each task or user story will be assigned user points, which indicate the relative size or complexity of the task compared to these examples.
 TODO: add examples
 
-\subsection{Burn down chart}
+\subsection{Burn Down Chart}
 The Burn Down Chart will be generated using Excel from the Scrum board data every week.
 Each user story or tasks marked as done will burn the chart downwards.
 This Burn down chart is shared in the weekly updates with the team and the project supervisor.
@@ -155,9 +196,9 @@ This keep the documentation and code seperate, resulting in ordened and manageab
 	\item Documentation Repository: \href{https://github.com/lonkaars/crepe-docs}{crepe-docs}
 \end{itemize}
 
-\subsection{Git new branch}
+\subsection{Git New Branch}
 % TODO: add here details from contributing.md?
-\subsection{Git merge to master}
+\subsection{Git Merge To Master}
 % TODO: add here diagram on what actions are taken before merge.
 \newpage