[ghetto-software] Requirements Definition, draft 1
- From: Damian Christey <damian@xxxxxxxxxxxx>
- To: ghetto-software@xxxxxxxxxxxxx
- Date: Wed, 10 Mar 2004 16:42:17 -0500
Here is what we have so far, in LaTeX and PDF formats. Sorry it took so
long, my TeX-fu is not very strong.
Feel free to make changes, fill in missing sections, correct any errors
you see, etc...
Please send your changes to the list by 10:00PM tonight, so I can merge
them and add my own.
%% LyX 1.3 created this file. For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[12pt,oneside,english]{book}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\setcounter{secnumdepth}{3}
\setcounter{tocdepth}{3}
\usepackage{varioref}
\usepackage{setspace}
\onehalfspacing
\makeatletter
\usepackage{babel}
\makeatother
\begin{document}
\title{Requirements Definition}
\author{by Ghetto Software, Inc.%
\footnote{Ghetto Software Core Team is: Nathan E. Moore, Cord Cornell Scott,
Vicki Faulkner, B. Lee Adamson, Damian Christey%
}}
\maketitle
\tableofcontents{}
\part{Introduction}
\chapter{Purpose}
The purpose of this document, \char`\"{}Requirements Definition\char`\"{},
is to clarify the requirements as stated to Ghetto Software Inc. by
the client Operations Manager Greg Mundy for the West Virginia International
Airport. This document will be the foundation for development of Clear
Skys 1.0. The intended audience for this document are those stakeholders
and owners of West Virginia International Airport. This will give
WV International Airport an opportunity to clarify and ambiguous requirements
and to correct any mistakes made on our part regarding the functionality
of this system.
\chapter{Scope}
\section{Product name}
The product being developed by Ghetto-Software Inc. is called Clear
Skys 1.0.%
\footnote{Yes, we spelled \char`\"{}skies\char`\"{} wrong on purpose.%
}
\section{What it will/will not do}
The purpose of this software support system is to replace an existing
software system at West Virginia International Airport which has been
in existence for fifteen years. The current system in place supports:
safety, security, efficiency, and compliance with FAA rules of the
Airport.
The new system will consist of four major subsystems: Air Space Manager,
Ground Operations Manager, Gate and Schedule Manager, Emergency Management.
This software, at a minimum, will: handle the simultaneous takeoff
and departure schedules of multiple aircrafts, administer gate and
runway assignments for aircrafts, provide an interface for a variety
of users to view different types of information about aircraft schedules,
and facilitate landing of unscheduled aircrafts in emergencies.
\section{Benefits, objectives, and goals}
\chapter{Definitions/Abbreviations}
\begin{description}
\item [AMS:]Airspace Management System
\item [ATC:]Air Traffic Controller
\item [EMS:]Emergency Management System
\item [FAA:]Federal Aviation Administration
\item [IEEE:]Institute of Electrical and Electronics Engineers
\item [TRACON:]Terminal radar approach control
\item [WVIA:]West Virginia International Airport
\end{description}
(more to be added as document develops)
\chapter{References}
See Bibliography.\vpageref{bibliography}
\chapter{Overview}
Part II of this document, entitled General Description, will place
Clear Skys 1.0 in perspective with regard to integration of other
systems. Part II will describe how the system will be developed and
the intended installation method. It will provide a list of functions
of the four major subsystems defined in this document. It will describe
the intended user with regards to education level, experience, technical
expertise, and user training. It will define the general constraints
as put forth by the customer WVIA, which will limit the design/implementation
of the system including: regulatory policies, hardware limitations,
and interfaces to other applications. The General Description segment
will also assess and evaluate risk and interdependency with external
systems/sources.
\part{General Description}
\chapter{Perspective}
\section{The big picture}
Our product, Clear Skys, is intended to be an integrated part of a
complete airport management system. Consequentially, it must interface
with other systems within and outside of the airport, as well as with
a variety of end users. In this section we will outline what those
interfaces are, and what type information will be passed across them.
\section{User interfaces}
\begin{itemize}
\item Air Traffic Controller (ATC) interface: This graphical interface will
simplify the tasks of the air traffic controllers by bringing information
from many different sources together. The main screen will show the
real-time output of the radar system. All planes in the airspace will
be represented by icons. Selecting a plane icon will bring up information
from our Airspace Management System and Scheduling System that will
include flight number, TRACON flight ticket, and scheduled landing
time. Weather information will be shown in real-time. When the Airspace
Management System detects that a plane is clear to land or takeoff,
its icon will be highlighted in the radar window and the ATC will
be prompted to establish radio communication with the plane. If the
AMS detects that two planes' flight paths conflict, the ATC interface
will show recommended corrective actions and automatically establish
radio contact with both planes. Any alerts from the Emergency Management
System will be displayed on the ATC interface, so that they can send
warnings to aircrafts.
\item Ground Operations interface: This graphical interface will mainly
show information from the Scheduling System, in order to facilitate
the assignment of ground crews to arriving flights. The interface
will likely be a table of gates and scheduled arrival times, updated
in real-time. The ground operations manager will also be responsible
for updating the status of planes as they arrive and depart. Alerts
from the Emergency Management System will be displayed on the Ground
Operations interface, so that fire/rescue crews can be deployed if
necessary.
\item Gate interface: These computerized displays will be the passengers'
primary source of information at the airport. Up to the minute information
displayed at each gate will include flight numbers, scheduled arrival
times, flights already arrived/departed, and any delays. A central
display will direct passengers to the correct gates.
\item Web interface: This will be a simple interface for passengers and
their families to get up to the minute information about flights,
arrival and departure times, and any delays. Information will be looked
up by flight number. Links will be provided to weather services.
\end{itemize}
\section{Other Components}
\begin{itemize}
\item Radar: The airport has a radar system onsite, to which we have been
told there is a software interface. Coordinate data for all planes
within range of the radar will feed into our Airspace Management System
and also directly to the air traffic controller interface.
\item TRACON: Our Airspace Management System will have continuous two-way
communication with TRACON using its flight strip protocol. As planes
enter the airspace, the AMS will receive the flight strip data from
TRACON, and will pass on an updated flight strip as the plane leaves
the airspace.
\item FAA: When a new flight is added through the Schedule Manager, the
system will contact the FAA to verify the flight plan, and receive
the information to generate a flight strip, which is then passed on
to the Airspace Management System upon takeoff.
\item Weather: Weather data is freely available from several online sources.
This data will be analyzed by our Emergency Management System, which
will generate alerts in the case of severe weather which would affect
normal airport operations. Weather data is also streamed to the Air
Traffic Controller interface.
\item Planes: All communication between air traffic controllers and planes
will be by radio. Our system will try to simplify communications with
planes, by interfacing to software controlled two-way radio hardware,
so that air traffic controllers can {}``point and click'' to contact
a plane.
\end{itemize}
\chapter{System Evolution}
\section{Life cycle model}
The system will be brought into affect using a modified linear sequential
model. Due to the inherent risks involved with the problem an incremental
or component based approach lacked practicality.
\section{Installation method}
Modularity of each subsystem is still a priority as each will be deployed
for parallel testing along side the current system sequentially to
minimize risks and increase the comprehensiveness of testing. This
style of deployment will ease integration issues while the subsystems
are installed individually.
Modules are to be developed separately each following the linear-sequential
model until deployment. In this situation it is crucial that the
responsibilities
of the current system are not immediately handed off to the new system.
Parallel testing will ensure that all functionalities are present
before final installation occurs.
\chapter{Functions}
\section{Airspace functions}
\begin{description}
\item [clear\_for\_takeoff]This function takes into consideration the states
of runways and locations of other planes and gives the air traffic
control staff notice that another flight is clear to take off.
\item [clear\_for\_landing]This function takes into consideration the states
of runways and locations of other planes and gives the air traffic
control staff notice that another flight is clear to land.
\item [send\_to\_FAA]Function for communication with the FAA. This allows
the flight plans and other pertinent data to be filed with the FAA.
\item [get\_from\_FAA]Function for communication with the FAA. This allows
data from the FAA to be received by the system and its users.
\item [get\_radar]This is the systems interface with the existing radar
system. The Radar data is processed for internal system usage. This
is a prerequisite function for flight tracking and is used by other
internal and external sources.
\item [get\_weather]This function is for the acquisition of weather related
data from the national weather service. This relies on externally
available services from the NWS.
\item [hold\_flight]This function makes recommendation to send a flight
into a holding pattern. This is a system recommendation function to
limit the risks of collision and other incidents. The actual final
decision as always will be made by the ATC staff.
\item [get\_flight\_ticket]The flight ticket is acquired for each flight
as the plane enters the airports airspace. This service relies on
the TRACON system.
\item [increment\_flight\_ticket]The flight ticket is passed on for each
flight as the plane leaves the airport's airspace. This service relies
on the TRACON system.
\item [near\_collision\_check]The purpose of this function is to check
for appropriate spacing between flights. If this spacing is compromised
the system will give notice to the ATC staff and offer a recommendation
to solve the problem. The actual final decision as always will be
made by the ATC staff.
\end{description}
\section{Ground functions}
\begin{description}
\item [gate\_clear]Checks the status of a gate to see if it clear or not.
Also determines if the gate is usable based on scheduling requirements.
\item [assign\_gate]The system will assign a gate to each flight based
on flight-specific requirements and scheduling needs.
\item [runway\_clear]Reports the status of a runway. Indicates usage by
flights and also closures due to emergencies or weather.
\item [clear\_runway]Initiates a system recommendation to clear the runway
for emergencies and other incidents. Relies on communication with
Emergency Management Subsystem. Allows for prioritized usage of the
runway for emergency purposes. The function also communicates these
needs to the scheduling subsystem.
\item [clear\_taxiway]Initiates a system recommendation to clear the taxiway
for emergencies and other incidents. Relies on communication with
Emergency Management Subsystem. Allows for prioritized usage of the
taxiway for emergency purposes. The function also communicates these
needs to the scheduling subsystem.
\item [clear\_gate]Reserves a gate for flights with emergency or priority
status.
\item [plane\_has\_arrived]This is a function designed to check the status
of the flight by indicating whether or not the plane has landed.
\item [plane\_has\_departed]This is a function designed to check the status
of the flight by indicating whether or not the plane has taken off.
\end{description}
\section{Scheduling functions}
\begin{description}
\item [add\_flight]This adds a flight to the schedule.
\item [delete\_flight]This Removes a flight from the schedule.
\item [update\_schedule]This functions always for the modification of the
schedule due to delays and other unforeseen factors. This may also
include weather- related problems and emergencies.
\item [update\_webserver]This allows for the web interface portion of the
system to be updated with new information.
\item [update\_log]This function adds any new information to the airports
flight log database.
\item [search\_log]Function allows access to the flight log database at
such times when this information is required.
\item [freeze\_schedule]This is dependent on other internal functions contained
in the EMS. All flights on the schedule can be frozen in times of
emergency or other incidents.
\item [reset\_schedule]Resets the schedule manager after a schedule freeze.
\end{description}
\section{Emergency functions}
\begin{description}
\item [hold\_all\_flights]In the case of an emergency the system enable
all flights to be held on the ground. Integration with the other subsystems
allows for efficient management of emergencies.
\item [reset\_all\_flights]This functions is integrated with other internal
functions in the other subsystem to allow a smooth reactivation of
airport activities follow an incident.
\item [emergency\_landing]In the case that a flight requests an emergency
landing this functions will allocate airport resources for that flight.
This involves the clearing of runways, activation of the hold flight
functions, and enabling functions in other subsystems to update the
schedule and clear runways and gates.
\end{description}
\chapter{User Characteristics}
\section{Organization}
(Note: Add relational diagrams? before finish draft)
\section{Technical expertise, experience, level of education}
There are two groups that will require training on the new system.
\begin{enumerate}
\item Systems Technical \& Support Personnel
\begin{enumerate}
\item Needs a minimum Associate Degree, Bachelor's preferred, Computer Science
or Information Systems.
\item Knowledge of Hardware maintenance recommended.
\end{enumerate}
\item Air Traffic Control Personnel
\begin{enumerate}
\item required a minimum of a Bachelors of Science, Computer Science or
Information Systems
\item Strong Mathematics and Logic is recommended.
\end{enumerate}
\end{enumerate}
\section{Training}
The System User training will be completed in stages. The staff of
Ghetto Software will train the Technical Support personnel, who will
in turn train the Air Traffic Control staff. GSI will remain on hand
to assist for one(1) year.
\chapter{General Constraints}
\section{General Constraints}
\begin{itemize}
\item WV International Airport will not sacrifice any part of their requirements
to reduce the cost or time needed for implementation of Clear Skys
1.0.
\item Clear Skys 1.0 must comply with FAA regulations regarding airport
operations.
\item Clear Skys 1.0 must be implemented with a failsafe backup service.
\item The entire system, including all hardware and software, will be housed
onsite at WV International Airport.
\item The hardware will be limited to architectures which are compatible
with the FAA systems, ground radar systems, and air radar systems.
\item Clear Skys 1.0 will interface with FAA systems, ground radar systems,
and air radar systems. It will also interface with a web-server hosted
on site which will provide real-time schedule information for customers
of the WV International Airport.
\end{itemize}
\section{Regulatory policies}
\section{Hardware limitations}
\section{Interfaces to other applications}
\chapter{Assumptions and dependencies}
\section{General assumptions}
Ghetto Software Inc. assumes that after one year of training involving
the technical staff at WV International Airport, that those technical
staff will be competent to train other users of the system and to
track and correct errors found in Clear Skys 1.0.
\section{Risk assessment}
Clear Skys 1.0 will be implemented in a way which will minimize risk
to the current systems operations of WV International Airport. Risk
is not acceptable due to the human lives and nature of the property
involved in daily operations.
\begin{thebibliography}{1}
\bibitem{IEEE830}\label{bibliography}IEEE 830 - Guideline for standard
requirements
definition documents.
\bibitem{SEbook}Pressman, Roger. Software Engineering: A Practitioner's
Approach.
New York: McGraw-Hill, 2001.\end{thebibliography}
\end{document}
Other related posts:
- » [ghetto-software] Requirements Definition, draft 1
