Online Car Rental System

Hafiz Muhammad Imran Nawaz FA19M2MB044

MCS 3RD EVENING
Software B Session:
Requirements Specification
2019-2021Document
Department Of computer science| Islamia university bahawalpur

02.02.2021
 CRS

Revision History
Date Description Author Comments
01-12-2020 Version 1.0 Hafiz Muhammad Imran First Revision
Nawaz

Document Approval
The following Software Requirements Specification has been accepted and approved by the following:
Signature Printed Name Title Date
Ms. Mehak Abbas Supervisor, CSIT 21306 02-12-2020
Ms. Quratulain Quraishi Reviewer, DAI
Ms.Sana Gul Reviewer, DCS

PAGE \* MERGEFORMAT iv
 CRS

Table of Contents

1. Introduction 1
1.1 Purpose 1
1.2 Scope 1
1.3 Definitions, Acronyms, and Abbreviations. 1
1.4 References 1
1.5 Overview 1

2. The Overall Description 2

2.1 Product Perspective 2
2.1.1 Operations 2
2.1.2 Site Adaptation Requirements 2
2.2 Product Functions 2
2.3 User Characteristics 3
2.4 General Constraints 3
2.5 Assumptions and Dependencies 3

3. Specific Requirements 4
3.1 External Interface Requirements 4
3.1.1 System Interfaces 4
3.1.2 Interfaces 4
3.1.3 Hardware Interfaces 4
3.1.4 Software Interfaces 4
3.1.5 Communications Interfaces 5
3.2 Functional Requirements 5
3.2.1 Login 5
3.2.2 Reservation 5
3.2.3 Cars 6
3.2.4 Rent 6
3.2.5 Logout 7
3.3 Use Cases 8
3.3.1 Use Case Login 8
3.3.2 Use Case Sign Up 8
3.3.3 Use Case Add Car 9
3.3.4 Use Case Delete Car 19
3.3.5 Use Case Check Status 10
3.3.6 Use Case Logout 11
3.3.7 Use Case Contact 12
3.3.8 Use Case Diagram 14
3.4 Classes / Objects 16
3.4.1 Class Diagram 16
3.5 Non-Functional Requirements 19
3.5.1 Performance 19
3.5.2 Reliability 19

PAGE \* MERGEFORMAT iv
 CRS

3.5.3 Availability 19
3.5.4 Security 19
3.5.5 Maintainability 19
3.5.6 Portability 19
3.6 Inverse Requirements 19
3.7 Logical Database Requirements 19
3.8 Design Constraints 22
3.8.1 Standards Compliance 22

4. Analysis Model 23
4.1 Sequence Diagram 23
4.2 Data Flow Diagrams 24
4.3 State-Transition Diagram 27

PAGE \* MERGEFORMAT iv
 CRS

1. Introduction
The system will provide all general services of car rental system to the customers. The customer
can book cars for rent online in few minutes. Online car rental system is very helpful to the
customers. This system includes various kinds of cars for the customers and their order, the
system will take the order and delivers cars at any location within area. The customers visit this
website and choose cars for rent online and order for book a car.

1.1 Purpose
The main objective of this SRS is to describe the system and all the requirements including
functional and nonfunctional requirements and the business logics and constrains.
The main purpose of this system is to save the time and money of human.

1.2 Scope
The scope of CRS is as follows:

 The administrator or staff can log in and manage the reservations of all Customers. They
can also change the status of reservations.
 The customer can submit their reservations online. They can view their reservations
status at their profile. The customer can also contact the administrator for any assistance.

1.3 Definitions, Acronyms, and Abbreviations.

 Car Rental System: CRS
 Data Flow Diagram: DFD
 Software requirement specification: SRS
 Hypertext preprocessor: PHP
 Hypertext markup language: HTML
 Cascade style sheet: CSS
 Search engine optimization: SEO
 Java Script: JS
 Structured Query Language: SQL

1.4 References
 www.w3schools.com
 www.Google.com
 SEII by Pressman

SRS Document 1.0 Page 1 of 27 01/05/24 f

 CRS

