|
- %&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.
|
