mar/content/case_experiment_feature_definition.tex

%&tex
    \subsection{Feature Definition}
                \label{sec:case_featuredefinition}
            At this point there are specifications and an initial design for the system.
            In the following steps of the design method features will be implemented one by one.
            The goal of this step is then to define these features.
            During this step it became clear that this approach was not feasible.
            Prior to this step the expectation was that this step would produce three features that could be implemented.
            These three features were the SCARA, the cable suspended carriage, and the end-effector.
            However, independent of the interpretation of this step, the result was not the three expected features.

            Why were those three features expected in the first place?
            During the previous steps a useful evaluation was to anticipate for the subsequent steps.
            Where one of the following steps is to implement an individual feature.
            Therefore, it must be possible to implement the feature.
            Separating the initial design into the smallest components that could still be implemented, resulted in the SCARA, carriage and end-effector.

            The problem is that these three components do not describe the complete system.
            Some functions of the system (feature) is performed by a combination of the components.
            Therefore can the components in the system not be seen as features of the system.
            Defining the components as features of the system is not a solution.
            The relations between the components and features is still required.

            %As the features describe the behavior of the components, it is not a solution to replace the features with components.

            A solution to organize the relations between features and components was found in RobMoSys\footnote{\url{https://robmosys.eu/approach/}}.
            RobMoSys defines a separation of levels in a design.
            Where the levels start functional and moves via software to hardware implementation.
            Although not all levels of RobMoSys are used, it was very useful to define the features of the system.
            The definition can be seen in \autoref{fig:robmosys}
            The current definition of features allows to start the implementation with a component.
            When the component is finished features can be implemented by following the tree upwards.
            \begin{figure*}
                \centering
                \includegraphics[width=0.85\linewidth]{graphics/robmosys}
                \caption{Feature Definition based on the separation of levels introduced by RobMoSys}
                \label{fig:robmosys}
            \end{figure*}

            \subsubsection{Evaluation}
                Even though there is a feature definition that can be used in the next step, there remain a couple of difficulties.
                There is still a really strong border between features and components.
                And the single level of components makes it impossible to depict the dependencies between components.
                Developing larger and complex systems will have sub-components in the system, introducing even more dependencies.
                Therefore, this is not a valid solution for feature definition.
                Fortunately the current solution suffices to continue the case study.