for goBerkeley Automated Data Collection and Enforcement ... 2.2.1 Collect, analyze, and report data...

Exhibit 1:

System Requirements Specification (SyRS)

for

goBerkeley Automated Data Collection and Enforcement

System

Version 1.0 July 15, 2014

Prepared by:

Exhibit 1: System Requirements Specifications

Table of Contents

1. Introduction ............................................................................................................................1 1.1 Purpose ...................................................................................................................................... 1 1.2 Intended Audience and Reading Suggestions ..................................................................... 1 1.3 Product Scope ........................................................................................................................... 1 1.4 References ................................................................................................................................. 2

2. Overall Description ...............................................................................................................3 2.1 System Perspective .................................................................................................................. 3 2.2 Product Functions ..................................................................................................................... 4 2.3 User Classes ............................................................................................................................. 5 2.4 Operating Environment ............................................................................................................ 6 2.5 Design and Implementation Constraints ............................................................................... 6 2.6 Assumptions and Dependencies ............................................................................................ 6

3. Requirements .........................................................................................................................6 3.1 Functional Requirements ......................................................................................................... 7 3.2 Performance Requirements .................................................................................................... 9 3.3 Interface Requirements .......................................................................................................... 10 3.4 Data Requirements ................................................................................................................. 10

4. External Interface Requirements ....................................................................................12 4.1 User Interfaces ........................................................................................................................ 12 4.2 Software Interfaces ................................................................................................................. 13 4.3 Communications Interfaces ................................................................................................... 13

5. Other Requirements ...........................................................................................................13

Appendix A: Requirements Traceability Matrix

Exhibit 1: System Requirements Specifications

Revision History

Name Date Reason For Changes Version

Craig Jameson, Jim Anderson, Sameer Jatana, Vince Chastain,

06/12/2014

Initial draft 1.0

Sameer Jatana 07/15/14 Final version 1.0

Software Requirements Specification for goBerkeley ADCES

1

1. Introduction

1.1 Purpose

This document lists the requirements for an Automated Data Collection and Enforcement System (ADCES) for the goBerkeley project. The City of Berkeley intends to procure a system that can be used for:

Reporting on and off-street parking occupancy Provide parking enforcement

1.2 Intended Audience and Reading Suggestions

This document System Requirements Specifications (SyRS) is intended for the system integrator and prospective vendors of a system that can be used for both occupancy detection and enforcement. The Concept of Operations (ConOps) is a prerequisite to this document. It is suggested that the goBerkeley ConOps and Systems Engineering and Management Plan(SEMP) documents be reviewed first before reviewing the detailed requirements listed in this document. This SyRS builds upon those concepts, particularly the User Needs, to document the required functionality, performance, interfaces, and other required characteristics for the ADCES System. The structure of this SyRS document is based on Institute of Electrical and Electronics Engineers (IEEE) Standard 1233-1998 IEEE Guide for Developing System Requirements Specifications. The SyRS document consists of the following sections:

Section 1 provides an overview of the ADCES System and an introduction to this SyRS document.

Section 2 lists the documents used as background information or as a source of requirements.

Section 3 provides the requirements for the ADCES System. This document is divided into multiple sections for different categories of requirements. The requirements are numbered in the following format: Functional Requirements – Fx.x (e.g. F1.1)

1.3 Product Scope

The City currently has approximately 2500 demarcated on-street parking spaces and 1500 off-street parking spaces spread over 200 block faces within the project area shown in figure 1. The majority of on-street parking is un-metered, with a large number regulated by Residential Parking Permit (RPP) zones.


2

Figure 1: goBerkeley project area The ADCES system being specified here will be used by the City to capture vehicle occupancy in both demarcated and non-demarcated areas in the goBerkeley project area. The occupancy data will be sent to a data hub being developed by Xerox in Phase 1 of the project. The format of the data and the mechanism for data transfer shall be defined by Xerox. In addition, the ADCES will integrate with City’s existing systems e.g. eTIMS, and LERMS to provide time limit and illegal parking enforcement. The vendor shall work with the vendors of City’s existing systems for the integration. The system shall be scalable to cover approximately 25,000 parking spaces and 1,300 RPP block faces if the City decides to expand the project to rest of the City areas.

