Rewrote the feature definition process

content/case_experiment_feature_definition.tex

@@ -1,55 +1,45 @@
 %&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 to define those features.
-    However, the predefined approach was not able to produces a set of features that could be implemented.
-    This forced me to create a new approach for this step, introducing components into the design.
-    This section will first address why the current approach is not suitable, followed by the alternative approach.
+    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.
+    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{Struggles with Features}
-        For their case study, \textcite{broenink_rapid_2019} design a control system for a mini-segway.
-        This mini-segway is an already existing \ac{cps} that is used during the lab-sessions of a control course, and any control-law can be uploaded directly to the system.
-        The specified features of that system are defined as:
-        \begin{enumerate}
-            \item Balancing the mini-segway upright
-            \item Steering the mini-segway
-            \item Driving forward and backward
-        \end{enumerate}
-        Although this is not explicitly explained, these features have dependencies: the steering and the driving both rely on a balanced segway.
+    \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.
 
-        A set of features for the Whiteboard writer would be:
-        \begin{enumerate}
-            \item Write character on position
-            \item Move carriage to position
-            \item Write text
-        \end{enumerate}
-        In this case, features 1 and 2 are required for feature 3.
-        However, in contrast with the mini-segway, the whiteboard writer does not exist yet.
-        Instead of creating a model based on the system, the system has to be designed first.
-        For these three features, the required hardware can be designed together with the feature.
-        The first feature would then also contain the design of the SCARA and the second feature the cable bot design.
-        Adding the features needed to meet the specifications for wiping the whiteboard, then such a feature would also need to design the SCARA.
-        In other words, more than one feature uses the SCARA in their behavior.
-        Resulting in the question: which feature should implement the hardware?
-
-    \subsubsection{Separating Functions and Components}
-        It was decided not to add the SCARA and the cable bot as features, for the reason that they do not define behavior.
-        Instead, the features define how the hardware behaves.
-        A solution to organize the relations between features and components was found in RobMoSys \autocite{noauthor_robmosys_2017}.
-        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 is shown 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.
+    \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.
+        
         \begin{figure*}
             \centering
-            \includegraphics[width=0.85\linewidth]{graphics/robmosys}
+            \includegraphics[width=136mm]{graphics/robmosys.pdf}
             \caption{Feature Definition based on the separation of levels introduced by RobMoSys}
             \label{fig:robmosys}
         \end{figure*}
+    \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.
 
     \subsubsection{Evaluation}
     \label{sec:case_featuredefinition_evaluation}