Completed sections 2 and 3. Note that the rest of this document is still a...

Completed sections 2 and 3. Note that the rest of this document is still a template. Revisions to sections 2 and 3 may be neeeded.

Doc/Design/DesignDocument.aux

+\relax 
+\providecommand\hyper@newdestlabel[2]{}
+\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument}
+\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined
+\global\let\oldcontentsline\contentsline
+\gdef\contentsline#1#2#3#4{\oldcontentsline{#1}{#2}{#3}}
+\global\let\oldnewlabel\newlabel
+\gdef\newlabel#1#2{\newlabelxx{#1}#2}
+\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}}
+\AtEndDocument{\ifx\hyper@anchor\@undefined
+\let\contentsline\oldcontentsline
+\let\newlabel\oldnewlabel
+\fi}
+\fi}
+\global\let\hyper@last\relax 
+\gdef\HyperFirstAtBeginDocument#1{#1}
+\providecommand\HyField@AuxAddToFields[1]{}
+\providecommand\HyField@AuxAddToCoFields[2]{}
+\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces \bf  Revision History}}{i}{table.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}{section.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {2}Anticipated and Unlikely Changes}{2}{section.2}}
+\newlabel{SecChange}{{2}{2}{Anticipated and Unlikely Changes}{section.2}{}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Anticipated Changes}{2}{subsection.2.1}}
+\newlabel{SecAchange}{{2.1}{2}{Anticipated Changes}{subsection.2.1}{}}
+\newlabel{acClass}{{1}{2}{\refstepcounter {acnum} \actheacnum :}{acnum.1}{}}
+\newlabel{acWeapon}{{2}{2}{\refstepcounter {acnum} \actheacnum :}{acnum.2}{}}
+\newlabel{acDamageCalculations}{{3}{2}{\refstepcounter {acnum} \actheacnum :}{acnum.3}{}}
+\newlabel{acSprites}{{4}{2}{\refstepcounter {acnum} \actheacnum :}{acnum.4}{}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Unlikely Changes}{2}{subsection.2.2}}
+\newlabel{SecUchange}{{2.2}{2}{Unlikely Changes}{subsection.2.2}{}}
+\newlabel{ucIO}{{1}{3}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.1}{}}
+\newlabel{ucArchitecture}{{2}{3}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.2}{}}
+\newlabel{ucGraph}{{3}{3}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.3}{}}
+\newlabel{ucNodeIdentification}{{4}{3}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.4}{}}
+\newlabel{ucPathfinder}{{5}{3}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.5}{}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}Module Hierarchy}{3}{section.3}}
+\newlabel{SecMH}{{3}{3}{Module Hierarchy}{section.3}{}}
+\newlabel{mHH}{{1}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.1}{}}
+\newlabel{mHH}{{2}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.2}{}}
+\newlabel{mHH}{{3}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.3}{}}
+\newlabel{mHH}{{4}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.4}{}}
+\newlabel{mHH}{{5}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.5}{}}
+\newlabel{mHH}{{6}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.6}{}}
+\newlabel{mHH}{{7}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.7}{}}
+\newlabel{mHH}{{8}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.8}{}}
+\newlabel{mHH}{{9}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.9}{}}
+\newlabel{mHH}{{10}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.10}{}}
+\newlabel{mHH}{{11}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.11}{}}
+\newlabel{mHH}{{12}{4}{\refstepcounter {mnum} \mthemnum :}{mnum.12}{}}
+\newlabel{mHH}{{13}{4}{\refstepcounter {mnum} \mthemnum :}{mnum.13}{}}
+\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces Module Hierarchy}}{4}{table.2}}
+\newlabel{TblMH}{{2}{4}{Module Hierarchy}{table.2}{}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}Connection Between Requirements and Design}{4}{section.4}}
+\newlabel{SecConnection}{{4}{4}{Connection Between Requirements and Design}{section.4}{}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Module Decomposition}{4}{section.5}}
+\newlabel{SecMD}{{5}{4}{Module Decomposition}{section.5}{}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Hardware Hiding Modules (M\ref  {mHH})}{5}{subsection.5.1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Behaviour-Hiding Module}{5}{subsection.5.2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.1}Input Format Module (M\ref  {mInput})}{5}{subsubsection.5.2.1}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.2}Etc.}{6}{subsubsection.5.2.2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Software Decision Module}{6}{subsection.5.3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.3.1}Etc.}{6}{subsubsection.5.3.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {6}Traceability Matrix}{6}{section.6}}
+\newlabel{SecTM}{{6}{6}{Traceability Matrix}{section.6}{}}
+\@writefile{lot}{\contentsline {table}{\numberline {3}{\ignorespaces Trace Between Requirements and Modules}}{6}{table.3}}
+\newlabel{TblRT}{{3}{6}{Trace Between Requirements and Modules}{table.3}{}}
+\bibstyle{plainnat}
+\bibdata{MG}
+\@writefile{lot}{\contentsline {table}{\numberline {4}{\ignorespaces Trace Between Anticipated Changes and Modules}}{7}{table.4}}
+\newlabel{TblACT}{{4}{7}{Trace Between Anticipated Changes and Modules}{table.4}{}}
+\@writefile{toc}{\contentsline {section}{\numberline {7}Use Hierarchy Between Modules}{7}{section.7}}
+\newlabel{SecUse}{{7}{7}{Use Hierarchy Between Modules}{section.7}{}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Use hierarchy among modules}}{7}{figure.1}}
+\newlabel{FigUH}{{1}{7}{Use hierarchy among modules}{figure.1}{}}

