Requirements.tex

%\documentclass[handout]{beamer} 
\documentclass[t,12pt,numbers,fleqn]{beamer}
%\documentclass[ignorenonframetext]{beamer}

\newif\ifquestions
%\questionstrue
\questionsfalse

\usepackage{pgfpages} 
\usepackage{hyperref}
\hypersetup{colorlinks=true,
    linkcolor=blue,
    citecolor=blue,
    filecolor=blue,
    urlcolor=blue,
    unicode=false}
\urlstyle{same}

\usepackage{booktabs}
\usepackage{hhline}
\usepackage{multirow}
\usepackage{multicol}
\usepackage{array}

\bibliographystyle{plain}

%\usetheme{Iimenau}

\useoutertheme{split} %so the footline can be seen, without needing pgfpages

%\pgfpagesuselayout{resize to}[letterpaper,border shrink=5mm,landscape]  %if this is uncommented, the hyperref links do not work

\mode<presentation>{}

\input{../def-beamer}

\newcommand{\topic}{03 Requirements}

\input{../titlepage}

\begin{document}

\input{../footline}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Requirements}

\bi
\item Administrative details
\item Questions: project choices?, software tools?
\item Problem statement and example
\item Software Engineering for Scientific Computing literature
\item Scientific Computing Software Qualities
\item Motivation: Challenges to Developing Quality Scientific Software
\item Requirements documentation for scientific computing
\item A requirements template
\item Advantages of new template and examples
\item The template from a software engineering perspective
\item Concluding remarks
\item References
\ei
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Administrative Details}

\bi
\item Add \texttt{smiths} to your GitHub repos
\item Linked-In
\item \structure{Assign the instructor an issue to review your problem statement}
\ei

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Administrative Details: Deadlines}
~\newline
\begin{tabular}{l l l}
\textbf{Problem Statement} & Week 02 & Sept 15\\
SRS Present & Week 04 & Week of Sept 25\\
SRS & Week 05 & Oct 4\\
V\&V Present & Week 06 & Week of Oct 16\\
V\&V Plan & Week 07 & Oct 25\\
MG Present & Week 08 & Week of Oct 30\\
MG & Week 09 & Nov 8\\
MIS Present & Week 10 & Week of Nov 13\\
MIS & Week 11 & Nov 22\\
Impl.\ Present & Week 12 & Week of Nov 27\\
Final Documentation & Week 13 & Dec 6\\
\end {tabular}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Questions?}
\begin{itemize}
\item Questions about project choices?
\item Questions about software tools?
\bi
\item git?
\item LaTex?
\ei
\item Partial tex files in the blank project template
\item \href{https://gitlab.cas.mcmaster.ca/smiths/cas741/blob/master/BlankProjectTemplate/Doc/ProblemStatement/ProblemStatement.tex}{Problem statement}
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Problem Statement}
\bi
\item Written in LaTeX
\item Due electronically (on GitLab) by deadline
\item Comments might be typed directly into your source
\item For later assignments with LaTeX source, include the LaTeX
  commands for comments
\item \textbf{What} problem are you trying to solve?
\item \textbf{Not how} you are going to solve the problem
\item Why is this an important problem?
\item What is the context of the problem you are solving? 
\bi
\item Who are the stakeholders?
\item What is the environment for the software?
\ei
\item A page description should be sufficient
\ei
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Sample Project Statements} 

