Add evaluation on Prep. phase

content/background.tex

@@ -13,6 +13,7 @@ The techniques of the \ridm replace the implementation and testing phase of the
 This chapter will introduce the basics of \ac{se} and the waterfall model, and analyse what the \ridm provides.
 
 \section{Systems Engineering}
+\label{sec:SE}
 \begin{marginfigure}
     \centering
     \includegraphics[width=2.9cm]{graphics/waterfall.pdf}

content/case_evaluation.tex

@@ -1,3 +1,42 @@
 %&tex
-\chapter{case evaluation}
-\label{case_evaluation}
+\chapter{Case Evaluation}
+\label{chap:case_evaluation}
+
+\section{Preparation Phase}
+\subsection{One-man development team}
+The case study was performed by me, as a single developer.
+Against all expectations, this one-man development team made the preparation phase more difficult instead of easier.
+The goal of the problem description and the specifications step is to get the stakeholders on the same line \autocite{shafaat_exploring_2015}.
+This involves creating agreed-upon requirements for the system, but with only one stakeholder, this agreement is implicit.
+Moreover, it undermines the incentive of the problem description and specifications step.
+Part of this is that there is no penalty for future reviews of the specifications, as I already agreed.
+
+Furthermore, specific details and decisions were often made subconsciously, while I was commuting, waiting in line, or even showering.
+Making structured documentation of these decisions at a later point in time without missing any of them was impossible.
+The social interaction within a design team stimulates this documenting process as it improves the recall and interpretation of information.
+It also improves the judgement and selection between design alternatives \autocite{lamb_221_2008}.
+
+\subsection{Information Flow}
+%% Aanknopen op het vorige verhaal?
+Although team members improve the information flow within a design team, it does not guarantee that all information is available.
+Throughout the case study, more and more information becomes available.
+During the initial design, new insight was gained that would have been useful during the problem description and the specifications step.
+And while making the tests, it became clear that the specifications were incomplete.
+It is possible to review the specifications step, but the succeeding steps have to be redone as well. 
+During the case study, I decided to continue with the design due to the scope of the research, namely the development design cycle was.
+
+Dealing with these design changes is a known weakness of the waterfall model.
+Many publications give credit to \textcite{royce_managing_1970}, for the concept of the waterfall model.
+Where they refer to the simple 5 to 8 step design concept, similar to the one in \autoref{sec:SE}.
+What these publications fail to address is that \textcite{royce_managing_1970} says: "I believe in this concept, but the implementation described above is risky and invites failure."
+Followed by multiple steps of improving the waterfall model.
+Royce adds a complete design step, loads of intermittent testing and documentation, and a literal instruction "Do it twice".
+With "Do it twice", he adds an extra 6 steps to develop a prototype parallel to the simple waterfall model, with the goal to spot every unforeseen requirement prior to any actual development.
+
+Interestingly, the mentioned problems that \textcite{royce_managing_1970} is providing a solution for, are similar to the difficulties in this case study.
+Studies and publications about the waterfall model would have been far more relevant if the authors included Royce's improvements.
+Especially as Royce explains that in his experience, the method without his improvements has never worked and that recovery costs far exceeded the added cost of the proposed improvements.
+I expect that these improvements would have had a significant impact on the design process.
+
+
+