|
|
@@ -1,14 +1,62 @@ |
|
|
%&tex |
|
|
%&tex |
|
|
\chapter{Analysis} |
|
|
\chapter{Analysis} |
|
|
\label{chap:analysis} |
|
|
\label{chap:analysis} |
|
|
|
|
|
\begin{marginfigure} |
|
|
|
|
|
\centering |
|
|
|
|
|
\includegraphics[width=6cm]{graphics/design_flow_analysis.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 design plan is split in a preliminary design and a \ridm part as shown in \autoref{fig:design_flow_analysis}. |
|
|
|
|
|
|
|
|
\section{Preparation} |
|
|
|
|
|
|
|
|
|
|
|
\subsection{Problem Description} |
|
|
|
|
|
|
|
|
|
|
|
\subsection{Design Specifications} |
|
|
|
|
|
|
|
|
\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{Feature Seperation} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\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. |
|
|
|
|
|
|
|
|
|
|
|
\subsection{Feature Definition} |
|
|
|
|
|
|
|
|
\section{Rapid Iterative Design Method} |
|
|
\section{Rapid Iterative Design Method} |
|
|
|
|
|
|
|
|
|