\bi
\item \href{https://gitlab.cas.mcmaster.ca/ThisTooShallParse/3XA3_CParser}{CParser}
\item \href{https://gitlab.cas.mcmaster.ca/theateam/FloppyFishGroup}{FloppyFish}
\item
  \href{https://gitlab.cas.mcmaster.ca/screenholders/screenholders}{Screenholders}
\item Template in repo
\ei

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{SE For SC Literature}

\begin {itemize}

\item CAS 741 process is document driven, adapted
from the waterfall model~\cite{GhezziEtAl2003, VanVliet2000}
\item Many say a document driven process is not used by, nor suitable for,
scientific software.
\bi
\item Scientific developers naturally use an agile
  philosophy~\cite{AckroydEtAl2008, CarverEtAl2007, EasterbrookAndJohns2009, Segal2005}, 
\item or an amethododical process~\cite{Kelly2013}
\item or a knowledge acquisition driven process~\cite{Kelly2015}.
\ei
\item Scientists do not view rigid, process-heavy approaches,
  favorably~\cite{CarverEtAl2007}
\item Reports for each stage of development are counterproductive~\cite[p.~373]{Roache1998}
\item Up-front requirements are
impossible~\cite{CarverEtAl2007, SegalAndMorris2008}
\item \structure{What are some arguments in favour of a rational document driven
    process?}
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Counter Arguments}

\begin {itemize}

\item Just because document driven is not used, does not mean it will not work
\item Documentation provides many
benefits~\cite{Parnas2010}: 
\bi
\item easier reuse of old designs
\item better communication about requirements
\item more useful design reviews
\item easier integration of separately
written modules
\item more effective code inspection
\item more effective testing
\item more efficient corrections and improvements.
\ei
\item Actually faking a rational design process
\item Too complex for up-front requirements sounds like an excuse
\bi
\item Laws of physics/science slow to change
\item Often simple design patterns
\item Think program family, not individual member
\ei
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Definition of Software Qualities}

\begin{itemize}
\item Measures of the excellence or worth of a software product (code or document) or process
with respect to some aspect
\item \structure{What are some important aspects (qualties) for scientific softwarwe?}
\item User Satisfaction = The Important Qualities are High + Within Budget
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}

\frametitle{Important Qualities for Scientific Computing Software}

\begin{itemize}

\item External qualities
\begin{itemize}
\item Correctness (Thou shalt not lie)
\item Reliability
\item Robustness
\item Performance
\begin{itemize}
%\item Tight bounds
\item Time efficiency
\item Space efficiency
\end{itemize}
\end{itemize}

\item Internal qualities
\begin{itemize}
\item Verifiability
%\item Productivity
\item Usability
\item Maintainability
%\begin{itemize}
%\item Repairability
%\item Evolvability
%\end{itemize}
\item Reusability
\item Portability
\end{itemize}

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Correctness Versus Reliability Versus Robustness}

What is the difference between these 3 qualities?\\
~\\
Can you assess correctness without a requirements specification?

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Correctness}

\begin{itemize}
\item A software product is correct if it satisfies its requirements specification
\item Correctness is extremely difficult to achieve because
\begin{itemize}
\item The requirements specification may be imprecise, ambiguous, inconsistent,
  based on incorrect knowledge, or nonexistent
\item Requirements often compete with each other
\item It is virtually impossible to produce ``bug-free'' software
\item It is very difficult to verify or measure correctness
\end{itemize}
\item If the requirements specification is formal, correctness can in theory and
  possibly in practise be
\begin{itemize}
\item Mathematically defined
\item Proven by mathematical proof
\item Disproven by counterexample
\end{itemize}
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Reliability}

\begin{itemize}
\item A software product is reliable if it usually does what is intended to do
\item Correctness is an absolute quality, while reliability is a relative quality
\item A software product can be both reliable and incorrect
\item Reliability can be statistically measured
\item Software products are usually much less reliable than other engineering
  products
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Robustness}

\begin{itemize}
\item A software product is robust if it behaves reasonably even in
  unanticipated or exceptional situations
% example of saving a file and power is lost
\item A correct software product need not be robust
\begin{itemize}
\item Correctness is accomplished by satisfying requirements
\item Robustness is accomplished by satisfying unstated requirements
\end{itemize}
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Question on Correctness. Reliability and Robustness}

Reliable programs are a superset of correct programs AND robust programs are a
superset of reliable programs.  Is this statement True or False?
\begin{enumerate}[A.]
\item True
\item False %answer - robust programs may or may not be correct or reliable
\end{enumerate}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Performance}