1.4 References

This section identifies all needed documents that support this SyRS.

City of Berkeley Systems Engineering and Management Plan – Value Pricing Pilot Program Parking Project ver 3.0 dated 6/20/2013


3

City of Berkeley Concept of Operations Value Pricing Pilot Program : Parking Project Version 2.0 dated February 2013

IEEE Std. 1233 Dec 1998 – IEEE Guide for Developing System Requirements Specifications

2. Overall Description

The ADCES being specified here includes the hardware that will be deployed in the field and its associated backend system including hardware and software. It also includes the user interfaces that will be available to City users for monitoring the system.

2.1 System Perspective

The ADCES will be used in conjunction with the following systems/data sources: a) For Occupancy

Existing systems o IPS single space meter session data o Cale pay stations session data

System being developed in Phase 1 of goBerkeley project

o Occupancy reporting data hub being developed by Xerox o City web site displaying parking occupancy statistics

b) For Enforcement

Existing systems o Electronic handheld ticket writer software – PocketPEO® (Xerox) o Citation database - eTIMS® (Xerox) o Law Enforcement Records Management System (LERMS) o Residential Parking Permit database – eTIMS® (Xerox)

Figure 1 shows the context in which the ADCES system operates as part of the overall goBerkeley system. The ADCES system is expected to integrate with existing enforcement systems and provide occupancy data to Xerox’s data hub. The occupancy data shall also include the ESRI based GIS data for the parking spaces and block faces.


4

Occupancy Reporting System

IPSPayment

Transactions

Cale Payment

Transactions

eTIMS

RPP

LERMS

ADCES System

Berkeley Existing Systems

Web site page - occupancy info on ESRI based map. Data made

avialable in RESTful JSON

API format for 3rd parties

City’s existing systems prior to goBerkeley project

Xerox developed system

ACDES System

Fig 1: goBerkeley ADCES context diagram

2.2 Product Functions

The City of Berkeley requires an Automatic Data Collections and Enforcement System (ADCES) to be used for the goBerkeley Pilot. The ADCES will perform two major functions:

2.2.1 Collect, analyze, and report data on vehicle parking

The ADCES will collect data on parked vehicles, as well as store, analyze, report, and make recommendations for improved management and utilization of the City’s parking assets, particularly the on-street spaces. Parking data collection is to be performed by intensive monitoring of on-street spaces within the Pilot area, 7days per week, and at all hours of the day. Among the key requirements of the system, it must be capable of:

Detecting vehicles in a variety of lighting and weather conditions Detect the length of a vehicle, the duration of stay of a vehicle in a space Store and analyze the data Generate reports on the data collected Collecting data on vehicles whether they are parallel parked or angle parked Detecting vehicles on one-way and two-way streets Differentiate between moving and stationary vehicles – including double parked vehicles Record and store license plate data, and integrate with the Pilot area’s parking regulation

and capacity database.


5

2.2.2 Support improved effectiveness of parking enforcement operations

The ADCES will be used to improve the effectiveness of enforcement operations by employing the Pilot technology to deliver data to enforcement officers and managers, in real time. The system shall:

Provide a unique identifier for each parked vehicle, including the state and number of the license plate, as well as other identifying information such as make, model, color and other unique vehicle and location identifyind data pointsIncorporate the existing enforcement beats into each record

Integrate the current parking regulations into the system Integrate with the current Residential Permit Parking (RPP) regulations in order to

determine if a parking time limit violation has occurred in time limit and RPP zones Display data recorded or captured by the system on parked vehicles, on the handheld

computer of the Parking Enforcement Officer (PEO) in real time, including “alarms” for violations resulting from the integration of the data recorded in the system

Integrate and transfer citation data to the existing citation database used by the City

