Extra information to template and FAQ in response to review of stdnt colleague repo reviews

BlankProjectTemplate/docs/SRS/SRS-FAQ.tex

@@ -103,6 +103,20 @@ question is shown below the question, in italic font.
     libraries, as System Constraints (and list them in the corresponding section
     of the SRS).}
 
+\item As I work on my Verification and Validation plan I find part of the SRS
+  should be changed.  What should I do? \medskip
+
+  \emph{This is completely natural and expected.  Students in the class make
+    this observation every year.  We cannot really have perfect knowledge when
+    we are writing the first draft of our SRS. We learn by jumping in and
+    starting the documentation. As we get further in the project our
+    understanding improves.}
+
+  \emph{This is why we have two ``official'' iterations of the SRS in the
+    course. You should also have many sub-iterations as the term goes along. Our
+    aim is to have documentation at the end of the course that fakes a rational
+    design process.}
+
 \end{enumerate}
 
 \end{document}

BlankProjectTemplate/docs/SRS/SRS.tex

@@ -350,7 +350,11 @@ characteristics and lists the system constraints.  \plt{This text can likely be
   properties, geometry, etc.).  Likewise, the outputs should be presented from
   an abstract point of view.  In some cases the diagram will show other external
   entities, besides the user.  For instance, when the software product is a
-  library, the user will be another software program, not an actual end user.}
+  library, the user will be another software program, not an actual end user.
+  If there are system constraints that the software must work with external
+  libraries, these libraries can also be shown on the System Context diagram.
+  They should only be named with a specific library name if this is required by
+  the system constraint.}
 
 \begin{figure}[h!]
 \begin{center}
@@ -362,7 +366,9 @@ characteristics and lists the system constraints.  \plt{This text can likely be
 
 \plt{For each of the entities in the system context diagram its responsibilities
   should be listed.  Whenever possible the system should check for data quality,
-  but for some cases the user will need to assume that responsibility.}
+  but for some cases the user will need to assume that responsibility.  The list
+of responsibilites should be about the inputs and outputs only, and they should
+be abstract.  Details should not be presented here.}
 
 \begin{itemize}
 \item User Responsibilities:
@@ -849,7 +855,7 @@ A correct solution must exhibit \plt{fill in the details}.  \plt{These
   properties are in addition to the stated requirements.  There is no need to
   repeat the requirements here.  These additional properties may not exist for
   every problem.  Examples include conservation laws (like conservation of
-  energy or mass) and known constraints on outputs (which are usually summarized
+  energy or mass) and known constraints on outputs, which are usually summarized
   in tabular form.  A sample table is shown in Table~\ref{TblOutputVar}}
 
 \begin{table}[!h]
@@ -865,6 +871,10 @@ A correct solution must exhibit \plt{fill in the details}.  \plt{These
 \end{longtable*}
 \end{table}
 
+\plt{This section is not for test cases or techniques for verification and
+  validation.  Those topics will be addressed in the Verification and Validation
+  plan.}
+
 \section{Requirements}
 
 \plt{The requirements refine the goal statement.  They will make heavy use of
@@ -897,6 +907,9 @@ qualities that the software is expected to exhibit.
 
 \end{itemize}
 
+\plt{Every IM should map to at least one requirement, but not every requirement
+  has to map to a corresponding IM.}
+
 \subsection{Nonfunctional Requirements}
 
 \plt{List your nonfunctional requirements.  You may consider using a fit