What are some ways you could measure software performance?\\
~\\
What are some ways you could specify performance requirements to make them
unambiguous and verifiable?

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Performance}

\begin{itemize}
\item The performance of a computer product is the efficiency with which the
  product uses its resources (memory, time, communication)
\item Performance can be evaluated in three ways
\begin{itemize}
\item Empirical measurement
\item Analysis of an analytic model
\item Analysis of a simulation model
\end{itemize}
\item Poor performance often adversely affects the usability and scalability of
  the product
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Usability}

What are some examples of excellent usability?\\
~\\
When you go to a friend's house, you can likely operate their microwave without
reading the manual.  What did human factors engineers do to make this possible?

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Usability}

\begin{itemize}
\item The usability of a software product is the ease with which a typical human
  user can use the product
\item Usability depends strongly on the capabilities and preferences of the user
\item The user interface of a software product is usually the principle factor
  affecting the product's usability
\item Human computer interaction (HCI) is a major interdisciplinary subject
  concerned with understanding and improving interaction between humans and
  computers
\end{itemize}
% talk about IBM usability lab and other things that Muir mentioned
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Verifiability}

\begin{itemize}
\item The verifiability of a software product is the ease with which the
  product's properties (such as correctness and performance) can be verified
\item Verifiability can be both an internal and an external quality
%\item What is the relationship between verifiability and correctness?
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Maintainability}

\begin{itemize}
\item The maintainability of a software product is the ease with which the
  product can be modified after its initial release
\item Maintenance costs can exceed 60\% of the total cost of the software product
\item There are three main categories of software maintenance
\begin{enumerate}
\item Corrective: Modifications to fix residual and introduced errors
\item Adaptive: Modifications to handle changes in the environment in which the product is used
\item Perfective: Modifications to improve the qualities of the software
\end{enumerate}
\item Software maintenance can be divided into two separate qualities
\begin{enumerate}
\item Repairability: The ability to correct defects
\item Evolvability: The ability to improve the software and to keep it current
\end{enumerate}
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Maintainability}

What do software developers do to promote maintainability?

% documentation, traceability, separation of concerns, modularity, design for
% change, design for generality

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Reusability}

What are the advantages of reusing code?\\
~\\
Why doesn't it happen more often?

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Reusability}

\begin{itemize}
\item A software product or component is reusable if it can be used to create a
  new product
\item Reuse comes in two forms
\begin{enumerate}
\item Standardized, interchangeable parts
\item Generic, instantiable components
\end{enumerate}
\item Reusability is a bigger challenge in software engineering than in other
  areas of engineering
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Portability}

\begin{itemize}
\item A software product is portable if it can run in different environments
\item The environment for a software product includes the hardware platform, the
  operating system, the supporting software and the user base
\item Since environments are constantly changing, portability is often crucial
  to the success of a software product
\item Some software such as operating systems and compilers, is inherently
  machine specific
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Understandability}

\begin{itemize}
\item The understandability of a software product is the ease with which the
  requirements, design, implementation, documentation, etc. can be understood
\item Understandability is an internal quality that has an impact on other
  qualities such as verifiability, maintainability, and reusability
\item There is often a tension between understandability and the performance of
  a software product
\item Some useful software products completely lack understandability
  (e.g. those for which the source code is lost)
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Relationship between Qualities}

Draw a diagram showing the relationships between the various software qualities

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Measurement of Quality}

\begin{itemize}
\item A software quality is only important if it can be measured - without
  measurement there is no basis for claiming improvement
\item A software quality must be precisely defined before it can be measured
\item Most software qualities do not have universally accepted
\item Can you directly measure maintainability?
\item How might you measure maintainability?
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}

\frametitle{Problems with Developing Quality Scientific Computing Software}

\begin{itemize}

