%&tex
\subsection{Problem Description}
The problem description describes the need for a solution or system.
In this case, I want a robot that can write a tweet on a whiteboard.
A specific requirement is that the system must be complex enough, such that the specific aspects of the design method are used.
These specific aspects are the ones that deal with complexity and are subject to the evaluation.
The system must meet the following requirements:
\begin{itemize}
    \item Write a twitter message, or tweet, on a whiteboard.
    \item Remove the tweet from the whiteboard.
    \item Write the tweet within three minutes on the board.
    \item The text must be readable across a meeting room.
    \item The solution must contain interesting dynamics.
\end{itemize}

\subsubsection{Evaluation}
The problem description is very brief, which is not a complete surprise.
As most of the work for the problem description was already done by choosing the subject of design.
However, it was not expected to be this minimal.
Perhaps the most serious disadvantage is the absence of stakeholders.
Normally, a good problem definition focusses on getting the stakeholders on the same line \autocite{shafaat_exploring_2015}.
However, this case study does only have one stakeholder, the author, defeating the purpose of getting everyone on the same line.
Creating a more elaborate problem description would not improve the evaluation of the design process, but it does cost valuable time.