1.5 Overview
The structure of this SRS is as follows. Section 2 presents an overall description of the CRS.
Attention is given to putting the resultant product into perspective and further outlining end user
characteristics, system requirements functional and non- functional in nature.

2. The Overall Description

The project is designed so as to be used by Car Rental Company specializing renting cars to
customers. It is an online system. The customer login the system from login page and fill up data
that was given in page, then they performed many operation about his choice that what he wants
e.g. view car, about rent and then reserve the car.

2.1 Product Perspective

The proposed system falls under RDBMS (Rational Data Base Management System) category. I
have adopted as HTML, CSS, JAVA SCRIPT and PHP APACHE front end for the software and
MYSQL/PHP as back of end.
MYSQL is at present the most reliable and secure RDBMS tool.
The following subsections describe how the software operates inside various constraints.

2.1.1 Operations
Specify the normal and special operations required by the user such as:
 Login
 Reservation of car
 Show car details
 Feedback
 Logout

2.1.2 Site Adaptation Requirements

A user can sign up for a profile if he doesn’t have one already.
On logging in, the user has options to
 Car reservation.
 Cancellation of his/her car issued.
 View all current cars booked by him.
 Change Password etc.
 Logout.

2.2 Product Functions

Any person can query for car availability according to specified conditions.
On logging in, the user has options to
 Car issued.

SRS Document 1.0 Page 2 of 27 01/05/24 f

 CRS

 View all current cars booked by him.

 Logout.
A Person can get all information regarding a vehicle if he keys in it.
 A person can get all information regarding a car if he keys in the cars id.
 A person can get the availability of all cars for the next 20 days.
 Administrator or assigned official members can add/modify delete vehicle
information.

2.3 User Characteristics

The users will be customers which can include traveling business people, out of town visitors
and local residents in need of a car. Other users of the system will the employees both at the store
level and a headquarter. The full website also must accommodate different operating systems.

2.4 General Constraints

It provides the general description of any other items that will be limited the developer’s
options. These can include:
 Each center user has an account created and authenticated by admin. This will
be done automatically no user can share their username and password to each
other
 There is no limitation in the operating system in which car rental system will
work. User can access the system with any internet browser.
 The system should be delivered according to the decided dates.

2.5 Assumptions and Dependencies

While cost estimation of the proposed system has been assumed that cost hardware and for
license of operating system end will be met by clients. Hence only the cost incurred for the
proposed software is included there in.

2.5.1 Regularity Policies:

Each center user has account created and authenticated by admin. This will be done
automatically no user will share their username and password to other.

2.5.2 Hardware Limitations:

There is no limitations in the operating system in which Car Rental System will work. However,
the CRS and the database will work on a server that needs to be always online. User can access
the system with any internet browser.

SRS Document 1.0 Page 3 of 27 01/05/24 f

 CRS

3. Specific Requirements
 The System will contain Customers Service modules that will allow store and
Corporate employees to provided information to the customers.
 The System will contain a Customer Service module that will allow store and
corporate employees’ access to the system for the purpose of Creating “Rental
Agreements” and collects payments.
 The customer account will require name, password, email, Phone No, CNIC
no and address etc.
 The system will allow for a block reservation of more than one (1) car at a
time.
 The system will identify and additional Charges that need to be charged for
any damage to the rental vehicle.
 After the vehicle inspection is done then the system will print off a final
invoice for the costumer to sign.

3.1 External Interface Requirements

3.1.1 System Interfaces
The system will interact with the banking network for the purpose of processing payments.
The system data need will be supported by a connection to the headquarters server.

3.1.2 Interfaces
 All the users will see the same page when they enter in this website. This page
asks the users a username and password.
 After being authenticated by correct username and password, user will be
redirect to the corresponding profile where they can do various activities.
 The interface will be simple and consistence, using terminology commonly
understood by intended users of the system.

3.1.3 Hardware Interfaces

 RAM 1 GB or higher
 Processor Dual Core 1.5 or higher
 Minimum 300 GB Storage Device
 Screen Laptop, Desktop, Smartphone Mobile, IPAD
 Internet connection, 3G, 4G

SRS Document 1.0 Page 4 of 27 01/05/24 f

 CRS