\item Need to know requirements to judge reliability
\item In many cases the only documentation is the code
\item Reuse is not as common as it could be
\begin{itemize}
\item \href{http://www.andrew.cmu.edu/user/sowen/softsurv.html}{\alert{Meshing software survey}}
\item \href{http://www.engr.usask.ca/~macphed/finite/fe_resources/node137.html}{\alert{Public domain finite element
programs}}
\item etc.
\end{itemize}
\item Many people develop ``from scratch''
\item Cannot easily reproduce the work of others
\item Neglect of simple software development technology~\cite{Wilson2006} 
% such as version control software

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}

\frametitle{Adapt Software Engineering Methods}

\begin{itemize}

\item Software engineering improves and quantifies quality %purpose of software engineering
\item Successfully applied in other domains
\begin{itemize}
\item Business and information systems
\item Embedded real time systems
\end{itemize}
\item Systematic engineering process
\item Design through documentation
\item Use of mathematics
\item Reuse of components
\item Warranty rather than a disclaimer %goal of software engineering

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}

\frametitle{Developing Scientific Computing Software}

\begin{itemize}

\item Facilitators
\begin{itemize}
\item One user viewpoint for specifying a physical model
\item Assumptions can be used to distinguish models
\item High potential for reuse
\item Libraries
\item Already mathematical
\end{itemize}

\item Challenges
\begin{itemize}
\item Verification and Validation
\item Acceptance of software engineering methodologies
\item No existing templates or examples %explain that templates are a tool for doc req.
\end{itemize}

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Outline of Discussion of Requirements}

\begin{itemize}

\item Background on requirements elicitation, analysis and documentation
\item Why requirements analysis for engineering computation?

\item System Requirements Specification and template for beam analysis software
\begin{itemize}
\item Provides guidelines
\item Eases transition from general to specific
\item Catalyses early consideration of design
\item Reduces ambiguity
\item Identifies range of model applicability
\item Clear documentation of assumptions
\end{itemize}

\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{A Rational Design Process}
%\begin{figure}
\begin{center}
 \includegraphics[width=1.0\textwidth]{../Figures/reqSE.pdf}
\end{center}
%\end{figure}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Sometimes Include Commonality Analysis}
%\begin{figure}
\begin{center}
 \includegraphics[width=1.0\textwidth]{../Figures/Waterfall.pdf}
\end{center}
%\end{figure}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Software Requirements Activities}
\begin{itemize}
\item A software requirement is a description of how the system should behave, or of a system property or attribute
\item Requirements should be unambiguous, complete, consistent, modifiable, verifiable and traceable
\item Requirements should express ``What'' not ``How''
\item Formal versus informal specification
\item Functional versus nonfunctional requirements
\item Software requirements specification (SRS)
\item Requirements template
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Why Requirements Analysis?}
%\begin{figure}
\begin{center}
 \includegraphics[width=1.0\textwidth]{../Figures/StagesInSciCompErrors.pdf}
\end{center}
%\end{figure}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Beam Analysis Software}
~\newline
~\newline
\begin{center}
 \includegraphics[width=1.0\textwidth]{../Figures/beamFBD.pdf}
\end{center}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Proposed Template}

\scalebox{0.85}{
\begin{minipage}{1.2\textwidth}
\begin{enumerate}

\item Reference Material: a) Table of Symbols ...

\item Introduction: a) Purpose of the Document; b) Scope of the Software Product; c) Organization of the Document.

\item General System Description: a) System Context; b) User Characteristics; c) System Constraints.

\item Specific System Description:
\begin{enumerate}
\item Problem Description: i) Background Overview ...
\item Solution specification: i) Assumptions; ii) Theoretical Models; ...
\item Non-functional Requirements: i) Accuracy of Input Data; ii) Sensitivity ...
\end{enumerate}

\item{Traceability Matrix}

\item List of Possible Changes in the Requirements

\item{Values of Auxiliary Constants}

