mahd/features/content/introduction.tex

\chapter{Introduction}
This document will describe the feature and test specification step.
The original plan was to specify features and give these features there own specifications.
Together these feature specifications have to ensure that the system specifications are met.
And eventually for each feature a set of tests is designed so that the feature specifications can be monitored.

However, during this step it became clear that this method was not feasible in the limited amount of time.
Spending more time on this step would not result in a better test of the method.
It might even have a negative effect as other steps would be overshadowed by this step.
Eventhough the step has not been finished we still managed to learn some valuable lessons.

One of the lessons was to use RobMoSys for the feature specifications.
This will be explained in \autoref{chap:robmosys}.
The feature specifications were very difficult as it turned out that a lot of this depended on the level of detail in the system specifications.
We will explain this part in \autoref{chap:specifications}.

\chapter{RobMoSys}
\label{chap:robmosys}
The original method was to just look at the features of the system and describe them.
This turned out to be impossible as there are a lot of features at different levels with different dependencies.
For example \textcite{broenink_variable_2018} defines three features on his segway.
However, the hardware already exist.
Therefore, features like wheels, motors, sensors, powerpack, etc. do not have to be considered.
We underestimated the amount of features if you do not have pre-existing hardware.
A problem was that, for example, a motor did not fit in our original idea of feature.
However, taking a high-level feature defeated the purpose of this method with multiple steps of implementation.
As this high-level feature would then include motors, control, sensors etc.

Eventually we used RobMoSys to separate the features in a way that made sense.
We started with a mission, which is in this case the 'tweet on a whiteboard' and broke it up in to tasks.
So what tasks are required to fulfill the mission.
These tasks required certain skills, which required then functions.
\autoref{fig:robmosys} shows the resulting graph of the separation into different levels.
The figure also shows our fifth layer as subsystem.
A full Robmosys would even separate this in to 4 additional layers but we decided on keeping it simpler.
The simplification was done as this was mainly in middle- and software which was not the focus of this thesis.
Furthermore, because we did not see any additional value but it would cost a lot of extra time.

\begin{figure*}
    \centering
    \includegraphics[width=0.8\paperwidth]{graphics/robmosys.pdf}
    \caption{Separation of the mission into tasks, skills, functions and subsystems based on a simplification of RobMoSys.}
    \label{fig:robmosys}
\end{figure*}

In the end the graph gives us a lot of sub-features.
We will not implement every single node as a feature because 15 small features would only create loads of overhead.
But what we can do is group sub-features.
This also brings another advantage because we include a higher-level feature that can be used as test.
For example, the SCARA can be tested by successfully moving the marker on the board.

In the later step where we will select one of the features we will use this graph as a basis.
We can group features from this graph such that they can be implemented in about a week.
This way we reduce the overhead of implementation and keep an eye on the progress.

\chapter{Specifications}
\label{chap:specifications}
The following step was to distribute the system specifications between the features.
The problem we ran in to is that neither the system specification nor the RobMoSys was implemented with enough detail that they could work together.
Parts of the specifications lacked in detail, even with the use the EARS-method \autocite{mavin_easy_2009}.
This resulted that some specification where valid for all sub-features as the specifications where to broad.
However, improving the specifications would sometimes result in that it did not fit on one of the sub-features.
This is because the RobMoSys misses sub-features which would specifically implement the control system.

While we were working on this step we updated the system specifications.
This was done because we found that some of the specification did not make any sense in for this research.
While others were really easy to expand.
Therefore, these following list represents the updated specifications:
\begin{itemize}
\item The Writer shall be able to write at least 50 characters per line.
\item The Writer shall be able to write at least 5 lines of text.
\item The Writer shall plot characters with a size that is readable from 4 meters for a person with good eyesight.
\item The Writer shall plot in a regular used font with corresponding character spacing.
\item When a new tweet is send to the Writer, the Writer, shall wipe the existing tweet and write down a new tweet.
\item If the Writer is not wiping or writing then the Writer shall not obstruct the view of the whiteboard.
\item While writing, the Writer shall have a writing speed of at least 1 character per second.
\item If the Writer is tasked to wipe the tweet, the Writer shall wipe the tweet within 60 seconds
\item When a reset-signal is send to the Writer, the Writer shall re-calibrate its position on the board.
\item When a wipe-signal is send to the Writer, the Writer shall wipe the board clean.
\item The Writer shall not damage itself.
\item While writing, the SCARA shall have a writing speed of at least 1.5 characters per second.
\item When the Carriage/base of the SCARA is at a static position, the SCARA shall be able to write at least 3 characters at that position.
\item When the SCARA finished writing at their current position, the Carriage shall move the SCARA to it's next position where it can write the subsequent characters.
\item When the SCARA has to be moved to a new position, the Carriage shall perform this movement within 1 second.
\end{itemize}

\chapter{Decision}
In the end we decided that a it was better to stop the current step.
We have some specific points that require improvement in a follow up.
The steps system specifications, initial design, feature separation and feature specifications have to be merged in to a kind of spiral model.
Where the process would start with a global description of the system and some initial designs.
This initial design can then be expanded with some course system specifications.
This would be followed by a RobMoSys-type of analysis.
The RobMoSys gives a brief interpretation of the different subsystems required.
For each subsystems we have to assign specifications, if it seems that this is difficult we can choose to review the specifications.
We can add more detail to the specifications for example, or split them in to multiple separate specifications.

For now, we have enough information to test the next steps.
At the beginning of each feature-implementation we will write the test specifications.
And during the selection we have to keep the list of specifications in mind.
We think that this is possible as the list of specifications and the set of systems is manageable.