Airline reservations system (ARS) is a online software application used to reserve and retrieve information and perform orders related to air travel. Formerly designed and performed by airlines, ARSes were later developed for the utilization of travel companies. Major ARS operations that book and sell seat tickets for multiple airlines are known as Global distribution systems (GDS). Airlines have divested the majority of their direct holdings to dedicated GDS companies, who make their systems accessible to consumers through Internet gateways. Modern GDSes are providing the services like booking hotel rooms and rental cars as well as airline tickets. In addition they provide usage of railway reservations in some markets although these are not always integrated with the main system.
REQUIREMENTS DOCUMENT
First we could developing a Software Requirements Standards (SRS) document that specifies what an air travel reservation system should and should not do. The SRS file is divided into five areas namely
System Objectives
Mainly we discuss the goals and objectives of the system categorized predicated on the point of view of the airline company and the customer. They help in a top-down development of the SRS.
System Context
This section clearly depicts the environment and restrictions of the ARS and the entities with which it interacts. It helps us observe how the system matches into the existing system of things. What the machine will do alone and what it desires other entities to do is plainly delineated.
Functional Requirements
These requirements areas the functions of the system - what it should do and what it will not. This may includes the most common requirements of the customer in addition to some additional features. like reserving tickets, rescheduling seat tickets etc. Flexibility from ambiguity and navigability were kept in mind while documents. A steady terminology has been implemented throughout and the terms are described in the appendix. The subsections follow a rational sequence that reflects real life. For example, a customer cannot reschedule a ticket unless he has bought one prior and cannot buy one unless he has checked out its supply.
Non-functional Requirements
These are quality requirements that stipulate the performance levels required of the machine for various types of activities. Numerical lower and upper limits arranged conditions on the response times, access times etc of the system. Sometimes, tradeoffs are essential among various non-functional requirements.
Future Requirements
As technology bettering daily, users needs are also increasing. so we have to update our applications period to amount of time in order to gratify the customers. They are the specifications that are not provided for now in today's version of ARS but that could be integrated into future variations. Some of these need advanced technologies and interfaces with other systems. The ARS could be designed in future to enhance the existing features or add totally new ones.
The assumptions and limits of the ARS have been interspersed in the SRS to present the same in their proper context.
REQUIREMENTS Evaluation DOCUMENT
1. System Objectives
1. 1 The Airline Booking System (ARS) is a software application to aid an airline with orders related to making solution reservations, which include obstructing, reserving, canceling and rescheduling tickets.
1. 2 From the viewpoint of the airline -
1. 2. 1 Minimize repeated work done by the system administrator and reservation clerks.
1. 2. 2 Maintain reliability among different access settings, e. g. by mobile, by web, at the information table and across different physical locations. The users should be essentially used through the same steps by the machine as each goes through in classic desk-reservation systems.
1. 2. 3 Maintain customer information in case of disaster, e. g. airline flight cancellation due to bad weather. The profile can even be utilized by the flight company to trail user preferences and travel patterns to serve them better, plan routes, for better marketing and efficient scheduling of flights.
1. 2. 4 Maximize the revenue of the flight company by various means:
1. 2. 4. 1 Increase awareness among regular travelers about various special deals and special discounts.
1. 2. 4. 2 Minimize the number of vacant seats over a flight and boost flight capacity utilization.
1. 2. 4. 3 Maintain the ability to adopt a adaptable pricing policy. The price tag on the seat tickets should be dynamically motivated based about how early, before the date of departure, the customer buys the ticket.
1. 3 A survey conducted by air travel companies shows that users of a preexisting reservation system would reply favorably to an ARS that satisfied or helped them meet the following aims:
1. 3. 1 Reduce effort and annoyance for travelers in arranging a vacation, especially by minimizing the search effort for the air travel they need to take.
1. 3. 2 Show all possible combinations and itineraries available for a pair of origin-destination towns.
1. 3. 3 Reduce redundancy in the info required from the customers in order for them to buy tickets, create customer accounts etc.
1. 3. 4 Check the validity of suggestions data and present a feedback to an individual in case of mistakes or inconsistency.
1. 3. 5 Provide adaptable access modes to users - internet, telephone, PDA.
1. 3. 6 Protect customers' privateness concerns.
1. 3. 7 Make it easy for travelers to check on the ticket position or make changes with their trip.
2. System Context
2. 1 The ARS will provide the next types of easy-to-use, interactive, and intuitive visual and telephonic interfaces.
2. 1. 1 The ARS provides an easy-to-use, intuitive Graphical INTERFACE (GUI) within the Clerk/Administrator's working desktop environment.
2. 1. 2 The ARS will also provide an interactive GUI, on the World Wide Web for the overall customers.
The above two ARS interfaces shall help provide the pursuing functionalities to the users - access to the ARS to check on the flight program, availability of seating, ticket price and block, reserve, cancel, and reschedule tickets.
The ARS will also provide an easy-to-use, simple telephonic interface, which can be accessed by the clients through phone or mobile phone from everywhere. This program shall provide gain access to, only to the next functionalities, namely, check flight program and check solution position including any change in the journey timings. The efficiency available through this telephonic program is bound because of security constraints.
2. 2 The system and its environment and the relationships between them are depicted in the diagram below.
DB-Reservations
Flight Schedule Database
Customer
Via Web
DB-User
DB-Schedule
I
N
T
E
R
F
A
C
E
'CW'
DB-Geography
ARS software
INTERFACE 'Cp'
Customer
Via Phone
INTERFACE 'A'
Administrator
The shut down boundary above plainly delineates the machine and the environment. The diagram shows the connections between the ARS software and the directories inside the machine. A couple of three databases internal to the machine and that your system preserves. DB-user is the database containing all the personal information of the registered users of the ARS. This can be updated by the user by logging in to the system. Information from this database is used during transactions like charging the bank card etc. DB-schedule is a copy of the airline flight schedule databases. The latter is out there independently and it is updated by way of a airfare scheduler system which is out of opportunity of the ARS. DB-schedule is kept up to date with the latest status of the journey schedule databases whenever you can find any change in the second option. For example, if a flight has been put into the schedule between two metropolitan areas on Tuesdays, DB-schedule gets kept up to date with this change through a process with which we are not concerned. It is external to the system and has gone out of the opportunity of the SRS. DB-schedule also contains the base prices of tickets for various trip figures. DB-reservations are a repository containing information about the number of car seats available on each school on different plane tickets. It offers provision for marking how many of the reserved seating have been obstructed however, not yet bought. DB-reservations should revise itself using DB-schedule, for example, if a fresh flight is added. DB-geography is a database, which includes information about the locations and cities serviced by the flight. The length between all towns and cities is within a matrix form. You will find three interfaces, one for the administrator, one for the customer via web and another for the client via telephone. The administrator can upgrade DB-schedule with any changes in the bottom prices of airfare tickets. The system uses a charges algorithm and dynamically decides the real price from this base price with regards to the date of reservation vis- -vis date of departure. The client interfaces (web and telephone) allow multiple functions that happen to be described in the next section - section 3.
3. Functional Requirements
Registration and creation of end user profile
Making Reservations/Blocking/Confirmation
View Ticket Status
Query Trip Details
User Accounts
The passenger, who will henceforth be called the 'individual', will be presented with 3 selections by the reservation system, as the first rung on the ladder in the connection between them. A end user can choose one of these and his choice would be governed by whether he's a visitor or a documented end user and whether he needs to check on the availability of seat tickets or also stop/buy them. The terms 'registered consumer' and 'visitor' are detailed below.
A user who may have journeyed by the flight earlier would have been given a consumer id and a security password. He would have his personal information stored in the repository referred preceding as 'DB-user'. This 'personal information' would be henceforth known as 'account'. Such a user with a account in DB-user will be called a 'registered customer'. A documented user will be able to check the availability of tickets as well as block/buy a ticket by logging into the system.
A new end user, on the other palm, would either have to
register himself with the machine by providing personal information or
log in to the system as a visitor.
In case of 'a', the new consumer becomes a recorded user.
In case of 'b', the new consumer would stay a guest.
A guest can only check the availability of seat tickets and cannot stop or buy tickets.
But a signed up customer can also become a guest if he only wishes to check on the availability of tickets. 'Supply of seat tickets' always identifies viewing the trip program for given days and nights, the price tag on seat tickets and any discount offers. The machine shall present an individual with a choice to exit from the machine at any time during the following processes.
Registration and creation of user profile
The system shall require a user to register, in order to handle any transactions with it aside from checking the option of tickets. It'll ask an individual for the following information leastwise - a user id, a security password, first name, last name, address, contact number, email address, gender, age, preferred mastercard number. The system will automatically create a 'sky miles' field and initialize it to zero in the user's profile.
Checking Availability
After logging in a user (the registered customer or a guest), the system shall require him to enter in the following details - source city and destination city. "City' is a common term and identifies a city or town as the case may be. The origin and destination metropolitan areas would be moved into as text. The machine shall now make reference to the flight schedule database, known as 'DB-geography' prior, and check when there is any ambiguity with the brands of the metropolitan areas. In case there are definitely more than two locations with same name as entered by an individual, the machine shall list all of them (with more qualifications) and have the user to choose one of them. In case, either the foundation or destination metropolitan areas are not stated in DB-geography to be straight serviced by the air travel, the machine shall suggest the nearest city to which service can be acquired, like the distance of the destination city from this nearest city.
After the foundation and destination cities are ascertained, the system shall now access the flight plan database, known as 'DB-schedule', and checks if there is a direct functional service between the two cities. If not, the machine shall suggest possible routes and transfer points using a 'option selection algorithm'. An individual shall now be presented with a choice of either selecting one of the routes. In case he chooses a route, the system shall complete the intermediate stop over tips and build a multiple trip itinerary for an individual.
The system shall now ask the user to enter the next details - category, one-way or
round trip, departure day and the number of adult travellers, children and senior
citizens.
'Class' refers to business course/first school/club school/smoking/non smoking. This choice shall be made by the user through a drop down menu indicating all the possible mixtures of choices. One-way/round trip shall be the drop down menu or a check package selection. 'Departure time frame' refers to either a sole date or a variety of dates, came into by having a calendar-like menu. This menu shall not show dates before or those schedules that are too ahead in the future(as determined by the airline insurance policy). In the event, the trip is a round trip, the machine shall also ask the user to type in the departure day on the go back trip. Having used all the above source from an individual, the system bank checks for any phony entries like the departure time frame on the return trip being earlier than the departure time on the onward trip. In case of incompatibility, the machine shall display the right error message and prompt the user to enter the info correctly. Having considered all of the information, the machine shall now access the flight schedule databases 'DB-schedule' and inquiries it using the insight provided by an individual. The system questions the reservation repository 'DB-reservations' to check on which of the plane tickets on the routine have seating available. The system displays the results the right form (a tabular form) with the following information depicted - for every flight number - the air travel number, departure time in origin city, introduction time in destination city, the period of the journey (taking into account the possibility of an change of your time zone) and the amount of seats on that airfare.
There can be several plane tickets between two towns and all of them will be outlined for this date that the user wants to depart from the foundation City. In the event, an individual has entered a variety of dates, the machine shall display all the plane tickets for all those dates in the range.
If an individual has requested a circular trip, the system shall display two desks - one for the onward trip and one for the come back trip. There will be a check field in front of each line in the stand representing a trip with available chairs.
The user is now asked to check on one of the boxes reflecting a selection of a flight number and time. In case there is a spherical trip, an individual is asked to check one container each in both tables.
The system shall now display the price of the solution for the trip. This will be the sum of the costs for all the customers of the travel party being symbolized by an individual.
The system shall also list any guidelines about the cancellation of tickets - what percentage of the price will be refunded within what time frame ranges. This will likely be displayed as a table.
Making Reservations/Preventing/Confirmation
After having considered an individual through the, Checking Availability, The system will now ask an individual if he wishes to stop/buy the ticket. If yes, and
if the user is a guest, he will have to first register and become a registered end user and then log onto the system.
If an individual is already a registered consumer, and if he has logged on already, he is able to block/buy the solution, but if he has been acting as a visitor, he'll have to sign on.
Having guaranteed that an individual is logged on validly according the system compares the departure date with the machine date. If the departure date falls within 2 weeks of the system date, the system informs an individual that he does not have any option to obstruct the solution and asks him if he would prefer to buy it.
If the difference between the departure time frame and system particular date is more than 2 weeks, the machine asks the user if he'd like to prevent or choose the ticket. The machine informs an individual that they can block the solution free now. In addition, it informs him that if he chooses to block the solution, he should make your final decision before 2 weeks of the departure time frame. The machine shall send a contact to an individual, 3 weeks before the departure day as a reminder, in case he determines to stop the ticket now.
Having used the insight from an individual, the system shall now proceed to update the reservation database DB-reservation. It'll decrement the number of available chairs on the particular flight for the particular class by the number of travelers being represented by an individual.
In case of the blocking, the system makes an email than it in the data source - to be used if an individual doesn't arrive before 2 weeks of the departure time frame. It generates a blocking quantity and displays it for an individual to notice down.
In case the user buys the ticket, the system accesses his account and charges the price of the solution to his credit card number. It concurrently generates a confirmation number and exhibits it to an individual for him to note down. The solution has been reserved.
It provides the mileage of the trip (accounting for the number of travelers) to the skymiles in his account.
Confirm Ticket
A user who has earlier clogged a ticket after going right through the prior steps necessary to either confirm the solution before fourteen days of the departure time frame or the ticket stands terminated.
To let the user confirm a ticket, the system shall first log him on and have for his obstructing amount. Then it accesses DB-reservation and cleans away the check symbol, which so far represented a blocked seat. The chair is now confirmed and reserved for an individual.
The system accesses DB-user and charges the price tag on the ticket to the credit card number of an individual. It simultaneously produces a confirmation quantity and displays it for an individual to notice down. The ticket has been reserved.
It gives the mileage of the trip (accounting for the number of travelers) to the skymiles in his account.
Reschedule Ticket
The system shall present an individual with an option to re-schedule his travel party's trip. In order to do this, the system first logs on an individual and requests his confirmation amount. It will not allow a consumer to reschedule a blocked solution but only a established ticket. Making use of this, it queries DB-reservation and presents the facts of the visit to the user, including however, not limited to origin city, destination city, night out of departure and day of introduction (in case the trip is a rounded trip).
The system shall now ask an individual to select new dates from the calendar-menu.
In case, there are no available tickets for the times entered, it displays a suitable concept informing him that rescheduling to that date is extremely hard.
In circumstance there are tickets available, the system asks an individual to select the flight quantity for the trip (another for the come back trip if the trip is a rounded trip) and proceeds to update the database.
The system accesses DB-reservation and decrements the amount of available seats on the flight(s) by the amount of people in the user's travel party. It then increments the access for the prior journey by the same quantity to reflect an increase in the available seats on it therefore of the rescheduling.
The system now checks when there is any difference in the costs of the tickets. If so, it accesses DB-user and charges or credits the credit card as the truth may be. The system generates a fresh confirmation number and displays it to the user.
Cancellation
The system shall also give the user an option to cancel a confirmed ticket or a clogged ticket.
The latter circumstance is simpler and you will be dealt with first - the machine shall first log on the user and submission the blocking number. Then it accesses DB-reservation and revisions it by incrementing the amount of available chairs by the number of folks in the user's travel party.
In the past case, i. e. , for a confirmed ticket, it asks for the confirmation amount and accesses DB-reservation and presents the details of the trip.
It then lists the relevant guidelines for cancellation of tickets and depending on the system particular date and the departure particular date, it exhibits the % of the total amount that might be refunded if an individual cancels the ticket.
After the user cancels the solution, the system produces a cancellation number and shows it for an individual to notice down. It accesses DB-reservation and updates it by incrementing the amount of available car seats on that airfare by the number of travelers in the user's get together. It accesses DB-user and credits the refund amount to his credit-based card number. The machine then deducts the mileage of the trip (taking into account the amount of travelers in his party) from the sky a long way in his profile.
Update Profile
The system shall permit an individual to revise his profile at any time. Changes can be produced in fields including but not limited to addresses, contact number and preferred credit-based card number.
View Solution Status
The system shall allow a consumer to view all information about his trip. After logging him on, it asks for his blocking amount or his verification amount. It accesses DB-reservation and retrieves the details of the trip and presents those to the user in a convenient format, including any last second changes to the journey timings etc. Such changes will be outlined.
Query Airfare Details
The system shall allow any end user (documented or non listed) to gain access to the details about the arrival and departure times of a airline flight by requesting the user to type the flight quantity and date. The machine accesses DB-schedule and presents the time of arrival and departure.
Telephone access
The system shall be accessible through a touch-tone telephone. The telephonic interface shall, at the least, provide the customer with the facility to check option of seat tickets and query flight details. The machine shall walk the client exactly through steps 3. 3 and 3. 9 respectively but by using a telephonic program.
Non-functional Requirements
Performance
Response time of the Flight Reservation System should be less than 2 second almost all of enough time. Response time refers to the waiting time as the system accesses, concerns and retrieves the information from the databases (DB-user, DB-schedule etc) (A local copy of airline flight schedule data source is taken care of as DB-schedule to reduce this access time)
ARS will be able to deal with at least 1000 transactions/inquiries per second.
ARS shall show no obvious deterioration in response time as the number of users or trip program data increases
Reliability
ARS shall be available 24 hours a day, 7 days a week
ARS shall always provide real-time information about flight availability information.
ARS will be robust enough to have a high degree of fault tolerance. For instance, if an individual enters a negative number of people or a value too large, the system shouldn't crash and shall identify the invalid suggestions and produce a suitable error meaning.
ARS will be able to recover from hardware failures, ability failures and other natural catastrophes and rollback the databases to their latest valid status.
Usability
ARS shall provide a easy-to-use graphical software similar to other existing reservation system so that the users do not have to learn a new style of conversation.
The web interface should be intuitive and easily navigable Users can understand the menu and options provided by ARS.
Any notification or problem messages generated by ARS shall be clear, succinct, polite and free from jargon.
Integrity
Only system administer gets the right to change system variables, such as pricing
policy etc. The machine should be secure and must use encryption to protect the
databases.
Users have to be authenticated before having access to any personal data.
Interoperability
ARS shall reduce the effort necessary to couple it to some other system, such as airfare schedule databases system.
Future Requirements
Support for holding out list functionality
ARS shall be made more adaptable in ticket booking handling, and shall agree to hanging around list for reservation. The hanging around list handling capacity for ARS will be made more advanced, by allowing it to send demands to the Trip Scheduler to schedule extra flights, with respect to the demand in a particular corridor, and providing the wait around listed travellers with a fresh flight.
The telephonic software of the ARS will be improved to aid more functionality like
allowing the customers to cancel a solution etc. , by including security actions.
ARS will be made more active and beneficial to the users by enabling it to send instant
messages to the passengers, of a cancelled or rescheduled journey, through email, mobile,
Fax etc. , informing them about the change, and providing them with other feasible
alternatives.
Information about the type of meals offered in a air travel and the sort of
entertainment offered over a flight should be integrated in to the system. Provide service
integration with vehicle rental businesses and hotel chains.
Interface for the travel agents shall be provided in the future variants with additional features like informing them of any option of seats over a flight that was earlier booked to capacity.
Choices like aisle or windows seats shall be provided to the users.
The ARS shall be able to cope with the problem where journey services can be found to multiple airports in a single city.
