Formal Methods and Programming Assessed Coursework 2 Group Project

Requirements for an airline reservation system

Paul Jackson, Anne Morley, Denish Gandhi, Meng Zhao, Chris Lewin MSc Software Systems 2011

Table of Contents
1. 2. Objective ..................................................................................................................................... 3 Main goals .................................................................................................................................. 3 Reservation.................................................................................................................................... 3 Cancellation ................................................................................................................................... 4 Passenger Inquiry ....................................................................................................................... 4 Flight Inquiry ................................................................................................................................ 5 Data File Operations .................................................................................................................. 5 3. System constraints ................................................................................................................. 6 Development ................................................................................................................................. 6 Flight / Passenger Details ........................................................................................................ 6 User Interface ............................................................................................................................... 6 User Access .................................................................................................................................... 7 Data Backups .................................................................. Error! Bookmark not defined. Error Checking ............................................................................................................................. 7 4. 5. 6. 7. System interface / Data Input ............................................................................................ 7 Security requirements........................................................................................................... 8 Testing requirements ............................................................................................................ 8 Documentation Requirements / Maintenance / Training ...................................... 8 Draft user guide ........................................................................................................................... 8 Draft Maintenance / Programmers Guide ......................................................................... 9

Assessed Coursework 2 - Group Project MSc Software Systems

Page 2 of 9

Formal Methods and Programming Airline Reservation System Requirements Analysis

1. Objective
To develop a prototype software system for Dr Claire Willis that acts as a computerised airline reservation system. This program will be used as the main computer system for a travel agency whose main role is to use the system to reserve flights for customers. The system should be designed with different user levels, one for the travel agents staff who will be making these bookings and one for administrators who will maintain the system.

2. Main goals
The system should implement and demonstrate the main functions of a computerised reservation system. It must be able to read in data from a text file and handle different types of booking requests. After preliminary discussions with the client, we decided that the main goals of the system are to be able to handle the following four basic types of request, plus file operations: (i) A reservation (ii) A cancellation (iii) A passenger inquiry (iv) A flight inquiry (v) Data file operations

Reservation
The first main goal of this system is to create a function that makes a flight reservation. The user should be able to input some information to obtain a list of suitable flights and then select a flight to book a seat and enter the passengers details. This input could be a date, a destination or a flight number. After discussions with our client, we decided the most useful input would be an arrival destination. The passenger should be given an option to choose between a first class and an economy seat. Each flight will have its own passenger lists, one for first class and one for economy class. These are needed to ensure that the number of seats booked on a flight corresponds to the number of seats available on that plane.
Assessed Coursework 2 - Group Project MSc Software Systems Page 3 of 9

 10% of the seats on every flight are first class. The rest are economy. Each passenger list should also have a waiting list. If there is no room available on a flight in the appropriate class, passengers should be added to the end of the waiting list (queue) for that class. If a passenger requests a first class seat and the first class seats are all full, the passenger should be offered an economy class seat, if available. If the economy seats are also full, the passenger will be added to either the first class or the economy class waiting list. Similarly, if a passenger requests an economy class seat and these seats are full, the passenger should be offered a first class seat or placed on the economy class waiting list. A passenger should not be booked on more than one flight per day, and should not be booked on a single flight more than once. Passengers may be booked on more than one flight and appear on multiple passenger lists. In this prototype system, a reservation cannot be made for more than one passenger at once. This could be a problem as one or more of the group could be put on a waiting list. The user must use this reservation system to enter the passenger details. We clarified what this information was in a meeting with the client. As a result, we have decided that the details required from each passenger are their title, first name, surname, address, passport number and telephone number. A passengers details may not be unique. Each passenger should be provided with a unique booking reference whenever a flight is booked. This reference will refer to both the passenger and flight they are booked on. The passenger should keep this booking reference safe, as this will be needed to access other requests in the system. After all Reservation actions, an appropriate message should be given to the user to indicate what action has been taken.

Cancellation
A passenger should have the option to cancel any of the flights they have booked. To access the cancellation system, a passenger must be able to provide their booking reference. This reference will allow the system to find which flight that passenger has been booked on. The user will then be given an option to cancel this booking. The passenger will then be removed from the passenger or waiting list of the flight. The first passenger on the appropriate waiting list will then be promoted onto the passenger list. There should be an appropriate message to inform the user what action has occurred. It is then up to the user of the system to inform any passengers of this update.

Passenger Inquiry
This function should allow the user to see a passengers details and what flights a passenger is booked on.
Assessed Coursework 2 - Group Project MSc Software Systems Page 4 of 9

 The input data for this function should be unique for each passenger. At the request of the client, the passengers name should be used. This may need revising, as a passengers name is not always unique. This system should then provide the user with the passengers travel and personal details. It should display a list of all the flights on which the passenger is booked and indicate if they are on the passenger list or the waiting list, and which class seat they are in.

Flight Inquiry
The flight inquiry system should allow the user access to the passenger and waiting lists of a flight. The user should input a flight number. This system should then print the passenger and waiting lists for this given flight, and it should also provide the user with some flight details, such as time and date.

Data File Operations

