09-03-2012, 03:24 PM
Airline Reservation System
[attachment=18163]
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.
[attachment=18163]
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.
