|
- %&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\footnote{\url{https://blog.twitter.com/official/en_us/topics/product/2017/tweetingmadeeasier.html}}.
- 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 to have interesting dynamics.
- Looking at simple plotters, they are referred to as 2.5D as the 'third' dimension only describes a binary state.
- For this system, the minimum is set to a system that has at least four full states that have to be controlled.
- Using \ac{ears} to define these specifications gives:
- \begin{enumerate}
- \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 Writer shall contain at least four states that require control in order to function.
- \end{enumerate}
- Some other specifications that are related to the operation of the system are:
- \begin{enumerate}
- \setcounter{enumi}{8}
- \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}
-
- 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{itemize}
- \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) in different sizes.
- \item Drill
- \item Screwtaps
- \item Jigsaw
- \item Wrenches
- \item Soldering iron
- \item Various Pliers
- \item PLA 3D printer
- \end{itemize}
- \end{itemize}
- \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.
|