\end{enumerate}
\end{minipage}
}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Provides Guidance}
\begin{itemize}
\item Details will not be overlooked, facilitates multidisciplinary collaboration
\item Encourages a systematic process
\item Acts as a checklist
\item Separation of concerns
\begin{itemize}
\item Discuss purpose separately from organization
\item Functional requirements separate from non-functional
%\begin{itemize}
%\item solve for forces
%\item system responds within 1 second
%\end{itemize}
\end{itemize}
\item Labels for cross-referencing
\begin{itemize}
\item Sections, physical system description, goal statements, assumptions, etc.
\item PS1.a ``the shape of the beam is long and thin''
\end{itemize}
%\item Use of parameters instead of explicit values
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Eases Transition from General to Specific}
\begin{itemize}
\item ``Big picture'' first followed by details
\item Facilitates reuse
\item ``Introduction'' to ``General System Description'' to ``Specific System Description''
\item Refinement of abstract goals to theoretical model to instanced model
\begin{itemize}
\item \textbf{G1}. Solve for the unknown external forces applied to the beam
\item $ \textbf{T1}~ 
\textrm{$\sum{F_{xi}} = 0$,}~  
\textrm{$\sum{F_{yi}} = 0$,}~
\textrm{$\sum{M_i} = 0$}$
\item \textbf{M1} \textrm{$F_{ax} - F_1\cdot \cos\theta_3 - F_2\cdot \cos\theta_4 - F_{bx} = 0$}
\end{itemize}
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Ensures Special Cases are Considered}
\scalebox{0.6}{
\begin{tabular}{| p{3.8cm} | p{1.7cm} | p{0.05cm} | p{9.0cm} | p{1.8cm} |}
\multicolumn{3}{c}{} & \multicolumn{2}{>{\large}c}{$H_1$} \\
\hhline{|~|~|~|-|-|}
\multicolumn{3}{c}{} & \multicolumn{1}{|c|}{$S_{GET} = S_{sym} - S_{unkF}$} & $S_{GET} \ne  (S_{sym} - S_{unkF})$ \\
\hhline{|~|~|~|-|-|}

\hhline{|-|-|~|-|-|} $S_{unkF} \notin \mathbb{P}_3$ & - &  & $(ErrorMsg'=InvalidUnknown)$ \newline
$\land ChangeOnly(ErrorMsg)$ &
\multirow{9}{2cm}{$FALSE$} \\
\hhline{|-|-|~|-|~|} $S_{unkF} = \newline \{@{F_{ax}}, @{F_{bx}}, @{F_{ay}} \}$ & - & & $ErrorMsg'=NoSolution$ \newline
$\land ChangeOnly(ErrorMsg)$ & \\
%\hhline{|-|-|~|-|~|} $S_{unkF} = \newline \{@{F_{ax}}, @{F_{bx}}, @{F_{by}} \}$ & - & & $ErrorMsg'=NoSolution$ \newline
%$\land ChangeOnly(ErrorMsg)$ & \\
%\hhline{|-|-|~|-|~|} $S_{unkF} = \newline \{@{F_{ax}}, @{F_{bx}}, @{F_1} \}$ & - & & $ErrorMsg'=NoSolution$ \newline
%$\land ChangeOnly(ErrorMsg)$ & \\
%\hhline{|-|-|~|-|~|} $S_{unkF} = \newline \{@{F_{ax}}, @{F_{bx}}, @{F_2} \}$ & - & & $ErrorMsg'=NoSolution$ \newline
%$\land ChangeOnly(ErrorMsg)$ & \\
\hhline{|-|-|~|-|~|}
%\multirow{3}{4.2cm}
{$S_{unkF} = \newline \{@{F_{ax}}, @{F_{ay}}, @{F_1}\}$} & 
$x_1 \ne 0 $ \newline
$\land~\theta_3 \ne 0$ \newline
$\land~\theta_3 \ne 180$
& & 
$F_{ax}' = $\newline
$\frac{-\cos\theta_3 F_2 x_2 \sin\theta_4 + \cos\theta_3 F_{by} L + F_2 \cos\theta_4 x_1 \sin\theta_3
+ F_{bx} x_1 \sin\theta_3}{x_1 \sin\theta_3}$\newline
$\land$\newline
$F_{ay}' = -\frac{F_2 x_2 \sin\theta_4 - F_{by} L - F_2 \sin\theta_4 x_1 + F_{by} x_1}{x_1}$\newline
{$\land~F_1' = \frac{-F_2 x_2 \sin\theta_4 + F_{by} L}{x_1 \sin\theta_3} \land ChangeOnly(S_{unkF})$}
& \\
\hhline{|~|-|~|-|~|} & $otherwise$ & & $(ErrorMsg'=Indeterminant)$\newline
$\land ChangeOnly(ErrorMsg)$ & \\
\hhline{|-|-|~|-|-|}

\multicolumn{5}{c}{} \\
\multicolumn{3}{>{\large}c}{$H_2$} & \multicolumn{2}{>{\large}c}{$G$} \\
\end{tabular} }
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Catalyses Early Consideration of Design}
\begin{itemize}
\item Identification of significant issues early will improve the design
\item Section for considering sensitivity
\begin{itemize}
\item Conditioning?
\item Buckling of beam
\end{itemize}
\item Non-functional requirements
\begin{itemize}
\item Tradeoffs in design
\item Speed efficiency versus accuracy
\end{itemize}
\item Tolerance allowed for solution: $|\sum{F_{xi}}| / \sqrt{\sum{F_{xi}}^2} \le \epsilon$
\item Solution validation strategies
\item List of possible changes in requirements
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Reduces Ambiguity}
\begin{itemize}
\item Unambiguous requirements allow communication between experts, requirements review, designers do not have to
make arbitrary decisions
\item Tabular expressions allow automatic verification of completeness
\item Table of symbols
\item Abbreviations and acronyms
\item Scope of software product and system context
\item User characteristics
\item Terminology definition and data definition
\item Ends arguments about the relative merits of different designs
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Identifies Range of Model Applicability}
\begin{itemize}
\item Clear documentation as to when model applies
\item Can make the design specific to the problem
\item Input data constraints are identified
\begin{itemize}
\item Physically meaningful: $0 \leq x_1 \leq L$
\item Maintain physical description: PS1.a, $0 < h \leq 0.1 L$
\item Reasonable requirements: $0 \leq \theta_3 \leq 180$
\end{itemize}
\item The constraints for each variable are documented by tables, which are later composed together
\item $(min_f \le |F_{ax}| \le max_f) 
\land (|F_{ax}| \ne 0) \Rightarrow \forall ({FF}|{@{FF} \in S_F} \cdot {FF \ne 0
\land  \frac{max\{{|F_{ax}|,|FF|}\}}{min\{{|F_{ax}|, |FF|}\}} \le 10 ^ {r_f}})$
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}

