Addition of NFR ideas to SRS template

BlankProjectTemplate/docs/SRS/SRS.tex

@@ -69,6 +69,9 @@
 \newcounter{reqnum} %Requirement Number
 \newcommand{\rthereqnum}{P\thereqnum}
 \newcommand{\rref}[1]{R\ref{#1}}
+\newcounter{nfrnum} %NFR Number
+\newcommand{\rthenfrnum}{NFR\thenfrnum}
+\newcommand{\nfrref}[1]{NFR\ref{#1}}
 \newcounter{lcnum} %Likely change number
 \newcommand{\lthelcnum}{LC\thelcnum}
 \newcommand{\lcref}[1]{LC\ref{#1}}
@@ -914,6 +917,56 @@ qualities that the software is expected to exhibit.
 
 \plt{List your nonfunctional requirements.  You may consider using a fit
   criterion to make them verifiable.}
+\plt{The goal is for the nonfunctional requirements to be unambiguous, abstract
+  and verifiable.  This isn't easy to show succinctly, so a good strategy may be
+to give a ``high level'' view of the requirement, but allow for the details to
+be covered in the Verification and Validation document.}
+\plt{An absolute requirement on a quality of the system is rarely needed.  For
+  instance, an accuracy of 0.0101 \% is likely fine, even if the requirement is
+  for 0.01 \% accuracy.  Therefore, the emphasis will often be more on
+  describing now well the quality is achieved, through experimentation, and
+  possibly theory, rather than meeting some bar that was defined a priori.}
+\plt{You do not need an entry for correctness in your NFRs.  The purpose of the
+  SRS is to record the requirements that need to be satisfied for correctness.
+  Any statement of correctness would just be redundant. Rather than discuss
+  correctness, you can characterize how far away from the correct (true)
+  solution you are allowed to be.  This is discussed under accuracy.}
+
+\noindent \begin{itemize}
+
+\item[NFR\refstepcounter{nfrnum}\thenfrnum \label{NFR_Accuracy}:]
+  \textbf{Accuracy} \plt{Characterize the accuracy by giving the context/use for
+    the software.  Maybe something like, ``The accuracy of the computed
+    solutions should meet the level needed for <engineering or scientific
+    application>.  The level of accuracy achieved by \progname{} shall be
+    described following the procedure given in Section~X of the Verification and
+    Validation Plan.''  A link to the VnV plan would be a nice extra.}
+
+\item[NFR\refstepcounter{nfrnum}\thenfrnum \label{NFR_Usability}:] \textbf{Usability}
+  \plt{Characterize the usability by giving the context/use for the software.
+    You should likely reference the user characteristics section.  The level of
+    usability achieved by the software shall be described following the
+    procedure given in Section~X of the Verification and Validation Plan.  A
+    link to the VnV plan would be a nice extra.}
+
+\item[NFR\refstepcounter{nfrnum}\thenfrnum \label{NFR_Maintainability}:]
+  \textbf{Maintainability} \plt{The effort required to make any of the likely
+    changes listed for \progname{} should be less than FRACTION of the original
+    development time.  FRACTION is then a symbolic constant that can be defined
+    at the end of the report.}
+
+\item[NFR\refstepcounter{nfrnum}\thenfrnum \label{NFR_Portability}:]
+  \textbf{Portability} \plt{This NFR is easier to write than the others.  The
+    systems that \progname{} should run on should be listed here.  When possible
+    the specific versions of the potential operating environments should be
+    given.  To make the NFR verifiable a statement could be made that the tests
+    from a given section of the VnV plan can be successfully run on all of the
+    possible operating environments.}
+
+\item Other NFRs that might be discussed include verifiability,
+  understandability and reusability.
+
+\end{itemize}
 
 \section{Likely Changes}    
 
@@ -1077,6 +1130,8 @@ instance models, requirements, and data constraints on each other.
 \plt{The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
 Their values are defined in this section for easy maintenance.}
 
+\plt{The value of FRACTION, for the Maintainability NFR would be given here.}
+
 \newpage
 
 \bibliographystyle {plainnat}