Parking Revenue Management System

Software Requirements Specification

Version 1.0

Group Id: S1802024CA (MC160200254)

Supervisor Name: Arif Hussain

 Revision History
Date Version Description Author
(dd/mm/yyyy)
09/05/2018 1.0 The aim of the project is to develop a MC160200254
Mobile Based Parking Revenue Collection
System, with a Web Based Portal, which
would facilitate the Government to collect
and manage the revenue and monitor
activities at the parking sites on real time.
Other than the government, this software
can be used by Hospital managements or
Mall managements to operate their
parking
 Table of Contents

Contents
1 Overview......................................................................................................................4
1.1 Goals and Objectives............................................................................................4
1.2 Scope of Project:...................................................................................................4
2 Functional Requirements:.............................................................................................4
2.1 Mobile Devices:....................................................................................................5
2.1.1 Startup............................................................................................................5
2.1.2 Security..........................................................................................................5
2.1.3 Connectivity...................................................................................................5
2.1.4 Printing of Parking Tickets............................................................................5
2.1.5 Update Portal.................................................................................................5
2.1.6 Reporting Logs..............................................................................................5
2.1.7 Synchronization of Data................................................................................5
2.2 Web Portal.............................................................................................................5
2.2.1 Admin Login..................................................................................................5
2.2.2 Dashboard......................................................................................................5
2.2.3 Defining Parking Sites...................................................................................6
2.2.4 Defining Mobile Devices...............................................................................6
2.2.5 Defining the Device Users.............................................................................6
2.2.6 Defining of Web Portal Users........................................................................6
2.2.7 Defining the Vehicle Types............................................................................6
2.2.8 Defining Fares or Rates.................................................................................6
2.2.9 Reporting.......................................................................................................6
3 Non-Functional Requirements:....................................................................................6
3.1 Operational Requirements.....................................................................................6
3.2 Maintenance Requirements...................................................................................7
3.3 Safety Requirements.............................................................................................7
3.4 Misuse of the Devices...........................................................................................7
3.5 Legal Requirements..............................................................................................7
3.6 Security of Database.............................................................................................7
 3.7 Other Operational Requirements..........................................................................7
4 Use Case Diagram(s):..................................................................................................7
4.1 Mobile Application:..............................................................................................7
Use Case: Main............................................................................................................7
4.2 Usage Scenarios – Mobiles Application:..............................................................8
4.2.1 Login..............................................................................................................8
4.2.2 Check-In........................................................................................................9
4.2.3 Add Parking...................................................................................................9
4.2.4 Reporting.....................................................................................................10
4.2.5 Synchronization...........................................................................................10
4.3 Use Case: Web Portal..........................................................................................11
4.3.1 Web Portal....................................................................................................11
5 Adopted Methodology...............................................................................................13
5.1 VU Process Model..............................................................................................13
5.2 Why VU Process Model......................................................................................13
5.2.1 Documentation driven Model......................................................................13
5.2.2 Concise and Advance...................................................................................13
5.2.3 Dependent on Risk Analysis........................................................................13
5.2.4 Corrective Measures....................................................................................14
5.3 VU process Model Diagram...............................................................................14
6 Work Plan..................................................................................................................15

SRS Document
1 Overview
Parking space in the heart of Pakistan, Lahore, is the need of the people as well as a
revenue generating source for the City District Government, Lahore (Now MCL). For a
long time, the parking sites were auctioned to contractors by the CDGL. After the
contract was awarded a small fee was deposited in the Government treasury but the
charges were arbitrarily charged causing revenue loss to the Government.

Looking into the matter above, CDGL moved a summery to the CM for making a parking
authority who would enter into a Private Public Partnership with a single contractor, who
would modernize the parking by introducing latest technology and develop parking that
would facilitate the public as well as generate revenue for the Government. The project
ran into jeopardy, as the awarding of contract got late and the authority having no
previous Parking Management experience re-employed, either the contractors or the
employees of the contractors who managed the sites earlier and the “Parchi System” still
exists, leaving the government with the same revenue embezzlement and loss as before.

The aim of the project is to develop a Mobile Based Parking Revenue Collection System,
with a Web Based Portal, which would facilitate the Government to collect and manage
the revenue and monitor activities at the parking sites on real time basis and get rid of the
above-mentioned Parchi System. Other than the government, Hospital managements or
Mall managements to operate their parking can use this software.

