Updates to blank project templates to include additional comments

BlankProjectTemplate/docs/Design/MG/MG.tex

@@ -148,8 +148,6 @@ decisions will be changed.
 \begin{description}
 \item[\refstepcounter{ucnum} \uctheucnum \label{ucIO}:] Input/Output devices
   (Input: File and/or Keyboard, Output: File, Memory, and/or Screen).
-\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] There will always be
-  a source of input data external to the software.
 \item ...
 \end{description}
 

BlankProjectTemplate/docs/Design/MIS/MIS.tex

@@ -173,6 +173,8 @@ The following table is taken directly from the Module Guide document for this pr
 
 \subsection{Syntax}
 
+\subsubsection{Exported Constants}
+
 \subsubsection{Exported Access Programs}
 
 \begin{center}
@@ -189,6 +191,19 @@ The following table is taken directly from the Module Guide document for this pr
 
 \subsubsection{State Variables}
 
+\wss{Not all modules will have state variables.  State variables give the module
+  a memory.}
+
+\subsubsection{Environment Variables}
+
+\wss{This section is not necessary for all modules.  Its purpose is to capture
+  when the module has external interaction with the environment, such as for a
+  device driver, screen interface, keyboard, file, etc.}
+
+\subsubsection{Assumptions}
+
+\wss{Try to minimize assumptions and anticipate programmer errors via
+  exceptions, but for practical purposes assumptions are sometimes appropriate.}
 
 \subsubsection{Access Routine Semantics}
 
@@ -199,6 +214,20 @@ The following table is taken directly from the Module Guide document for this pr
 \item exception: \wss{if appropriate} 
 \end{itemize}
 
+\wss{A module without environment variables or state variables is unlikely to
+  have a state transition.  In this case a state transition can only occur if
+  the module is changing the state of another module.}
+
+\wss{Modules rarely have both a transition and an output.  In most cases you
+  will have one or the other.}
+
+\subsubsection{Local Functions}
+
+\wss{As appropriate} \wss{These functions are for the purpose of specification.
+  They are not necessarily something that is going to be implemented
+  explicitly.  Even if they are implemented, they are not exported; they only
+  have local scope.}
+
 \newpage
 
 \bibliographystyle {plainnat}

BlankProjectTemplate/docs/SRS/CA.tex

@@ -78,7 +78,7 @@
 
 \begin{document}
 
-\title{Program Family Title} 
+\title{Program Family Title \wss{\famname should appear in the title}} 
 \author{Author Name}
 \date{\today}
 
@@ -435,4 +435,17 @@ show the values of the symbolic parameters introduced in the report.}
 \wss{The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
 Their values are defined in this section for easy maintenance.}
 
+\noindent \wss{Advice on using the template:
+\begin{itemize}
+\item Assumptions have to be invoked somewhere
+\item ``Referenced by'' implies that there is an explicit reference
+\item Think of traceability matrix, list of assumption invokations and list of
+  reference by fields as automatically generatable
+\item If you say the format of the output (plot, table etc), then your
+  requirement could be more abstract
+\item For families the notion of binding time should be introduced
+\item Think of families as a library, not as a single program
+\end{itemize}
+}
+
 \end{document}
\ No newline at end of file

BlankProjectTemplate/docs/SRS/SRS.tex

@@ -531,8 +531,8 @@ The goals \wss{reference your goals} are solved by \wss{reference your instance
 
 \subsubsection{Data Constraints} \label{sec_DataConstraints}    
 
-Tables~\ref{TblInputVar} and \ref{TblOutputVar} show the data constraints on the
-input and output variables, respectively.  The column for physical constraints gives
+Table~\ref{TblInputVar} shows the data constraints on the
+input output variables.  The column for physical constraints gives
 the physical limitations on the range of values that can be taken by the
 variable.  The column for software constraints restricts the range of inputs to
 reasonable values.  The constraints are conservative, to give the user of the
@@ -576,6 +576,16 @@ Table~\ref{TblSpecParams}.
 \end{longtable*}
 \end{table}
 
+\subsubsection{Properties of a Correct Solution} \label{sec_CorrectSolution}
+
+\noindent
+A correct solution must exhibit \wss{fill in the details}.  \wss{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
+  in tabular form.  A sample table is shown in Table~\ref{TblOutputVar}}
+
 \begin{table}[!h]
 \caption{Output Variables} \label{TblOutputVar}
 \renewcommand{\arraystretch}{1.2}
@@ -589,11 +599,6 @@ Table~\ref{TblSpecParams}.
 \end{longtable*}
 \end{table}
 
-\subsubsection{Properties of a Correct Solution} \label{sec_CorrectSolution}
-
-\noindent
-A correct solution must exhibit \wss{fill in the details}
-
 \section{Requirements}
 
 This section provides the functional requirements, the business tasks that the
@@ -787,4 +792,51 @@ show the values of the symbolic parameters introduced in the report.}
 \wss{The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
 Their values are defined in this section for easy maintenance.}
 
+\newpage
+\noindent \wss{The following is not part of the template, just some things to consider
+  when filing in the template.}
+
+\noindent \wss{Grammar, flow and \LaTeX advice:
+\begin{itemize}
+\item \texttt{*.DS\_Store} should be in \texttt{.gitignore}
+\item \LaTeX{} and formatting rules
+\begin{itemize}
+\item Variables are italic, everything else not, includes subscripts (link to
+  document)
+\begin{itemize}
+\item \href{https://physics.nist.gov/cuu/pdf/typefaces.pdf}{Conventions}
+\item Watch out for implied multiplication
+\end{itemize}
+\item Use BibTeX
+\item Use cross-referencing
+\end{itemize}
+\item Grammar and writing rules
+\begin{itemize}
+\item Acronyms expanded on first usage (not just in table of acronyms)
+\item ``In order to'' should be ``to''
+\end{itemize}
+\end{itemize}}
+
+\noindent \wss{Advice on using the template:
+\begin{itemize}
+\item Difference between physical and software constraints
+\item Properties of a correct solution means \emph{additional} properties, not
+  a restating of the requirements (may be ``not applicable'' for your problem).
+  If you have a table of output constraints, then these are properties of a
+  correct solution.
+\item Assumptions have to be invoked somewhere
+\item ``Referenced by'' implies that there is an explicit reference
+\item Think of traceability matrix, list of assumption invokations and list of
+  reference by fields as automatically generatable
+\item If you say the format of the output (plot, table etc), then your
+  requirement could be more abstract
+\end{itemize}
+}
+
+\noindent \wss{The relationships between the parts of the document are show in the
+  following figure}
+\begin{figure}[H]
+  \includegraphics[scale=0.9]{../../../Lectures/Figures/RelationsBetweenTM_GD_IM_DD_A.pdf}
+\end{figure}
+
 \end{document}
\ No newline at end of file