3.1.4 Software Interfaces

The system is web based application it’s all processing done on sever site.
Database is based on SQL server.
 Operating System (WIN 2000 or Higher)
 Internet Browser (Mozilla Firefox, Netscape Navigator, Opera, Google
chrome)
 PHP as a Front-end Tool
 MYSQL as a Back-end Tool
3.1.4.1 PHP local Server
The car rental system web based application that is xamp/wamp server as a database to
access customer records using PHP at back hand on server side.

3.1.5 Communications Interfaces

 This system use communication resources which includes but not limited to,
HTTP protocol for communication with the web browser and web server and
TCP/IP network protocol with HTTP.
 This application will communicate with the database that holds all the
booking information. Users can contact with server side through HTTP
protocol by means of a function that is called HTTP services.

3.2 Functional Requirements

The proposed system facilitates the customers to fill up their details, and to give a brief
description of a vehicle they want to book. This new system is very useful for customers
who want to hire their vehicles through this site.

3.2.1 Login
 The system should allow the manager to login and logout to the system using
their username and password.
 The system shall allow the admin to change account password.
 The system shall allow admin to logout.

Input:
 Customer data new customer (added)or old one (fetched)

Processing:
 Data will be checked for old customer
 New customer data will be updated

Output:
 Successfully log in or failed

SRS Document 1.0 Page 5 of 27 01/05/24 f

 CRS

Error handling:
 If log in failed then error cause will be showed.

3.2.2 Reservation
 The system must allow the customer to register for reservation.
 The system shall allow the customer to view detail description of particular
vehicle.
 The system must notify on selection of unavailable vehicles while reservation.
 The system must allow the customers to select specific vehicle using different
search category while reservation.

Input:
 Customer data new customer or old one

Processing:
 Data will be checked for old customer
 New customer data will be updated
 Specific Vehicle will be searched

Output:
 Successfully reserved or not

Error handling:
 If reservation is failed message will be shown.

3.2.3 Car
 The system should allow admin/staff to register new cars.
 The system shall allow admin/staff to update information of the cars in need
of modification.
 The system shall allow admin/staff to display the entire available cars.

Input:
 Car data new or old one

Processing:
 Data will be checked for car
 New car data will be updated
 Specific car will be searched

Output:
 Successfully rented or not

SRS Document 1.0 Page 6 of 27 01/05/24 f

 CRS

Error handling:
 If reservation is failed message will be shown.

3.2.4 Rent
 The system shall allow staff to register customers into rental list.
 The system shall allow staff to update about customer rent record details in
the rental list.
 The system shall allow staff to display all customers, who rent vehicles.
 The system shall allow staff to display all customers rent record.

Input:
 Selected car

Processing:
 Data will be checked from car
 Rent will be checked
 Specific car rent will searched

Output:
 Successfully displayed rent list

Error handling:
 If list is failed to display then again checked.

3.2.4 Logout

Introduction
 Admin or user shall be able to logout to a computer.

Inputs
 The person clicks the logout option to logout.

Processing
 Person session is destroyed.

Outputs
 Logout successfully.

Error Handling
 If the person clicks the logout option and the person is not logout a message is
displayed and shows an error occurs please try again.

SRS Document 1.0 Page 7 of 27 01/05/24 f

 CRS

3.3 Use Cases

This section contains use cases of the Car Rental System. Actor and use case shows the detail
description of interaction between the actors and their use cases.

3.3.1 Use Case Login

This use case describes the process of admin login in the application to see the all
products in the site.

Figure: 3.1 Use Case Login Diagram

Flow of events:-
Primary scenario:-
 Administrator will run application and login window will opened.
 Administrator will enter username/email.
 Administrator will enter password.
 Administrator will click the login button.
 This use case ends.
Exceptions:-
 The User is not admin.
 The Username or password is incorrect.
Post condition:
 The admin logs in successfully.

3.3.2 Use Case Sign Up

Description: This use case describes the process of user sign up to the system.

SRS Document 1.0 Page 8 of 27 01/05/24 f

 CRS

Actor: Customer.

Add Detail

Sign Up

