mar/content/analysis.tex

%&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}
    From this point, the design plan is based on the \ridm and not anymore on the waterfall model.
    The first step is the feature definition, which prepares the required features based on the initial design.
    The features are defined by splitting the system in such a way that the results of each implemented feature are testable.
    The definition of the feature contains a description and a set of sub-requirements which is used to implement and test the feature.
    During the feature definition, the dependencies, risks and time resources are determined as well, this establishes the order of implementation in the feature selection step.

    The second step is the feature selection, where one of the features is selected. 
    This selection is based on the dependencies, risk, and time requirements in the feature definitions.
    The third step is the rapid development cycle, which uses the sub-requirements and description of the selected feature to create an initial design, a minimal implementation and tests.
    In the last step, the variable detail approach is used to add detail to the minimal implementation over multiple iterations.
    The tests are used to determine if the added detail does not introduce any unexpected behavior.
    This cycle of adding detail and testing is repeated till the feature is fully implemented.
    From this point, the \ridm is repeated from the second step until all features are implemented.

\subsection{Feature Definition}
    \label{sec:featuredefinition}
    During the feature definition, the system will be split into features as to prepare for the rapid development cycle and the variable-detail approach.
    The goal is to split the system in such way that the resulting features are as small as possible, but can still be implemented and tested individually.


\subsection{Feature Selection}
    \label{sec:feature_selection}

\subsection{Rapid Development Cycle}

\subsection{Variable Approach}