|
|
|
@@ -1,6 +1,42 @@ |
|
|
|
%&tex |
|
|
|
\chapter{Reflection} |
|
|
|
\label{chap:reflection} |
|
|
|
\chapter{Design Method Evaluation} |
|
|
|
\label{chap:reflection} |
|
|
|
|
|
|
|
\section{Factorizing features} |
|
|
|
During the course of this study, the concepts of specifications, components and functions are added to the design method. |
|
|
|
As explained in the background chapter, having an approach to determine specifications is a crucial concept of a design process. |
|
|
|
Because \ac{ridm} did not include such an approach, a \ac{se} approach was added. |
|
|
|
The aim of the \ac{se} approach is to deliver a set of features to be used in the \ac{ridm}. |
|
|
|
To be more specific, the set of features was expected to be the result of the feature definition step. |
|
|
|
Contrary to that expectation, multiple attempts for this step did not produce a satisfactory definition of features. |
|
|
|
As explained in \autoref{sec:case_featuredefinition}, there was a clear discrepancy between the expected and resulting features. |
|
|
|
It was expected to get features in the form of components that can be developed during the design process. |
|
|
|
However, the resulting features came off as functions of the system. |
|
|
|
In the end, a solution was found in the RobMoSys approach. |
|
|
|
Even though the RobMoSys approach was too comprehensive for this case study, it provided the basis for the split between functions and components. |
|
|
|
Furthermore, it resulted in the hierarchical structure of functions and sub-functions as shown in \autoref{fig:robmosys}. |
|
|
|
|
|
|
|
\begin{figure} |
|
|
|
\centering |
|
|
|
\includegraphics[width=85mm]{graphics/functional_relation.pdf} |
|
|
|
\caption{Relations and elements within a feature. \autocite{kordon_model-based_2007}} |
|
|
|
\label{fig:functional_relation} |
|
|
|
\end{figure} |
|
|
|
|
|
|
|
Creating a hierarchy for the functions and a separate set of components allowed for the continuation of the case study. |
|
|
|
There were still a number of challenges with this approach. |
|
|
|
For example, it was almost impossible to divide the specifications between components and functions. |
|
|
|
Furthermore, the roll of electronics did not fit in the current approach either. |
|
|
|
In reviewing the literature, the approach used in this case study shows clear resemblances with \ac{mbed} \autocite{kordon_model-based_2007}. |
|
|
|
\ac{mbed} introduces explicit relations between the requirements, components and functions, as shown in \autoref{fig:functional_relation}. |
|
|
|
Additionally, the paper includes a layout for the hierarchy of requirements, functions and components. |
|
|
|
Based on this, the approach by \textcite{kordon_model-based_2007} further supports the idea of dividing features into specifications or requirements, functions, and components. |
|
|
|
|
|
|
|
What is interesting about this new insight is that it helps to understand the difference with the case study performed by \textcite{broenink_rapid_2019}. |
|
|
|
The hardware components used by Broenink and Broenink was a mini-segway, which was designed for a student project. |
|
|
|
The requirement of this mini-segway is that has to balance, drive, and steer. |
|
|
|
Causing the requirements and components to be implicitly defined in their case study. |
|
|
|
Therefore, the function that needs to be implemented, fits very well within the definition of a feature. |
|
|
|
|
|
|
|
\section{Information Flow} |
|
|
|
%% Aanknopen op het vorige verhaal? |
|
|
|
|