2.3 User Classes

The goBerkeley Pilot is being conducted to determine if new and advanced technology can be used to better manage, improve access to and utilization of, the parking assets of the City of Berkeley. At such, members of the traveling and parking public, all may be potential users of the system. There are three classes of users, within the city’s government, which are responsible for setting requirements, selecting, implementing, testing, and evaluating the results yielded by the systems and technologies, used for the ADCES Pilot:

1. Public Works Department 2. Berkeley Police Department – Parking Enforcement 3. Department of Information Technology

2.3.1 Public Works Department

The Parking Services and Planning sections of the Public Works Department are key users of the ADCES. Parking Services is responsible for implementing and managing parking rules and regulations, as well as operating key parking assets such as metered parking, time limit parking, RPP parking, and loading zones. Planning is responsible for assessing needs, designing solutions, determining requirements and evaluating the effectiveness of the results, of the Pilot.

2.3.2 Berkeley Police Department – Parking Enforcement

The Parking Enforcement section of the Berkeley Police Department is charged with enforcing parking rules and regulations. The Parking Enforcement section must fulfill their role in order to ensure that a level of compliance with regulations is attained that will facilitate achieving the desired results of better access to and utilization of, the City’s on-street parking assets. One of the key functions of the Pilot is to improve the effectiveness of the officers in enforcing regulations, from the current state.

2.3.3 Department of Information Technology


6

The Information Technology (IT) department is responsible for ensuring that systems are compliant with the City’s requirements for data access, data management as well as with the City’s technical requirements for IT systems. The Pilot will require integration with City, third-party vendors, and a host of other network, hardware, and software resources. Effective oversight and coordination with the IT department, by the Pilot system providers, is needed to support the system(s) being evaluated and achieve the best results possible from the Pilot.

2.4 Operating Environment

The vendor’s software system(s) are required to operate in concert with components which comprise the City’s parking management system. The parking management system is comprised of various City systems as well as other vendor supplied, and possibly, managed systems. These systems include, but are not limited to:

The City’s parking data hub Citation processing system Parking meter management system(s)

2.5 Design and Implementation Constraints

The vendor is required to present the City with a detailed, logical, innovative and efficient plan to meet the scope of services described within this document. The vendor is required to present plans to produce a highly functional and reliable parking management system that enables the City to effectively manage parking monitoring, collections and enforcement via data and business intelligence. The vendor’s system(s) are required to capable of integrating to the data hub.

2.6 Assumptions and Dependencies

The Pilot system must be capable of interfacing with the following systems:

Electronic handheld ticket writer software – PocketPEO® (Xerox) Citation and RPP database - eTIMS® (Xerox) Meter management integrating software - Merge® (Xerox)

3. Requirements

This section of the document lists the ADCES System Requirements. The requirements are categorized broadly into two columns:

Essential requirements: These are the ‘must have’ requirements and essential to the goBerkeley project

Optional requirements: These are the ‘would like to have’’ requirements. Although not essential, the City would prefer a system that not only meets the essential requirements, but also meets the optional ones. Meeting of these requirements could play a role when doing a comparative analysis of multiple systems.


7

3.1 Functional Requirements

The Functional requirements specify actionable behaviors of the ADCES System. Equipment vendors should respond as to whether the equipment can meet the specific requirement. If the equipment cannot meet the requirement, but can provide information or services to support he requirement, the vendor should specify this in detail.

Sys Req ID Equipment Vendor Requirements System Integrator

Requirements

F1 The system shall detect the presence of a parallel parked vehicle in situations where parked vehicle bumpers are at least 6 inches apart.

F1.1 The system shall detect the vehicles with or without license plates

F1.2 The system shall report vehicles parked at the curb as well as double parked and differentiate between the two

The system shall report vehicles parked at the curb as well as double parked and differentiate between the two

F1.3

The system shall be able to detect legally parked stationary vehicles with curbside wheels parallel and no further than 18 inches from the curb edge(optional requirement)

