This testing approach can be used by either an internal test team or an
independent testing team. The test effort's goal is to become confident about
-the conformance of the implementation to the specification created by
+the conformance of an existing implementation to the specification created by
\textit{The Internet Engineering Task Force}
(IETF)\footnote{\url{http://www.ietf.org}} as document
-\textit{RFC793}~\cite{rfc793}.
+\textit{RFC793}~\cite{rfc793}. This document is explicitly \emph{not} intented
+to serve as guideline for testing during the development phase, but for testing
+conformatiy to the specification of an \emph{existing} implementation.
\subsection{SUT}
%3,4
\subsection{Risks}
%5. Risks
-Risks can be divided into two categories. Project risks and Product risks.
-\begin{itemize}
- \item\textbf{Project Risks}\\
- \item\textbf{Product Risks}\\
-\end{itemize}
+Risks can be divided into two categories. Project risks and product risks.
+Because an existing implementation is used the project risk are non applicable.
+Product risks even more so, since it is unknown if the product has been
+tested during development.
+
+The product risks for the SUT are significant because misbehaviour of the SUT
+could have potential large consequences. The key characteristics of TCP are
+integrity and reliability~\cite{rfc793}, these characteristics cease to exist
+when the implementation is faulty.
+
+Because TCP is a core functionality of a networking capable system it is
+crucial that the TCP implementation functions according to the specification.
+Several critical systems could rely on the correct functionality of the TCP
+implementation. A failure in the SUT could therefore have extensive
+consequences.
+Even more so since TCP is a computer-to-computer protocol, which leaves no
+room for ambiguity, which could be solved in a computer-to-human protocol.
+
+