Chapter 1

Introduction

1.1 Purpose

The purpose of this document is to present a detailed description of the Tourism management System. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document is intended for both the stakeholders and the developers of the system.

1.2 Project Scope

The Tourism Management System project is an implementation of a managing Tourism website which helps the customers to search the availability of various tourist places and prices of various hotel rooms in particular places, along with the different packages available with the reservations. This project also covers various features like online registration of the users, modifying the details of the website by the management staff or administrator of the website, by adding, deleting or modifying the customer details or packages information. In general, this website would be designed to perform like any other Tourist management website available online .

1.3 Intended Audience

Developer, tester, and administrators will have access to this SRS. Hotel staff will use this system for updating their information in the database. Tourists information will also be stored in the system. Admin uses this to monitor expenses.

1.4 Risk Definition

-It should maintain database of the project and its tourists and hotels. If there is any changes or update in the information it should be dealt nicely. -OS must handle expected or unexpected errors in ways that prevent loss in information and long down time periods. -System will ensure no data is lost in case user change devices or if the user’s device is extensively damaged.

Chapter 2

Overall Description

2.1 Product Functions

Thus this system like a self-containing shell, that covers all the major aspects in the computerization of tourist agency. Some tasks are described in detail : Sight Seeing Tours: Tourist can enjoy, sightseeing tours to any of the place, listed in Agencies Data File. Before that Customer has to make the booking by registering his/her name in Data-File and informing date of journey and No. of operations. Hotels: Agency also makes the reservation for the Hotels registered with agency. Billing: Once the Customer makes the booking or reservation, Bill will be generated for him/her, and money has to be paid on the spot itself. Report Generation: Details about the locations, hotels in that location and final report on the journey fare.

2.2 User Classes and Characteristics

Customer: The one who uses the system. For which the system is created. Manager: The one who manages the system, provide details to the customers Administrator: The one who operates the system , modifies ,add or delete the customer records in databases.

2.3 Operating Environment

Platform: Javascript/ Python/ Django. Operating System: Any system that supports a modern web browser. For this project, we are using windows10. Software: PyCharm, Atom, Django Framework. Database Configuration: SQL for Database

2.4 Constraints

• The developed system must work in both window, macOS and Linux. • The implementation language must be in Python. • This problem must be solved in 2 months with the given amount. • User’s current training/education level must be given.

2.5 Assumptions

• The users can understand English/Bengali language. • The users have moderate laptop or desktop and updated software. • PC with sufficient RAM and ROM will be providing the best performance as data collections and moderation depends on the RAM and ROM amount and data transmission speed. • Proper browser should be used for the web app and a stable internet connection is required. • Users have some basic ideas of operating this kind of software.

Chapter 3

Requirements

3.1 Functional Requirements

Customer module: There are two types of users. Visitors to the site and Tourists. The user module has the following sub divisions.

1. Search: All visitors to the system can search for tourist centers in Kerala, as per specific location, district, category and season. They can get information about different recreational facilities available at each Tourist centers and information about facility providers, quality and cost.
2. Registration: The tourist who wishes to avail of the facilities provided by DTPC has to register with the system giving all the details. He / she have to provide a user id and password. The registration process, user login process, security checking regard to these is taken care of in this module.
3. Online Booking: In this module tourists can book online the following facilities: Home stay, travel agents, Health care centers (Indian System) and hotels / restaurants, one month in advance. They can also make on line payment of bills for booking. They can also cancel the booking and get the payment back after deduction booking charges.
4. Feed back: Options to give feed back by the users are coming under this sub module.

Administrator Module: This module has the following sub modules. 1.Information Module: In this module there provides data about different Tourist centers photos, clippings, audio and video gallery. Addition, deletion and modification of data is taken care of in this module. New centers with all information are added in the system. 2.Client Module: Recreational facilities and service providers at tourist centers are considered as clients of the system. They have to register first before doing operations. Therefore in this module online registration of clients, cancellation of a client permit, client login, and security checking are taken care of. 3.Reports Mail: Generation of different reports, sending mails to clients and tourists, providing reports and data are considered here. 4. Advertisements: The clients can advertise here .The functionality is developed and executed in this module

3.2 Non Functional Requirements

3.2.1 Performance Requirements

The Tourism management System application should be able to respond to the queries submitted by the customer without much delay. When a user searches for a tour location, the application should not take much time to return the results, similarly for the motel and package information. Considering that the application is of moderate size, it should be able to display 10 results at a time on each page, when the customer looks up for any particular data. Since the Online tourism websites have much traffic, the user should also be able to logon to the system using high speed internet. Most of the requests sent to the application should be answered in less than 5 seconds.

3.2.2 Security Requirements

It must be ensured that access will be provided to the authorized persons through user ID and password. Network security will be provided by the use of firewalls. Checks can be performed at regular internals to ensure data integrity 3.2.3 Software Quality Attributes Reliable: For all services that rely on TMS for access control, lack of availability of the supported services. The product should not crash under any circumstance such as user entering invalid values, user trying to find unusual data etc. It should show appropriate message for every user generated message. Transparent: Ideally, the user should not be aware that authentication is taking place beyond the requirement to enter a password. Salable: The system should be capable of supporting large number of client and servers.This suggests modular, distributed architecture. Portable: Our product will be portable to carry and will run in any machine provided it runs a Windows Operating System.

Appendices

Appendix A

Glossary

Term their definitions are listed below. Active Article:The document that is tracked by the system; it is a narrative that is planned to be posted to the public website. Author Person submitting an article to be reviewed. In case of multiple authors, this term refers to the principal author, with whom all communication is made. Database: Collection of all the information monitored by this system. Editor: Person who receives articles, sends articles for review, and makes final judgments for publications. Field: A cell within a form. Historical Society Database: The existing membership database (also HS database). Member: A member of the Historical Society listed in the HS-database. Reader: Anyone visiting the site to read articles. Review: A written recommendation about the appropriateness of an article for publication; may include suggestions for improvement. Reviewer: A person that examines an article and has the ability to recommend approval of the article for publication or to request that changes be made in the article. Software Requirements Specification: A document that completely describes all of the functions of a proposed system and the constraints under which it must operate. For example, this document. Stakeholder: Any person with an interest in the project who is not a developer. User: Reviewer or Author.