The flight inquiry system will be required to read and write to data files where all data for the system will be stored. Databases are not to be used for this system, by request of the client. Our starting point for defining the files required comes from the written specification. The Flight Control Group file - FCGDATA stores flight details. This is a text file that acts as a database of scheduled flights. We must automatically generate flight details for this file, again at the specific request of the client. The FCGDATA file will need to contain flight number, number of seats, time (24 hour clock) and date of flight (ddmmyyyy) in the following format: BA679 250 0950 25091998 AA321 380 0800 31121998 It should also accept data in a less defined spacing format: BA679 250 0950 25091998 AA321 380 0800 31121998 We have clarified with the client that correct handling of irregular data formats must be demonstrated to them when we handover the system. We have also learned that the FCGDATA file is a flexible format and we have been asked to include an arrival destination field in it. Other fields may be added as appropriate, such as departure destination. Other data files can be created as needed. For example, passenger waiting lists could be defined with four separate lists: economy, first, economy waiting, first waiting.

Assessed Coursework 2 - Group Project MSc Software Systems

Page 5 of 9

Given that we have been asked to create two levels of user for this system, users and administrators, we have clarified that a file of user (staff) details is not required for the prototype system. We need to demonstrate to the client that administrators can write to the data files.

3. System constraints
Development
The prototype will be demonstrated on the Eclipse IDE and therefore must work correctly on this platform in the PC Lab. Our documentation should reflect how we might implement a database solution for this project and also consider the advantages/disadvantages of a database over data files.

Flight / Passenger Details

As this is a prototype system, the client has asked that the FCGDATA file should include approximately 50 flights. We should automatically generate flight details for this file. As stated above, the first class passengers must be 10% of any flight. The client is not concerned as to how many people are on each flight. Therefore we may consider generating this number randomly. During our meeting with the client it was stated that the prototype does not require flight prices, only the final version. We should consider how adding this feature would affect the final product, such as encrypting passenger payment details. The client has asked that we consider the prototype writing to a customer data file, so that upon restart the system will not be blank (no customer data). The system does not need to provide tickets or e-tickets or any other sort of passenger confirmation. There is no other extra functionality required, such as baggage handling, online check-in, insurance, car hire, hotels, etc. This can be considered in our documentation if we wish.

User Interface
The prototype should be user-friendly for non-IT literate users who have received minimal training on the system.
Assessed Coursework 2 - Group Project MSc Software Systems Page 6 of 9

Fields for passenger data entry are not restricted and do not require checking eg. Firstname, Surname, Street etc. Other data entry will be validated.

User Access
There needs to be two user levels. One for ordinary staff and one for administrative staff. Not everyone should have access to flight and passenger files, only administrators. Everyone should have access to reservation system. We asked the client whether or not the program should be capable of handling multiple users at the same time. In response, we were told that the prototype should not handle multiple users at the same time, although we should consider how our system could do this in our documentation.

Error Checking
The client requires the following error checking. The system must: Deal with errors gracefully Be robust Not crash with incorrect data entry Recover from errors Reject incorrect data read from files

4. System interface / Data Input

The client wishes users to be able to log on to a computer, open the software and immediately be presented with command options. We are to design this interface for ordinary travel agents staff (users) who will search and reserve flights, plus their supervisors (administrators) who will maintain the system and add and remove records. The interface should be as user-friendly as possible. The client would like clear instructions on how to input data and how to move through the system. Option lists should be context sensitive. The client does not want users to be baffled by endless menus. The prototype system will need a command line interface, however the final product can be adapted to have a WIMP interface. Data input will be via the command line via keyboard only. Data input will be letters and numeric characters. Passenger details will be free text, all other keyboard inputs will be constrained and validated. We need to consider that the client has specified that the system must run on the Eclipse IDE and design our solution to work effectively through that interface.
Assessed Coursework 2 - Group Project MSc Software Systems Page 7 of 9

5. Security requirements
As there are two levels of user access in this system, there has to be two levels of security. The client has asked that ordinary users should only have access to the reservation, query and cancellation systems, whereas administrative users should have access to the flight and passenger databases. Administrative users should also be able to edit these databases, for example to add or remove flights. A username and password should be requested before any access to the system is given to the user. Access to the databases should have further password protection, which only allows access to administrators. The system should have appropriate backup facilities. If information is lost, these backups should be used to restore any data in the system. In the final product, these passwords would be stored and encrypted in a database containing details of staff, however for the prototype, a password simulation will be sufficient. As stated above, the user database will not be created for the prototype. All databases would need to be encrypted to protect personal information, but for simplicity reasons, we shall not be demonstrating this in the prototype.

6. Testing requirements
All aspects of the program should be thoroughly tested, including the functionality of the system as a whole and of the individual functions. This testing should be carried out in a suitable demonstration program. The testing should include both black box and white box testing, however the testing need not be exhaustive due to time restraints. A prototype version of the interface should be developed, so we can obtain feedback from users.

7. Documentation Requirements / Maintenance / Training

The prototype system requires the following documentation:

Draft user guide

This describes what the system does, and how to use it. It must include installation instructions. It should be brief and informative.

Assessed Coursework 2 - Group Project MSc Software Systems

Page 8 of 9

We are not required to offer training sessions for any users, only a demonstration session for the client, Dr Willis.

Draft Maintenance / Programmers Guide

A brief but informative guide which details key issues for anyone who may have to maintain the system. It should clearly describe what functionality is found in each class. Note: The reader may not know anything about your code, but may be asked to maintain it. Our coding team should be rigorous in their commenting of code to aid the construction of the maintenance guide and aid client readability.

Assessed Coursework 2 - Group Project MSc Software Systems

Page 9 of 9