Devansh Bajaj

2000320159001
Computer Engineering

PROGRAM: 1

1.1OBJECTIVE 1.2THEORY 1.3 PROCEDURE 1.4 OUTPUT

1.1 OBJECTIVE: Prepare an SRS document in line with the IEEE recommended
standards.

1.2 THEORY: An SRS is basically an organization's understanding (in writing) of a customer

or potential client's system requirements and dependencies at a particular point in time
(usually) prior to any actual design or development work. It's a two-way insurance policy
that assures that both the client and the organization understand the other's requirements
from that perspective at a given point in time.
Well-designed, well-written SRS accomplishes four major goals:
1. It provides feedback to the customer.
2. It decomposes the problem into component parts.
3. It serves as an input to the design specification.
4. It serves as a product validation check.

The basic issues that the SRS shall address are the following:

1 Functionality. What is the software supposed to do?

2 External interfaces. How does the software interact with people, the system’s
hardware, other hardware, and other software?
3 Performance. What is the speed, availability, response time, recovery time of
various software functions, etc.?
4 Attributes. What is the portability, correctness, maintainability, security, etc.
considerations?

1.3 PROCEDURE:

IEEE Standard SRS Template

1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms & abbreviations
1.4. References
1.5. Overview
2. Overall description
2.1. Product perspective
2.1.1. System interfaces
2.1.2. User interfaces
2.1.3. Hardware interfaces
2.1.4. Software interfaces
2.1.5. Communications interfaces
2.1.6. Memory constraints
Devansh Bajaj
2000320159001
Computer Engineering
2.1.7. Operations
2.1.8. Site adaptation requirements
2.2. Product functions
2.3. User characteristics
2.4. Constraints
2.5. Assumptions and dependencies
2.6. Apportioning of requirements
3. Specific Requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces 
3.1.3 Software interfaces  
3.1.4 Communication interfaces 
3.2 Specific requirements
3.2.1 Sequence diagrams
3.2.2 Classes for classification of specific requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.5.1 Reliability
3.5.2 Availability
3.5.3 Security
3.5.4 Maintainability
3.6 Other requirements
4. Supporting information
4.1 Table of contents and index
4.2 Appendixes

Note: History of versions of this document with author/contributor info may be included
before the main sections of the document. 

1.4 OUTPUT:

PARKING LOT MANAGEMENT SYSTEM

1.0 PROBLEM DEFINITION

The parking lot management system is software, which automates the job of a
librarian.
 Now a days in parking like valet parking they maintain just with the tokens
and they have recorded the vehicle details in books so that during some
critical situations like police enquiry of terrorist car or vehicle referrer that
case it is difficult to find the details of particular vehicle but in this case is
easy to find in 1 to 2 seconds
 By parking the vehicle in public place, the vehicle can be claimed by tow-
ing person but in this case, there is no towing problems and no need to
give fine for anything we can park our vehicle with securely.

2.0 SYSTEM REQUIREMENT SPECIFICATION

Devansh Bajaj
2000320159001
Computer Engineering

2.1 INTRODUCTION

2.1.1 Purpose
2.1.1.1 The purpose of this SRS is to describe the requirements
involved in developing a Parking Lot Management System.
2.1.1.2 The intended audience is any person, who wants to inquire,
get and park the cars.
2.1.2 Scope
2.1.2.1 The product is titled Parking Lot Management System.
2.1.2.2 The product will perform the following tasks
2.1.2.2.1 Enquire about the availability of car parking space.
2.1.2.2.2 Get space if available.
2.1.2.2.3 Get back the parked car.
2.1.3 Definitions, Acronyms and Abbreviations
2.1.3.1 DDBMS – Database Management System.
2.1.4 References
2.1.4.1 IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.5 Overview
2.1.5.1 The SRS contains an analysis of the requirements necessary to help easy
design.
2.1.5.2 The overall description provides interface requirements for the Library
Management System, product perspective, hardware interfaces, software
interfaces, communication interface, memory constraints, product
functions, user characteristics and other constraints.
2.1.5.3 Succeeding pages illustrate the characteristics of typical naïve users
accessing the system along with legal and functional constraints enforced
that affect parking lot management system in any fashion.

2.2 THE OVERALL DESCRIPTION

2.2.1 Product perspective
2.2.1.1 Hardware interfaces
2.2.1.1.1 Hard disk: The database connectivity requires a hardware
configuration that is on-line. This makes it necessary to have a
Devansh Bajaj
2000320159001
Computer Engineering
fast database system running on high rpm hard disk permitting
complete data redundancy and back-up systems to support the
primary goal of reliability.
2.2.1.1.2 The system must interface with the standard output devise,
keyboard and mouse to interact with this software.
2.2.1.2 Software interfaces
2.2.1.2.1 Back End: MS-Access 2007
2.2.1.2.2 Front End: Microsoft Visual Basic 6.0
2.2.1.3 Memory Constraints
2.2.1.3.1 No specific constraints on memory.
2.2.1.4 Operations
2.2.1.4.1 The software allows three modes of operations
Enquire about the availability and status of cars.
By extracting the username and password the software allows the user
to park a maximum of three cars.
By extracting the username and password the software allows the user
get the parked car.

2.2.2 Product Functions

 Need for an application that makes communicating easy and comfortable.

 An application that enables user to park a vehicle with safe and secure.
 Need for an application that is easy to use and widely available and hence a web ap -
