Addition of an FAQ document for frequently asked questions about the SRS

BlankProjectTemplate/docs/SRS/SRS-FAQ.tex

+\documentclass[12pt]{article}
+
+\usepackage{hyperref}
+\hypersetup{colorlinks=true,
+    linkcolor=blue,
+    citecolor=blue,
+    filecolor=blue,
+    urlcolor=blue,
+    unicode=false}
+\urlstyle{same}
+
+\begin{document}
+
+\title{SRS Frequently Asked Questions}
+\author{Spencer Smith}
+\date{\today}
+
+\maketitle
+
+A list of Frequently Asked Questions are given below.  The answer to the
+question is shown below the question, in italic font.
+
+\begin{enumerate}
+
+\item If we are solving an ``intermediate problem,'' should we state the
+  output(s) of that step or we should only talk about the raw inputs of the
+  software and ultimate outputs?" \medskip
+
+  \emph{Without any other qualifying information, I would say that the
+    intermediate steps are not relevant in the SRS.  The SRS should be abstract.
+    It should say what we want, not how to calculate it.  However, the world of
+    requirements specification doesn't always lend itself to an absolute answer.
+    :-) There are definitely cases where the best course of action is to
+    describe how to get from $a$ to $c$ by first passing through $b$.  The cases where
+    specifying the intermediate steps makes sense are as follows: 
+    \begin{enumerate}
+    \item If the intermediate steps have value on their own, then they should be
+      included as a goal.  For instance, in the Solar Water Heating System
+      example the energy in the water and the PCM depends on the temperatures.
+      If the ultimate goal was to know the energies, it still would make sense
+      to output the temperatures, since they have value on their own.
+    \item If the intermediate steps make the specification clearer, or easier to
+      understand, they should be included.  Although a specification should say
+      what is desired, there are cases where the appropriate way to specify
+      ``what'' is to say ``how.''  This is called an operational specification.  An
+      operational specification gives the steps for the intended behaviour.  All
+      other things being equal, our preference is still a descriptive specification.
+      A descriptive specification says what is required in terms of the desired
+      properties, without reference to how it will be done.  As an example, a
+      descriptive specification for finding the minimum of a list would describe
+      what is meant by minimum.  A descriptive specification would say that the
+      output is the element of the list that is equal to or less than all other
+      elements.  The corresponding operational specification would give the
+      algorithm for finding the minimum.  The topic of operational versus
+      descriptive specification is covered further in these
+      \href{https://gitlab.cas.mcmaster.ca/smiths/se2aa4_cs2me3/-/blob/master/Lectures/L25_IntroToSpecContinued/IntroToSpecContinued.pdf}
+      {slides} (starting around slide 22). One of the points on operational
+      specifications that sometimes confuses students is that the operational
+      specification is phrased in terms of ``how,'' but the intention is still to
+      say ``what.'' That is, the implementation is not required to use the steps
+      given for how, as long as the results match the what.  In the above
+      example, the operational specification for the minimum of a list gives an
+      algorithm, but the implementation is free to use any algorithm, as long as
+      the output returned matches the output that would be returned by following
+      the operational specification.
+    \end{enumerate}
+    In the SRS intermediate calculations can come through supporting theoretical
+    models, general definitions, instance models and/or data definitions.  The
+    short answer to the original question is that sometimes it makes sense to
+    include an intermediate problem in the specification, and sometimes it
+    doesn't.  A generalization isn't really possible.  The answer depends on the
+    specific problem at hand. \smallskip}
+
+\end{enumerate}
+
+\end{document}