%&tex
\chapter{Analysis}
\label{chap:analysis}
\begin{marginfigure}
    \centering
    \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}
The previous chapter introduced how two design methods are combined to form the bases for one complete design method.
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 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{Rapid Iterative Design Method}

\subsection{Feature Definition}

\subsection{Feature Selection}

\subsection{Rapid Development Cycle}

\subsection{Variable Approach}


