mar/content/case_experiment_feature_definition.tex

%&tex
\subsection{Feature Definition}
    \label{sec:case_featuredefinition}
    This step divides the specifications and initial design into features. 
    These features will be implemented one by one during the development cycle, later in the process.
    As described in \autoref{sec:featuredefinition}, the functionality of the system is split over four different levels of abstraction.
    The result of this split is shown \autoref{fig:robmosys}.
    
    \begin{figure*}
        \centering
        \includegraphics[width=136mm]{graphics/robmosys.pdf}
        \caption{Hierarchical tree of different functions and components.}
        \label{fig:robmosys}
    \end{figure*}

    \subsubsection{Evaluation}
    \label{sec:case_featuredefinition_evaluation}
        The mission and task features are easy to define.
        The skill and service features become a bit more vague, often features fit in both categories.
        Sometimes it is difficult to split a skill into a service, as they are already very specific.
        Additionally, I attempted to keep the feature tree a bit compact, to keep in scope with this thesis.
        If each feature would have been split methodically, the amount of features would be immense.

        The components could also use a similar approach as the functions, resulting in a hierarchical structure of sub-components.
        Where the \ac{scara} would have motors and electronics as sub-components.
        
%        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 clear separation 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.

    %%%%%%%%%%%%%%%%%%%%%%%
%    It was however not possible to describe the all aspects of the design with features.
%    I found that the design method did not take components into account.
%
%    
%
%    However, the initial set of features did not meet the expected set of features.
%    This led me to review how the features are defined.
%    The following sections explain what the problem caused and how it is solved.
%
%    \subsubsection{Splitting the features}
%        The first issue was the lack of a clear border between features.
%        Thus, depending on where the developer places that border, the set of features changed significantly.
%        For example, the main functionality is \emph{writing a tweet on a white-board.}
%        A clear feature of this functionality is \emph{writing}.
%        However, must the \emph{writing} be split in a feature for writing a line, a word, or single character?
%        Moreover, it is also possible to argue that \emph{writing one character} a sub-feature of \emph{writing a word}, which in itself is a sub-feature of \emph{writing a line} etcetera.
%
%    \subsubsection{Missing features}
%        The second issue was that the resulting set of features did not contain any of the expected features.
%        From the initial design it was expected that the features must include a SCARA and a cable driven carriage, because they make the system and have to be implemented somewhere in the process.
%        However, independent of how the functionality was split into features, no SCARA nor cable driven carriage was included in the set of features.
%        Which is not surprising as the SCARA and carriage do not define any functionality and can therefore not be a result from the current approach.
%        This mismatch between results and expectation together with the ambiguity of splitting features called for a review the design method regarding the current step.
%        
%    \subsubsection{Feature and Component Hierarchy}
%        The solution for both issues is a hierarchical structure for the features.
%        The structure is based on the RobMoSys principle for separation of levels \autocite{noauthor_robmosys_2017}.
%        The top-level of the structure is the mission, which represents the higher level goal of the system.
%        Each mission consists of a number of tasks, where each task consists of a number of skills.
%        The levels cascade down towards the bottom-level for RobMoSys, which is the hardware layer.
%        Although not all the different levels from the RobMoSys principle were applicable to the design method in this study, it enabled me to create the feature definition as shown in \autoref{fig:robmosys}.
%        In this feature definition, the levels from mission to function are used to describe the different features of the system.
%        The mission describes the holistic functionality of the system.
%        The subsequent levels all split off in more detailed behavior.
%        The bottom level is used to describe the hardware components which are responsible for performing the functions of the system.
%        This hierarchy allows to implement features or components one by one, starting from the bottom and combining this into a system towards the top.