\documentstyle[titlepage,psfig,fullpage]{article}

%%
%% Definition of commands that we will use in the document
%%

% screen names
\newcommand{\tiscreen}{{\em task information screen}}
\newcommand{\pscreen}{{\em project screen}}
\newcommand{\pcscreen}{{\em PERT chart screen}}
\newcommand{\gcscreen}{{\em Gantt chart screen}}
\newcommand{\poscreen}{{\em export options screen}}
\newcommand{\flsscreen}{{\em file load-store screen}}

% the name of our tool
\newcommand{\xplan}{{\em xplan}}

%%
%% Document title and authors
%%
\title{Software Requirements Specification\\[.5in]Project Planning Tool}

\author{Brian Gaubert \and Mark M. Lacey \and Richard Malingkas \and
Mike Marlow}

\begin{document}

\maketitle

\pagenumbering{roman} % number table of contents and list of figures
		      % with roman numerals

\tableofcontents      % make a table of contents for the document
\newpage              % begin a new page

\listoffigures        % list of figures used in the document
\newpage              % begin a new page

\pagenumbering{arabic} % start numbering pages with arabic numerals

%###########################################################################
%###########################################################################
% INTRODUCTION                                                INTRODUCTION %
%###########################################################################
%###########################################################################
%
%  This section provides a high level overview of the system.
%
\section{Introduction}

This document gives an analysis and description of the functional and
behavioral properties of our project planning tool, \xplan, along
with a description of the information it will keep track of and the
flow of information within the tool.  The purpose of \xplan\/ is to
facilitate the planning of projects by providing storage and retrieval
of information related to tasks that are a part of the project being
planned.  Project information can be stored to a file, thereby saving
it for later retrieval.  The tool will allow one project file to be
loaded and manipulated at a given time.  Project planning is further
facilitated by the automatic generation of both PERT and Gantt charts
based on the task dependency information in the task database.  Direct
generation of \LaTeX\ representations of the task information, along
with both PERT and Gantt charts, provides the user with an easy
mechanism for incorporating the output of the tool into project
planning documents.

%
%  This section provides a bibliography of any documents
%  and manuals that may be referred to from within this
%  document
%
\subsection{System Reference}

For more information on PERT and Gantt charts, and critical path
analysis in particular, see \cite{cpa}.  For more information on the
project planning tool that we are presenting, refer to \cite{prj-desc}
and \cite{prj-plan}.

%
%  This section provides an overall description of the system
%  much like the introduction of the project plan
%
\subsection{Overall Description}

The tool will include a graphical user interface (GUI) built using the
Sun OpenWindows Developer's Guide.  This restricts the platforms that
the tool will run on to Unix\footnote{Unix is a trademark of AT\&T
Bell Labs.} machines running the X Windows system and having the XView
libraries.  Since X Windows and the XView libraries are both
distributed freely\footnote{A nominal distribution fee is charged if
the libraries are distributed on tape.}, and free implementations of
Unix exist (386BSD, linux) which are powerful enough to run X Windows,
the restrictions are minimal.

At the heart of the graphical user interface is the \pscreen\/ (see
figure~\ref{project-screen} on page~\pageref{project-screen}) which
contains a list of tasks, along with pull-down menus that perform
functions such as file loading and saving, PERT and Gantt chart
display, date calculations, and \LaTeX\ file generation.  By
double-clicking on a task in the task list, the user will be able to
bring up the \tiscreen\/ for that task.  The user can then modify
information about the task, and save the changes into the task
database.  These two screens are used throughout the process of
building a task list, which can then later be displayed graphically as
a PERT or Gantt chart.

\begin{figure}
\centering
\centerline{\psfig{figure=project-screen.ps,height=3in}}
\caption[Project Screen]{\label{project-screen} The \pscreen\/
with example task list.}
\end{figure}

The \tiscreen\/ (see figure~\ref{task-info-screen} on
page~\pageref{task-info-screen}) is the means by which the user enters
and views specific information about each task that is a part of the
project they are planning.  That information includes task name; task
description; task duration; planned, actual, forecast, earliest, and
latest start and end dates; float time; resource list; sub-task list;
dependency list; and flags which indicate if completion of this task
is a milestone, and if completion of this task yields a deliverable.
Some items, like the earliest and latest start and end dates, cannot
be modified by the user, but are rather filled in by selecting the
{\em Date Calculation}\/ item in the {\em Analyze}\/ menu of the
\pscreen.  The resource, sub-task, and dependency lists are accessed
by selecting the appropriate button on the \tiscreen.  Once the user
is satisfied with the information entered for the task, he/she can
select the {\em Apply}\/ button to save the information for the given
task into the task database.  If at any point before selecting {\em
Apply}\/ the user decides he/she would like to revert to what was
previously stored in the database, the {\em Reset}\/ option can be
chosen.

\begin{figure}
\centering
\centerline{\psfig{figure=task-info-screen.ps,height=4in}}
\caption[Task Information Screen]{\label{task-info-screen} The
\tiscreen\/ with detailed task information.}
\end{figure}

The \pcscreen\/ is for the graphical display of PERT charts which
correspond to the task list created by the user.  The chart is
generated automatically based upon the tasks and their dependency
lists.  Each box on the chart will be the same size, and will contain
the task name, planned start and end date for the task, task number,
and task duration.  Task dependency will be indicated by placing the
tasks that have to be completed first on the left end of the chart,
and drawing lines to those tasks that can be started once the task is
complete.  If the task is part of the critical path, the line from
that task to the next task on the critical path will be drawn thicker
than other lines, to give a good graphical representation of its
importance.  By double-clicking on a task box, the user will cause the
\tiscreen\/ to be displayed with the details of that task.

