[ghetto-software] Requirements Definition, draft 2
- From: Damian Christey <christey@xxxxxxxxxxxx>
- To: ghetto-software@xxxxxxxxxxxxx
- Date: Thu, 11 Mar 2004 02:10:25 -0500
Since I haven't seen any suggested additions yet, I'm going to assume
I'm the only one who is still up and call it a night. I filled in what
I could.
%% 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 Gregory 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.
This system is not intended to be an autopilot, nor is it intended
to replace the air traffic control persons. It is our opinion that
all crucial decisions should be made by humans in a critical system
such as this. The system can suggest possible decisions, but these
should always be able to be overridden.
\section{Benefits, objectives, and goals}
The goal of Ghetto Software is to provide our customers with the highest
quality customized software, at the lowest possible price. This may
seem like a contradiction, but by utilizing innovative techniques
and cutting edge technology, we make it a reality.
We were given the following specific objectives for our system:
\begin{itemize}
\item It must be reliable.
\item It must be maintainable.
\item It must be expandable.
\item It must meet the new FAA requirements.
\item It should make scheduling of flights more efficient.
\item It must be fail safe.
\end{itemize}
Our plan for Clear Skys is to implement as much of the system as possible
using existing Free / Open Source solutions. This will benefit the
customer by reducing development time and cost, and will result in
a more stable and secure system.
\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 [GSI:]Ghetto Software, Inc.
\item [IEEE:]Institute of Electrical and Electronics Engineers
\item [NWS:]National Weather Service
\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 update the status
of the flight by indicating whether or not the plane has landed.
\item [plane\_has\_departed]This is a function designed to update 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}
This software must comply with all relevant FAA and local regulations.
\section{Hardware limitations}
WVIA has indicated that they are planning on replacing all their existing
computing hardware, currently PDP11 architecture. We recommend that
they purchase PC compatible hardware on which to run our system, as
it is cheaply available, and will be easier to replace as hardware
wears out. However, our software will be designed to be portable to
other architectures, including but not limited to: Macintosh Power
PC, and Sun Sparc. Portability will help us {}``future proof'' our
software, to avoid the problem that WVIA now faces; dependency on
an archaic hardware platform that is no longer produced.
All critical systems will have redundant backup systems and automatic
fail-over.
\section{Interfaces to other applications}
Clear Skys 1.0 is designed to run in a Unix environment, with GNU/Linux
specifically in mind. All of our software will be portable to other
Unix operating systems, including but not limited to: FreeBSD, Sun
Solaris, IBM AIX, and Mac OS X. Standard Unix user accounts and groups
will be used to provide the separation of user privileges that our
system requires.
We favor Linux as an operating system platform for several reasons.
First is the cost savings to our customer. Linux is available for
free under a non-restrictive licence that allows us to install it
on as many computers as necessary. Commercial support is available,
if needed, through many companies that provide Linux distributions.
Second is reliability. Linux is the continuation of the heritage of
Unix operating systems, which have been used in mission critical systems
since the 1970s and noted for their stability. The final reason is
security. The Open Source development model results in more secure
software than closed source, because the more people looking at the
source code, the faster bugs can be found and fixed. Regular security
updates can be entirely automated in Linux. As security is a major
concern of WVIA, the system we are building must have a secure operating
system at its foundation.
\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 2