Doc/Design/DesignDocument.lof

+\contentsline {figure}{\numberline {1}{\ignorespaces Use hierarchy among modules}}{7}{figure.1}

Doc/Design/DesignDocument.lot

+\contentsline {table}{\numberline {1}{\ignorespaces \bf Revision History}}{i}{table.1}
+\contentsline {table}{\numberline {2}{\ignorespaces Module Hierarchy}}{4}{table.2}
+\contentsline {table}{\numberline {3}{\ignorespaces Trace Between Requirements and Modules}}{6}{table.3}
+\contentsline {table}{\numberline {4}{\ignorespaces Trace Between Anticipated Changes and Modules}}{7}{table.4}

Doc/Design/DesignDocument.out

+\BOOKMARK [1][-]{section.1}{Introduction}{}% 1
+\BOOKMARK [1][-]{section.2}{Anticipated and Unlikely Changes}{}% 2
+\BOOKMARK [2][-]{subsection.2.1}{Anticipated Changes}{section.2}% 3
+\BOOKMARK [2][-]{subsection.2.2}{Unlikely Changes}{section.2}% 4
+\BOOKMARK [1][-]{section.3}{Module Hierarchy}{}% 5
+\BOOKMARK [1][-]{section.4}{Connection Between Requirements and Design}{}% 6
+\BOOKMARK [1][-]{section.5}{Module Decomposition}{}% 7
+\BOOKMARK [2][-]{subsection.5.1}{Hardware Hiding Modules \(M??\)}{section.5}% 8
+\BOOKMARK [2][-]{subsection.5.2}{Behaviour-Hiding Module}{section.5}% 9
+\BOOKMARK [3][-]{subsubsection.5.2.1}{Input Format Module \(M??\)}{subsection.5.2}% 10
+\BOOKMARK [3][-]{subsubsection.5.2.2}{Etc.}{subsection.5.2}% 11
+\BOOKMARK [2][-]{subsection.5.3}{Software Decision Module}{section.5}% 12
+\BOOKMARK [3][-]{subsubsection.5.3.1}{Etc.}{subsection.5.3}% 13
+\BOOKMARK [1][-]{section.6}{Traceability Matrix}{}% 14
+\BOOKMARK [1][-]{section.7}{Use Hierarchy Between Modules}{}% 15

Doc/Design/DesignDocument.tex