F2 The system shall be able to detect the presence of a stationary angle parked vehicle- defined as a stationary vehicle (angled between 45 and 90 degrees to the curb)

F3 The system shall detect the presence of a parked vehicle, notwithstanding changes in illumination (shadows, sunlight, glare, day/night lighting transition)

F4

The system shall detect a vehicle, the length of the vehicle notwithstanding ("Smart" Cars to tractor-trailer trucks, bicycles are NOT defined as vehicles in these requirements). Two and three wheeled vehicles are not included

F5 The system shall detect vehicles simultaneously on both sides of the street

F6 The system shall not report vehicles parked at adjacent blocks or moving in travel lanes.

F7 The system shall report the block face (per City's block face ID) where the detected vehicle is located

F8

The system shall calculate the number of stationary vehicles per block face for a given time period (e.g. 30 minutes, 60 minutes, 9 a.m. to 12 p.m., daily, monthly, yearly)

F9 The system shall have a unique identifier for each vehicle (such as license plate, make, model, color or other unique data points) if detected as a parked vehicle

F10 The system shall incorporate existing enforcement beat areas in each record


8

Sys Req ID Equipment Vendor Requirements System Integrator

Requirements

F11 The system shall generate statistical reports by enforcement beat areas

F12 The system shall identify vehicles that have been moved up to 200 feet within a block.

F13 The system shall integrate with current parking regulations information (eTIMS, PocketPEO) to automatically detect a parking time limit violation

F13.1 The system shall incorporate multiple time limit zones on the same enforcement run.

F14

The system shall integrate with current Residential Permit Parking (RPP) regulations to determine a permit zone violation; and a parking time limit violation within an RPP zone

F15 The system shall display recorded data to the Parking Enforcement Officer on the ADCES system laptop and then interface to the handheld for citation issuance.

F16

Report violation "alarms" that result from integration of

recorded data with parking regulations to the Parking

Enforcement Officer's handheld Computer in real-time.

Violation alarms are desired for:

Violation of time limits in the City’s 30 minute, 2 hr, 3hr and 8 hr time limit zones

Violation of time limits and/or non-permit parking in the City’s Residential Permit Parking zones

F17

The system shall allow PEO ability to override an alarm and enter an "exception" note or report. Overridden alarms will be tracked by time, day and PEO. Overridden data shall be a permanent record and cannot be modified or edited.

F18 The system shall have a list of pre-defined common exceptions and allow entry of freeform comment

F19 The system shall generate daily, weekly, monthly and annual statistical reports detailing but not limited to:

F19.1 Total number of vehicle license plate reads

F19.2 Total number of parking violations issued as a result of read vehicle license plate data . The report shall separate data for each Berkeley Municipal Code (BMC).

F19.2.1 Total of parking violations not issued

F19.3 Individual PEO enforcement activity and performance

F19.4 Total number of vehicles which have not moved despite issuance of citation

F20

The system shall ask the officer to login using unique security PIN and badge number

F21 The detection system shall be mountable with temporary mounts on the following types of vehicles: (a) GO-4 (b) Sedan


9

3.2 Performance Requirements

The Performance requirements specify quantifiable characteristics of ADCES System operations.

Sys Req ID

Equipment Vendor Requirements System Integrator Requirements

P1 The system shall record and store the state and number of a license plate with (n-2) 98% accuracy

P2 The vendor shall provide ample processing power with the ability to dynamically scale CPU resources as needed for up to 25,000 spaces Citywide

The vendor shall provide ample processing power with the ability to dynamically scale CPU resources as needed for up to 25,000 spaces Citywide

P3 The vendor shall provide disk space that is in accordance with the specifications listed in this document.

The vendor shall provide disk space that is in accordance with the specifications listed in this document.

P4

The system shall be scalable such that when additional resources such as processing power, memory allocation, or disk space are needed; the system will dynamically scale accordingly to handle data collection and enforcement of up to 25,000 spaces Citywide.


P5

The vendor shall provide the appropriate bandwidth to meet or exceed the desired level of service to handle data collection and enforcement of up to 25,000 spaces Citywide.


P6 The system shall accurately detect the presence of a parked vehicle at least 90% of the time

P7 The system shall differentiate between legally parked and moving vehicles at least 90% of the time

P8 The system shall report direction of travel at the time of vehicle detection at least 90% of the time

P9 The system shall report accurate GPS coordinates at the time of vehicle detection at least 90% of the time

P10 The system shall accurately report the block face where the vehicle is physically located at least 90% of the time

P11 The system shall have a uniquely identify each vehicle (such as license plate, make, model, color or other unique data points)at least 98% of the time

P12 All data shall be in real-time and actively available on PEO handheld on site at least 98% of the time


10

3.3 Interface Requirements

The Interface requirements define the ADCES System’s external interfaces to the other goBerkeley systems

Sys Req ID

Equipment Vendor Requirements System Integrator

Requirements

R1

The vendor systems shall provide interfaces which support TCP/IP communications. Data exchange between systems shall be implemented via XML structured data over Web Services.

R2 System to system communications shall be secured using SSL or IPSec.

R3

The vendors shall work with Xerox during the requirements & design phases of the project to define and document data exchange file formats via interface control documents and XML XSD definitions.

3.4 Data Requirements

The Data requirements define the data stored within the ADCES System and the Occupancy Reporting System.

Sys Req ID


D1

The system shall record and store the date, day and time of the detection of a parked vehicle in the following format (04/15/2013, Monday, 20:15:36 )


D1.1

The Date (mm, yy, dd, Mondays etc) and time shall be separate data fields. Either A) time zone indicator should be provided with the data or B) all date/times should be in the GMT timezone format.

