[attachment=11832]
AIRLINE RESERVATION SYSTEM (ARS)
Background
This project deals with the development of a Software Requirements Specification (SRS) document that specifies what an airline reservation system should and should not do. The SRS document is divided into five sections namely
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:
1.2.4.1 Increase awareness among frequent travelers about various special offers and discounts.
1.2.4.2 Minimize the number of vacant seats on a flight and maximize flight capacity utilization.
1.2.4.3 Maintain the capability to adopt a flexible pricing policy. The price of the tickets should be dynamically determined based on how early, before the date of departure, the customer buys the ticket.
1.3 A survey conducted by airline companies shows that users of an existing reservation system would respond favorably to an ARS that satisfied or helped them satisfy the following objectives:
1.3.1 Reduce effort and frustration for travelers in scheduling a trip, especially by reducing the search effort for the flight they need to take.
1.3.2 Show all possible combinations and itineraries available for a pair of origin-destination cities.
1.3.3 Reduce redundancy in the information required from the customers in order for them to buy tickets, create user accounts etc.
1.3.4 Check the validity of input data and give a feedback to the user in case of errors or inconsistency.
1.3.5 Provide flexible access modes to users – internet, telephone, PDA.
1.3.6 Protect customers’ privacy concerns.
1.3.7 Make it easy for travelers to check the ticket status or make changes to their trip.
2. System Context
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. This interface shall provide access, only to the following functionalities, namely, check flight schedule and check ticket status including any change in the flight timings. The functionality available through this telephonic interface is limited because of security constraints.
2.2 The system and its environment and the interactions between them are depicted in the diagram below.