Jury Systems Design Incorporated thanks you for the opportunity to propose a feasible solution to your growing system needs at Flin Flon Airlines. After extensive meetings, we have prepared the functional specification and management plan we hope will be suitable to your business needs. We look forward to future discussion with your management team as well as the employees whom will be using the system. Again, thank you for the opportunity to do business together.
ATICS represents a software tool that models core business processes at Flin Flon Airlines with respect to processing customer travel plans and maintaining fleet information to accommodate customer travel. The core business processes were outlined in the informational requirements specification provided by Flin Flon Airlines.
ATICS will be a system tailored to a small growing airline company. The objective of ATICS is to replace all common functions currently conducted on a manual basis with a tool which will greatly expedite the speed of which business transactions are completed by booking agents and system administrators. Of critical concern is to maximize the system usability to facilitate the ease of learning the system.
ATICS will operate on the basis of requiring only a minimal amount of information from the staff who use the system; once the minimal amount of information is entered into the system, ATICS will search for all corresponding data and display this onto the screen for both booking agents as well as system administrators.
ATICS will be designed in a flexible manner to allow booking agents to handle the day-to-day operations pertaining to passenger bookings. ATICS will also be able to satisfy the needs of system administrators with their business control efforts. The critical functions of ATICS are summarized below, and are classified by booking agent functions and system administrator functions.
Booking agents will be able to perform a number of essential functions using ATICS:
System administrators will be able to perform a number of essential functions as well:
In reviewing the informal requirements specification, several benefits will be derived by implementing ATICS. The highlights of these are outlined below.
Two hardware options have been identified. One is PC based and the other is UNIX workstation based. The best cost/performance solution will include a Sybase database server with PC's providing the user interface. All booking agent queries must be completed in 3 seconds. System administration queries must be completed in 5 seconds. The network connecting the database server and PC's must be secure from outside access.
The user will first be presented with a login screen. He or she will be prompted for his or her login name. Once a login name is entered, the user will be prompted for a password.
If the login name or password is invalid, then an error message will be displayed and the user will again be prompted for a login name.
If both login name and password are authenticated, then the main menu is presented to the user.
The System Administration main screen will have a row of tabs across the top labelled:
There will also be an "Exit" button beside the tabs which will exit the program. When the System Administration system is exited, the user must then re-enter his or her login name and password to perform system administration tasks.
When the user selects the 'Flights' tab, a screen will appear containing the list of flights sorted alphabetically. Beside each flight number are fields displaying the rest of the flight information, such as departure date and time, destination, aircraft, etc. The user can scroll through the list with the mouse.
The screen will contain an "Add Flight" button which will create a new entry in the flights list. The user can then modify each field as desired, or press the "Undo" button to not add the flight.
To modify a flight, the user can click on a field and type in the new value. The "Undo" button will restore the field to its original value. The user can cancel a flight by pressing the "Cancel Flight" button.
The changes are validated when the user selects a different flight or moves to a different screen. If the changes are acceptable, then they are saved. Otherwise the incorrect fields are listed with examples of correct values. The user can then correct the fields.
Some examples of incorrect input would include:
When the user selects the 'Booking Agents' tab, a screen will appear containing the list of booking agents, sorted alphabetically.
The "Booking Agent" tab works similarly to the "Flights" tab. The screen contains an "Add Booking Agent" button to create a new agent. It also contains a "Delete Agent" for removing an agent, and an "Undo" button to restore fields to their previous values.
Booking agents can be modified by selecting a field and typing in the new value. For example, click the mouse button on the first booking agent's telephone number. Now type in "555-1234". Click the mouse button on the next booking agent's name. The new telephone number will be validated and saved. If the telephone number was not valid, such as 555-87, the user will be notified and shown what format the telephone number should look like.
Some examples of incorrect input would include:
If an invalid change is made, the user will be notified of the nature of the incorrect input, and no change will be made.
When the user selects the 'Aircraft' tab, a screen will appear containing the list of aircraft, sorted by aircraft identifier.
The "Aircraft" tab works similarly to the "Flights" tab. The screen contains an "Add Aircraft" button to create a new aircraft entry. It also contains a "Delete Aircraft" for removing an aircraft, and an "Undo" button to restore fields to their previous values.
Press the "Add Aircraft" button to create a new aircraft entry. The user can now select each field for the aircraft and enter the correct value. For example, click on the seating capacity field and enter '35'. After all the values are entered, select a different aircraft and the changes will be validated. If the values are correct, they will be saved. Otherwise the user will be notified which fields are not correct and be provided with a description of what the fields should contain.
Errors in input would include:
If there is an error then an error message will be displayed telling the user the nature of the error. The user will then be able to either change the input or cancel the modification. Otherwise all changes will be saved and a message stating that the airplane was changed will be displayed.
The user will first be presented with a login screen. He or she will be prompted for his or her login name. Once a login name is entered, the user will be prompted for a password.
If the login name or password is invalid, then an error message will be displayed and the user will again be prompted for a login name.
If both login name and password are authenticated, then the main menu is presented to the user.
The booking agent's main screen will contain a row of tabs across the top labeled:
There will also be an "Exit" button beside the tabs which will exit the program. When the Booking Agent System is exited, the user must then re-enter his or her login name and password to perform booking agent tasks.
When the user selects the "Booking a Passenger" tab, a screen will appear that will allow them to enter all information needed to book a passenger on a flight.
This includes input such as passenger first and last name, complete address and phone number, class, destination, date and time of departure, seating arrangement, and any special requirements the passenger may have e.g. wheelchair access.
The agent has the options to search the help function if they have any problems, clear the screen so all entries are blank, or proceed with the booking so the agent may confirm that all information is correct.
The agent will need to complete all essential fields before being able to proceed with the booking . The agent can move to the next entry field with the tab key or move back with Shift-tab. The agent also can move to any field or window with the mouse.
Example:
The agent would select the "Booking a Passenger" tab from the top of the screen. They would then be presented with a new screen that will allow them to enter information.
The agent would enter the passenger's first name, then the last name, moving through each field with the tab key. The agent will continue to enter information in this fashion until they reach the destination field.
This field presents a list of all possible destinations. The agent has many options available to select a destination. They could scroll down the list using the arrow keys or mouse until the desired destination was selected. Or they could start typing the first characters of the destination until the one the agent wants is selected (highlighted). When a destination is selected, pressing tab will place the cursor in the next field.
Then the agent would change the default Month and Year the passenger would like to leave, if necessary. When these values have been entered a field similar to the destination field will be updated presenting to the agent all possible time and dates the passenger can leave on. After one is selected the agent has the option of pressing the select seat button. This will bring up a new screen that will display all the seats for that flight. The agent can pick any seat the passenger request's. If no seat is requested, then the computer will select one.
To Proceed with this booking the agent would press the "Proceed with Booking" button.
This would bring the agent to a confirmation screen that would display all relevant data, including the Flight Number, Ticket Number, and Ticket price. If all information is correct the agent can press the "Make Reservation" button to finalize the booking. If any corrections need to be made the agent also has an option to return to the previous screen by pressing the "Return to previous Screen" button.
If a reservation is made it is assumed that the passenger has paid, in full, the amount of the ticket.
After a reservation is made, all flight records will be updated and the screen will be ready for the next booking.
If at anytime during the booking, an agent wants to quit the booking, they may do so by pressing the "Exit Booking" button. This will erase the information entered for that booking.
When the user selects the "Query Passenger Information" tab, a screen will appear containing a table of 3 columns with all the sorted ticket numbers, all the name of passengers sorted alphabetically ,and their phone numbers.
Ticket Numbers -- a 6 digit integer which is unique to each passenger and flight.
When the agent double clicks on the specific ticket number, a window will display all the information about that passenger. This includes a list of flights on which the passenger is booked, their associated flight numbers, ticket numbers, class numbers and a field indicates whether the customer has paid the full amount. The window will also display the name of passenger, address, phone number and his/her special requirements.
Name of Passengers -- first name followed by last name.
When the agent double clicks on the specific name, if it is the case that there exists more than one person with the same name, a small window will pop up with a list of phone numbers according to the name entered. Then, the agent can click on the phone number and a window which is the same as described in the previous paragraph will be displayed.
Phone Number -- format: (DDD) DDD-DDDD.
When the agent double clicks on the specific phone number, if it is the case that there exists more than one customer who use the same phone number, then, a small window will pop up with a list of names according to the phone numbers entered. Then, the agent can click on the name and the system will display the same window as described above.
Note: There are buttons for the agent to click on to go back to the previous menu or the main menu for each of the windows except the main menu. There will be no actions taken when the agent clicks on the wrong area.
When the user selects the "Query Flight Information" tab, a screen will appear containing a table of 3 columns. The 3 columns of the table are:
Destination -- a list of all destinations sorted alphabetically that the airlines support.
The agent can double click on a destination to get further information. As the agent clicks on the specific field, a list of all dates and flight numbers associated with the destination will be displayed in another window.
For example, the agent double clicks on the field 'Toronto', a window will show a list of dates and flight numbers with flights that will fly to Toronto.
Flight Number -- a list of all sorted flight numbers. A flight number is composed of 2 characters followed by 4 digit integers.
When the agent double clicks on the specific flight number, a window will pop up with the following information:
Dates -- a list of dates from today to the near future indicate when the customers can book their flights. The date will be displayed in the format 'Month DD, YYYY'.
Again, double clicking on the specific date will lead the system to another window. The window will display a list of flight numbers and destination which the flights will fly on that date.
When the user selects the "Boarding Passes" tab, a screen will appear that will list the flights leaving the airport on the current day. The booking agent can then select a flight to start issuing boarding passes. The screen will be similiar to the "Query Flight Information" screen.
Since the booking system allows a flight to be overbooked by 15%, that 15% overflow of passengers are not allowed to make reservation on seats. Hence, those with no reserved seats must wait until 15 minutes before the time of departure to request boarding passes. Those with reserved seats can get their boarding passes at time of check in.
The process of issuing boarding passes involves the agent to select the ticket number. At this stage, the agent will have a map of the seating plan of the plane. The agent can click on a seat in the map that was reserved by the checked in passenger, in which the seat will turn to a purple color to indicate that the seat is now occupied. If the agent clicks on the wrong seat, the agent can always click on it again to turn it back to its original state and then can select a different seat. After confirming that a certain seat is taken, the agent can go ahead and issue a boarding pass by clicking on a button. The output will be a boarding pass which will be given to the current check in passenger.
The information on the boarding pass will include:
In case the agent enters in the wrong input, say, the input is someone else's ticket number, he/she can match the name of the ticket holder and the name on the screen before he/she issues a boarding pass. If the name matches, the agent can print out the boarding pass, or else, he/she can cancel the request and re-enter the ticket number. If the input entered by the agent does not match with any ticket number in the database then the system simply asks the operator to re-enter the ticket number.
During the 15 minutes prior to departure time, the remaining reserved seats which were not checked in by anyone become available for others to book. According to the number of available seats, those 15% passengers are then allowed to book their seats during the request of boarding passes. Hence, the agent who issue boarding passes also have the authority to assign seats to passengers at the time of issuing boarding passes. The agent can select the green colored seats, which means that the seats were reserved but are now available, assuming that the people who booked them decide not to board the plane. The process of issuing a boarding pass at this time is still the same as above.
The following section deals with the specific features we wish to incorporate into the airline reservation system, the classes of functions and their inter-relation, a preliminary choice of data structures and algorithms, a section devoted to minimal system requirements, and possible enhancements to the system. The structure of the design team is also included at the end of this document. Because this document has been prepared relatively early in the design phase of this project, all specifications in this report are subject to change.
This system will mostly be used by booking agents with varying levels of familiarity with computers. With this in mind, an important feature of this software is that it be relatively simple to use. The main function of the software will be to book passengers on selected flights. If the desired flight is not full the passenger should be given the option to choose his/her seat. Due to different needs of todays' travelers, the system will store special requests for food or assistance to inform the flight crew prior to departure. Any agent should be able to obtain information on flights, passengers, and possibly seat configuration layouts of each flight in order to quickly process each check-in and provide a detailed boarding pass to the customer. Over booking is commonly practiced among airlines to ensure there are no empty seat on the plane due to no-shows. The system should allow for this and in the event of an overbooked flight with too few seats, provisions should allow for compensation of the customer.
The overall system can be broken down into two subsystems. The first is the Administrative subsystem and the second the Booking Agent subsystem.
The two subsystems form the ATICS application which is a functionally complete program that is capable of running an airline reservation system.
The administrative subsystem has three main modules. They are responsible for maintaining the different types of aircraft, booking agents, and scheduled flights.
The aircraft properties will be modifiable. Furthermore, an aircraft can be removed from active commission. Also, a new aircraft can be added to a new commission. Therefore, the datatype aircraft can be added/deleted/modified by the aircraft maintenance module.
The system information that will be affected by the aircraft maintenance module is as follows:
Aircraft:
Booking Agent properties will also be modifiable much like the aircraft's. An agent can either be added, modified or deleted from the system. The system information that will be affected by the Booking Agent module is as follows:
Booking Agent:
Finally, scheduled Flight properties will be modifiable via the Flight maintenance module. Flights can either be added, removed, or modified. The system information that will be affected by this module is as follows:
Flight:
The Booking Agent subsystem has four main modules. They are responsible for maintaining the type Bookings and Seat Selection. Also, they will perform general queries and the task of checking in passengers.
The first module is for maintaining the type Booking. This is where the user can either add, modify or delete a booking. The system information affected by this module is as follows:
Booking:
The second module is for maintaining the type Seat Selection. This is where the user can either add, modify or delete a seat selection. The system information affected my this module is as follows:
Seat Selection:
The General Query module will allow the user to obtain more information regarding a flight or a passenger. The queries will be performed by flight number, date, or destination. It should result in a list of passengers(with ticket numbers) and/or display a complete seat map. If a passenger query is executed the search should result in a listing of flights a given passenger has booked or display passenger information.
The final module is designed to check in a passenger. It will be used the day of the flight. If the passenger has already chosen a seat they will be issued a boarding pass. Otherwise, a seat will be assigned. Information that should appear on the boarding pass is as follows:
Boarding Pass:
Both possibilities use industry standard equipment which is commonly available and are secure networked systems.
MS-Access 2.0 Relational Database
Overview:
This system would consist of "forms" which the user would fill out when
conducting the check-in procedure. The customer information fields would be
filled out and seating arranged. The database is updated after each form
is completed. The object oriented environment of MS-Access provides a
transparent system for the users.
Features:
Hardware Environment:
PC Based Local Area Network with workstations for each agent.
File Server for centralized access to the database.
Sybase Relational Database
Overview:
A similar paradigm would be used in this implementation with "screens"
used to gather the customer data for updating the database.
Features:
Hardware Environment:
UNIX Based Local Area Network with workstations or PC's for each agent.
File Server for centralized database.
Please note that this information is preliminary.
Relational Database for airline flight schedule information
The data structures used for relational databases are tables. A table would exist for the customers, one for the flight schedule, and one for the seat selection on one flight. These tables are then linked via common information.
User formulated queries for flight information using structured queries. Users are lead through the queries via an easy to use graphical environment with fields for various search criteria.
e.g. List flight from Flin Flon to Vancouver between March 3 and
March 5
e.g. List customer on flight # 102 with lastname "SMITH"
Due to Flin Flon Airlines' desire for the quick implementation of this project and their need for a scaled down version to be operational by late February, each feature must be categorized either as a minimal system feature or enhancement feature which will be incorporated at a later date.
The features in their major function groupings and feature categories are listed below:
Minimal Features:
Enhancements:
Minimal Features:
Enhancements:
As a well-structured software supply team, we make it our duty to please the customer. Flin Flon Airlines needs are important to us and we will do our best to meet the needs of your distinguished company. The important key points of our management plan are as follows:
The structure of our software supply team followed by the designated responsibilities of each team member will be as follows:
| Jerry Coolidge | Designation pending. |
| Hanna Dang | Our team scribe; responsible for keeping minutes of group meetings and then making them accessible for all team members. |
| Ernest Domshy | Designation pending. |
| Micheal Downey | Designation pending. |
| Charanjeet Jugdev | Designation pending. |
| Jamie Kromrey | Designation pending. |
| Andrew MacNeil | Our team "Web Master" who maintains a web page with all our groups collected documents and other affiliated information. |
| Josephine Ng | Designation pending. |
| Alvin Schur | As designated team leader Alvin will be responsible for group organization, team guidance, and maintaining a high team morale. He will keep the team on schedule. |
| Andrew Taylor | Designation pending. |
| Mark Vann | Second in command. Mark will be responsible to the role of leader if Alvin is unavailable. He is also Alvin's cohort. |
| Rob Vollman | The group liaison. Rob will be in charge of relaying messages to and from our team to Brent(our lab instructor), Dr. Shaw, and whoever else. |
Basically the team structure will be broken down into four subgroups; management (2 people), programmers (4-5 people), technical writers (3-4 people), and user-system interfacing (3 people). Exact structure break down is still to be determined.