The Date (mm, yy, dd, Mondays etc) and time shall be separate data fields. Either A) time zone indicator should be provided with the data or B) all date/times should be in the GMT time zone format.

D2

The system shall integrate with the Pilot's parking regulation and capacity database. At a minimum, the parking regulation and capacity database will list the number of legal parking spaces per block face with a unique block face ID

D3

The system shall calculate the "parking occupancy" per block face per time period, defined as (number of stationary vehicles) /(number of legal parking spaces)

D4

The system shall calculate the average "parking duration" (duration is defined as the time in which a stall is occupied by a single vehicle) per block face per time period, defined as the average of parking duration of all stationary vehicles on a block face for a time period

D5 The system shall be able to differentiate between legal and illegal parking zones (optional requirement)


11

Sys Req ID


D6 The system shall be able to report whether a vehicle is parked in a legal or illegal parking zone

D7

The system shall provide data output that is compatible with the latest versions Microsoft SQL. As the new versions of Microsoft SQL become available, the provider will ensure compatibility. The proposed system should provide a way to store custom data elements and to enforce validation and business rules for that data. The system should further support the ability to include that data in reports and dashboards.


D8 The system shall provide a data output that is compatible with ESRI data models.

The system shall provide a data output that is compatible with ESRI data models.

3.4.1 Non-Functional Requirements

The Non-Functional requirements define the characteristics of the overall operation of the system such as reliability, maintainability, safety, and environmental requirements. Sys Req

ID Equipment Vendor Requirements System Integrator Requirements

N1

The system shall keep the captured data (license plate information) secure. Adequate information security shall be applied to protect all data collected and stored. Systems through which data is passed or is stored shall be protected from unauthorized access from both internal and external sources.

N2

The system shall have the capability to specify a separate user-configurable retention period on read and hit data. The retention settings shall result in all read/hit data captured before the specified period to be automatically purged without user intervention.

N3 The vendor shall host supporting networks and systems outside of the City of Berkeley network.

The vendor shall host supporting networks and systems

N4

The system shall provide a system with high availability and configured according to industry standard 99.999% of uptime or less than five (5) minutes of unscheduled downtime per year.


N5