The \gcscreen\/ is for the graphical display of Gantt charts, which
like the PERT charts will be generated based on the information in the
task list created by the user.  The user will have the ability to
select a task from the Gantt chart which will cause the \tiscreen\/ to
be displayed with information on that task.

In addition to those main screens, a \flsscreen\/ along with a
\poscreen\/ are provided so that the user can control the destination
of save the project file and \LaTeX\ output that the program produces.

The \flsscreen\/ includes a field with the path to the current
directory displayed in it, along with a list of files in the current
directory, and a field in which the user can enter a directory that
they would like to move to or the name of a file they would like to
load.

The \poscreen\/ contains fields for the user to enter directory and
file names for the generated \LaTeX\ code to be stored in.  Direct
printing of the \LaTeX\ files from within the application will not be
provided since the main purpose of using a \LaTeX\ format for the
output is to allow a user to incorporate generated task sheets, along
with PERT and Gantt charts, into his/her own document for later
printing.  If the user chooses to print the generated files directly
rather than incorporating them into another document, the normal {\tt
latex}, {\tt dvips}, and {\tt lpr} commands can be used from a command
shell.

%
%  This section lists any constraints imposed on the project.
%
\subsection{Software Project Constraints}

This section will describe the constraints that are imposed within the
software from the functionality aspects of the program. These
constraints include using one set of data or database at a time, the
calculations will be done on the fly, meaning they will be done when
needed. Other constraints include the hard coded portion of the
\LaTeX\ generated code within that partition of the program, the file
that is to be written will be in special form, so that it can be read
easily. This format will come from the program but could also come
from another source, just as long as the same format is maintained.
The database is represented as a list so that the size of the list
will depend on the amount of memory that is available to the user.
Some other constraints is that the user interface must run on an open
windows environment and the size of the file will be determined by the
amount of disk space available to the user.

%
%
%
%
\section{Special Issues}

 There are no issues at this time.



%###########################################################################
%###########################################################################
% INFORMATION DESCRIPTION                          INFORMATION DESCRIPTION %
%###########################################################################
%###########################################################################
%
%  This section provides a detailed description of the problem
%  that the software must solve.  
%
\section{Information Description}

Project planning, especially for large projects, can be a very time
consuming and error-prone activity.  Detailed lists of tasks and task
dependency information must be kept track of, and graphical displays
of the task information are often needed to display (in a very concise
manner) the relationships between the tasks.  For this reason a tool
like \xplan\/ is needed.

The information that the tool keeps track of is made up of a list of
tasks and their associated information (detailed in the introduction
to the document).  Each task may itself have a list of sub-tasks, and
each of the sub-tasks its own sub-tasks, the recursive structure
limited only by the memory of the machine.

%
% This section gives a high-level view of the information (data and
% control) flow.  
%
\subsection{Information Flow Representation}

%
% Give data flow diagram of high-level view of system: what are the
% external entities?
%
\subsubsection{Data Flow}

\begin{figure}
\centering
\centerline{\psfig{figure=l0dfd.ps,height=4in}}
\caption[Level 0 Data Flow Diagram of System]{\label{l0-dfd} 
Level 0 data flow diagram of system.}
\end{figure}

\begin{figure}
\centering
\centerline{\psfig{figure=l1dfd.ps,height=4in}}
\caption[Level 1 Data Flow Diagram of System]{\label{l1-dfd} 
Level 1 data flow diagram of system.}
\end{figure}

%
% Give control flow diagram of high-level view of system: what are the
% external entities?
%
\subsubsection{Control Flow}

\begin{figure}
\centering
\centerline{\psfig{figure=l0cfd.ps,height=4in}}
\caption[Level 0 Control Flow Diagram of System]{\label{l0-cfd} 
Level 0 control flow diagram of system.}
\end{figure}

\begin{figure}
\centering
\centerline{\psfig{figure=l1cfd.ps,height=4in}}
\caption[Level 1 Control Flow Diagram of System]{\label{l1-cfd} 
Level 1 control flow diagram of system.}
\end{figure}

\subsection{Information Content Representation}

The project planning tool will store the task information in a linear
form in the order that the user enters the tasks into the system.
Each entry in the list represents one task in the task list.  Each of
these tasks can then have a sub-task list off of itself.  During the
generation of PERT and Gantt charts, the task database will be copied
over into an intermediate form that is more amenable to sorting by
dependency.  This intermediate database will not be kept, and will
come and go as the user generates charts.  The dependency and
resources lists that each task has will also be linear structures.

%
%  This section describes the interfaces of the system in
%  terms of hardware, software, human interfaces.
%
\subsection{System Interface Description}

The project planning tool will require a Unix-based platform with an
ANSI C compiler, along with the X Windows system, and the XView
libraries.  A keyboard and three button mouse, along with a graphical
display, will be required for entry and viewing of task information.
Although a color display would be preferable (users find them more
desirable), it is not necessary, since there will be no inherent
meaning in the colors used on the information screens and generated
charts.