User
Figure: 3.2 Use Case Sign Diagram
Pre-condition:-
 Internet must be connected.
 Any browser should be in execution.
Flow of events:-
Primary Scenario:-
 The user will enter the correct details.
 Admin will check the user request.
 Admin will respond the user request.
 This use case ends.
Exceptions:-
 This properties are not available or it sale.
 These properties no exist here post condition.
 User signup successfully.

3.3.3 Use case Add post:

Description: This use case describes the process of admin to add the car.
Actor: Administrator.

Add Car

View Car

Admin

SRS Document 1.0 Page 9 of 27 01/05/24 f

 CRS

Figure: 3.3 Use Case Add Car Diagram

Pre-condition:-
 Administrator should be logged in.
Flow of events:-
Primary Scenario:
 Administrator will login to website.
 He will add the car detail.
 Admin will press the add button.
 This use case ends.

3.3.4 Use Case Delete Post:

Description: This use case describes the process of admin to delete the Car.
Actor: Administrator

Select Car

Delete Car

Admin

Figure: 3.4 Use Case Delete Car Diagram

Pre-Condition:-
 Administrator should be log in.
Flow of events:-
Primary Scenario:-
 Administrator will login to website.
 He will select the Car to delete.
 Admin will press the Delete button.
 This use case ends.

3.3.5 Use case check status:

Description: This use case describes the process of admin to check status.

SRS Document 1.0 Page 10 of 27 01/05/24 f

 CRS

Actor: Administrator.

Figure: 3.5 Use Case Check Status Diagram

Pre- condition:-
 Administrator/manager must be logged in.
Flow of events:-
Primary Scenario:-
 Administrator will log in to the main login part.
 Administrator will check the status of the system.
 The Administrator will update to the database.
 Administrator will respond about the status.
 This use case ends.
Exceptions:-
 The administrator isn’t signed in.
 The required data is not provided.

Secondary Scenario:-
 The admin check status successfully.

3.3.6 Use case logout:

Description: This use case describes the process of logout.
Actor: Administrator

SRS Document 1.0 Page 11 of 27 01/05/24 f

 CRS

Figure: 3.6 Use Case logout Diagram

Pre- condition:-
 Administrator must be login.
Flow of events:-
Primary Scenario:-
 Administrator running the application and must be login.
 This use case ends.
Exceptions:-
 User is not active.
Secondary Scenario:-
 Administrator may cancel the operation.
Post condition:
 Admin logout successfully.

3.3.7 Use Case contact:

Description: This use case describes the process of buying property.

Check
Status

Email/Phone

User

SRS Document 1.0 Page 12 of 27 01/05/24 f

 CRS

Figure: 3.7 Use Case contact Diagram

Pre-Condition:-
 User must be login to check status.
Flow of Events:-
Primary Scenario:-
 User must open the site to check email or Phone.
 This use case ends.
Exceptions:-
 Browser may does not work properly.
 Site may be under Construction.
 Internet may not work properly.
Secondary Scenario:-
 User may cancel the operation.

3.3.8 Use Case Diagram.

<<Extend>>
See Post

<<Include>>
Reservation
Login
<<Include>>
Cancel Admin

<<Include>>
Payment

Customer Inquiry for <<Include>>

Order
SRS Document 1.0 Page 13 of 27 01/05/24 f
 CRS

<<Include>>
Feedback

Deliver Car <<Include>>

Upgrade <<Include>> Staff

system

<<Include>>
Logout

Figure: 3.8 Use Case Diagram

Actor and use case description shows the detail description of interaction between the actors and
their use cases. The description enables to have a proper understanding of how actor interacts
with the system through their use cases.
Customer
Register as member
This use case describes the activities of the customer to register online and become a member.
Customer's details are required as part of the registration. Login detail is automatically sent to the
customer after successful registration.
Make reservation
This use case enable customer to search and make reservation. Non-register customer will be
directed to register before their reservation can be confirmed. Notification is automatically send
to the customer after the task is completed.
Return car
This use case describes the event of customer returning the car borrowed, the use case extends
"process rental" use case from the staff actor.
Give feedback
This use case is used by the customer to provide feedbacks/comment to the company; a
confirmation notification will be send to the customer once a feedback has been submitted.
Staff

