Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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.
Software Requirements Specification for goBerkeley ADCES
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
Software Requirements Specification for goBerkeley ADCES
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.
Software Requirements Specification for goBerkeley ADCES
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.
Software Requirements Specification for goBerkeley ADCES
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
Software Requirements Specification for goBerkeley ADCES
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.
Software Requirements Specification for goBerkeley ADCES
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
Software Requirements Specification for goBerkeley ADCES
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
Software Requirements Specification for goBerkeley ADCES
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.
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.
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
Software Requirements Specification for goBerkeley ADCES
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
Equipment Vendor Requirements System Integrator Requirements
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 )
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)
Software Requirements Specification for goBerkeley ADCES
11
Sys Req ID
Equipment Vendor Requirements System Integrator Requirements
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.
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.
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).
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
Software Requirements Specification for goBerkeley ADCES
12
Sys Req ID
Equipment Vendor Requirements System Integrator Requirements
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
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.
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.
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.
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.
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
Software Requirements Specification for goBerkeley ADCES
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.
Software Requirements Specification for goBerkeley ADCES
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
Software Requirements Specification for goBerkeley ADCES
Sys Req ID
Equipment Vendor Requirements System Integrator Requirements City
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
Software Requirements Specification for goBerkeley ADCES
Sys Req ID
Equipment Vendor Requirements System Integrator Requirements City
Requirement ID
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
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
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.
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.
1.3.10
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.
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.
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
Software Requirements Specification for goBerkeley ADCES
Sys Req ID
Equipment Vendor Requirements System Integrator Requirements City
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
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 )
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 )
1.1.3
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 time zone 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.
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
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.
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.
1.3.15
Software Requirements Specification for goBerkeley ADCES
Sys Req ID
Equipment Vendor Requirements System Integrator Requirements City
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
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.
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.
1.3.2
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).
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).
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
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
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
1.3.5
Software Requirements Specification for goBerkeley ADCES
Sys Req ID
Equipment Vendor Requirements System Integrator Requirements City
Requirement ID
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.
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.
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
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.
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.
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
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.
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.
1.3.14
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.
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.
1.3.17