The task database will be stored to a human-readable ASCII text file.
This file can also be loaded into \xplan\/ to retrieve information for
tasks that had previously been entered into the system.  In addition,
the software has the ability of generating \LaTeX\ output files that
represent PERT and Gantt charts, along with task lists, which can then
later be used in a project planning document.

%###########################################################################%
%###########################################################################%
% FUNCTIONAL DESCRIPTION                             FUNCTIONAL DESCRIPTION %
%###########################################################################%
%###########################################################################%

%
%  This section describes the required functions needed for
%  solving the problem. 
%
\section{Functional Description}

The PERT/Gantt chart generator interacts with a project planner to a
create task list, generate the corresponding PERT and Gantt charts,
perform task analysis such as finding the critical path and time
calculation, and provide hard and soft copy output of the task list
and the resulting charts.  The interaction is done via a graphical
user interface (GUI) subsystem where the project planner can fill in
the information requested by the subsystem. The information is then
stored to the database to be processed by the database management
subsystem. The system can also accept information submitted by
file. In this case, the File subsystem will perform the necessary file
conversion so that the information can be used by other subsystems.
The program then will be able to generate PERT and/or Gantt charts
based on the project planner's request. The charts are then displayed
to the screen as a feedback mechanism to the planner. Since the
planner will not be able to modify the charts directly, modifications
must be done to the task list. The charts will then be adjusted
accordingly.  The planner might want to analyze the dependencies among
the tasks or the time flow of a given series of tasks. The planner can
send a request to the calculation subsystem which will highlight the
critical path along the task network or perform the necessary time
calculation.  On request of the planner, the program will provide
\LaTeX\ format output of the task lists along with the corresponding PERT
and Gantt charts.

%
%  This section gives a high level overview of the decomposition
%  of the system.
%
\subsection{Functional Partitioning}

The project is divided into 5 major subsystems:

\begin{enumerate}

\item {\bf GUI subsystem}\\
Provides the interaction with the project planner, handles user
requests or queries and acts as a ``command interpreter.''

\item {\bf File subsystem}\\
Handles operations involving reading and writing to a file such as
parsing the input file, converting the formats between file and the
database (involving syntax and lexical analysis), and writing to an
output file.

\item {\bf Calculation subsystem}\\
Performs calculation on the information stored in the database.  This
includes finding the critical path in the task network, and date
arithmetic.

\item {\bf \LaTeX\ generator subsystem}\\
Generates the \LaTeX\ format files that represent a task sheet, PERT
chart, and Gantt chart.

\item {\bf Database subsystem}\\
Performs general database functions such as adding  or deleting
information to/from the database, search for item(s) in the database,
and sorts the database by dependencies.

\end{enumerate}

%
%  This section contains a description of a single function 
%  identified in the partitioning section.  This section includes:
%     a) processing narrative
%     b) performance requirements
%     c) design constraints
%     d) supporting diagrams
%
%%%
%%% A FUNCTIONAL DESCRIPTION NEEDS TO BE HERE FOR EACH SUBSYSTEM
%%%

%===========================================================================
% GRAPHICAL USER INTERFACE SUBSYSTEM
%===========================================================================
\subsection{Graphical User Interface Subsystem}

The graphical user interface (GUI) subsystem provides the user a means
of access and modification of the information in the task database.
Descriptions of tasks and their dependencies are entered into the
\tiscreen\/ and from the resulting task database the user has options
of generating a task list, Gantt chart, or PERT chart, all of which
can be exported to a \LaTeX\ file for incorporation into other
documents.  The GUI focuses on the \pscreen\/ and \tiscreen\/ as
primary elements of filling the task database.

\subsubsection{Processing Narrative}