+\documentclass[12pt, titlepage]{article}
+\usepackage{fullpage}
+\usepackage[round]{natbib}
+\usepackage{multirow}
+\usepackage{booktabs}
+\usepackage{tabularx}
+\usepackage{graphicx}
+\usepackage{float}
+\usepackage{hyperref}
+\hypersetup{
+    colorlinks,
+    citecolor=black,
+    filecolor=black,
+    linkcolor=red,
+    urlcolor=blue
+}
+\usepackage[round]{natbib}
+\newcounter{acnum}
+\newcommand{\actheacnum}{AC\theacnum}
+\newcommand{\acref}[1]{AC\ref{#1}}
+\newcounter{ucnum}
+\newcommand{\uctheucnum}{UC\theucnum}
+\newcommand{\uref}[1]{UC\ref{#1}}
+\newcounter{mnum}
+\newcommand{\mthemnum}{M\themnum}
+\newcommand{\mref}[1]{M\ref{#1}}
+\title{SE 3XA3: Software Requirements Specification\\Title of Project}
+\author{Team \#, Team Name
+		\\ Student 1 name and macid
+		\\ Student 2 name and macid
+		\\ Student 3 name and macid
+}
+\date{\today}
+
+\begin{document}
+\maketitle
+\pagenumbering{roman}
+\tableofcontents
+\listoftables
+\listoffigures
+\begin{table}[bp]
+\caption{\bf Revision History}
+\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
+\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
+\midrule
+Date 1 & 1.0 & Notes\\
+Date 2 & 1.1 & Notes\\
+\bottomrule
+\end{tabularx}
+\end{table}
+\newpage
+\pagenumbering{arabic}
+\section{Introduction}
+Decomposing a system into modules is a commonly accepted approach to developing
+software.  A module is a work assignment for a programmer or programming
+team~\citep{ParnasEtAl1984}.  We advocate a decomposition
+based on the principle of information hiding~\citep{Parnas1972a}.  This
+principle supports design for change, because the ``secrets'' that each module
+hides represent likely future changes.  Design for change is valuable in SC,
+where modifications are frequent, especially during initial development as the
+solution space is explored.  
+Our design follows the rules layed out by \citet{ParnasEtAl1984}, as follows:
+\begin{itemize}
+\item System details that are likely to change independently should be the
+  secrets of separate modules.
+\item Each data structure is used in only one module.
+\item Any other program that requires information stored in a module's data
+  structures must obtain it by calling access programs belonging to that module.
+\end{itemize}
+After completing the first stage of the design, the Software Requirements
+Specification (SRS), the Module Guide (MG) is developed~\citep{ParnasEtAl1984}. The MG
+specifies the modular structure of the system and is intended to allow both
+designers and maintainers to easily identify the parts of the software.  The
+potential readers of this document are as follows:
+\begin{itemize}
+\item New project members: This document can be a guide for a new project member
+  to easily understand the overall structure and quickly find the
+  relevant modules they are searching for.
+\item Maintainers: The hierarchical structure of the module guide improves the
+  maintainers' understanding when they need to make changes to the system. It is
+  important for a maintainer to update the relevant sections of the document
+  after changes have been made.
+\item Designers: Once the module guide has been written, it can be used to
+  check for consistency, feasibility and flexibility. Designers can verify the
+  system in various ways, such as consistency among modules, feasibility of the
+  decomposition, and flexibility of the design.
+\end{itemize}
+The rest of the document is organized as follows. Section
+\ref{SecChange} lists the anticipated and unlikely changes of the software
+requirements. Section \ref{SecMH} summarizes the module decomposition that
+was constructed according to the likely changes. Section \ref{SecConnection}
+specifies the connections between the software requirements and the
+modules. Section \ref{SecMD} gives a detailed description of the
+modules. Section \ref{SecTM} includes two traceability matrices. One checks
+the completeness of the design against the requirements provided in the SRS. The
+other shows the relation between anticipated changes and the modules. Section
+\ref{SecUse} describes the use relation between modules.
+
+\section{Anticipated and Unlikely Changes} \label{SecChange}
+This section identifies possible changes to the software system. These changes to the design choices are organized into two categories. Anticipated changes, and unlikely changes. Anticipated changes are listed in Section \ref{SecAchange}, and the unlikely changes are listed in Section \ref{SecUchange}.
+
+\subsection{Anticipated Changes} \label{SecAchange}
+The design decisions in this section are likely to change because they are hidden in modules. When these changes are made, they can be done easily and not affect other modules of the project.
+\begin{description}
+\item[\refstepcounter{acnum} \actheacnum \label{acClass}:] All classes that implement the Class interface are likely to have their stats change for balancing reasons.
+
+\item[\refstepcounter{acnum} \actheacnum \label{acWeapon}:] All weapons that implement the Weapon interface are likely to have their stats change for balancing reasons.
+
+\item[\refstepcounter{acnum} \actheacnum \label{acDamageCalculations}:] The getHitRate() and getCritRate() methods inside the DamageCalculations class are likely to change for balancing reasons.
+
+\item[\refstepcounter{acnum} \actheacnum \label{acSprites}:] All sprites from outside sources. It has been determined that the project should contain all original content. 
+
+\end{description}
+
+
+\subsection{Unlikely Changes} \label{SecUchange}
+The following design decisions are unlikely to change because they affect many modules. Since they affect multiple modules, changing these decisions may result in multiple changes in the overall design of the project. Unless these changes are necessary, they will not occur.  
+\begin{description}
+\item[\refstepcounter{ucnum} \uctheucnum \label{ucIO}:] Input/Output devices
+  (Input: Mouse, Output: Updated Model and Screen).
+\item[\refstepcounter{ucnum} \uctheucnum \label{ucArchitecture}:] The software implements the MVC (Model-View-Controller) architecture.
+\item[\refstepcounter{ucnum} \uctheucnum \label{ucGraph}:] The Graph of nodes that represents the playable grid.
+\item[\refstepcounter{ucnum} \uctheucnum \label{ucNodeIdentification}:] Nodes are identified by their x and y coordinates.
+\item[\refstepcounter{ucnum} \uctheucnum \label{ucPathfinder}:] The path finding algorithm.
+
+
+\end{description}
+\section{Module Hierarchy} \label{SecMH}
+This section provides an overview of the module design. Modules are summarized
+in a hierarchy decomposed by secrets in Table \ref{TblMH}. The modules listed
+below, which are leaves in the hierarchy tree, are the modules that will
+actually be implemented.
+\begin{description}
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Hardware-Hiding Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Behaviour-Hiding Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Software Decision Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Graph Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Node Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Unit Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Weapon Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Player Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Game State Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Damage Calculations Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Game Function Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Game Construction Module
+\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Mouse Handler Module
+
+
+\end{description}
+
+
+\begin{table}[h!]
+\centering
+\begin{tabular}{p{0.4\textwidth} p{0.4\textwidth}}
+\toprule
+\textbf{Level 1} & \textbf{Level 2} \\
+\midrule
+{Hardware-Hiding Module} & ~ \\
+\midrule
+\multirow{7}{0.3\textwidth}{Behaviour-Hiding Module} 
+& Graph Module\\
+& Node Module\\
+& Unit Module\\
+& Weapon Module\\
+& Player Module\\
+& Game State Module\\ 
+& Damage Calculations Module\\
+\midrule
+\multirow{4}{0.3\textwidth}{Software Decision Module} & Game Module\\
+& Game Function Module\\
+& Game Construction Module\\
+& Mouse Handler Module\\
+\bottomrule
+\end{tabular}
+\caption{Module Hierarchy}
+\label{TblMH}
+\end{table}
+
+Since Blaze-Brigade consists of purely software, M1 does not apply to the system. The software never interfaces with the hardware itself. The lowest level of interfacing with the software is the OS.
+
+\section{Connection Between Requirements and Design} \label{SecConnection}
+The design of the system is intended to satisfy the requirements developed in
+the SRS. In this stage, the system is decomposed into modules. The connection
+between requirements and modules is listed in Table \ref{TblRT}.
+\section{Module Decomposition} \label{SecMD}
+Modules are decomposed according to the principle of ``information hiding''
+proposed by \citet{ParnasEtAl1984}. The \emph{Secrets} field in a module
+decomposition is a brief statement of the design decision hidden by the
+module. The \emph{Services} field specifies \emph{what} the module will do
+without documenting \emph{how} to do it. For each module, a suggestion for the
+implementing software is given under the \emph{Implemented By} title. If the
+entry is \emph{OS}, this means that the module is provided by the operating
+system or by standard programming language libraries.  Also indicate if the
+module will be implemented specifically for the software.
+Only the leaf modules in the
+hierarchy have to be implemented. If a dash (\emph{--}) is shown, this means
+that the module is not a leaf and will not have to be implemented. Whether or
+not this module is implemented depends on the programming language
+selected.
+\subsection{Hardware Hiding Modules (\mref{mHH})}
+\begin{description}
+\item[Secrets:]The data structure and algorithm used to implement the virtual
+  hardware.
+\item[Services:]Serves as a virtual hardware used by the rest of the
+  system. This module provides the interface between the hardware and the
+  software. So, the system can use it to display outputs or to accept inputs.
+\item[Implemented By:] OS
+\end{description}
+\subsection{Behaviour-Hiding Module}
+\begin{description}
+\item[Secrets:]The contents of the required behaviours.
+\item[Services:]Includes programs that provide externally visible behaviour of
+  the system as specified in the software requirements specification (SRS)
+  documents. This module serves as a communication layer between the
+  hardware-hiding module and the software decision module. The programs in this
+  module will need to change if there are changes in the SRS.
+\item[Implemented By:] --
+\end{description}
+\subsubsection{Input Format Module (\mref{mInput})}
+\begin{description}
+\item[Secrets:]The format and structure of the input data.
+\item[Services:]Converts the input data into the data structure used by the
+  input parameters module.
+\item[Implemented By:] [Your Program Name Here]
+\end{description}
+\subsubsection{Etc.}
+\subsection{Software Decision Module}
+\begin{description}
+\item[Secrets:] The design decision based on mathematical theorems, physical
+  facts, or programming considerations. The secrets of this module are
+  \emph{not} described in the SRS.
+\item[Services:] Includes data structure and algorithms used in the system that
+  do not provide direct interaction with the user. 
+  % Changes in these modules are more likely to be motivated by a desire to
+  % improve performance than by externally imposed changes.
+\item[Implemented By:] --
+\end{description}
+\subsubsection{Etc.}
+\section{Traceability Matrix} \label{SecTM}
+This section shows two traceability matrices: between the modules and the
+requirements and between the modules and the anticipated changes.
+% the table should use mref, the requirements should be named, use something
+% like fref
+\begin{table}[H]
+\centering
+\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
+\toprule
+\textbf{Req.} & \textbf{Modules}\\
+\midrule
+R1 & \mref{mHH}, \mref{mInput}, \mref{mParams}, \mref{mControl}\\
+R2 & \mref{mInput}, \mref{mParams}\\
+R3 & \mref{mVerify}\\
+R4 & \mref{mOutput}, \mref{mControl}\\
+R5 & \mref{mOutput}, \mref{mODEs}, \mref{mControl}, \mref{mSeqDS}, \mref{mSolver}, \mref{mPlot}\\
+R6 & \mref{mOutput}, \mref{mODEs}, \mref{mControl}, \mref{mSeqDS}, \mref{mSolver}, \mref{mPlot}\\
+R7 & \mref{mOutput}, \mref{mEnergy}, \mref{mControl}, \mref{mSeqDS}, \mref{mPlot}\\
+R8 & \mref{mOutput}, \mref{mEnergy}, \mref{mControl}, \mref{mSeqDS}, \mref{mPlot}\\
+R9 & \mref{mVerifyOut}\\
+R10 & \mref{mOutput}, \mref{mODEs}, \mref{mControl}\\
+R11 & \mref{mOutput}, \mref{mODEs}, \mref{mEnergy}, \mref{mControl}\\
+\bottomrule
+\end{tabular}
+\caption{Trace Between Requirements and Modules}
+\label{TblRT}
+\end{table}
+\begin{table}[H]
+\centering
+\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
+\toprule
+\textbf{AC} & \textbf{Modules}\\
+\midrule
+\acref{acHardware} & \mref{mHH}\\
+\acref{acInput} & \mref{mInput}\\
+\acref{acParams} & \mref{mParams}\\
+\acref{acVerify} & \mref{mVerify}\\
+\acref{acOutput} & \mref{mOutput}\\
+\acref{acVerifyOut} & \mref{mVerifyOut}\\
+\acref{acODEs} & \mref{mODEs}\\
+\acref{acEnergy} & \mref{mEnergy}\\
+\acref{acControl} & \mref{mControl}\\
+\acref{acSeqDS} & \mref{mSeqDS}\\
+\acref{acSolver} & \mref{mSolver}\\
+\acref{acPlot} & \mref{mPlot}\\
+\bottomrule
+\end{tabular}
+\caption{Trace Between Anticipated Changes and Modules}
+\label{TblACT}
+\end{table}
+\section{Use Hierarchy Between Modules} \label{SecUse}
+In this section, the uses hierarchy between modules is
+provided. \citet{Parnas1978} said of two programs A and B that A {\em uses} B if
+correct execution of B may be necessary for A to complete the task described in
+its specification. That is, A {\em uses} B if there exist situations in which
+the correct functioning of A depends upon the availability of a correct
+implementation of B.  Figure \ref{FigUH} illustrates the use relation between
+the modules. It can be seen that the graph is a directed acyclic graph
+(DAG). Each level of the hierarchy offers a testable and usable subset of the
+system, and modules in the higher level of the hierarchy are essentially simpler
+because they use modules from the lower levels.
+\begin{figure}[H]
+\centering
+%\includegraphics[width=0.7\textwidth]{UsesHierarchy.png}
+\caption{Use hierarchy among modules}
+\label{FigUH}
+\end{figure}
+%\section*{References}
+\bibliographystyle {plainnat}
+\bibliography {MG}
+\end{document}
\ No newline at end of file

Doc/Design/DesignDocument.toc

+\contentsline {section}{\numberline {1}Introduction}{1}{section.1}
+\contentsline {section}{\numberline {2}Anticipated and Unlikely Changes}{2}{section.2}
+\contentsline {subsection}{\numberline {2.1}Anticipated Changes}{2}{subsection.2.1}
+\contentsline {subsection}{\numberline {2.2}Unlikely Changes}{2}{subsection.2.2}
+\contentsline {section}{\numberline {3}Module Hierarchy}{3}{section.3}
+\contentsline {section}{\numberline {4}Connection Between Requirements and Design}{4}{section.4}
+\contentsline {section}{\numberline {5}Module Decomposition}{4}{section.5}
+\contentsline {subsection}{\numberline {5.1}Hardware Hiding Modules (M\ref {mHH})}{5}{subsection.5.1}
+\contentsline {subsection}{\numberline {5.2}Behaviour-Hiding Module}{5}{subsection.5.2}
+\contentsline {subsubsection}{\numberline {5.2.1}Input Format Module (M\ref {mInput})}{5}{subsubsection.5.2.1}
+\contentsline {subsubsection}{\numberline {5.2.2}Etc.}{6}{subsubsection.5.2.2}
+\contentsline {subsection}{\numberline {5.3}Software Decision Module}{6}{subsection.5.3}
+\contentsline {subsubsection}{\numberline {5.3.1}Etc.}{6}{subsubsection.5.3.1}
+\contentsline {section}{\numberline {6}Traceability Matrix}{6}{section.6}
+\contentsline {section}{\numberline {7}Use Hierarchy Between Modules}{7}{section.7}