RE: Airline Reservation System
|| AIRLINE RESERVATION SYSTEM
Ars2.doc (Size: 105.5 KB / Downloads: 63)
1. System Objectives
This section lists all the goals and objectives of the system categorized based on the viewpoint of the airline company and the customer (passenger). These are higher-level goals which are somewhat broad in nature. They help in a top-down development of the SRS.
2. System Context
This section clearly depicts the environment and boundaries of the ARS and the entities with which it interacts. It helps us see how the system fits into the existing scheme of things. What the system will do by itself and what it expects other entities to do is clearly delineated.
3. Functional Requirements
This section is the bulk of the document and precisely states the functions of the system – what it should do and what it should not. This section is split into subsections modeled after the real world activities like reserving tickets, rescheduling tickets etc. Freedom from ambiguity and navigability were kept in mind while documentation. A consistent terminology has been followed throughout and the terms are explained in the appendix. The subsections follow a logical sequence that reflects the real world. For example, a customer cannot reschedule a ticket unless he has bought one earlier and cannot buy one unless he has checked its availability.
4. Non-functional Requirements
These are quality requirements that stipulate the performance levels required of the system for various kinds of activities. Numerical lower and upper limits set conditions on the response times, access times etc of the system. Sometimes, tradeoffs are necessary among various non-functional requirements.
5. Future Requirements
These are the specifications which are not provided for now in the current version of ARS but which could be incorporated into future versions. Some of these need advanced technologies and interfaces with other systems. The ARS could be designed in future to enhance the existing capabilities or add entirely new ones.
The assumptions and limitations of the ARS have been interspersed in the SRS to present the same in their proper context.
1. System Objectives
1.1 The Airline Reservation System (ARS) is a software application to assist an airline with transactions related to making ticket reservations, which includes blocking, reserving, canceling and rescheduling tickets.
1.2 From the viewpoint of the airline -
1.2.1 Minimize repetitive work done by the system administrator and reservation clerks.
1.2.2 Maintain consistency among different access modes, e.g. by phone, by web, at the information desk and across different physical locations. The users should be basically taken through the same steps by the system as they go through in conventional desk-reservation systems.
1.2.3 Maintain customer information in case of emergency, e.g. flight cancellation due to inclement weather. The profile can also be used by the airline company to track 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 airline company by various means:
18.104.22.168 Increase awareness among frequent travelers about various special offers and discounts.
22.214.171.124 Minimize the number of vacant seats on a flight and maximize flight capacity utilization.
2.1 The ARS will provide the following types of easy-to-use, interactive, and intuitive graphical and telephonic interfaces.
2.1.1 The ARS will provide an easy-to-use, intuitive Graphical User Interface (GUI) as part of 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 general customers.
2.1.3 The above two ARS interfaces shall help provide the following functionalities to the users - access to the ARS to check the flight schedule, availability of seats, ticket price and to block, reserve, cancel, and reschedule tickets.
2.1.4 The ARS will also provide an easy-to-use, simple telephonic user interface, which can be accessed by the customers through telephone or cell phone from anywhere.
3.1 User Accounts
3.1.1 The passenger, who will henceforth be called the ‘user’, will be presented with 3 choices by the reservation system, as the first step in the interaction between them. A user can choose one of these and his choice would be governed by whether he is a guest or a registered user and whether he wants to check the availability of tickets or also block/buy them. The terms ‘registered user’ and ‘guest’ are described below.
126.96.36.199 A user who has traveled by the airline earlier would have been given a user id and a password. He would have his personal information stored in the database referred to earlier in section 2 as ‘DB-user’
Registration and creation of user profile
The system shall require a user to register, in order to carry out any transactions with it except for checking the availability of tickets. It will ask the user for the following information at the least – a user id, a password, first name, last name, address, phone number, email address, sex, age, preferred credit card number. The system will automatically create a ‘sky miles’ field and initialize it to zero in the user’s profile.
3.3 Checking Availability
3.3.1 After logging in a user (either a registered user or a guest), the system shall request him to enter the following details – origin city and destination city. “City’ is a generic term and refers to a city or town as the case may be. The origin and destination cities would be entered as text.
3.3.2 The system shall now refer to the flight schedule database, referred to as ‘DB-geography’ in section 2, and check if there is any ambiguity with the names of the cities. In case there are more than two cities with same name as entered by the user, the system shall list all of them (with more qualifications) and ask the user to select one of them. In case, either the origin or destination cities are not listed in DB-geography as being directly serviced by the airline, the system shall suggest the nearest city to which service is available, including the distance of the destination city from this nearest city.