Skip to content
Snippets Groups Projects
Commit 1020eca7 authored by Andrew Hum's avatar Andrew Hum
Browse files

Merge branch 'master' of https://gitlab.cas.mcmaster.ca/khana172/3xa3-project

parents 00b4034b ab174bc8
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 0 additions and 751 deletions
BlankProjectTemplate/Doc/Design/MG/MG.bib deleted 100644 → 0
+ 0
− 67
View file @ 00b4034b
%% This BibTeX bibliography file was created using BibDesk.
%% http://bibdesk.sourceforge.net/
%% Created for Spencer Smith at 2016-10-27 23:57:04 -0400
%% Saved with string encoding Unicode (UTF-8)
@inproceedings{Parnas1978,
Address = {Piscataway, NJ, USA},
Author = {David L. Parnas},
Booktitle = {ICSE '78: Proceedings of the 3rd international conference on Software engineering},
Date-Added = {2016-10-28 03:56:16 +0000},
Date-Modified = {2016-10-28 03:56:16 +0000},
Isbn = {none},
Location = {Atlanta, Georgia, United States},
Pages = {264--277},
Publisher = {IEEE Press},
Title = {Designing Software for Ease of Extension and Contraction},
Year = {1978}}
@article{Parnas1972a,
Author = {David L. Parnas},
Date-Added = {2016-10-28 03:55:43 +0000},
Date-Modified = {2016-10-28 03:55:43 +0000},
Journal = {Comm. ACM},
Month = {December},
Number = {2},
Pages = {1053--1058},
Title = {On the Criteria To Be Used in Decomposing Systems into Modules},
Volume = {15},
Year = {1972},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QOS4uLy4uLy4uLy4uLy4uLy4uL1dvcmsvUmVzZWFyY2gvUmVmZXJlbmNlcy9QYXJuYXMxOTcyLnBkZtIXCxgZV05TLmRhdGFPEQGmAAAAAAGmAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAAXAgwOUGFybmFzMTk3Mi5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3+xs9CaVP4AAAAAAAAAAAAGAAQAAAkgAAAAAAAAAAAAAAAAAAAAClJlZmVyZW5jZXMAEAAIAADOl6vDAAAAEQAIAADQmptOAAAAAQAUABcCDAAXAE0AFv3tAAj3ZgACZI4AAgBGTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFdvcms6AFJlc2VhcmNoOgBSZWZlcmVuY2VzOgBQYXJuYXMxOTcyLnBkZgAOAB4ADgBQAGEAcgBuAGEAcwAxADkANwAyAC4AcABkAGYADwAaAAwATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAEgA0VXNlcnMvc21pdGhzL1dvcmsvUmVzZWFyY2gvUmVmZXJlbmNlcy9QYXJuYXMxOTcyLnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOAMoAzwDXAoECgwKIApMCnAKqAq4CtQK+AsMC0ALTAuUC6ALtAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAu8=}}
@inproceedings{ParnasEtAl1984,
Author = {D.L. Parnas and P.C. Clement and D. M. Weiss},
Booktitle = {International Conference on Software Engineering},
Date-Added = {2016-10-28 03:55:23 +0000},
Date-Modified = {2016-10-28 03:55:23 +0000},
Pages = {408-419},
Title = {The modular structure of complex systems},
Year = {1984},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QPy4uLy4uLy4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1Bhcm5hc0V0QWwxOTg0LnBkZtIXCxgZV05TLmRhdGFPEQHcAAAAAAHcAAIAAAxNYWNpbnRvc2ggSEQAAAAAAAAAAAAAAAAAAADOl3ODSCsAAAkx/Q0SUGFybmFzRXRBbDE5ODQucGRmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACTH9RNNvBNMAAAAAAAAAAAAFAAMAAAkgAAAAAAAAAAAAAAAAAAAAF1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzAAAQAAgAAM6Xq8MAAAARAAgAANNvPRMAAAABABQJMf0NCTHuxwASFacACPdmAAJkjgACAFVNYWNpbnRvc2ggSEQ6VXNlcnM6AHNtaXRoczoAUmVwb3M6AHNlNHNjOgBTY2lDb21wQW5kU29mdEVuZ1BhcGVyczoAUGFybmFzRXRBbDE5ODQucGRmAAAOACYAEgBQAGEAcgBuAGEAcwBFAHQAQQBsADEAOQA4ADQALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAENVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvUGFybmFzRXRBbDE5ODQucGRmAAATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOANAA1QDdAr0CvwLEAs8C2ALmAuoC8QL6Av8DDAMPAyEDJAMpAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAys=}}
@book{RobertsonAndRobertson2012,
Author = {James Robertson and Suzanne Robertson},
Date-Added = {2016-09-22 13:54:40 +0000},
Date-Modified = {2016-09-22 14:01:42 +0000},
Edition = {16},
Publisher = {Atlantic Systems Guild Limited},
Title = {Volere Requirements Specification Template},
Year = {2012}}
@article{ParnasAndClements1986,
Author = {David L. Parnas and P.C. Clements},
Date-Added = {2016-09-10 13:11:57 +0000},
Date-Modified = {2016-09-10 13:11:57 +0000},
Journal = {IEEE Transactions on Software Engineering},
Number = {2},
Pages = {251--257},
Title = {A Rational Design Process: How and Why to Fake it},
Volume = {12},
Year = {February 1986},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QRi4uLy4uLy4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1Bhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGbSFwsYGVdOUy5kYXRhTxEB9gAAAAAB9gACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAAzpdzg0grAAAJMf0NGVBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkx/UPTbwTTAAAAAAAAAAAABQADAAAJIAAAAAAAAAAAAAAAAAAAABdTY2lDb21wQW5kU29mdEVuZ1BhcGVycwAAEAAIAADOl6vDAAAAEQAIAADTbz0TAAAAAQAUCTH9DQkx7scAEhWnAAj3ZgACZI4AAgBcTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFJlcG9zOgBzZTRzYzoAU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnM6AFBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYADgA0ABkAUABhAHIAbgBhAHMAQQBuAGQAQwBsAGUAbQBlAG4AdABzADEAOQA4ADYALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAEpVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvUGFybmFzQW5kQ2xlbWVudHMxOTg2LnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOANcA3ADkAt4C4ALlAvAC+QMHAwsDEgMbAyADLQMwA0IDRQNKAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA0w=}}
BlankProjectTemplate/Doc/Design/MG/MG.pdf deleted 100644 → 0
+ 0
− 0
View file @ 00b4034b
File deleted
BlankProjectTemplate/Doc/Design/MG/MG.tex deleted 100644 → 0
+ 0
− 355
View file @ 00b4034b
\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}
\input{../../Comments}
\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 lists possible changes to the system. According to the likeliness
of the change, the possible changes are classified into two
categories. Anticipated changes are listed in Section \ref{SecAchange}, and
unlikely changes are listed in Section \ref{SecUchange}.
\subsection{Anticipated Changes} \label{SecAchange}
Anticipated changes are the source of the information that is to be hidden
inside the modules. Ideally, changing one of the anticipated changes will only
require changing the one module that hides the associated decision. The approach
adapted here is called design for
change.
\begin{description}
\item[\refstepcounter{acnum} \actheacnum \label{acHardware}:] The specific
hardware on which the software is running.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The format of the
initial input data.
\item ...
\end{description}
\subsection{Unlikely Changes} \label{SecUchange}
The module design should be as general as possible. However, a general system is
more complex. Sometimes this complexity is not necessary. Fixing some design
decisions at the system architecture stage can simplify the software design. If
these decision should later need to be changed, then many parts of the design
will potentially need to be modified. Hence, it is not intended that these
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}
\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 ...
\end{description}
\begin{table}[h!]
\centering
\begin{tabular}{p{0.3\textwidth} p{0.6\textwidth}}
\toprule
\textbf{Level 1} & \textbf{Level 2}\\
\midrule
{Hardware-Hiding Module} & ~ \\
\midrule
\multirow{7}{0.3\textwidth}{Behaviour-Hiding Module} & ?\\
& ?\\
& ?\\
& ?\\
& ?\\
& ?\\
& ?\\
& ?\\
\midrule
\multirow{3}{0.3\textwidth}{Software Decision Module} & {?}\\
& ?\\
& ?\\
\bottomrule
\end{tabular}
\caption{Module Hierarchy}
\label{TblMH}
\end{table}
\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
BlankProjectTemplate/Doc/Design/MG/README.md deleted 100644 → 0
+ 0
− 3
View file @ 00b4034b
# Module Guide
The folders and files for the module guide.
BlankProjectTemplate/Doc/Design/MIS/README.md deleted 100644 → 0
+ 0
− 3
View file @ 00b4034b
# Module Interface Specification #
Use doxygen (or equivalent) to document the interface for your modules.
BlankProjectTemplate/Doc/Design/README.md deleted 100644 → 0
+ 0
− 5
View file @ 00b4034b
# Design Documentation
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/DevelopmentPlan/DevelopmentPlan.pdf deleted 100644 → 0
+ 0
− 0
View file @ 00b4034b
File deleted
BlankProjectTemplate/Doc/DevelopmentPlan/DevelopmentPlan.tex deleted 100644 → 0
+ 0
− 59
View file @ 00b4034b
\documentclass{article}
\usepackage{booktabs}
\usepackage{tabularx}
\title{SE 3XA3: Development Plan\\Title of Project}
\author{Team \#, Team Name
\\ Student 1 name and macid
\\ Student 2 name and macid
\\ Student 3 name and macid
}
\date{}
\input{../Comments}
\begin{document}
\begin{table}[hp]
\caption{Revision History} \label{TblRevisionHistory}
\begin{tabularx}{\textwidth}{llX}
\toprule
\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
\midrule
Date1 & Name(s) & Description of changes\\
Date2 & Name(s) & Description of changes\\
... & ... & ...\\
\bottomrule
\end{tabularx}
\end{table}
\newpage
\maketitle
Put your introductory blurb here.
\section{Team Meeting Plan}
\section{Team Communication Plan}
\section{Team Member Roles}
\section{Git Workflow Plan}
\section{Proof of Concept Demonstration Plan}
\section{Technology}
\section{Coding Style}
\section{Project Schedule}
Provide a pointer to your Gantt Chart.
\section{Project Review}
\end{document}
\ No newline at end of file
BlankProjectTemplate/Doc/DevelopmentPlan/README.md deleted 100644 → 0
+ 0
− 5
View file @ 00b4034b
# Development Plan
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/FinalPresentation/README.md deleted 100644 → 0
+ 0
− 5
View file @ 00b4034b
# Final Presentation
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/ProblemStatement/ProblemStatement.pdf deleted 100644 → 0
+ 0
− 0
View file @ 00b4034b
File deleted
BlankProjectTemplate/Doc/ProblemStatement/ProblemStatement.tex deleted 100644 → 0
+ 0
− 49
View file @ 00b4034b
\documentclass{article}
\usepackage{tabularx}
\usepackage{booktabs}
\title{SE 3XA3: Problem Statement\\Title of Project}
\author{Team \#, Team Name
\\ Student 1 name and macid
\\ Student 2 name and macid
\\ Student 3 name and macid
}
\date{}
\input{../Comments}
\begin{document}
\begin{table}[hp]
\caption{Revision History} \label{TblRevisionHistory}
\begin{tabularx}{\textwidth}{llX}
\toprule
\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
\midrule
Date1 & Name(s) & Description of changes\\
Date2 & Name(s) & Description of changes\\
... & ... & ...\\
\bottomrule
\end{tabularx}
\end{table}
\newpage
\maketitle
Put your problem statement here.
\wss{comment}
\ds{comment}
\mj{comment}
\cm{comment}
\mh{comment}
\end{document}
\ No newline at end of file
BlankProjectTemplate/Doc/ProblemStatement/README.md deleted 100644 → 0
+ 0
− 5
View file @ 00b4034b
# Problem Statement
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/README.md deleted 100644 → 0
+ 0
− 5
View file @ 00b4034b
# Documentation folders
The folders and files for this folder are as follows:
Describe ...
\ No newline at end of file
BlankProjectTemplate/Doc/SRS/README.md deleted 100644 → 0
+ 0
− 5
View file @ 00b4034b
# Software Requirements Specification
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/SRS/SRS.bib deleted 100644 → 0
+ 0
− 30
View file @ 00b4034b
%% This BibTeX bibliography file was created using BibDesk.
%% http://bibdesk.sourceforge.net/
%% Created for Spencer Smith at 2016-09-22 10:01:42 -0400
%% Saved with string encoding Unicode (UTF-8)
@book{RobertsonAndRobertson2012,
Author = {James Robertson and Suzanne Robertson},
Date-Added = {2016-09-22 13:54:40 +0000},
Date-Modified = {2016-09-22 14:01:42 +0000},
Edition = {16},
Publisher = {Atlantic Systems Guild Limited},
Title = {Volere Requirements Specification Template},
Year = {2012}}
@article{ParnasAndClements1986,
Author = {David L. Parnas and P.C. Clements},
Date-Added = {2016-09-10 13:11:57 +0000},
Date-Modified = {2016-09-10 13:11:57 +0000},
Journal = {IEEE Transactions on Software Engineering},
Number = {2},
Pages = {251--257},
Title = {A Rational Design Process: How and Why to Fake it},
Volume = {12},
Year = {February 1986},
Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QQy4uLy4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1Bhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGbSFwsYGVdOUy5kYXRhTxEB9gAAAAAB9gACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAA0khroUgrAAAAhfxhGVBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACF/LDT7aEvAAAAAAAAAAAABAADAAAJIAAAAAAAAAAAAAAAAAAAABdTY2lDb21wQW5kU29mdEVuZ1BhcGVycwAAEAAIAADSSKPhAAAAEQAIAADT7dlvAAAAAQAUAIX8YQCF7/8AILODAAlg3gAGKpoAAgBcTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFJlcG9zOgBzZTRzYzoAU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnM6AFBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYADgA0ABkAUABhAHIAbgBhAHMAQQBuAGQAQwBsAGUAbQBlAG4AdABzADEAOQA4ADYALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAEpVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvUGFybmFzQW5kQ2xlbWVudHMxOTg2LnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOANQA2QDhAtsC3QLiAu0C9gMEAwgDDwMYAx0DKgMtAz8DQgNHAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA0k=}}
BlankProjectTemplate/Doc/SRS/SRS.pdf deleted 100644 → 0
+ 0
− 0
View file @ 00b4034b
File deleted
BlankProjectTemplate/Doc/SRS/SRS.tex deleted 100644 → 0
+ 0
− 150
View file @ 00b4034b
\documentclass[12pt, titlepage]{article}
\usepackage{booktabs}
\usepackage{tabularx}
\usepackage{hyperref}
\hypersetup{
colorlinks,
citecolor=black,
filecolor=black,
linkcolor=red,
urlcolor=blue
}
\usepackage[round]{natbib}
\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}
\input{../Comments}
\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}
This document describes the requirements for .... The template for the Software
Requirements Specification (SRS) is a subset of the Volere
template~\citep{RobertsonAndRobertson2012}. If you make further modifications
to the template, you should explicity state what modifications were made.
\section{Project Drivers}
\subsection{The Purpose of the Project}
\subsection{The Stakeholders}
\subsubsection{The Client}
\subsubsection{The Customers}
\subsubsection{Other Stakeholders}
\subsection{Mandated Constraints}
\subsection{Naming Conventions and Terminology}
\subsection{Relevant Facts and Assumptions}
User characteristics should go under assumptions.
\section{Functional Requirements}
\subsection{The Scope of the Work and the Product}
\subsubsection{The Context of the Work}
\subsubsection{Work Partitioning}
\subsubsection{Individual Product Use Cases}
\subsection{Functional Requirements}
\section{Non-functional Requirements}
\subsection{Look and Feel Requirements}
\subsection{Usability and Humanity Requirements}
\subsection{Performance Requirements}
\subsection{Operational and Environmental Requirements}
\subsection{Maintainability and Support Requirements}
\subsection{Security Requirements}
\subsection{Cultural Requirements}
\subsection{Legal Requirements}
\subsection{Health and Safety Requirements}
This section is not in the original Volere template, but health and safety are
issues that should be considered for every engineering project.
\section{Project Issues}
\subsection{Open Issues}
\subsection{Off-the-Shelf Solutions}
\subsection{New Problems}
\subsection{Tasks}
\subsection{Migration to the New Product}
\subsection{Risks}
\subsection{Costs}
\subsection{User Documentation and Training}
\subsection{Waiting Room}
\subsection{Ideas for Solutions}
\bibliographystyle{plainnat}
\bibliography{SRS}
\newpage
\section{Appendix}
This section has been added to the Volere template. This is where you can place
additional information.
\subsection{Symbolic Parameters}
The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
Their values are defined in this section for easy maintenance.
\end{document}
\ No newline at end of file
BlankProjectTemplate/Doc/TestPlan/README.md deleted 100644 → 0
+ 0
− 5
View file @ 00b4034b
# Test Plan
The folders and files for this folder are as follows:
Describe ...
BlankProjectTemplate/Doc/TestPlan/TestPlan.pdf deleted 100644 → 0
+ 0
− 0
View file @ 00b4034b
File deleted
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment