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 towing
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 fast
database system running on high rpm hard disk permitting complete
Devansh Bajaj
2000320159001
Computer Engineering
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
application
• 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
• Maintainability: This website is capable to secure the data and easily retrieve the data.
• Scalability: This system can further modify in future.
Devansh Bajaj
2000320159001
Computer Engineering

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.

• 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:

Devansh Bajaj
2000320159001
Computer Engineering
• 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.

2.7 CLASS DIAGRAM

Devansh Bajaj
2000320159001
Computer Engineering

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.

• 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.
Devansh Bajaj
2000320159001
Computer Engineering
• ElectricPanel: Customers will use the electric panels to pay and
charge their electric vehicles.
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
Devansh Bajaj
2000320159001
Computer Engineering

11