SOFTWARE REQUIREMENTS

SPECIFICATION

VEHICLE RENTAL WEBSITE

UDAYA SOWMYA K
2403917762222028
MCA I
 TABLE OF CONTENTS
S.No Title PageNo
1 Introduction 3
1.1 Purpose 3
1.2 Scope 3
1.3 Definitions, Acronyms, and Abbreviations 3
1.4 References 3
1.5 Overview 4
2 The Overall Description 4
2.1 Product Perspective 4
2.2 Product Functions 4
2.3 User Characteristics 4
2.4 Constraints 5
2.5 Assumptions and Dependencies 5
3 External Interface Requirements 5
3.1 User Interfaces 5
3.2 Hardware Interfaces 6
3.3 Software Interfaces 6
3.4 Communications Interfaces Requirements 6
4 System Features 6
4.1 User Management 6
4.2 Product Management 6
4.3 Shopping Cart and Wishlist 7
4.4 Payment Processing 7
4.5 Order Management 7
5 Other Non-Functional Requirements 7
5.1 Performance Requirements 7
5.2 Capacity 8
5.3 Dynamic Requirements 8
5.4 Quality Requirements 8
5.5 Reliability 9
5.6 Availability 9
5.7 Security 9
5.8 Maintainability 10
6 Business Rules 10
7 Appendix 11
1. Introduction

1.1 Purpose

The purpose of this document is to provide a detailed Software

Requirements Specification (SRS) for the vehicle rental website. It serves as a
blueprint for the design and development of the system, outlining the
functional and non- functional requirements, system features, and constraints.
This system enables users to browse, book vehicles, manage their profiles, and
make payments. It also provides admin functionalities for managing vehicles,
users, and bookings.

1.2 Scope

The system is designed to accommodate both guest and registered users,

offering a seamless experience across desktop and mobile devices. Users can
browse the available vehicles and view detailed information about each one.
The system also allows for booking rentals, including selecting the desired date
and time. Registered users benefit from additional features, such as managing
their profiles and viewing booking history. The payment process for bookings is
integrated into the platform, ensuring secure and efficient transactions. Admin
users have dedicated tools to manage the vehicle inventory, oversee user
accounts, and track booking history, maintaining smooth operation and up-to-
date information.

1.3 Definitions, Acronyms, and Abbreviations

 Guest User: A user who has not registered an account but can
browse vehicles and make bookings.

 Registered User: A user who has created an account and can

manage their profile, view booking history, and save payment
details.

 Admin: A user with special permissions to manage vehicles, users,

and bookings within the system.

 Booking: A reservation made by a user for a vehicle rental.

 Payment Gateway: The service used to process payments for bookings.

1.4 References

 PCI DSS (Payment Card Industry Data Security Standard)

 ISO 27001 - Information Security Management Systems (ISMS)

Car Rental Website Development Tips: All You Need to Know |

Stfalcon

1.5 Overview

It includes an overall description of the product, user

characteristics, system features, external interface requirements, and
non-functional requirements.

2. The Overall Description

2.1 Product Perspective

The vehicle rental system will be a web-based application that

interacts with a back-end server to provide real-time data for users. The
system integrates with third-party payment gateways for secure payment
processing.

2.2 Product Functions

 Vehicle Browsing: Users can search and filter available vehicles

based on different parameters (e.g., vehicle type, price range,
availability).

 Booking: Users can reserve vehicles for specific time periods.

 Profile Management: Registered users can view and update their

profile, including personal information and booking history.

 Payments: The system will process payments via an integrated

payment gateway.

 Admin : Admin users can manage vehicles, users, and bookings.

2.3 User Characteristics

 Guest Users: Can browse vehicles and make bookings, but

cannot manage profiles or view past bookings.

 Registered Users: Can manage their profile, view booking history,

and save payment information.

 Admin Users: Have permissions to view, create, update, and

delete vehicles, manage user profiles, and view all booking data.