SRS Document 1.0 Page 14 of 27 01/05/24 f

 CRS

Add new car

This use case is used by the staff to add new car to the company's fleet database. Staff will need
to login to activate this use case.
Update car details
This use case is used by the staff to edit and modify car details whenever there is new renewal
(insurance, road tax). It allows the company to keep up-to-date record of their fleet.
Reply to customer’s feedback
This use case describes the event by which staff sends reply to customer's earlier feedback. It
depends on `give feedback' use case from the customer.
Process rental
This use case described the event by which staff updates the system when customer pick up or
when returning car.
Admin
Add new car
This use case is used by the staff to add new car to the company's fleet database. Staff will need
to login to activate this use case.
Update car details
This use case is used by the staff to edit and modify car details whenever there is new renewal
(insurance, road tax). It allows the company to keep up-to-date record of their fleet.
Reply to customer’s feedback
This use case describes the event by which staff sends reply to customer's earlier feedback. It
depends on `give feedback' use case from the customer.
Process rental
This use case described the event by which staff updates the system when customer pick up or
when returning car.
Check messages
A new user or customer can contact through message admin will check these messages take the
necessary actions.

3.4 Classes / Objects

This section contains major classes of the Car Rental System.

3.4.1 Class Diagram

This section contains major classes of the “Online car rental system”.
Admin

SRS Document 1.0 Page 15 of 27 01/05/24 f

 CRS

Attributes (Id, Username, Password, Email)

Customer
Attributes (Id, Username Password, Email, Name, Phno, CNIC, Address)
Reservation
Attributes (Id, Customer ID, Car ID, Reservation Date, Return Date, Location, Driver)
Car
Attributes (Id, Name, Model, Color, Registration no, Rate)
Feedback
Attributes (Id, Customer ID, Feedback title, Feedback Type, Feedback Description, Date)
Payment
Attributes (Id, Customer ID, Car ID, Transaction Id, Transaction Type, Date, Amount)
Description
In the below diagram we can see the class diagram of car rental system. In this diagram we can
see the different classes of the system and their attributes and functions. Every class divided into
3 parts class name, attributes and functions. Car rental system will manage all the things that are
written in the diagram like, car, payment, admin, customer and reservation feedback etc.

SRS Document 1.0 Page 16 of 27 01/05/24 f

 CRS

Payment
Id: Integer
Customer Id: Integer
Car Id: Integer
Transaction Id: String
Transaction type: String
Date : String
Amount: double
Add (): public
View (): public

Admin
Id: Integer
Name : String
Password: String
Email: string
Add (): public
View (): public
Update (): public
Delete (): public

Customer
Cars
Id: Integer Reservation
Name : String Car Id: integer
Password: String Id: Integer Car Name : string
Email: String Customer ID: Integer Car model: String
Phno: String Car ID: Integer Car color: String
CNIC: integer Reservation date: String Registration no: String
Address: string Return date: string Rate: integer
login (): public Feedback Location : Map Add Cars(): public
Update profile (): public Driver: Boolean List Cars(): public
Id: Integer Create reservation(): public
Search Cars(): public
Reservation (): public
Customer Id: Integer List of reservation():public
Delete Cars(): public
Feedback (): public
Feedback title: String View reservations():public
Feedback Type: String Search reservation():private
Feedback Description:
String
Date: String
Create feedback(): public
Lit of feedback(): public
Search feedback(): public
Delete feedback(): public

SRS Document 1.0 Page 17 of 27 01/05/24 f

 CRS

Figure: 3.9 Class Diagram

3.4.1.1 Attributes
Entities List

Customer Car Reservation Admin Payment Feedback

Entity Attributes
Customer Car Reservation Admin Payment Feedback

Customer_id Car_id Reservation_id Admin_id Payment_id Feedback_id

Customer_name Car_name Customer_id Admin_name Customer_id Customer_id

1.5
Customer_password Car_model Car_id Admin_passw
ord
Car_id Feedback_title
Customer_email Car_color Reservation_date transaction_id Feedback_type
2. Admin_email
Customer_Phoneno Car_registration Return_date transaction_type Feedback_Desc
_no ription
Customer_CNIC Location Date
Car_rate Date
Customer_Address Driver Amount