1.1 Goals and Objectives

The main goal of the project is to develop a parking revenue managements system, which
will provide the following:
1. Printing of e-tickets using an android-based system.
2. Send real time parking data of the four vehicle types i.e. car, bike, van and truck
to the web portal.
3. Collect real time data of the parking fee collected, on the cloud, or at some data
center for further analysis by CDGL.

1.2 Scope of Project:

The scope of the application is to provide the intended users, i.e. the admin staff of
CDGL the details of revenue collected from the parking sites on real time basis and
administration of the mobile devices issued on the parking sites, it is also in the scope of
the application to generate e-tickets on the parking sites, send data to the web portal and
maintain the record on the devices for further use.

2 Functional Requirements:
2.1 Mobile Devices:
2.1.1 Startup
This would check the internet connectivity and login and fetch data like types of vehicles
and their rates from the internet and store in a local DB (SQLite) and would facilitate
even if the 4G were not available. If the internet connectivity is not available, an error
will be generated

2.1.2 Security
IEMI or SIM number will be stored on the cloud and at the time of login, the app will
compare the numbers (either of the both) and if checked, it will proceed to next activity.

2.1.3 Connectivity
An SDK will be used to make the connectivity with a portable Bluetooth printer and use
its features. If the device is not paired and error will be generated.

2.1.4 Printing of Parking Tickets

After the connectivity with the printer, the operator will choose the desired vehicle (Car,
bike, van or truck) for which the ticket will be issued, enter the vehicle’s numeric
number, and a ticket will be printed with some required information.

2.1.5 Update Portal

After the ticket is issued, the data entered will be sent on the cloud, containing
information like, the vehicle no, time of arrival, etc. If in case, the data is not sent due to
fluctuation in the 4G it will be saved in the local DB, to be sent later.

2.1.6 Reporting Logs

Mobile device wise daily or date wise report (either or both), shall be printed at any given
time of the day for inspection by authorities for day closing purpose containing the count
of tickets issued to different vehicles.

2.1.7 Synchronization of Data

Due to fluctuation of 4G, the un-synced data mentioned above in point 5 will be synced
and complete data will be sent to the web portal for reviewal of the authorities, next day
or whenever required.

2.2 Web Portal

2.2.1 Admin Login
An admin login will be done, by the authorized personals, who wants to perform various
tasks, as per authorization. A super admin will have all the rights.

2.2.2 Dashboard
An attractive dashboard depicting various summaries in form of graphs shall be
presented.
2.2.3 Defining Parking Sites
This process shall be used for definition of the parking sites, i.e. the parking sites can be
created, edited or deleted. Sometimes, due to some governmental issues like construction
(Orange line, or extension in metro etc.) or any other reasons, parking operations on those
areas has to be terminated for sometime, so the status of the site can be deactivated, and
afterwards activated on resume.

2.2.4 Defining Mobile Devices

Keeping in view the security of devices and unauthorized usage, this process shall
register the SIM number or IEMI, which when set to active mode shall be used to login
the mobile device. Other than registering the device the process shall be used to delete the
device (incase of theft or damaged to SIM or device) and update the status of the device
like its activation or deactivation (in case of lost device or SIM).

2.2.5 Defining the Device Users

This process shall define the device users. The admin can create, edit, delete, activate or
deactivate the users who will operate the mobile devices.

2.2.6 Defining of Web Portal Users

Like wise the device users, web portal users can be created, edited, deleted, activated and
deactivated. This will also define the rights of the portal users.

2.2.7 Defining the Vehicle Types

The vehicles types shall be defined, though by default it is assumed that there are four
types of vehicles, Car, Bikes, Vans and Trucks.

2.2.8 Defining Fares or Rates

This process shall define the fares of the vehicles and this process will consider that on
which parking site, what types of vehicles are allowed and their rates. Sometimes, due to
some gazetted occasion, like 23rd of March or some cricket match, the authorities might
decide to let the parking for free or subsidized for all or some types of vehicles, this
process will be used edit the fares.