plication
 Handling all functions done with organization in a computerized manner.
 Allowing the user to park the vehicle directly.

Functional Requirement
 Admin need to enter all details for registration.
 Admin need to insert all details about customer and vehicle.
 Admin need to save all the details of customer and vehicle.
 Admin can retrieve the details of customer.
 Admin must generate a report for payment.

Non-functional Requirement
 Usability: This website has appropriate user interface and adequate information to
guide the user in order to use the website.
 Portability: The website is portable as it is online website running across the net
 Flexibility: It is very flexible
 Security: This website provides user and authentication so that only the legitimate
user is allowed to use the website
Devansh Bajaj
2000320159001
Computer Engineering
 Maintainability: This website is capable to secure the data and easily retrieve the
data.
 Scalability: This system can further modify in future.

2.3 SPECIFIC REQUIREMENTS

2.3.1 Logical Database Requirements

2.3.1.1 The system should contain databases that include all necessary information
for the product to function according to the requirements. These include
relations such as user details and car details.
2.3.1.2 The user details refer to the information such as name, car number, the model
and the name of the manufacturer of the car that were parked.
2.3.1.3 The car details refer to the information such as the model of the book, owner
availability status and the number of same models that is available.
2.4 FRONT – END DESCRIPTION
The parking lot management system is automated parking system where the
user can get a dedicated parking space giving his/her details. By entering the
username and the password the software, by checking the number of car that are
already parked enables us to get a dedicated space for parking. And by entering
the username and password (car number), which is unique, the user can get his
car back.
2.5 BACK – END DESCRIPTION
The parking lot management system consists of two tables. One contains the
owner details such as the name, car number that is the password, model and the
manufacturer of the car, which could be parked. The car details consist of the
model of the car, number of cars parked, owner and the availability state

2.6 USE-CASE DIAGRAM

Here are the main Actors in our system:

 Admin: Mainly responsible for adding and modifying parking

floors, parking spots, entrance, and exit panels, adding/removing
parking attendants, etc.
 Customer: All customers can get a parking ticket and pay for it.
 Parking attendant: Parking attendants can do all the activities
on the customer’s behalf, and can take cash for ticket payment.
Devansh Bajaj
2000320159001
Computer Engineering
 System: To display messages on different info panels, as well as
assigning and removing a vehicle from a parking spot.

Here are the top use cases for Parking Lot:

 Add/Remove/Edit parking floor: To add, remove or modify

a parking floor from the system. Each floor can have its own
display board to show free parking spots.
 Add/Remove/Edit parking spot: To add, remove or modify a
parking spot on a parking floor.
 Add/Remove a parking attendant: To add or remove a
parking attendant from the system.
 Take ticket: To provide customers with a new parking ticket
when entering the parking lot.
 Scan ticket: To scan a ticket to find out the total charge.
 Credit card payment: To pay the ticket fee with credit card.
 Cash payment: To pay the parking ticket through cash.
 Add/Modify parking rate: To allow admin to add or modify
the hourly parking rate.
Devansh Bajaj
2000320159001
Computer Engineering

2.7 CLASS DIAGRAM

Here are the main classes of our Parking Lot System:

 ParkingLot: The central part of the organization for which this

software has been designed. It has attributes like ‘Name’ to
distinguish it from any other parking lots and ‘Address’ to define
its location.

 ParkingFloor: The parking lot will have many parking floors.

 ParkingSpot: Each parking floor will have many parking spots.

Our system will support different parking spots 1) Handicapped,
2) Compact, 3) Large, 4) Motorcycle, and 5) Electric.

 Account: We will have two types of accounts in the system: one

for an Admin, and the other for a parking attendant.

 Parking ticket: This class will encapsulate a parking ticket.

Customers will take a ticket when they enter the parking lot.
Devansh Bajaj
2000320159001
Computer Engineering
 Vehicle: Vehicles will be parked in the parking spots. Our
system will support different types of vehicles 1) Car, 2) Truck, 3)
Electric, 4) Van and 5) Motorcycle.

 EntrancePanel and ExitPanel: EntrancePanel will print

tickets, and ExitPanel will facilitate payment of the ticket fee.

 Payment: This class will be responsible for making payments.

The system will support credit card and cash transactions.

 ParkingRate: This class will keep track of the hourly parking

rates. It will specify a dollar amount for each hour. For example,
for a two hour parking ticket, this class will define the cost for the
first and the second hour.

 ParkingDisplayBoard: Each parking floor will have a display

board to show available parking spots for each spot type. This
class will be responsible for displaying the latest availability of
free parking spots to the customers.

 ParkingAttendantPortal: This class will encapsulate all the

operations that an attendant can perform, like scanning tickets
and processing payments.

 CustomerInfoPortal: This class will encapsulate the info

portal that customers use to pay for the parking ticket. Once paid,
the info portal will update the ticket to keep track of the payment.

 ElectricPanel: Customers will use the electric panels to pay and

charge their electric vehicles.
Devansh Bajaj
2000320159001
Computer Engineering
Devansh Bajaj
2000320159001
Computer Engineering
2.8 ACTIVITY DIAGRAM
Customer paying for parking ticket: Any customer can perform
this activity. Here are the set of steps:
Devansh Bajaj
2000320159001
Computer Engineering

11