3.4.1.2 Functions
 The system must allow the customer to register for reservation.
 The system shall allow the customer to view detail description of particular
vehicle.
 The system must notify on selection of unavailable vehicles while reservation.
 The system must allow the customers to select specific vehicle using different
search category while reservation.
 The system should allow admin/staff to register new vehicles.
 The system shall allow admin/staff to update information of the vehicle in
need of modification.
 The system shall allow admin/staff to display the entire available vehicle.

SRS Document 1.0 Page 18 of 27 01/05/24 f

 CRS

3.5 Non-Functional Requirements

Non-functional requirements, as the name suggests, are requirements that are not directly
concerned with the specific services delivered by the system to its users. They may relate to
emergent system properties such as reliability, response time, and store occupancy.
Alternatively, they may define constraints on the system implementation such as the capabilities
of I/O devices or the data representations used in interfaces with other systems. On-functional
requirements, such as performance, security, or availability, usually specify or constrain
characteristics of the system as a whole.

3.5.1 Performance
The response time of the system for every instruction given by the user must not exceed
minimum of 10 seconds. The system should do best performance when executing user’s
instruction should be able to give response within a very short time.

3.5.2 Reliability
It is reliable and can be used with further new features.

3.5.3 Availability
The system should available always 24/7 a weak.

3.5.4 Security
The system should take the login information of the user to see the posts etc.

3.5.5 Maintainability
Any change and new updating can be made easily with few resources.

3.5.6 Portability
The system shall run in any Microsoft Windows environment that contains Java Runtime and the
database.

3.6 Inverse Requirements

When the system is completely developed and submitted to the client, few sessions will be
required to make the users of the system understand about the functionally of it and some time to
adapt to the system. After those sessions, it’s required that a member from the development team
should spend sometime in the system background for an agreed time period. That time period
will be used in identifying new bugs that could not be reached in the earlier phases of the
development process. Client should have a valid e-mail account in order to receive notifications.

3.7 Logical Database Requirements

The data in the database should be is in Entity Relationship.
The data in the database should not be duplicated.
The data in the database should be store in the form of tables.

SRS Document 1.0 Page 19 of 27 01/05/24 f

 CRS

Customer E-R diagram

Passwor Email
Ph.no
d
Custome
r name CNIC

Custom Address
er- id Customer

Figure: 3.10 Customer E-R Diagram

Description
In this customer ER diagram Customer is the entity and his id, name, password, Ph.no etc. are his
attributes that will be given by the customer to make his account on the system for reservation.
Car E-R diagram

Car Car
model color
Registra
tion no
Car name

Rate
Car id
Car

Figure: 3.11 Car E-R Diagram

Description
In this car ER diagram Car is the entity and it’s id, name, model etc. are it’s attributes that will be
given by the admin or staff to show the detail of the cars to customers for reservation.

SRS Document 1.0 Page 20 of 27 01/05/24 f

 CRS

Reservation E-R diagram

Reservatio
n date Return
Car id
date
Custom Location
er id

Reserva Reservation Driver

tion id

Figure: 3.12 Reservation E-R Diagram

Description
In this reservation ER diagram Reservation is the entity and reservation id, reservation date,
return date, driver are it’s attributes that will be given by the customer for reservation. And some
other attributes will take from customer table and car table that will be used as foreign key.
Payment E-R diagram

Transacti
Transacti
Car id on id
on Type

Custom Date
er id

Paymen Payment Amount

t id

Figure: 3.13 Payment E-R Diagram

Description
In this reservation ER diagram Payment is the entity and payment id, transaction id, transaction
type, transaction date, are it’s attributes that will be given by the customer for payment detail.
And some other attributes will take from customer table and car table that will be used as foreign
key.

SRS Document 1.0 Page 21 of 27 01/05/24 f

 CRS

Feedback E-R diagram

Type
Title Descripti
on
Custom
er id Date

Feedba Feedback
ck id

Figure: 3.14 Feedback E-R Diagram

Description
In this reservation ER diagram Feedback is the entity and feedback id, title, type, description,
date are it’s attributes that will be given by the customer for reservation. And some other
attributes will take from customer table that will be used as foreign key.

3.8 Design Constraints

Since CRS will be used on PCs and will function via internet or Intranet in any browser.

3.8.1 Standards Compliance

There shall be consistency in variable names within the system. The graphical user interface
shall have a consistent look and feel.

SRS Document 1.0 Page 22 of 27 01/05/24 f

 CRS

4. Analysis Models of CRS

The analysis model is a concise, precise abstraction of weather desired system must do, and not
how it will be done after the study of the existing system is completed.
The steps which are essential models analysis are:
 Research and define essential components.
 Review draft requirements document with user, Trainers and other concerned
personnel.
 Expand and Update project plan.

4.1 Sequence Diagrams of CRS

Sequence diagrams are used to demonstrate the behavior of objects in a use case by describing
the objects and the messages they pass. It provides a graphical representation of object
interactions over time. Sequence diagrams show an actor, the objects and components they
interact with in the execution of a use case. One sequence diagram represents a single Use Case
'scenario' or events. Sequence diagrams show the flow of messages from one objector another,
and as such correspond to the methods and events supported by an object.

Customer Staff Car Records Owner/

Admin

Inquiry for car Check for availability

Car available

Give detail

Give order

Give payment

Check for feasibility Receipt generation

Deliver car

Return car

Feedback

Figure: 4.1 Sequence Diagram

SRS Document 1.0 Page 23 of 27 01/05/24 f

 CRS

4.2 Data Flow Diagrams of CRS

A data flow diagram (DFD) is a graphical representation of the flow of data in which information
system and modeling. A DFD is often used as a preliminary step to create an overview of the
system, which can be elaborated.
Context Diagram

Reservation
Management

Car Customer
Management Management
Car
Rental
System
System User
Payment
Management
Management

Login
Management

Figure: 4.2 Context Diagram

Description
In the above diagram we can see the context diagram of car rental system. In this diagram we can
see what type of functions can be performed in the system. Car rental system will manage all the
things that are written in the rectangle shape like, car, payment login, system user, customer and
reservation etc.

SRS Document 1.0 Page 24 of 27 01/05/24 f

 CRS

1st Level DFD

Car Generate Car

Management Report

Reservation Generate
Management Reservation Report

Customer Car Rental

Generate Customer
Management System
Report

Payment
Generate Payment
Management
Report

Login Generate Login

Management Report

System User Generate System

Management User Report

Figure: 4.3 1st level DFD

Description
In the above diagram we can see the 1st level data flow diagram of car rental system. In this
diagram we can see how data will flow in the system. Car rental system will manage all the
things that are written in the left side like, car, payment login, system user, customer and
reservation and will generate their reports according to them.

SRS Document 1.0 Page 25 of 27 01/05/24 f

 CRS

2nd Level DFD

Log in to
Admin system

Check rules Manage Car

of access Details

Manage Customer
Forget
Details
Password

Check Mange Reservation

credentials Details

Manage Payment
Details
Send Manage
Email to Modules
user
Manage Rent
Details

Manage Feedbacks

Manage system Manage user permission

Manage rules of users
admins

Figure: 4.4 2nd level DFD

Description

SRS Document 1.0 Page 26 of 27 01/05/24 f

 CRS

In the above diagram we can see the 2 nd level data flow diagram of car rental system. In this
diagram we can see how admin control the system. Admin manage all the modules that are
written in the rectangle shape like, car, payment, system user, customer and reservation. If the
customer forgets his password admin will send a new password to the customer and then
customer will change his password.

4.3 State- Transition Diagrams Of CRS:

An STD is a way of describing the time-dependent behavior of the system. The basic consistency
rule is:” A system’s behavior in any state must be the same, no matter by which path the state is
arrived at”.

Company Busy

Company Sells Available do/check

maintenance
Machine Release

Customer Rents Customer

Returns Maintenance required/logout of

Information Services Out of Service

Rented

Figure: 4.5 State Transition Diagram

SRS Document 1.0 Page 27 of 27 01/05/24 f