\documentclass[11pt]{article} 
\usepackage{fullpage}
\usepackage[pagewise]{lineno}
%
% End_New:
%
\newenvironment{usecase}{\begin{center}\begin{minipage}[t]{5in}}{\end{minipage}\end{center}} 
\begin{document}
\include{epsf}
\thispagestyle{empty}
\title{{\LARGE\bf Requirements Analysis Document}}
\author{{\Large\it Authors} \\
\vspace*{2.5in} 
\mbox{} \\
{\Large Title of Project} \\
{\large Name of Group}
\vspace*{2.5in} 
\mbox{} \\
\date{\today}
}
\maketitle
\linenumbers
\clearpage
\tableofcontents
\clearpage
\bibliographystyle{plain}
%***************************************************************************
%
% Format of template: Comments appear BEFORE the section header
%
%***************************************************************************


% The first section is an introduction to what your system is, basically an
% abstract of the system and what is to follow in this document.  
% This section introduces the domain for your project (e.g.,
% automotive, appliances, etc.).   In other words, the introduction is a
% short  section that indicates what is the purpose of
% the system, what is the domain that it is used in, what is the purpose
% of the document, and how the document is organized.
% 
\section{Introduction}




%
% The next section is a brief description of the problem and its domain.
% It provides a high-level description of the problem your
% system solves
%
\subsection{Problem Description}


%
% The next section gives background motivation for your system.
% It indicates why the system is needed, the purpose it
% serves, etc.  If there are special challenges/difficulties/risks, they
% should be mentioned here.
%
\subsection{Motivation}


%
% The next section should give an overview of your system operation.
% It may be in the form of a problem statement or a processing narrative of
% the functionality of your system.  A user senario may be a useful subsection
% to further describe the system.
% So, this section is a general overview of how someone will use the
% system.   You could base this section on a high-level problem
% statement.  A couple of user scenarios could be
% used to illustrate the main patterns of interaction.

\section{Overview}

%
% The next section will give DETAILED requirements for your system.  It
% will basically serve as a contract between your team and your customer.
% One possible organization of this section is to first state the requirements
% briefly in a few paragraphs and bullets, and then create subsections that
% address each requirement in detail.  Try to find an organization that
% works well for your group.
% This section should be stated with sufficient detail and
% precision that a software engineer could come up with UML models for
% the system based on this section.  
%
\section{Requirements}


%
% The next section and its subsections will contain your UML analysis.
% The Object Model section will include the actual diagram(s) and a
% data dictionary with entries for each entity in the system.
% The Dynamic Model section will include the appropriate
% diagram(s).  Each section will also contain prose descriptions of the
% analysis and diagrams.  Also include explanations of how and why you
% arrived at this particular UML model.
%
% So this next section is the largest section of the document.  It contains
% the UML models that you came up with to describe the problem domain.
% It should be accompanied by explanatory prose.  It should cross
s% reference the previous section so the reader can see where different
% requirements in the previous section are modeled in this section.  You
% should strive for completeness, but if you are not able to completely
% model the entire system, then you should model the most important
% components/functionality, documenting those components/functionality
% that you did not have time to model.  Consistency is more important
% than total completeness at this point.  The models that you do create
% must be consistent with each other and with the requirements.
%
\section{UML Analysis}


%
% - Identify actors of system
% - Identify use cases involving those actors
% - Iterate
% - Remember where the system boundary is
%
\subsection{Use Cases}

%
% Following is a template for a use case (make copies for each use case)
%
\fbox{
\begin{minipage}[t]{5in}
\begin{usecase}
	\begin{description}
	\item[{Use case: }] 
	\item[{Actors: }]
	\item[{Type: }] % Primary or secondary, essential, etc
	\item[{Description: }] 
	\item[{Cross-reference: }] % (Requirement references)
	\item[{Uses: }] % use cases that it uses
	\item[{Extended by: }] % use cases that extends current use case
	\item[{Extends: }] % use case that curent one extends
	\end{description}
\end{usecase}
\end{minipage}
}


%
% - Identify nouns in system (potential classes)
% - Identify relationships between nouns (potential associations)
% - Refine class list
% - Identify aggregation relationships
% - Identify inheritance relationships
% - Iterate
%
\subsection{Object Model}


%
% The next subsection contains the diagrams describing behavior, including
% the state diagrams and sequence diagrams
% - Create a state diagram for entire system
% - Use use cases to provide scenarios of events
%   in system
% - Create sequence diagrams for scenarios capturing messages between objects;
%   include sequence diagrams for normal and special case usage scenarios
% - Create state diagrams to capture behavior of objects 
% - Iterate and refine state diagrams
%
\subsection{Dynamic Model}


%
% The final section contains the sources of any and all references to other
% group documents, articles, books, etc.  that you used in creating this
% document.  You need to have created the file analysis.bib with
% entries for all of your sources.
%
\bibliography{analysis} % analysis.bib is the bibliography file name
\end{document}