When the user starts \xplan\/ he/she begins at the \pscreen (see
figure~\ref{project-screen} on page~\pageref{project-screen}).  This
screen is used throughout the process of building a task database for
the project.  Initially the user will either want to start working
with a new project (which he/she can do immediately after starting the
program), or will want to load a previously saved project from disk.
File loading and saving is done through the {\em File}\/ menu (refer to
figure~\ref{file-menu} on page~\pageref{file-menu}.  If the user opts
for the second choice, the task list for the project they load will be
filled in on the \pscreen.

By double clicking on an item in the task list, the user brings up the
task information for the given task.  If the user would like to add a
new task to the database he/she selects an item off of the {\em
Insert}\/ menu, which has the effect of popping up the \tiscreen.  In
either case, the user can now modify the information for a task, and
then select the {\em Apply}\/ button to store the information back
into the task database.

The \tiscreen\/ contains fields for all of the information that
\xplan\/ stores and works with.  Most of the areas on the screen are
simple text fields that have no restrictions on what is entered.  Some
items, like the {\em milestone}\/ and {\em deliverable}\/ options are
check-boxes, which allow the user to specify a binary relation (i.e.\
it either is a milestone, or it isn't).  Once the user has modified
the displayed task information, the {\em Apply}\/ option can be chosen,
which then causes the window to be dismissed, and the task information
to be stored in the task database.

Once the user has built up a sufficient task list, he/she may want to
generate PERT and/or Gantt charts for graphical display within the
software system.  This is done by selecting the appropriate entry from
the {\em Chart}\/ menu (refer to figure~\ref{chart-menu} on 
page~\pageref{chart-menu}.  Once the user selects one of these two entries,
the software copies the task database over into a form that is more
amenable to dependency sorting and eventually the user is presented
with a graphical display of the chart they selected in a pop-up
window.  The pop-up window is complete with up/down and right/left
scroll-bars, so if the generated chart is too large for the pop-up
window to display at one time, the user may scroll through.  The PERT
and Gantt chart windows are both dismissed by ``un-pinning'' the
pop-up window from the desk-top.

Implicit in the process of generating the PERT and Gantt charts is the
action of checking the dependency lists of the tasks for dependency
loops.  If a loop is found, an error message is displayed, and the
information for the offending task at which the loop is noticed is
displayed in the \tiscreen.  If the user chooses to check for
dependency loops explicitly during the processing of building a
project database, he/she can select the {\em Check Dependencies}\/
option from the {\em Analyze}\/ menu (figure~\ref{analyze-menu},
page~\pageref{analyze-menu}).  Also available on the {\em Analyze}\/
menu is an option to find the critical path in the task network, and
an option calculate the earliest/latest start and end dates along with
the float time for the task.

The {\em Export}\/ menu (figure~\ref{export-menu},
page~\pageref{export-menu}) of the \tiscreen\/ is used to generate
\LaTeX\ files that represent task sheets and both PERT and Gantt
charts.  The generated files can then be included in project planning
documents.  The {\em Options...}\/ item of the {\em Export}\/ menu is
used to select the directory and file name that the exported \LaTeX\
commands are to be stored to.

\subsubsection{Performance Requirements}

Due to the fact that the GUI is interactive and must have a user
controlling it, the performance is important.  Unlike batch systems in
which there is no interaction, and long response delays and processing
delays are normal and expected, long response delays in an interactive
system can have very damaging effects.  The user may be so turned off
by the response of the system that he/she decides not to use it any
longer.  On the other hand, unlike real-time software, immediate
(instantaneous) response is not, in general, required.

For these reasons, the performance requirements we are setting for the
user interface are that it give {\em reasonable}\/ response in all
conditions.  In this context, reasonable would mean a maximum 2
second delay for menu selection, a maximum 5 second delay for popping
up a window, and a delay of up to 5 seconds for each hundred tasks
when generating PERT and Gantt charts (interactively displayed, or
written to \LaTeX\ files).

\subsubsection{Design Constraints}

The user interface will have to be designed in such a way that windows
like the task information screen can be displayed several times at
once for different tasks.  In general, since at any given time several
screens of different types can be displayed, this has to be taken into
consideration.

\subsubsection{Supporting Diagrams}

\begin{figure}
\centering
\centerline{\psfig{figure=file-menu.ps,height=1in}}
\caption[File Menu]{\label{file-menu} 
The {\em File}\/ menu of the \pscreen.}
\end{figure}

\begin{figure}
\centering
\centerline{\psfig{figure=chart-menu.ps,height=1in}}
\caption[Chart Menu]{\label{chart-menu} 
The {\em Chart}\/ menu of the \pscreen.}
\end{figure}

\begin{figure}
\centering
\centerline{\psfig{figure=analyze-menu.ps,height=1in}}
\caption[Analyze Menu]{\label{analyze-menu} 
The {\em Analyze}\/ menu of the \pscreen.}
\end{figure}

\begin{figure}
\centering
\centerline{\psfig{figure=export-menu.ps,height=1in}}
\caption[Export Menu]{\label{export-menu} 
The {\em Export}\/ menu of the \pscreen.}
\end{figure}

%===========================================================================
% FILE READ/WRITE SUBSYSTEM
%===========================================================================
\subsection{File Subsystem}

The file subsystem performs functions to load and save project files.
The data transferred during loading will be inserted into the proper
internal structures and stored into the database using the database
subsystem.  Similarly, during a file save the data will be dumped from
the internal structures into the format of the file.

\subsubsection{Processing Narrative}

When the read/write function is invoked the user will specify the type
of processing that is to take place. A file that is to be read could
have been previously generated by the project planning tool, or could
be generated from another program or a person typing directly into an
ASCII file, provided that the file structure is correct.  When reading
the data, the control will come from the the database and into a
format function, then to the read function. The read is then invoked
from the directory and file specified by the user. The data is then
read, formatted, and put into the database. When the write is invoked,
then database will send data to a format function, where the data will
be formatted in a way that will be easy to read from the read
function. Then the format function will invoke the write function.
Here the file specified by the user, whether a new or old file, will
be created, and the formatted data will put in. The files will be read
and written to in a sequential manner.

\subsubsection{Performance Requirements}

The performance of the read/write function will be determined by the
size of the file. Usually the process will take between 1 and 10
seconds if the user is using a Sun SPARCstation 2. If the user is
using a SPARCstation 1 (or 1+) then the routine should take between
1-15 seconds. The data within the database will be formatted in a way
that will maximize efficiency. This means that the actual read/write
from the file will not be from the data structures within the
program. A buffer will be created for this purpose. The read and write
functions will read and write to the specified files in a sequential
manner, which will save processing time.

\subsubsection{Design Constraints}

The user will only be able to work with one database at a time. This
means that if the user tries to read in another file while he/she is
currently working with one, the user will be prompted to save the
current project and load the new one, or to just load the new one.
The file written by the subsystem can only be as large as the disk
being written to, and the quota of the user that is using the tool.
If the user creates a file with another tool or source, then
the only way that the read function will be able to read it is if the
file has the same format as what the program creates. If a file
currently exists and the user specifies a save, the user will be
prompted on whether they would like to replace the file on disk.

\subsubsection{Supporting Diagrams}

\begin{figure}
\centering
\centerline{\psfig{figure=l2dfdfile.ps,height=4in}}
\caption[Data Flow Diagram of File Subsystem]{\label{file-dfd} 
A data flow diagram of the file subsystem.}
\end{figure}

\begin{figure}
\centering
\centerline{\psfig{figure=l2cfdfile.ps,height=4in}}
\caption[Control Flow Diagram of File Subsystem]{\label{file-cfd} 
A control flow diagram of the file subsystem.}
\end{figure}

%===========================================================================
% CALCULATION SUBSYSTEM
%===========================================================================
\subsection{Calculation Subsystem}

The Calculation subsystem will perform three user commands sent via
GUI subsystem. Those commands are:
\begin{enumerate}
\item Find critical path
\item Check for dependency loops
\item Fill earliest/latest date
\end{enumerate}

Each of those three commands is handled by another subsubsystem within
the {\em Calculation}\/ subsystem. The {\em calculate critical path}\/
subsubsystem will find the critical path along the task network and
highlight that particular path.  The {\em dependency checking}\/
subsubsystem will check the database information for loops within the
task network. It will notify the user (via GUI subsystem) about the
existence dependency loop, and show where the loop appears in the
network.  The {\em date calculation}\/ subsubsystem will generate the
earliest/latest start/end dates for a given task, along with the
duration (if necessary) and float time.  The calculated dates are then
stored back into the database.
 
The three tasks above require the {\em calculation}\/ subsystem to
access the data stored in the database. So one function supported by
the {\em calculation}\/ subsystem is to get database information. This
information is then used by the above three subsubsystems to perform
the corresponding commands.

On request of the user, the data is sent to {\em generate display info}\/
subsubsystem.  As the name suggests, {\em generate display info}\/ will
transform the data into a chart format and send the chart to GUI or
\LaTeX\ generator subsystem.  This will require the calculation of
screen and/or paper position and layout.

\subsubsection{Processing Narrative}

{\bf {\em Interpret command}\/ subsubsystem}\\
This subsubsystem will communicate with GUI subsystem with a specific
command format. The format to be used will be determined later in the
design phase.  When the user wants to perform a calculation, GUI
subsystem will enscript the command as a {\em value}. This value is
then sent to Calculation subsystem.  The interpret-command
subsubsystem will interpret this value, and invoke the necessary
functions to perform the given command.

{\bf {\em Get database info}\/ subsubsystem}\\
This subsubsystem will communicate with database function subsystem,
in order to get the information out from the database. The information
is then transferred to other subsubsystem that requires them.

{\bf {\em Calculate critical path}, {\em check dependencies}, {\em
calculate date info}\/ subsubsystems}\\
These three subsubsystems will perform the calculation needed for each
of the user commands. This will involve dealing with several graph
algorithms and dates manipulation. The algorithm is decided later at
the design phase.

{\bf {\em Generate display info}\/ subsubsystem}\\
This subsubsystem will convert the database information into format
that can be displayed to the screen, or used with other \LaTeX\
document. This involve calculating the position of the chart on the
screen, as well as on \LaTeX\ document. The resulting chart data is
either passed to GUI subsystem to be displayed, or to \LaTeX\
generator subsystem to be modified into \LaTeX\ format.

\subsubsection{Performance Requirements}

Performance is based on running \xplan\/ on SPARCstation 2 on top of
OpenWindow, with no other application running.  The calculation of
critical path will take approximately 5 seconds for each 100 subtasks
in the task network.  The calculation for dependency loops will take
approximately 5 seconds for each 100 edges in the task network.  The
calculation of dates will take approximately 10 seconds for each 100
subtasks in the network. Generating the information for display will
take approximately 10 seconds for each 100 subtasks in the network.

\subsubsection{Design Constraints}

The subsystem can only perform one calculation at a time, since the
calculation might involve modifing/updating the database. The
calculation time is also depend on the complexity of the task network.
The time complexity could run in exponential order compare to the
number of tasks, for a complex network.  The resulting chart
information must also conform with what the \LaTeX\ can generate. For
example, we could only draw items that can be displayed in \LaTeX\
format.

\subsubsection{Supporting Diagrams}

\begin{figure}
\centering
\centerline{\psfig{figure=l2dfdcalc.ps,height=4in}}
\caption[Data Flow Diagram of Calculation Subsystem]{\label{calc-dfd} 
A data flow diagram of the calculation subsystem.}
\end{figure}

%===========================================================================
% LaTeX GENERATION SUBSYSTEM
%===========================================================================
\subsection{\LaTeX\ Generation Subsystem}

The \LaTeX\ generation subsystem will generate a \LaTeX\ file for the
user to use in his/her documentation, or for printing out. The
subsystem will generate task sheets, PERT charts, and Gantt charts.
Information on chart layout will be retrieved from the calculation
subsystem.  The output from the function as a whole will be the
\LaTeX\ file in the directory and names specified by the user.

\subsubsection{Processing Narrative}

From the calculations, the function will need the file name, the type
of chart that is to be printed, the locations of the boxes and lines
connecting them (For PERT charts only), the times that will be
displayed, the task description, the tasks that are deliverables or
milestones, and the dates. These calculations will be transferred to
the chart descriptions and dimensions functions. This function will
formulate what path to take in order to generate the correct chart.
The calculations are put into a form that is easily transferable so
the next function can determine the format of the \LaTeX\ file. There
are three different functions in determining the format for the
\LaTeX\ file. The PERT function, Gantt function, and the task sheet
function, will set up a buffer that is in the correct \LaTeX\ format
for each chart. These three functions will use hard coded \LaTeX\
formats. The boxes on the PERT chart format will all be the same size
and will include the task description and the begin and end dates for
that task. The boxes will be connected with a line. The milestones
will be labeled as diamond shaped characters on the chart. The
critical path will be determined by the thickness of the lines that
connect the boxes. The Gantt charts will include the task on the side
of the sheet, and thick lines that determine the duration of the
tasks. The milestones will be labeled in a similar fashion as the PERT
charts, with a smaller diamond. The time scale will be listed at the
top of the charts. The task sheet will include the task descriptions,
the start and end dates, the durations, and the resources.

\subsubsection{Performance Requirements}

The efficiency for this function will me maximized in the format stage
of the generated \LaTeX\ file, because of the hard coded formats of each
\LaTeX\ entity that will be used. The whole process, on the other hand
will take approximately 10 seconds for each hundred tasks in the task
list (assuming a SPARCstation 2 is being used). If the user is using a
SPARCstation 1 then the performance will go down and the time will go
up to approximately 12 seconds for each hundred tasks. 

\subsubsection{Design Constraints}

The program will only create a \LaTeX\ file for the user to print, so
the user can incorporate documentation of his/her own choice into the
file.  This also saves the tool from invoking the {\tt latex} command
and sending the file to the printer. The format functions will use
hard coded \LaTeX\ commands that will be used to build the file. With
the program only building the \LaTeX\ file, the user must invoke the
{\tt latex} and {\tt dvips} commands to print the output. A ``.tex''
will be added to the end of the file that the user specifies.
This will allow the user to select any name for the generated \LaTeX\
file.

\subsubsection{Supporting Diagrams}

\begin{figure}
\centering
\centerline{\psfig{figure=l2dfdlatex.ps,height=4in}}
\caption[Data Flow Diagram of \LaTeX\ Subsystem]{\label{latex-dfd} 
A data flow diagram of the calculation subsystem.}
\end{figure}

\begin{figure}
\centering
\centerline{\psfig{figure=l2cfdlatex.ps,height=4in}}
\caption[Control Flow Diagram of \LaTeX\ Subsystem]{\label{latex-cfd} 
A control flow diagram of the calculation subsystem.}
\end{figure}

%===========================================================================
% DATABASE SUBSYSTEM
%===========================================================================
\subsection{Database Subsystem}

\subsubsection{Processing Narrative}

The project planning tool will store all of its runtime data for the
project being planned in a main memory database.  There are two ways of
filling the database with data.  The first is for the user
to use the graphical user interface to fill in task information
screens for the tasks, and the other is to use the file load function
to load the data from a file.  Storage will be dynamically allocated,
so the tool will be limited only by the amount of available memory in the
machine.

The data items stored in the database are graphically represented in
figure~\ref{dbblockdiag} on page~\pageref{dbblockdiag}. Only one
project can be loaded into our software at a time.  Referring to
figure~\ref{dbblockdiag} each task will have a variety of information
associated with it.  The main items are the dates, options, duration
and float times, name, dependencies, sub-tasks, resources, and
description of the task.  The various planned, actual, forecast,
earliest, and latest start and end dates will be specified for a
particular task.  Also, options of labeling the task a milestone or
deliverable are for marking the importance of the particular task.
The user may specify a text description of the task in their own
words.  The dependencies is a list of other tasks which the particular
task absolutely needs to have done, before it is possible to do or
complete.  A list of sub-tasks may be listed for a particular task, so
the user may specify how to divide the work of the particular task.  A
list of resources is also provided, so the user can specify the tools
and people that are needed for working on the particular task.

\subsubsection{Performance Requirements}

Database retrieval and storage will have to be very quick since the
database subsystem is the heart of the tool.  All of the other systems
use it extensively.  Storage and retrieval will then have to be close
to instantaneous, with no noticeable delay time.

\subsubsection{Design Constraints}

The major design constraints for the database system include only
being able to have one file loaded at a time, and being limited to the
amount of memory in the machine. 

\subsubsection{Supporting Diagrams}

\begin{figure}
\centering
\centerline{\psfig{figure=dbblockdiag.ps,height=4in}}
\caption[Block Diagram of Data Elements]{\label{dbblockdiag} A
block diagram of data elements and their relationships.}
\end{figure}

\begin{figure}
\centering
\centerline{\psfig{figure=l2dfddb.ps,height=4in}}
\caption[Data flow Diagram of Database Subsystem]{\label{db-dfd} 
A data flow diagram of the database subsystem.}
\end{figure}

%===========================================================================
% END OF FUNCTIONAL DESCRIPTIONS OF SUBSYSTEMS
%===========================================================================

\subsection{Control Description}

\subsubsection{Control Specification}

The program control is always start from the project screen. The project
screen will then transfer the flow of control to other states depending
on the user commands. Each states will then return the control back to
the project screen. So technically the project screen acts as a control
driver for the whole project. Some of the states will require an error-checking
procedure. In this case, the control is passed to the Error message state (for
notifying the user about the error), and then the control is transferred back
to the calling state.

\begin{figure}
\centering
\centerline{\psfig{figure=sysstates.ps,height=4in}}
\caption[State Transition Diagram]{\label{sysstates} 
A state transition diagram of the entire system.}
\end{figure}

\subsubsection{Design Constraints}

Since the main control is at the Project screen, the user will not be able
to give a command from system prompt for example.

%###########################################################################
%###########################################################################
% BEHAVIORAL DESCRIPTION                            BEHAVIORAL DESCRIPTION %
%###########################################################################
%###########################################################################

%
%  This section describes the system in terms of how the system
%  reacts to external events and internally generated control
%  characteristics.
%
\section{Behavioral Description}

The system, when started up, will display a Project screen (Task
screen). This will be the main screen that the user will be working
from. From this screen, the user will have the options to save and
read from a file, display PERT and Gantt charts, analyze data by
finding the critical path, and checking the dependencies of the tasks.
The user will also be able to create \LaTeX\ files containing PERT and
Gantt charts and a Task sheet. These functions will appear on the
Project screen as button menus. An insert and edit button are also
displayed on this screen. The edit button will allow the user to cut,
copy, paste, and delete any task that is shone in the task list. These
functions will be invoked by the user when the button or specific
button menu item is chosen. When the insert button is pressed, the
options will be to insert a task before, after, top, or bottom of the
list. In any case, when an insert button menu item is selected, a task
information screen will appear. Within this screen, the user has the
options to enter a task name, enter a task description, enter the
start and end planned, actual, forecasted, earliest, and latest dates.
The user can also enter in float and duration times, and check if the
task is a milestone or deliverable. The \tiscreen\/ also
has buttons for the user to enter in the dependencies, subtasks, and
resources for the main task. If the user pushes the dependencies
button, a dependencies screen will pop up so the user can type in the
dependencies for that task. If the user pushes the resources button,
then a resource screen will appear that will hold a list of all of the
resources within that task. If the user pushes the subtask button, a
pop-up screen containing the list subtasks will appear. Within this
subtask screen, the user will be able to create a list of subtask and
create subtasks under subtasks for how ever many level that the user
wants. A subtask information screen will be used to input the
information. Each subtask will have the same elements used as the main
task information sheet. Now, from the main task sheet, if the user
presses the button {\em Apply}\/ then the task will be entered into the
task list, the screen that is started when the program is initialized.
The same procedure is done for the subtasks, although the subtask will
not show up in the main task sheet. Just the main tasks will show up
here. The subtasks will show up in the subtasks list for a given
tasks. The reset button on the task and subtask list will bring the
information that was previously stored within that task or subtask.
When the user is finished with the application he/she will exit the
program from the quit function on the menu from the top of the
application.

\subsection{System States}

Within the state diagram, there is a \pscreen\/ state, {\em file
save}\/ state, {\em error on file save}\/ state, {\em display PERT and
Gantt chart}\/ state, {\em store \LaTeX\ file}\/ state, {\em initiate
calculations}\/ state, \tiscreen\/ state, {\em sub-task list}\/ state
(which comes from the \tiscreen\/ state), {\em file load}\/ state, and 
corresponding {\em error on file load}\/ state.  Refer to
figure~\ref{sysstates} on page~\pageref{sysstates}.

\subsection{Events and Actions}

The main state is the Project Screen state. From this state there are
the file save state, Display PERT or Gantt chart state, file load
state, save latex file state, initiate calculations state, Task
information entry screen state and the sub-task list. The file save
state will save the file to the disk. From this state there is an
error state. The error state will display a message if there are any
problems with the file save state. The Display PERT and Gantt chart
state will display the PERT and Gantt chart from within the user
interface. The Save Latex file state will figure out what chart the
user wants to create and create them using a latex format in the file
specified by the user. The initiate Calculations state will calculate
the critical path, dates, and dependencies. The task information entry
state will pop up a screen to allow the user to enter the task
information. This task information will include the task description,
dates, milestones, deliverables, resources, and all other subtask that
apply to the task. The subtask is used like a main task sheet in that
it holds all of the same properties, but is labeled under a main task.

%###########################################################################
%###########################################################################
% VALIDATION CRITERIA                                  VALIDATION CRITERIA %
%###########################################################################
%###########################################################################

%
%  This section describes the criteria to be used to determine
%  that the system is what the user expected and the criteria
%  to be used to determine that the system works.
%
\section{Validation Criteria}

The validation section of the program will involve certain tests that
will insure its correctness. One way that will be used to validate the
project is to use the same data from what was used in processing the
PERT and Gantt charts from MS-Project for our own project. The
critical path, PERT and Gantt charts, and task sheet will be checked
for similarity with the output of MS-Project.  Another method that the
program will be validated with is branch testing of individual
modules.  The test cases for the branch testing technique will involve
dividing the number of ways that the program will go through the code.
For example, If there was an if, else if, else if, structure there
will involve three test cases that go through every branch of the
program. If every branch of the program works, then the program can
declared valid. Finally, another way to insure the validity of the
program is to build test cases that run through every line of code in
the program.  These forms of testing and validation are part of the
unit tests. From the unit test there must be a system test, where
testing is on the performance of the machine that your running the
program on and how this program will work within certain environments
within the system.

\subsection{Performance Bounds}

Since the project planning tool software for creating, editing,
storing, and displaying the project information is graphically
oriented, the main limitation on performance will be the size of the
task list.  As the size of the task list increases, so too will the
time required for the display of the generated charts. File reading
and witting of ASCII text files will also depend on their size for the
amount of time necessary.  It will take longer to format a \LaTeX\
file than an ASCII text file for large charts, because of the
\LaTeX\ commands and formats which must also be inserted.  The
graphical user interface part of our software will operate on events
generated by the user. It is very important to note that issues such
as external system load, machine configuration, and hardware resources
will affect the performance time of our software for very large
PERT/Gantt charts.  Basically, a linear relationship between size and
time is assumed in describing performance time required for
calculations and displays of the PERT/Gantt charts.

\subsection{Expected Software Response}

The project planning tool software will respond to user commands in
real time.  For example, pressing ``edit'' will allow the user to edit
a task.  The pop up windows will also be labeled.  The Graphical User
Interface will also provide online help for first time users who are
unfamiliar with our Project Planning Tool.  Since the GUI was built
with the Guide 3.0 tools, the help facility we incorporate online will
function the way Guide 3.0 tools builds help menus to work.  Pop up
windows will be displayed when requested to get help, and then
dismissed by the user when no longer necessary.  Since the Project
Planning Tool software is graphical and menu oriented, it will be
simple to use with a keyboard for typing data, and a 3 button mouse
for pointing and clicking on the GUI control buttons.  The button
functions on the mouse will be explained for each window as necessary
when the window pops up.

When the mouse clicks on a control button or menu item, that item will
be highlighted for the user.  When ``save'' features are used to write
to a file, a pop up window will be displayed to ask the user to
confirm their choice to save, so that existing files will not be
accidentally overwritten.  When windows are no longer desired for
viewing, the ``quit'' button can be clicked with the mouse to dismiss
them.  In addition to input of PERT/Gantt chart tasks and information
from the keyboard, the user may specify an ASCII text file for input
data.  Also, when a Project Planing Tool session is completed, the
user may save the PERT / Gantt chart information to an ASCII file for
later input to the software, or input into another software package.
Also, the \LaTeX\ file format may be chosen, so that the information
developed and displayed by the use of the Project Planning Tool
software may be incorporated into the \LaTeX\ document processing
system.  \LaTeX\ was chosen as an output format because of its wide
availability, popular usage, and low cost for integration of our
software into a total project planing document environment.

The response to user commands will be in proportion to the amount of
data that needs to be manipulated by the Project Planning Tool.  For
example, menu and control windows will respond quickly to user
commands within 2 or 3 seconds.  However, the graphical display of
PERT / Gantt charts to the graphics display terminal may take longer
for PERT/Gantt charts with large numbers of tasks and subtasks.
However, our software will be robust and fault tolerant.  Thus, if a
user attempts to input a chart that exceeds the memory limits of a SPARC 1
or 2, then our software will avoid catastrophic failure, and will
display a pop up window explaining an error message to the user.
After clicking with the mouse to dismiss the error pop up window, the
user may select another ASCII text file for input, or resume
interactive data input through the graphical user interface.  The
Project Planning Tool software will incorporate as many software
features as possible to avoid catastrophic failure and system
deadlock.  For example, if faulty data which does not match the
specified format of Project Planning Tool ASCII text file input data
is attempted to be loaded, an appropriate error window will be
displayed, and the user may continue working.

If for some reason a calculation error such as memory overflow occurs,
an error window will be displayed explaining that the PERT /Gantt
chart calculations were terminated due to error. Basically, the goal
of the fault tolerant portion of our software is to avoid catastrophic
failures which could be caused by our Project Planning Tool software
operation and performance.  However, if some error external to our
software should occur, our software is not guaranteed to operate under
external system, or machine errors.

Furthermore, it should be noted that as the number of tasks in the
PERT / Gantt charts increases, the time required for processing the
calculations of dependencies and other analysis functions will
increase.  Also, it will take more time to display very large charts
to the graphics terminal.  These time features will be dependent on
the operation of the X Windows environment running under the Unix
operating system on the SPARC 1 and 2s.  Other factors such as system
load and machine configuration external to the Project Planning Tool
software may also increase the required operations time.

Finally, vertical and horizontal scroll bars will be provided for
users to view PERT/Gantt charts which are to large to display in
their entirety on the graphics terminal.  Also, all of the PERT/Gantt
charts will be drawn and displayed by the Project Planning Tool
software.  The only interaction the user will have with the
graphically displayed charts will be to display them, interact with
the GUI to edit tasks from the keyboard, refresh the charts display,
scroll in horizontal and vertical directions if necessary, and
terminate the display of a chart.  Both PERT and Gantt charts may be
displayed at the same time, but it that will slow the time required
for calculations and displays of large PERT/Gantt Charts.  If the user
wants to hand edit ASCII text, or \LaTeX\ file, they will have to do
that outside of our software.

\subsection{Special Considerations}

The validation of the software project will consume a large amount of
time. This is because the the program used a variety of GUI screens.
So the person validating the software will have to enable all of the
screens, and type in text into the correct fields for all of the
possible fields. This process of validation will involve test cases
that are used to break the program. In these cases, the software will
have to take into account for that bad data and should not crash.
data.

%###########################################################################
%###########################################################################
% SPECIAL ISSUES                                            SPECIAL ISSUES %
%###########################################################################
%###########################################################################
\section{Special Issues}

None at this time.

%###########################################################################
%###########################################################################
% REFERENCES                                                    REFERENCES %
%###########################################################################
%###########################################################################
\appendix
\newpage               % start a new page for bibliography, etc.
\section{References}

\bibliographystyle{plain}
\bibliography{req-spec}

\end{document}
