mar/content/case_experiment_specifications.tex

%&tex
    \subsection{Specifications}
    \label{sec:specifications}
        The next step is to create specifications based on the problem description.
        The goal is to write and remove a tweet on the whiteboard.
        Originally a tweet had a character limit of 140, but this was doubled to 280\autocite{rosen_tweeting_2017}.
        However, for this system the limit remains at 140 characters.
        The text is limited to fifty characters per line, with a total of three lines.
        This results in ten extra characters that can be used for word wrapping.
        For the readability, the distance to a whiteboard in a meeting room is taken as \SI{4}{\meter}.
        The operating speed should allow the tweet to be written within three minutes. 
        Therefore, the goal is to write one character per second.
        The last requirement is that the dynamics of the system must be sophisticated.
        Meaning that a solution with complex or non-trivial behavior is preferred.
        Using \ac{ears} to define these specifications gives:
        \begin{specification}
            \begin{enumerate}
                \setlength{\itemsep}{10pt}
            \item The Writer shall be able to write at least fifty characters per line.
            \item The Writer shall be able to write at least three 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 the 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 one character per second.
            \item The dynamics of the Writer shall be complex/sophisticated/interesting.
        \end{enumerate}
        \end{specification}
        Some other specifications that are related to the operation of the system are:
        \begin{specification}
            \begin{enumerate}
                \setcounter{enumi}{8}
                \setlength{\itemsep}{10pt}
                \item If the Writer is tasked to wipe the tweet, the Writer shall wipe the tweet within sixty seconds
                \item When a reset-signal is send to the Writer, the Writer shall recalibrate 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.
            \end{enumerate}
        \end{specification}

        Additionally there are some restrictions on construction.
        As the rapid prototyping facilities at the university are closed due to the Covid-19 pandemic, the available tooling in reduced to some hobby/DIY tools:
        \begin{specification}
            \begin{itemize}
                \setlength{\itemsep}{10pt}
                \item The Writer shall not exceed a total cost in materials and/or tools of €200.
                \item The Writer shall be constructed with simple tools in the following list:
                    \begin{itemize}
                        \item Screwdrivers (Hex/Inbus, Torx, Philips, etc)
                        \item Drill
                        \item Screwtaps
                        \item Jigsaw
                        \item Wrenches
                        \item Soldering iron
                        \item Various Pliers 
                        \item PLA 3D printer
                    \end{itemize}
            \end{itemize}
        \end{specification}
        \subsubsection{Evaluation}
            The specifications step was performed without problems.
            Defining the specifications for the problem description did not present any difficulty.
            Due to the simplicity of the problem description, there were no contradictory requirements, which would complicate the specifications.
            Furthermore, a single stakeholder takes away any negotiation the stakeholders.

            Although the specifications itself are not difficult to define, ensuring that they are complete is difficult.
            Team members and stakeholders help to spot any ambiguity or problems with the validity.
            \ac{ears} was very useful in this case as it gives a strong template to help avoid ambiguity.