2.4 Constraints

 The system must be accessible from modern web browsers

(Chrome, Firefox etc.).

 The payment gateway must comply with PCI-DSS security standards.

 The website must be responsive, supporting both desktop and

mobile devices.

2.5 Assumptions and Dependencies

 The system relies on third-party services for payment processing

and vehicle location tracking.

 Users must have internet access to interact with the system.

3. External Interface Requirements

3.1 User Interfaces

 Homepage: Displays featured vehicles, search bar, and login options.

 Search Results: Shows a list of available vehicles with filters for sorting.

 Vehicle Detail Page: Provides detailed information about each vehicle.

 Booking Form: Allows users to select the rental period and complete
the reservation.

 User Profile Page: Displays user information, booking history,

and payment methods.
  Admin Dashboard: Provides an interface for admins to manage
vehicles and users.

3.2 Hardware Interfaces

 Web Server: Hosts the web application.

 Payment Gateway: External service to handle transactions.

3.3 Software Interfaces

 Payment Gateway API: For processing payments securely.

 Database: Stores user information, vehicle data, and booking history.

3.4 Communications Interfaces Requirements

 The system must support HTTPS for secure communication between

the client and server.

 Integration with external payment systems via APIs for

payment processing.

4. System Features

 Vehicle Management (Admin): Admins can add, update, and

remove vehicles, set availability, and manage pricing.

 User Management (Admin): Admins can view user details,

manage accounts, and reset passwords.

 Booking Management: Admins can view all bookings, update

status, and cancel bookings if necessary.

 Search Functionality: Users can filter vehicles by type, availability,

and price range.

5. Other Non-Functional Requirements

5.1 Performance Requirements

 The system should handle up to 100,000 users concurrently.

  Response time for browsing vehicles should be under 2 seconds.

5.2 Capacity

 The system should support up to 10,000 active users at any given time.

5.3 Dynamic Requirements

 The system must dynamically update vehicle availability in real-time.

 The booking system should prevent double-booking for the same

vehicle at the same time.

5.4 Quality

 The system must be highly intuitive, with minimal learning curve

for users.

5.5 Reliability

 The system should be available 99.9% of the time.

5.6 Availability

 The system should be accessible 24/7.

5.7 Security

 Data transmission must be encrypted using SSL.

 Payment information should never be stored on the system.

5.8 Maintainability

 The system should allow for easy updates, with minimal downtime.

6. Other Requirements

 Multi-language Support: The system should be able to display

content in multiple languages, depending on user preference.

 Accessibility: The website must comply with WCAG 2.1 standards

to ensure accessibility for users with disabilities.

7. Business Rules
  Prices will be applied according to predefined pricing rules
(e.g., rental duration, vehicle type, seasonal pricing, discounts).

 Users must have an account to make a booking (requiring age

and license verification).

 All vehicles must comply with local safety and regulatory standards

(e.g., roadworthiness, insurance, maintenance).

 Admins have full control over the system, including managing

vehicle availability, customer accounts, and booking details.

 Customers can browse available vehicles, add to cart,

complete bookings, and track rental status (pickup, drop-off,
return).

 Bookings must be confirmed immediately after payment

(confirmation sent via email or SMS within seconds).

Appendix A: Glossary
 Booking Confirmation: The final step in the booking process,
where a user receives a receipt and details of their reservation.

 Payment Gateway: A service that processes credit card and other

forms of payments securely.

Appendix S: Analysis Models

 Use Case Diagrams: Visual representation of system interactions.

 Entity-Relationship Diagram (ERD): Diagram

showing the relationships between data entities.

 Class Diagrams: Visual models that represent the system's

object- oriented design.

 System Architecture: A high- level diagram showing how different

components of the system interact
 CRC DIAGRAMS

ENTITY – RELATIONSHIP DIAGRAM

SEQUENCE DIAGRAM
CLASS DIAGRAM
ACTIVITY DIAGRAM
DATA FLOW DIAGRAM