fixup! fixup! fixup! Add analysis

content/analysis.tex

@@ -3,7 +3,7 @@
 \label{chap:analysis}
 \begin{marginfigure}
     \centering
-    \includegraphics[width=6cm]{graphics/design_flow_analysis.pdf}
+    \includegraphics[width=6cm]{graphics/design_flow.pdf}
     \caption{Overview of the design flow, split in two phases: Preliminary Design and the \ac{ridm}.}
     \label{fig:design_flow_analysis}
 \end{marginfigure}
@@ -11,58 +11,53 @@ The previous chapter introduced how two design methods are combined to form the
 In this chapter, a design plan is created from this combined design method.
 The goal is to have a concrete design plan that can be used in the case study.
 All of the steps in the design plan must be specific such that each of these steps can be evaluated after the case study is finished.
-The design plan is split in a preliminary design and a \ridm part as shown in \autoref{fig:design_flow_analysis}.
+The first three steps of the design phase are based on the \ac{se} approach and are already described with great extend by \textcite{blanchard_systems_2014}.
+As the evaluation of \ac{se} is not in the scope of this thesis, this chapter only covers the minimal description of the design steps in \ac{se}.
+The steps that are introduced by \ridm are covered in more detail.
+
+\section{Systems Engineering}
+    The goal of the preliminary design is to setup system requirements and an initial design according to the problem definition.
+    Although these design steps in \ac{se} play a crucial roll in the success of the development, they are, however, very exhaustive.
+    A major part of this complete design process is the required documentation to ensure agreement about the design between the different stakeholders.
+    Resulting in a process that can take months or even years, which is not feasible for this thesis.
+    In this thesis, this design plan is only used for evaluation and will have only one stakeholder, the author.
+    This allows for a simple implementation of the \ac{se} approach, as it not possible to create a false start due to misunderstanding, saving valuable time.
+    For each of these \ac{se} steps is explained what is involved with a full implementation, and what part of the step is used in the design plan.
+
+    \subsection{Problem Definition}
+        Before any design process can start, the "problem" has to be defined.
+        In other words, why is the function of the system needed?
+        This is described in a \emph{statement of the problem}.
+        In this statement of the problem it is important to describe "what" has to be solved, not directly "how".
+        \textcite{blanchard_systems_2014} also note that "defining the problem is often the most difficult part of the process".
+        It is important to ensure good communication and understanding between the different stakeholders.
+        Otherwise, it is possible that the designed product is not up to the customers expectations.
+        It furthermore involves defining the subjects like what are the primary and secondary functions? When must this be accomplished? What is not a function?
+        For this thesis, however, the problem definition is limited to a short statement of the problem, covering some required functions with corresponding requirements.
+
+    \subsection{System Requirements}
+        The system requirements are derived from the problem definition, and describe the characteristics of the system.
+        As these characteristics form the foundation of the system, the requirements must be defined without any ambiguity, vagueness or complexity.
+        The requirements will be written according to the \ac{ears} \autocite{mavin_easy_2009}.
+        \ac{ears} was chosen for this design method due to its simplicity, which fits the scope of this thesis.
+        Later in the design, these requirements are divided over the subsystems.
+        Any issues, like ambiguity, in the requirements, propagate through these subsystems.
+        This might lead to a redesign of multiple sub-systems when these requirements have to be updated.
+
+    \subsection{Initial Design}
+        In the initial design step, the "what has to be solved", is expanded with a solution on "how it is solved".
+        To find the best solution it is important to explore the different solutions and design space.
+        Often, there are many possible alternatives but they must be narrowed down to the solutions that fit within the schedule and available resources.
+        This step results in one initial design that can be used in the next phase of the design.
 
-
-
-\section{Preliminary Design}
-    The goal of the preliminary design is to setup a list of features that can be implemented in the \ridm phase.
-    To get to this list, there are four different steps to be completed.
-    Although these steps play a crucial roll in the success of the development, they are, however, also the most difficult steps of a design process \autocite{blanchard_systems_2014}.
-    An exhaustive design process would takes months or even years, and is just not feasible for this thesis.
-
-
-\subsection{Problem Definition}
-    The first step of the design cycle is to describe the problem that has to be solved.
-    A clear and concise problem definition increases a successful design process.
-    It gives a better basis for the system requirements.
-    Therefore, lowering the number of reviews required for the system requirements.
-    Furthermore, good definitions help determine the overall feasibility of the project in an early stage.
-
-\subsection{System Requirements}
-    The system requirements are derived from the problem definition.
-    As the features will be derived from these system requirements, the goal is to define the requirements without any ambiguity, vagueness or complexity.
-    The requirements will be written according to \ac{ears} \autocite{mavin_easy_2009}.
-    \ac{ears} was chosen for this design method due to its simplicity, which is is deemed suitable for the scope of this research.
-    If issues, like ambiguity, are not dealt with correctly, these issues can propagate into the sub-requirements that will be defined for each feature.
-    Solving these issues in a later stage of the design could require a redesign of features that were already completed.
-
-\subsection{Initial Design}
-    At the start of a development the final solution for the problem is unknown.
-    It is important to explore the different solutions and design space.
-    The goal of this initial design is to create an overview of these possibilities.
-    Due to the scope of this research, the choice of design solutions is made for a design that is expected to fit this research, instead of determining the optimal solution.
-
-    However, in an actual design case, this step is crucial and can even be extended.
-    A problem can be solved with more than one design.
-    It is expected that these design solutions contain identical features.
-    For example, take a cube that has to be moved.
-    Each design has a grab feature that picks up the cube.
-    Instead of choosing a specific initial design, we could start by implementing the grab-feature.
-    If the grab feature proofs to be infeasible, we know that we have to choose a different design.
-    Would the grabber be a success, then the feature is already implemented for the designs that use it.
-
-    This can reduce the risk during the design by implementing features first that have overlap in other design solutions.
-    First of all, it can help select a suitable design solution.
-    If a initial design fails in a later stage, switching to a different design can be cheaper as some features are transferable.
+\section{Rapid Iterative Design Method}
 
 \subsection{Feature Definition}
 
-\section{Rapid Iterative Design Method}
+\subsection{Feature Selection}
 
 \subsection{Rapid Development Cycle}
 
 \subsection{Variable Approach}
 
-\subsection{Feature Selection}