Addition of performance as a frequently implicit quality that should still be verified

Lectures/L29_IntroductionToVerification/IntroductionToVerification.tex

@@ -431,7 +431,7 @@ Avoids potential ArrayIndexOutOfBoundsException Exception
 \item Even implicit qualities should be verified
 \begin{itemize}
 \item Because requirements are often incomplete
-\item For instance robustness, maintainability
+\item For instance robustness, maintainability, performance
 \end{itemize}
 \item \structure{What is better than implicitly specified
     qualities?} % explicit!
@@ -481,4 +481,35 @@ Avoids potential ArrayIndexOutOfBoundsException Exception
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{Does our Engineering Analogy Fail?}
+
+\begin{itemize}
+
+\item \structure{If a bridge can hold 512 kN, can it hold 499 kN?}
+\item \structure{If our software works for the input 512, will it work for 499?}
+
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Verification in Engineering}
+
+\begin{itemize}
+
+\item Example of bridge design
+\item One test assures infinite correct situations
+\item In software a small change in the input may result in significantly different behaviour
+\item There are also chaotic systems in nature, but products of engineering
+  design are usually stable and well-behaved
+% consider the examples of weather, bifurcation in engineering, chaos theory for traffic, etc.
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \end{document}
\ No newline at end of file