2.2.9 Reporting
Several reports like, Date wise reports of all the vehicles, Vehicles wise reports, for a
particular date, Summary report just the count of vehicles type for a particular period,
Site wise reports etc. can be produced. They can be downloaded in PDF format for
further usage or record purposes.

3 Non-Functional Requirements:
3.1 Operational Requirements
As the operational staff, which are, workers and supervisors, on the parking sites are not
well educated, except for some exceptions, needs to be trained and educated. The
common functions of mobile devices like, setting the internet connectivity, pairing
Bluetooth devices and usage of keyboard is required.

3.2 Maintenance Requirements

As the devices are assumed to be roughly used, maintenance is required, at least on
quarterly basis.

3.3 Safety Requirements

For the safety of devices, glass protection to save the screen and touch, will be required.

3.4 Misuse of the Devices

So that the operators do not misuse the devices, a data sim with 4G connection will be
provided, to avoid phone calls, and some pattern security software to avoid unnecessary
downloads and change of mobile settings.

3.5 Legal Requirements

No such legal requirements currently required.

3.6 Security of Database

Only the DB admin whomever the authorities appoint shall be allowed to make changes
in the database structure of the handle the data.

3.7 Other Operational Requirements

No such operational requirements currently required, other than mentioned above.

4 Use Case Diagram(s):

4.1 Mobile Application:
Use Case: Main
4.2 Usage Scenarios – Mobiles Application:
4.2.1 Login
Use Case Name Main Login
Implementation Priority
Actor Device User
Summary The device users will login from the main screen providing the
username and a password
Pre-Condition Internet connection either 4G or DSL is required, Bluetooth
Printer should be paired and Bluetooth services activated.
Extends
Uses
Normal Course of The device user will check internet connectivity, the Bluetooth
Action pairing for each device and the login by providing username
and password.
Alternative Path If 4G connection is not available, using the nearest provided
DSL or any hotspot to connect the devices
Exception If the internet, the Bluetooth is not available or either username
or password is not provided, the system will through
exceptions.
Assumption
4.2.2 Check-In
Use Case Name Check-In
Implementation Priority
Actor Device User, Admin User
Summary The user will select the required vehicle type to perform
operation like car, bike, van or truck.
Pre-Condition Although, Internet is not necessary, but to synchronize data to
live DB internet is required. Bluetooth connectivity with the
printer a prerequisite.
Extends Add Parking activity
Uses
Normal Course of The user clicks on the check-in option and will be taken to the
Action vehicle selection option. There the user will click on the
required vehicle type and will proceed to the Add Parking
activity. Sometimes it is observed that the Bluetooth skips
connectivity with the paired devices, so rather the user wastes
time in unpairing and the re-pairing to re-gain the connectivity,
a button to re-pair will be available.
Alternative Path N/A
Exception No exception observed at this point.
Assumption

4.2.3 Add Parking

Use Case Name Add Parking
Implementation Priority
Actor Device User, Admin User
Summary Takes in the number of the vehicle and prints the E-tickets
Pre-Condition Only Bluetooth connectivity is required, Internet connectivity
is optional.
Extends N/A
Uses N/A
Normal Course of On the arrival of vehicle, the Device user will enter the
Action Numeric number (alpha numeric may cause delay) and hit the
save button, The system will print the ticket with the name of
the parking site, time in, the fare to be paid, a barcode or a QR
code and some disclaimers. The data will be saved locally and
if the internet is available the data will sync to live DB on the
cloud which will be displayed on the web portal and if due to
any reason the internet connectivity is not available the data
will be saved on the local device informing the user through
some message alert or a toast that the data saved but not synced
but saved.
Alternative Path N/A
Exception If due to Bluetooth disconnection, which rarely occurs, the
system will throw an exception, the device user will get a
 Bluetooth connectivity error, which the user can resolve by
pressing the re-pairing button.
Assumption

4.2.4 Reporting
Use Case Name Reporting
Implementation Priority
Actor Device user, Admin User
Summary Prints Daily and Date wise reports
Pre-Condition Bluetooth printer should be active
Extends N/A
Uses Daily reports and Date Wise Reports
Normal Course of The user will press the reports button from the main operation
Action screen will be taken to the reports activity. There the user can
print 2 types of reports
 Daily report
 Date wise report
The devise user will just press the daily report button. The only
exception to be taken care is that the report should be taken
before 12:00 am at day closing. The report will display the site
name, the count of vehicles and the total revenue collected
from that particular device.
Same actions will be taken for Date Wise reports except that
the user will give the starting and an ending date and the same
report with the number of tickets showing the count of vehicles
types dispensed from a particular device from a specific
starting and ending date along with the revenue collected will
be printed on the report.
Alternative Path No alternative path
Exception N/A
Assumption

4.2.5 Synchronization
Use Case Name Synchronization
Implementation Priority
Actor Admin User
Summary Synchronizes data to the cloud DB
Pre-Condition Internet Connectivity is required
Extends
Uses
Normal Course of At the end of the day when the collection team comes to collect
Action the revenue, after getting the reports from the devices, the
admin or the collection team will use their logins to
 synchronize the data that was left un-synchronized during the
day due to fluctuation in 4G connection.
Alternative Path If 4G is not available any DSL Connection can also be used to
sync the data.
Exception During the data transformation, if the 4G is used, there might
be chances that some data might be left un synchronized,
keeping in view the fluctuation nature of 4G, a message that
some data might be left unsynchronized will be displayed to
the user. The user will run the process once again until all of
the data is synchronized and the OK message displayed.
Assumption It is assumed that a high speed DSL is used for this process

4.3 Use Case: Web Portal

4.3.1 Web Portal

Use Case Name Web Portal
Implementation Priority
Actor Web User, Admin User
Summary The Web Portal will be the controlling center for defining all
the users, vehicle types, vehicle fare, devices, parking sites and
reports.
Pre-Condition The user must be logged in
Extends PDF Builder
Uses
Normal Course of The web user will perform different administrative functions
Action here.
 The user will login in giving a username and a
password.
 The user will define the vehicle type. Usually there will
be four types of vehicles, Cars, Bikes, Van, and Trucks.
The user van delete and edit the types
 The user can define fares of the vehicles types here and
define that what type of vehicle will be allowed on
which parking site.
 In the management section:
o The user can define, update and delete Parking
Locations.
o The user can define, update and delete the
android devices. The user will provide the
location where the device is to be used, the SIM
number and its status, whether the device should
be activated or not.
o The user can define mobile device uses and web
users by defining their username and passwords.
The user can delete or edit any entry
 The Reports section defines 2 types reports,
o Date wise
o Site Wise and Date Wise
The user will provide the start date and an end date and
hit the view report button.
In the second report, the user will provide the start date
and an end date and finally provide the parking site
name for which to view the report.

Both the reports will provide the location name, vehicle

type, ticket number, time in and the amount paid. The
user can down load both the reports by hitting the
download PDF button.
Alternative Path N/A
Exception N/A
Assumption N/A
5 Adopted Methodology
Methodology is framework that is used to structure, plan and control the
process of development of any software. The required methodology by
the institution is VU process Model. The description is as follows:

5.1 VU Process Model

This methodology is a combination of waterfall methodology and spiral
methodology. This may also be called as “Hybrid Methodology”. It has
five phases which are
 Gathering and analysis requirements
 Design phase
 Development Phase
 Testing Phase
 Final Report and implementation
This model, as mentioned above is the hybrid model which is
developed keeping in view the pros and cons of both waterfall
methodology and the spiral methodology. In this model each stage of
waterfall is preceded by identification of alternatives and risk analysis
and then followed by evaluation and planning of next phase. It
enhances the quality of project through documentation of each phase
and minimize risk by doing task analysis.

5.2 Why VU Process Model

Some of the reasons for choosing this model is as follows
5.2.1 Documentation driven Model
The VU Process Model is a documentation driven model. It generates complete
documentation and makes maintenance of tasks such easier because the feedback
the user gives must be fulfilled on each phase of development

5.2.2 Concise and Advance

Comparing the waterfall model, this model is more concise and advanced,
because at any stage we can go back, do the task and again move forward, but in
waterfall we can cannot move back.

5.2.3 Dependent on Risk Analysis

The VU process model is very much dependent on risk analysis and contentiously
evaluating each phase.
5.2.4 Corrective Measures
Corrective measures are allowed any stage.

5.3 VU process Model Diagram

6 Work Plan