The vendor shall provide adequate disaster recovery and take routine backups of the system with a four {4) hour Recovery Point Objective (RPO) and an eight (8) hour Recovery Time Objective (RTO).


N6

The vendor shall provide security in accordance with industry standard SSAE 16 Type II for hosted solutions. Provider will protect system with the appropriate industry standard security provisions including firewall protection, AES 256

The vendor shall provide security in accordance with industry standard SSAE 16 Type II for hosted solutions. Provider will protect system with the appropriate industry standard security provisions including firewall


12

Sys Req ID


bit data encryption, antivirus protection, logging access of data and manipulation of data.

protection, AES 256 bit data encryption, antivirus protection, logging access of data and manipulation of data.

N7

The vendor shall provide means to authenticate City personnel to access the equipment/service management system. The solution must allow for future integration in Active Directory when the system is hosted in the City


N8

Provide a way to log different activities including, but not limited to, user authentication, file modification, user activity. Additionally, the system must provide a way to turn logging up such that debugging events may be achieved.


N9 The vendor shall use virtualization technology that is compatible with VMware when the system is hosted in the City

The vendor shall use virtualization technology that is compatible with VMware when the system is hosted in the City

N10

The vendor shall provide City staff access to the system to perform any data manipulation that may be required. Ideally, this will be administered in a web based platform.


N11 Provide an overall architecture that is in line with industry best practices. The design should use open standards protocols.

Provide an overall architecture that is in line with industry best practices. The design should use open standards protocols.

N12

The vendor shall provide maintenance of the system such that service packs and patches are applied in a timely fashion. The provider is responsible for the health of the Operating System and Core applications.


N13

The vendor shall adhere to UML documentation standards for workflow improvement and technology implementation projects and provide the proposed process flow and high level technical specifications for interface assumptions/requirements, required 3rd party components/services, and data exchange mechanisms.


4. External Interface Requirements

4.1 User Interfaces

The vendor’s system(s), where appropriate, are required to provide secure web based graphical user interfaces (GUIs) implemented via modern web development methodologies and frameworks. Security The vendor’s system(s), where appropriate, are required to provide user interfaces for obtaining fault reporting, audit data and system status reporting


13

4.2 Software Interfaces

The vendor is required to provide Open APIs through which third parties’, including the City’s, systems may be integrated to the vendor’s system(s). System interfaces are required to provide both real-time and historical data. The vendor is required to provide documentation which describes all their system(s) external interfaces. The vendor is required to provide the City with a list of data that will be made available via their system(s) APIs, describe how these interfaces establish connectivity, provide security as well as describing the frequency of data availability.

4.3 Communications Interfaces

The vendor is required to interface to the City’s data hub via TCP/IP communications. Data exchange between the vendor’s system(s) and the City’s data hub system shall be implemented via XML structured data over Web Services. Communications are to be secured using SSL or IPSec for communications between the vendor’s system(s) and the City’s data hub system. In the event that security is compromised, both parties will work diligently to apply additional protocol to restore security. If such a security event is a result of Subcontractor fault, any such action will require review and acceptance in writing from the City’s program management. Where appropriate, the vendor’s system(s) is required to accept data from the City’s data hub via XML over secured web service interface(s). Vendors with exiting interfaces definitions are required to submit documentation describing these interfaces to the City for review. In cases where new interfaces are to be developed for this project the vendor will work in conjunction with the City to design and define the interface(s).

5. Other Requirements

The vendor is required to demonstrate a positive track record of system maintenance and system uptime. The vendor is required to provide 24/7/365 support for the system(s) provided to the City.


Appendix A: Requirements Traceability Matrix

Sys Req ID

Equipment Vendor Requirements System Integrator Requirements City

Requirement ID

F1

The system shall detect the presence of a parallel parked vehicle in situations where parked vehicle bumpers are at least 6 inches apart.

1.1.1

F1.1 The system shall detect the vehicles with or without license plates

1.1.1

F1.2 The system shall report vehicles parked at the curb as well as double parked and differentiate between the two

The system shall report vehicles parked at the curb as well as double parked and differentiate between the two

