diff --git a/BlankProjectTemplate/docs/SRS/SRS-FAQ.pdf b/BlankProjectTemplate/docs/SRS/SRS-FAQ.pdf
index 814afd8fb2daf4d52da4649a07bf1828a5dbf4ce..6c4e37f5804a929b7c744a9289cb9bb32210dc92 100644
Binary files a/BlankProjectTemplate/docs/SRS/SRS-FAQ.pdf and b/BlankProjectTemplate/docs/SRS/SRS-FAQ.pdf differ
diff --git a/BlankProjectTemplate/docs/SRS/SRS-FAQ.tex b/BlankProjectTemplate/docs/SRS/SRS-FAQ.tex
index c16a511efef2552386d2db12fcae7fdf05237453..e00c965b982668f8d2ce29f90d17cecf51deb761 100644
--- a/BlankProjectTemplate/docs/SRS/SRS-FAQ.tex
+++ b/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}
diff --git a/BlankProjectTemplate/docs/SRS/SRS.pdf b/BlankProjectTemplate/docs/SRS/SRS.pdf
index 6c8252c39bb5f15c8a9803f62c0fc9de5b072327..1693898f50ba23f95308fe6c4da8fd5c869e7ad8 100644
Binary files a/BlankProjectTemplate/docs/SRS/SRS.pdf and b/BlankProjectTemplate/docs/SRS/SRS.pdf differ
diff --git a/BlankProjectTemplate/docs/SRS/SRS.tex b/BlankProjectTemplate/docs/SRS/SRS.tex
index 6b4779cd2117817727f685d4ea035350e767dfdc..5f86894fd0249384225d29d6206d6fc01aa43947 100644
--- a/BlankProjectTemplate/docs/SRS/SRS.tex
+++ b/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