\frametitle{Summary of Variables}

\begin{table}
\begin{center}
\scalebox{0.9}{
\begin{tabular}{|l|l|p{3.0cm}|p{3.3cm}|l|}
\multicolumn{5}{c}{} \\
\hline
\textbf{Var} & \textbf{Type} & \textbf{Physical\newline Constraints} & \textbf{System\newline Constraints} &
\textbf{Prop} \\
\hline $x$ & $Real$ & $x\ge 0 \land x\le L$ & $min_d \le x \le max_d$ & NIV \\
\hline $x_1$ & $Real$ & $x_1\ge0 \land x_1\le L$ & $min_d \le x_1 \le max_d$ & IN \\
\hline $x_2$ & $Real$ & $x_2\ge0 \land x_2\le L$ & $min_d \le x_2 \le max_d$ & IN \\
\hline $e$ & $Real$ & $e>0 \land e \le h$ & $min_e \le e \le max_e$ & IN \\
\hline $h$ & $Real$ & $h>0 \land h\le 0.1L$ & $min_h \le h \le max_h$ & IN \\
\hline $L$ & $Real$ & $L>0$ & $min_d \le L \le max_d$ & IN \\
\hline $E$ & $Real$ & $E>0$ & $min_E \le E \le max_E$ & IN \\
\hline $\theta_3$ & $Real$ & $-\infty < \theta_3 < +\infty$ & $0 \le \theta_3 \le 180$ & IN \\
\hline $\theta_4$ & $Real$ & $-\infty < \theta_4 < +\infty$ & $0 \le \theta_4 \le 180$ & IN \\
\hline $V$ & $Real$ & $-\infty < V < +\infty$ & - & OUT \\
\hline $M$ & $Real$ & $-\infty < M < +\infty$ & - & OUT \\
\hline $y$ & $Real$ & $-\infty < y < +\infty$ & - & OUT \\
\hline $...$ & $...$ & $...$ & ... & ... \\
\hline
\end{tabular} }
\end{center}
\end{table}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Clear Documentation of Assumptions}
\scalebox{0.82}{
\begin{tabular}{| p{1.3cm} | p{1.3cm} | l | l | l | l | l | l | l | l | l | l | l | l |}
\hhline{--------------}
Phy. Sys. /Goal & Data /Model & \multicolumn{10}{c|}{Assumption} & \multicolumn{2}{c|}{Model} \\
\hhline{~~------------}
&  & A1 & A2 & ... & A4 & ... & A8 & A9 & A10 & ...  & A14 & \textbf{M1} & ... \\
\hhline{--------------}
\textbf{G1} & \textbf{T1} & $\surd$ & & ... &  & ... & $\surd$ & $\surd$ &  & ... & & $\surd$ & ...\\
\hhline{--------------}
\textbf{G2} & \textbf{T2} & $\surd$ & & ... & &... & $\surd$ & $\surd$ &  & ... & &  & ... \\
\hhline{--------------}
\textbf{G3} & \textbf{T3} & $\surd$ & & ... &  &... &  & $\surd$ & $\surd$ & ... & &  & ...\\
\hhline{--------------}
~ & \textbf{M1} &  & $\surd$ & ...  &  & ... &  & &  & ... & & $\surd$ &... \\
\hhline{--------------}
PS1.a & $L$ &  & &... & &...  & & & $\surd$  & ... & & ... & ... \\
\hhline{--------------}
... & ... & ... & ... & ... & ... & ... & ... & ... & ... & ... & ... & ... & ... \\
\hhline{--------------}
\end{tabular}
}
~\newline
~\newline
\textbf{A10}. The deflection of the beam is caused by bending moment only, the shear does not contribute.\\
%\textbf{A15}. The beam behaves as a rigid body
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\frame{\frametitle{More on the Template}
\begin{itemize}%[<+-| alert@+>]%[iacolor=gray]
\item Why a new template?
\item The new template
\begin{itemize}
\item Overview of changes from existing templates
\item Goal $\rightarrow$ Theoretical Model $\rightarrow$ Instanced Model hierarchy
\item Traceability matrix
\item System behaviour, including input constraints
\end{itemize}
\end{itemize}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\frame{\frametitle{Why a New Template?}
\begin{enumerate}%[<+-| alert@+>]%[iacolor=gray]
%\item Reasons for a new template also form principles for its design
\item One user viewpoint for the physical model
\item Assumptions distinguish models
\item High potential for reuse of functional requirements
\item Characteristic hierarchical nature facilitates change
\item Continuous mathematics presents a challenge
\end{enumerate}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\frame{\frametitle{Overview of the New Template}

\begin{itemize}

\item{Reference Material}

\item{Introduction:} 
{a) Purpose of the Document}
{b) Scope of the Software Product}
{c) Organization of the Document}

\item General System Description:
{a) System Context}