1.1.1

F1.3

The system shall be able to detect legally parked stationary vehicles with curbside wheels parallel and no further than 18 inches from the curb edge(optional requirement)

1.1.1

F2

The system shall be able to detect the presence of a stationary angle parked vehicle- defined as a stationary vehicle (angled between 45 and 90 degrees to the curb)

1.1.2

F3

The system shall detect the presence of a parked vehicle, notwithstanding changes in illumination (shadows, sunlight, glare, day/night lighting transition)

1.1.4

F4

The system shall detect a vehicle, the length of the vehicle notwithstanding ("Smart" Cars to tractor-trailer trucks, bicycles are NOT defined as vehicles in these requirements). Two and three wheeled vehicles are not included

1.1.5

F5 The system shall detect vehicles simultaneously on both sides of the street

1.1.6

F6 The system shall not report vehicles parked at adjacent blocks or moving in travel lanes.

1.1.7

F7 The system shall report the block face (per City's block face ID) where the detected vehicle is located

1.1.8

F8

The system shall calculate the number of stationary vehicles per block face for a given time period (e.g. 30 minutes, 60 minutes, 9 a.m. to 12 p.m., daily, monthly, yearly)

1.1.9

F9

The system shall have a unique identifier for each vehicle (such as license plate, make, model, color or other unique data points) if detected as a parked vehicle

1.2.1

F10 The system shall incorporate existing enforcement beat areas in each record

1.2.1

F11 The system shall generate statistical reports by enforcement beat areas

1.2.1

F12 The system shall identify vehicles that have been moved up to 200 feet within a block.

1.2.1


Sys Req ID


Requirement ID

F13

The system shall integrate with current parking regulations information (eTIMS, PocketPEO) to automatically detect a parking time limit violation

1.2.3

F13.1 The system shall incorporate multiple time limit zones on the same enforcement run.

1.2.3

F14

The system shall integrate with current Residential Permit Parking (RPP) regulations to determine a permit zone violation; and a parking time limit violation within an RPP zone

1.2.4

F15

The system shall display recorded data to the Parking Enforcement Officer on the ADCES system laptop and then interface to the handheld for citation issuance.

1.2.5

F16

Report violation "alarms" that result from integration of recorded data with parking regulations to the Parking Enforcement Officer's handheld Computer in real-time. Violation alarms are desired for:

1.2.6 Violation of time limits in the City’s 30

minute, 2 hr, 3hr and 8 hr time limit zones

Violation of time limits and/or non-permit parking in the City’s Residential Permit Parking zones

F17

The system shall allow PEO ability to override an alarm and enter an "exception" note or report. Overridden alarms will be tracked by time, day and PEO. Overridden data shall be a permanent record and cannot be modified or edited.

1.2.7

F18 The system shall have a list of pre-defined common exceptions and allow entry of freeform comment

1.2.7

F19 The system shall generate daily, weekly, monthly and annual statistical reports detailing but not limited to:

1.2.8

F19.1 Total number of vehicle license plate reads 1.2.8.1

F19.2

Total number of parking violations issued as a result of read vehicle license plate data. The report shall separate data for each Berkeley Municipal Code (BMC).

1.2.8.2

F19.2.1 Total of parking violations not issued 1.2.8.2

F19.3 Individual PEO enforcement activity and performance

1.2.8.5

F19.4 Total number of vehicles which have not moved despite issuance of citation

New

F20 The system shall ask the officer to login using unique security PIN and badge number

New

F21 The detection system shall be mountable with temporary mounts on the following types of vehicles: (a) GO-4 (b) Sedan

New

P1 The system shall record and store the state 1.2.2, 2.2


Sys Req ID


Requirement ID

and number of a license plate with (n-2) 98% accuracy

P2



1.3.8

P3 The vendor shall provide disk space that is in accordance with the specifications listed in this document.

The vendor shall provide disk space that is in accordance with the specifications listed in this document.

1.3.9

P4



1.3.10

P5



1.3.11

P6 The system shall accurately detect the presence of a parked vehicle at least 90% of the time

2.1

P7 The system shall differentiate between legally parked and moving vehicles at least 90% of the time

2.1

P8 The system shall report direction of travel at the time of vehicle detection at least 90% of the time

2.1

P9 The system shall report accurate GPS coordinates at the time of vehicle detection at least 90% of the time

2.1

P10 The system shall accurately report the block face where the vehicle is physically located at least 90% of the time

2.1

P11

The system shall have a uniquely identify each vehicle (such as license plate, make, model, color or other unique data points)at least 98% of the time

2.2

P12 All data shall be in real-time and actively available on PEO handheld on site at least 98% of the time

2.2

R1

The vendor systems shall provide interfaces which support TCP/IP communications. Data exchange between systems shall be implemented via XML structured data over Web Services.

New

R2 System to system communications shall be secured using SSL or IPSec.

1.3.4


Sys Req ID


Requirement ID

R3

The vendors shall work with Xerox during the requirements & design phases of the project to define and document data exchange file formats via interface control documents and XML XSD definitions.

New

D1



1.1.3

D1.1



1.1.3

D2

The system shall integrate with the Pilot's parking regulation and capacity database. At a minimum, the parking regulation and capacity database will list the number of legal parking spaces per block face with a unique block face ID

1.1.10

D3

The system shall calculate the "parking occupancy" per block face per time period, defined as (number of stationary vehicles) /(number of legal parking spaces)

1.1.11

D4

The system shall calculate the average "parking duration" (duration is defined as the time in which a stall is occupied by a single vehicle) per block face per time period, defined as the average of parking duration of all stationary vehicles on a block face for a time period

1.1.12

D5 The system shall be able to differentiate between legal and illegal parking zones (optional requirement)

1.1.13

D6 The system shall be able to report whether a vehicle is parked in a legal or illegal parking zone

1.1.14

D7



1.3.15


Sys Req ID


Requirement ID

D8 The system shall provide a data output that is compatible with ESRI data models.

The system shall provide a data output that is compatible with ESRI data models.

1.3.16

N1

The system shall keep the captured data (license plate information) secure. Adequate information security shall be applied to protect all data collected and stored. Systems through which data is passed or is stored shall be protected from unauthorized access from both internal and external sources.

New

N2

The system shall have the capability to specify a separate user-configurable retention period on read and hit data. The retention settings shall result in all read/hit data captured before the specified period to be automatically purged without user intervention.

New

N3 The vendor shall host supporting networks and systems outside of the City of Berkeley network.

The vendor shall host supporting networks and systems

1.3.1

N4



1.3.2

N5



1.3.3

N6

The vendor shall provide security in accordance with industry standard SSAE 16 Type II for hosted solutions. Provider will protect system with the appropriate industry standard security provisions including firewall protection, AES 256 bit data encryption, antivirus protection, logging access of data and manipulation of data.

The vendor shall provide security in accordance with industry standard SSAE 16 Type II for hosted solutions. Provider will protect system with the appropriate industry standard security provisions including firewall protection, AES 256 bit data encryption, antivirus protection, logging access of data and manipulation of data.

1.3.4

N7



1.3.5


Sys Req ID


Requirement ID

N8



1.3.6

N9 The vendor shall use virtualization technology that is compatible with VMware when the system is hosted in the City

The vendor shall use virtualization technology that is compatible with VMware when the system is hosted in the City

1.3.7

N10



1.3.12

N11 Provide an overall architecture that is in line with industry best practices. The design should use open standards protocols.

Provide an overall architecture that is in line with industry best practices. The design should use open standards protocols.

1.3.13

N12



1.3.14

N13



1.3.17

for goBerkeley Automated Data Collection and Enforcement ... 2.2.1 Collect, analyze, and report data...

Documents

Transcript of for goBerkeley Automated Data Collection and Enforcement ... 2.2.1 Collect, analyze, and report data...