diff --git a/BlankProjectTemplate/docs/SRS/SRS-FAQ.pdf b/BlankProjectTemplate/docs/SRS/SRS-FAQ.pdf
index 41de58973f220bd501c791fb09ff101b89a5b803..814afd8fb2daf4d52da4649a07bf1828a5dbf4ce 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 0c422942b875cd386c2a71eaacf4619d5652b4ee..c16a511efef2552386d2db12fcae7fdf05237453 100644
--- a/BlankProjectTemplate/docs/SRS/SRS-FAQ.tex
+++ b/BlankProjectTemplate/docs/SRS/SRS-FAQ.tex
@@ -71,6 +71,38 @@ question is shown below the question, in italic font.
     doesn't.  A generalization isn't really possible.  The answer depends on the
     specific problem at hand. \smallskip}
 
+\item If your work depends on other applications or libraries, how does this
+  show up in the SRS? \medskip
+
+  \emph{The first thought may be that you should assume that the libraries are
+    available; that is, that you should capture this information through
+    assumptions.  I can see why assuming that a library exists might be called
+    an assumption, but this isn't the best location for this information.
+    Assumptions are used to refine the scope; they take a very general problem
+    and turn it into something that we have a hope of solving.  For instance,
+    assuming that a function is differentiable is needed for many theoretical
+    proofs.  This assumptions is saying that the software won't work for all
+    functions; the class of functions that will work has been restricted.
+    Assumptions refine ``what'' you are solving; they don't refine ``how'' you
+    are going to solve the problem.  Building on the work of others is relevant
+    to make the problem feasible, but it isn't technically needed to make the
+    problem solvable.}
+
+  \emph{There are two spot in the SRS to show that you are building on the work
+    of others: System Context and System Constraints.  The System Context shows
+    the boundary between your software and the environment in which it works.
+    If the software will depend on services from other libraries, the
+    availability of these services should be mentioned.  In the system context
+    diagram there would be other boxes that your program would point to.  You
+    are then explicitly saying that your program will depend on these services.
+    Ideally, the services will be given generic names.  That is, unless you have
+    no choice, you should leave it open as to which library will actually
+    provide the services.  In this way you keep your document abstract.
+    However, there are cases where the design decision is imposed on you.  In
+    these cases you would include the names of the specific library, or
+    libraries, as System Constraints (and list them in the corresponding section
+    of the SRS).}
+
 \end{enumerate}
 
 \end{document}