+ \item \textbf{Performance efficiency} \label{sec:perf_eff}\\
+ As the SUT runs as a service on a system with other programs it must have
+ efficient \emph{resource utilisation}. It can not contain any memory leaks
+ or use other resources more than necessary.
+ \item \textbf{Compatibility}\\
+ \emph{Interoperability} is the key feature of the SUT as it's purpose is to
+ communicate with other systems implementing the TCP protocol. Therefore it
+ is of vital importance that the SUT implements the TCP protocol correctly.
+ Furthermore it is very important that the SUT can \emph{co-exist} with
+ other programs on the system it runs on, since it is used as a service by
+ those programs. This means that the SUT has to handle preemption as well as
+ having multiple programs requesting it's services at once.
+ \item \textbf{Reliability}\\
+ As stated before, the SUT is used as a core service, this means it has to
+ be very \emph{mature}. It needs to behave as expected under normal working
+ conditions. As it can continually be requested the SUT needs to have
+ constant
+ \emph{availability}. As the SUT relies on a potentially unreliable channel
+ to send and receive data it needs to be \emph{fault tolerant}. The SUT
+ needs to properly handle errors in received data or complete unavailability
+ of the underlying channel.
+\end{itemize}
+This leaves four categories which are not relevant the SUT. Below we will
+shortly discuss per category why these are not relevant. \emph{Maintainability}
+is an important aspect of any software system, however for the SUT it is not a
+core aspect, as it is first and foremost of importance that the implementation
+is correct, furthermore TCP does not change often. \emph{Usability} isn't a
+core aspect either, as the SUT is not used directly by humans, but is a service
+which is addressed when another program needs it. \emph{Portability} isn't
+either as the SUT is installed on a system once and intended to work on that
+system. \emph{Security} isn't a feature of the SUT either, systems using the
+SUT can add their own security mechanisms on top of it.
+
+
+\subsubsection{Quality in use}
+Quality in use is dived into five subcategories. Below we will discuss the
+categories which are relevant to the SUT.
+\begin{itemize}
+ \item \textbf{Effectiveness}\\
+ This is the core aspect of the SUT, users (other programs) need to be able
+ to effectively use the SUT to send and receive data.
+ \item \textbf{Efficiency}\\
+ This issue has already been covered above under
+ ``performance efficiency''~\ref{sec:perf_eff}.
+ \item \textbf{Satisfaction}\\
+ It is important that programs using the SUT can \emph{trust} that the SUT
+ provides the promised services. This means that data is send and received
+ reliably and the SUT provides clear and unambiguous errors when this
+ service
+ can not be provided.
+ \item \textbf{Context Coverage}\\
+ The SUT needs to behave as expected in all specified contexts
+ (\emph{context completeness}).
+\end{itemize}
+This leaves \emph{freedom from risk}, which we consider not relevant as the SUT
+itself does not pose any risks, and correct implementation (which is covered in
+the other categories) gives clear guarantees to programs using the services of
+the SUT.
+
+\subsection{Levels and types of testing} \label{section:levels}
+The client will deliver a product for certification. This means our team will
+only conduct \emph{acceptance testing} and assume that the client who requested
+certification has conducted \emph{unit}, \emph{module} and \emph{integration
+testing}. We will only be conducting \emph{black-box testing} and the client
+is not required to handover any source-code.
+
+Initially we will conduct a few basic \emph{manual tests} based on experience
+acquired from previous certification requests (\emph{error guessing}). If the
+product fails these basic tests we immediately reject it and seize all further
+activities.
+
+If the product is not rejected after the basic \emph{manual tests} we will
+proceed with the second stage of testing. For these follow-up tests we will use
+\emph{equivalence partitioning} to reduce the number of test cases. Every test
+case will result in a test report. If any of the test cases fail the product
+is rejected. In order to deliver usable feedback to the client we will still
+produce a test report.
+
+\subsubsection{Manual tests}
+
+The basic tests mentioned in Section~\ref{section:levels} are conducted using a
+checklist. If any of the checks fail we immediately reject the product.
+
+\begin{enumerate}
+ \item Is the product complete?
+ \item Does the product come with a manual or quick start guide?
+ \item Is it possible to get the product in a usable state?
+ \item Can we use the product to initiate a connection in a corruption
+ free
+ environment?
+\end{enumerate}
+
+These\emph{ manual tests} are performed in order to ensure that the client has
+delivered a usable product.