PRR 19667 - IPAS2 RFP For The Oakland Police Department IPAS System Replacement PDF

CITY OF OAKLAND
OFFICE OF THE CITY ADMINISTRATOR
Request For Proposal (RFP)
Oakland Police Department

Second Generation Early Warning
System Project
Office of the City Administrator,

Contracts and Compliance Division
250 Frank Ogawa Plaza, 3rd Floor, Suite 3341
Oakland, CA 94612
DATE: December 17, 2013

Summary of Key Information
Overview of the The City of Oakland seeks a vendor to replace the Oakland
Opportunity: Police Departments current Early Warning System, the
Internal Personnel Assessment System (IPAS), with a new
Early Warning System (IPAS2). The scope of the opportunity
is:
Provide a complete business intelligence solution utilizing
a Microsoft platform to report on early warning activities as
defined by this RFP.
Provide a data capture solution utilizing a Microsoft
Platform, that will:
Replace 7 existing MS Access databases used to capture
source system data.
Replace existing data capture functionality in the current
IPAS Solution
Provide stability and scalability for source data, with the
ability to add new data sources over time.
Support workflows and notification requirements.
Provide implementation activities that include:
Data Conversion from source systems.
Unit Testing and System Testing
Technical Documentation
End User Training and Documentation
Solution Implementation
Warranty and Support Services.
MANDATORY Pre- Tuesday, January 7, 2014 at 10:00 AM, Hearing Room 3,
proposal Meeting: City Hall at 1 Frank Ogawa Plaza, 1st Floor, Oakland, CA
94612. Dial in information will be available upon request
Inquiries Deadline: Friday, January 10, 2014 at 4:00pm
Closing Time: Friday, January 31, 2014, by 2:00pm
Closing Location: Office of the City Administrator,
Contracts and Compliance Division
250 Frank Ogawa Plaza, 3rd Floor, Suite 3341
Oakland, CA 94612
Phone: (510) 238-3190
Proposals must be received and stamped by Contracts and
Compliance Staff No Later Than 2:00pm
Early Warning System Request for Proposal Page / i

Contact Person: IT Director and Process Coordinator, Ahsan Baig at
abaig@oaklandnet.com or (510) 238-3010
The City of Oakland will be soliciting proposals for the Early Warning System. Effective
December 6, 2013, we are implementing a Cone of Silence whereby all inquiries and
conversations regarding the RFP must be directed to Ahsan Baig, IT Director, and
Process Coordinator only.
All prospective respondents must communicate with the City only through the
designated Process Coordinator identified in this RFP. Prospective respondents shall
not communicate with City staff, City agents, and elected officials and instead will refer
any inquires to the designated Process Coordinator.
The Contractor shall be required to comply with all applicable City programs and
policies. Details are presented in the project documents and will be discussed at the
pre-proposal meeting i.e. Equal Benefits Campaign Contribution Post-project
Contractor Evaluation Prompt Payment Arizona Boycott and 50% L/SLBE (not
applicable, but L/SLBE participation is strongly encouraged) Dispute Disclosure. In
addition, descriptions and policies are available online at
(http://www2.oaklandnet.com/Government/o/CityAdministration/d/CP/s/policies/index.ht
m)
Contractors that wish to participate in the RFP process are required to register in
iSupplier in order to receive payments or notification of contracting opportunities.
Without proper registration, your firm may not receive notification from iSupplier
regarding contracting opportunities. We recommend updating your firms primary email
contact regularly and confirming that the Products and Services section of your profile
is correctly filled out. If you have any questions, please email
isupplier@oaklandnet.com. For further information and detailed iSupplier registration
instructions, please visit the following link
http://www2.oaklandnet.com/oakca1/groups/contracting/documents/webcontent/dowd02
1639.pdf.
Free copies of the RFP documents and Addenda are available in iSupplier. Hard copies
will NOT be available for purchase from the City. Consult the City website for the Plan
Holder list.
iSupplier Registration/Login:
http://www2.oaklandnet.com/Government/o/CityAdministration/d/CP/index.htm. New
registrants can email isupplier@oaklandnet.com for registration instructions. Allow 3
working days for approval to access bid documents through iSupplier
iSupplier Plan Holders List:
http://www2.oaklandnet.com/Government/o/CityAdministration/d/CP/s/PlanHoldersList/i
ndex.htm
Early Warning System Request for Proposal Page / ii

Contact Information: Due to the Cone of Silence, the ONLY City staff that is
available to answer questions regarding this RFP is the Process Coordinator, Ahsan
Baig, IT Director at abaig@oaklandnet.com or 510.238.3010
Early Warning System Request for Proposal Page / iii

Table of Contents
Summary of Key Information ................................................................................................... i
Table of Contents .....................................................................................................................iv
Glossary of Terms ................................................................................................................... x
1 Introduction ........................................................................................................................ 1
1.1 Scope of Services ..................................................................................................... 1
1.2 Procurement Timeline ............................................................................................... 3
1.3 The Contract ............................................................................................................. 3
1.4 Project Timeline ........................................................................................................ 3
2 IPAS Overview .................................................................................................................... 5
2.1 IPAS Definition ......................................................................................................... 5
2.2 Current IPAS Solution ............................................................................................... 5
2.3 System Context ........................................................................................................ 6
2.3.1 Data Context ................................................................................................. 7
2.3.2 IPAS Data Model Screen .............................................................................10
2.3.3 IPAS Reports ...............................................................................................11
2.3.4 Ad-Hoc Queries............................................................................................11
2.3.5 IPAS Superviewer ........................................................................................11
2.3.6 Outlier Identification .....................................................................................12
2.3.7 Threshold Reports........................................................................................12
2.3.8 PAS Activity Reviews ...................................................................................12
2.4 IPAS Technical Descriptions ....................................................................................12
2.4.1 Use of Force ................................................................................................12
2.4.2 Internal Affairs Database (IAD).....................................................................13
2.4.3 CER (Case Evaluation Report).....................................................................13
2.4.4 OC Checkout ...............................................................................................13
2.4.5 Canine Deployment ......................................................................................13
2.4.6 Vehicle Pursuit .............................................................................................14
2.4.7 Personnel (PDB) ..........................................................................................14
2.4.8 Training (TMS) .............................................................................................14
2.4.9 Training (Power DMS) ..................................................................................15
2.4.10 Law Records Management System (LRMS) .................................................15
2.4.11 Oracle Personnel .........................................................................................15
2.4.12 Vehicle Collision ...........................................................................................15
2.4.13 IPAS.............................................................................................................16
2.5 PAS Program Functional Description .......................................................................16
2.5.1 PAS Users ...................................................................................................16
2.6 PAS Workflows ........................................................................................................17
2.6.1 Peer Group Identification..............................................................................17
2.6.2 Outlier Identification Workflow ......................................................................19
2.6.3 Threshold Response Workflow.....................................................................20
2.6.4 Supervisory Monitoring/Intervention Workflow ..............................................21
2.6.5 Supervisory Notes Workflow ........................................................................22
2.6.6 Audit Process Workflow ...............................................................................23
Early Warning System Request for Proposal Page / iv

3 Proposal Submittal Requirements ...................................................................................24
3.1 Evaluation ................................................................................................................24
3.2 Evaluation Stage One Proposal Content ...............................................................24
3.3 Required Proposal Elements and Format ................................................................25
3.3.1 Transmittal Letter .........................................................................................25
3.3.2 Executive Summary .....................................................................................25
3.3.3 Company Profile...........................................................................................25
3.3.4 Company Qualifications ...............................................................................26
3.3.5 Proposed Solution ........................................................................................27
3.3.6 Project Approach and Organization ..............................................................28
3.3.7 Project Personnel .........................................................................................29
3.3.8 Maintenance and Support ............................................................................30
3.3.9 References...................................................................................................30
3.3.10 Project Costing .............................................................................................30
3.3.11 Proposal Validation ......................................................................................30
3.3.12 Rejection of Proposals .................................................................................31
3.4 Evaluation Stage Two Presentations ....................................................................31
3.4.1 Presentation Evaluation ...............................................................................32
3.5 Evaluation Stage Three Reference Checks ..........................................................32
4 Contract Negotiations and Award ....................................................................................33
4.1 Contract Negotiations ..............................................................................................33
4.2 Fixed Price ..............................................................................................................33
4.3 Hold-Back ................................................................................................................33
4.4 Contract Award ........................................................................................................33
4.5 Professional Services Agreement ............................................................................33
4.6 Notice to Proceed ....................................................................................................33
4.7 Evaluation and Audit ................................................................................................33
5 General Terms and Conditions ........................................................................................34
5.1 City of Oakland Tax Certificate ................................................................................34
5.2 Rejection of Bids ......................................................................................................34
5.3 The Citys Local and Small Business Enterprise Program........................................34
5.4 The Citys Living Wage Ordinance ...........................................................................34
5.5 Equal Benefits Ordinance ........................................................................................35
5.6 Prompt Payment Ordinance .....................................................................................36
5.7 Non-Discrimination/Equal Employment Practices ....................................................37
5.8 Arizona and Arizona-Based Businesses ..................................................................38
5.9 Pending Dispute Disclosure Policy ..........................................................................39
5.10 City of Oakland Campaign Contribution Limits .........................................................39
5.11 Nuclear Free Zone Disclosure .................................................................................39
5.12 Sample Professional Services Agreement ...............................................................39
5.13 Insurance Requirements ..........................................................................................39
5.14 City Contractor Performance Evaluation ..................................................................40
5.15 Violation of Federal, State, City/Agency Laws, Programs or Policies .......................40
5.16 Contractors Qualifications .......................................................................................40
5.17 Staff Available for Questions ....................................................................................41
5.18 Responses ..............................................................................................................41
5.19 Limitations ...............................................................................................................41
Early Warning System Request for Proposal Page / v

5.20 Proposal Evaluation .................................................................................................41
5.21 Right to Modify, Suspend or Terminate ....................................................................41
5.22 Service Provider ......................................................................................................41
5.23 Public Record ..........................................................................................................41
5.24 Fair Political Practices Act .......................................................................................41
Appendix A - Functional Requirements ................................................................................43
1. Functional Requirements .................................................................................................43
1.1 Purpose of Document ..............................................................................................43
2. Business and Project Context ..........................................................................................43
2.1 Background .............................................................................................................43
2.2 Objectives ................................................................................................................43
2.3 Scope ......................................................................................................................44
2.4 Assumptions ............................................................................................................44
3. Context and Business Services Overview.......................................................................45
3.1 Context Diagram ......................................................................................................45
3.2 Personnel Assessment Subject Area .......................................................................45
3.2.1 Sample Period .............................................................................................46
3.2.2 Peer Group Selection Criteria.......................................................................46
3.2.3 Events Definition ..........................................................................................46
3.2.4 Exclusion Criteria .........................................................................................47
3.3 IPAS2 Components .................................................................................................47
3.3.1 Business Services ........................................................................................48
3.4 Business Processes ................................................................................................49
3.4.1 Business Process Diagram ..........................................................................49
3.4.2 Business Process Summary.........................................................................49
3.5 IPAS2 Business Processes .....................................................................................49
3.5.1 Define Peer Group .......................................................................................50
3.5.2 Assign Employees to Peer Group ................................................................50
3.5.3 Define Threshold ..........................................................................................50
3.5.4 Identify Single Event Threshold Met .............................................................51
3.5.5 Identify Outliers ............................................................................................52
3.5.6 Refer to PAS Program..................................................................................52
3.5.7 Reporting and Analysis ................................................................................53
3.5.8 Audit Processes ...........................................................................................53
4. Functional Requirements .................................................................................................54
4.1 Overview .................................................................................................................54
4.2 Source Data.............................................................................................................54
4.3 Peer Groups ............................................................................................................54
5.24.1 4.3.1 Peer Group Requirements...................................................................55
4.4 Thresholds ...............................................................................................................56
4.4.1 Thresholds Requirements ............................................................................56
4.5 Outliers ....................................................................................................................57
4.5.1 Outliers Requirements..................................................................................57
4.6 Queries and Reporting .............................................................................................58
4.6.1 Queries and Reporting Requirements ..........................................................58
Early Warning System Request for Proposal Page / vi

4.6.2 Event Cross Referencing .............................................................................60
5. Data Requirements............................................................................................................60
5.1 Data Architecture .....................................................................................................60
5.2 Historical Data .........................................................................................................61
5.3 Data Refresh Requirements ....................................................................................61
5.4 Source Data.............................................................................................................61
5.4.1 Source Data Requirements ..........................................................................61
6. Non-Functional Requirements .........................................................................................61
6.1 Usability Requirements ............................................................................................62
Appendix B - Technical Requirements ..................................................................................63
1. Technical Requirements ...................................................................................................63
1.1 Reference Architecture ............................................................................................63
1.2 Security ...................................................................................................................64
1.3 General....................................................................................................................65
1.4 Performance, Uptime, and Scalability ......................................................................65
1.5 Longevity / Maintainability ........................................................................................66
1.6 Backup / Restore .....................................................................................................66
1.7 Audit and Security....................................................................................................66
1.8 Data Integration (ETL) .............................................................................................68
1.9 Supplemental Tools .................................................................................................68
1.10 Physical Environments ............................................................................................69
2. Interface Requirements ....................................................................................................69
2.1 Machine Interfaces ..................................................................................................69
2.2 Human Interfaces ....................................................................................................69
Appendix C - Implementation Requirements ........................................................................71
1. Implementation Requirements .........................................................................................71
1.1 Overview .................................................................................................................71
1.2 Project Management Requirements .........................................................................71
1.2.1 Planning Activities ........................................................................................71
1.2.2 Execution & Controlling Activities .................................................................72
1.2.3 Project Closing Activities ..............................................................................72
1.3 Implementation Requirements .................................................................................73
1.3.1 Change Management ...................................................................................73
1.3.2 Communication ............................................................................................73
1.3.3 Training ........................................................................................................73
1.3.4 System Documentation ................................................................................73
1.3.5 Integration Testing .......................................................................................74
1.3.6 User Acceptance Testing .............................................................................74
1.3.7 Infrastructure (Hardware & OS Software) .....................................................75
1.3.8 Establish Software Environments .................................................................75
1.3.9 Data Conversion ..........................................................................................76
1.3.10 Configuration Management ..........................................................................76
1.3.11 Production Cut-Over ....................................................................................77
1.3.12 Warranty and Support ..................................................................................77
Early Warning System Request for Proposal Page / vii

1.3.13 Backup and Recovery Strategy ....................................................................79
Appendix D IPAS2 Source System Requirements .............................................................80
1. Introduction .......................................................................................................................80
1.1 Purpose of Document ..............................................................................................80
2. Business and Project Context ..........................................................................................80
2.1 Background .............................................................................................................80
2.2 Objectives ................................................................................................................80
2.3 Scope ......................................................................................................................80
2.4 Assumptions ............................................................................................................81
3. Context and Business Services Overview.......................................................................82
3.1 Context Diagram ......................................................................................................82
3.1.1 Business Services ........................................................................................83
3.2 Business Processes ................................................................................................86
3.2.1 Business Process Diagram ..........................................................................86
3.2.2 Business Process Summary.........................................................................87
3.2.3 Business Process Model Create Case Evaluation Report .........................88
3.2.4 Business Process Model Record Vehicle Pursuit ......................................89
3.2.5 Business Process Model Record Vehicle Collision ....................................90
3.2.6 Business Process Model Record Canine Deployment ...............................91
3.2.7 Business Process Model Record Use of Force..........................................92
3.2.8 Business Process Model Receive IAD Complaint ......................................93
3.2.9 Business Process Model Create Supervisory Notes ..................................95
3.2.10 Business Process Model Review Supervisory Notes .................................96
3.2.11 Business Process Model Record OC Checkout.........................................97
3.2.12 Business Process Model Create PAS Report ............................................98
3.2.13 Business Process Model Monitor PAS Program Activity ............................99
3.2.14 Business Process Model Manage Code Tables ......................................100
3.3 Process to Use Case Mapping...............................................................................101
4. Functional Requirements ...............................................................................................104
4.1 Actor List ...............................................................................................................104
4.2 Use Cases .............................................................................................................105
4.2.1 Use Case Diagram .....................................................................................105
4.2.2 UC01 Search Record ..............................................................................110
4.2.3 UC02 - Retrieve Employee Information ......................................................113
4.2.4 UC03 Record Case Evaluation ................................................................114
4.2.5 UC04 Create IAD Referral .......................................................................117
4.2.6 UC05 Send Notification ...........................................................................120
4.2.7 UC06 Record Vehicle Pursuit ..................................................................122
4.2.8 UC07 Record Vehicle Collision ...............................................................125
4.2.9 UC08 Record Canine Information............................................................128
4.2.10 UC09 Record Canine Event ....................................................................130
4.2.11 UC10 Record Use of Force .....................................................................133
4.2.12 UC11 Investigate Use of Force ...............................................................136
4.2.13 UC12 Approve Use of Force Investigation Recommendation ...................139
4.2.14 UC13 Record Use of Force Distribution and Form Links .........................143
Early Warning System Request for Proposal Page / viii

4.2.15 UC14 - Request Use of Force Investigation Extension ...............................144
4.2.16 UC15 Track Use of Force Investigation ...................................................146
4.2.17 UC16 - Create Chronological Log ..............................................................148
4.2.18 UC17 - Search IAD Complaint....................................................................150
4.2.19 UC18 Receive IAD Complaint .................................................................152
4.2.20 UC19 Create IAD Complaint ...................................................................155
4.2.21 UC20 Record IAD Complaint Finding ......................................................158
4.2.22 UC21 Create Supervisory Note ...............................................................162
4.2.23 UC22 - Review/ Append Supervisory Note .................................................163
4.2.24 UC23 Create OC Inventory .....................................................................165
4.2.25 UC24 Request OC Checkout ..................................................................166
4.2.26 UC25 Record OC Checkout ....................................................................168
4.2.27 UC26 Create PAS Report Request .........................................................170
4.2.28 UC27 Create PAS Report .......................................................................172
4.2.29 UC28 Create PAS Disposition Strategy ...................................................175
4.2.30 UC29 - Record PAS Meeting......................................................................177
4.2.31 UC30 End PAS Monitoring ......................................................................179
4.2.32 UC31 - Route Record to Another User .......................................................181
4.2.33 UC32 - Update Code Table ........................................................................183
4.2.34 UC33 Audit User Activity .........................................................................184
4.2.35 UC34 - Print Record ...................................................................................185
5 Data Requirements..........................................................................................................187
5.1 Reporting Requirements ........................................................................................187
5.2 Non-Functional Requirements ...............................................................................188
Appendix E Draft IT Agreement and Instructions to Offerors .........................................189
Appendix F - Schedule Q Insurance Requirements.........................................................218
Appendix G - Schedule E Project Consultant Team Listing............................................222
Appendix H - Schedule O Campaign Contributions ........................................................224
Appendix I - Pricing ..............................................................................................................226
1. Solution and Implementation Costs .......................................................................226
2. Solution Maintenance and Support Costs ..............................................................227
3. Hourly Rates for Vendor Team ..............................................................................227
Appendix J - Support ............................................................................................................228
Severity Levels ..................................................................................................................229
Early Warning System Request for Proposal Page / ix

Glossary of Terms
Term Description
Ad Hoc Report An Ad Hoc Report is the ability to create a completely new report
from the business subject area (s). They are professionally
formatted and include prompting and are meant for mass
distribution.
AOI Adjudication of Investigations
Bar A histogram which graphically illustrates the Key Performance
Indicator (KPI) percentage ranking for the incumbent or employee
as compared to his/her peer group
BIQUERY Software toolset for generating reports from databases and create
data models (Hummingbird)
BI Portal A BI Portal is the end users point of entry into the BI system. The
BI Portal is in essence a web page with a series of tabs providing
the highest level of organization and assistance for the myriad of
information products typically contained in the BI system.
Business A Business Intelligence (BI) System is a purpose built system
Intelligence whose main role is to organize data from a business perspective,
Solution automate workflows, and facilitate end user reporting and analysis
in an intuitive and user friendly manner. A BI System consists of
three layers:
1) Source System Layer
2) Data Warehouse Layer, including Workflow Engine
3) Reporting & Presentation Layer
CER Case Evaluation Report
City City of Oakland
COTS Commercial Off The Shelf
CRT Crime Reduction Team
Early Warning System Request for Proposal Page / x

Term Description
Cube A Cube is a physical packaging of data drawn from a subject area
(aka OLAP On into a multi-dimensional structure. This structure allows an end
user to explore or analyze their data (slice and dice) in an
Line Analytical
interactive manner. Usually each subject area will be delivered
Processing)
with at least one cube that is a collection of selected Facts and
Dimensions from a particular subject area. Cubes contain typically
summary data. From the cube users can drill thru to detail
information via Drill Through Reports.
Dashboard A Dashboard is in essence a single report page that contains many
panes each displaying different albeit related data to an end user.
The dashboard is used to deliver the concept of Guided Analysis.
This concept is one where a related series of reports, cubes,
metrics, links, etc for a specific business process are grouped for
ease of navigation. They enhance the end user experience by
providing a series of analytical pathways on a particular topic.
Data A Data warehouse is a separate database / server where data is
Warehouse organized from a business perspective. The Data Warehouse
typically contains two areas. The first is commonly referred to as
Staging, where the initial physical copy of source system data
occurs. The second area is for the Subject Areas. Here data is
organized into Subject Areas which are usually based on business
processes eg: for OPD Events, Assignments, etc.
Dimension Dimensions are descriptive in nature and answer the questions:
who, what, where and when, hence why. Each Subject Area is
presented with a set of dimensions. Dimensions are structured
hierarchically into levels. For example a date dimension can be
organized into year, quarter, month and week levels.
Drill Through A Drill Thru report can be invoked from either a cube or another
Reports report. This type of report shows the details of a given record(s) in
a subject area. After a user has selected a subset of data, via a
cube or report, they can invoke a pre-defined drill through report.
The parameters passed to the drill thru report are the identifiers of
the records of data that were highlighted by the user.
ETL ETL stands for Extract, Transform and Load. It is the technical
process by which data is Extracted from source systems,
Transformed into a business perspective, and Loaded into a
Subject Area data model. ETL Tools are usually employed to
perform this function.
Event An operational event that when analyzed with other factors, can be
a predictor of risk.
Early Warning System Request for Proposal Page / xi

Term Description
Event Count The number of times an event or incident occurs
Facts Facts are any quantitative value related to the users data, such as
dollars or counts. Facts or measures can also be derived from the
data via a calculation. ie: Average number of preventable
collisions.
Grain The Grain is the lowest level of detail contained within a subject
area. For example: For an event subject area the grain would be
one row per event per employee.
Histogram A histogram is the graphical version of a table which shows what
proportion of cases fall into each of several or many specified
categories
IAD Internal Affairs Division
IC In Custody
ICD In Custody Deaths
DIT Department of Information Technology
Information Information products represent the many ways that information will
Products be provided to the end user community. Information products
come in many forms including: Reports, Cubes, Drill Through,
Queries, and Metrics.
IPAS Internal Personnel Assessment System
IMT Independent Monitoring Team appointed by the Federal Judge
KPI Key Performance Indicator A set metrics or measurements to
reflect the present and past assessment in an organization. These
measurements reflect numerical calculations for a defined time
period, and the results are used for comparison analysis.
LRMS Law Records Management System
NSA Negotiated Settlement Agreement
OC Oleoresin Capsaicin (Pepper Spray)
OIS Officer Involved Shootings
OPD Oakland Police Department
OPDNET OPD Domain Network
PAS Personnel Assessment System
PDB OPD Personnel Data Base Application
Early Warning System Request for Proposal Page / xii

Term Description
Peer Group The members in a selected group with similar attributes that can be
associated by rank, status, work assignments or other criteria.
Peer Group A group of people statistical similarities that share a common factor
Size e.g. rank, status, work assignments or other criteria.
Performance Metrics are measures of business activity and health of an
Metrics organization. A Metrics consists of a defined indicator, a Target,
and a Tolerance. These are then compared against an actual
(aka KPIs - Key
measure to determine whether that target has been achieved. In
Performance
some respects Metrics can be viewed as high level exception
Indicators)
reporting.
Prompted Prompted reports are pre-defined reports where a user can select
Reports from a series of prompts or filters to narrow the size of the report or
dataset that is returned in the report format.
Record Count The number of events counted for a selected criteria
Reporting and The Reporting or Presentation layer is where all of the various
Presentation Information Products are presented to the end user. Information
Layer products come in many forms including: Reports, Cubes, Drill
Thurs, Queries, and Metrics. Information products are contained
within a BI Portal and organized in a way that is intuitive and easy
to navigate.
Queries A Query is the ability for a user to create their unique query into the
subject area data. This is usually one-off in nature and is used
when the required information is well defined.
RRN Report Review Notices
Source System Source systems are any system where data is originally captured
Layer to facilitate some business function within the organization.
Examples of source systems include: Use of Force, IAD, Legacy
Systems, Flat files and External data sources. The source system
provides the data to the Data Warehouse.
SSL Secure Socket Layer
Subject Area Subject Areas or Data Marts is a method of storing and organizing
data from a business perspective. Data is organized in a
dimensional model which contains a single Fact table and multiple
Dimension tables. Subject Areas are usually based on business
processes i.e.: Threshold Events. Subject areas in a warehouse
should share many of the same dimensions. The creation of
business subject areas represents the majority of the effort in a
typical BI System development.
Early Warning System Request for Proposal Page / xiii

Term Description
Threshold A level, point, or value above which an event is true or will take
place, and below which an event it is not true or will not take place
Early Warning System Request for Proposal Page / xiv

1 Introduction
The Oakland Police Department (OPD) is budgeted for approximately 1100 sworn and
professional staff members. Each member of the department completes multiple
assignments daily. There are a variety of custom and commerical off the shelf
information systems throughout the Department that are used to support the business.
These include:
The legacy Records Management System which will soon be replaced,
Oracle ERP Solution,
TMS a FoxPro training system
Power DMS training system
Vision Tek a field based reporting solution that will be incorporated into the new
RMS.
Multiple Microsoft Access database systems created internally within OPD
The majority of the Departments systems are based in SQL Server 2000, text files,
spreadsheets, Microsoft Access databases and XML documents. The data is accessed
with various software programs, which resides in desktops, laptops and mobile
computer platforms running Windows XP.
OPD is interested in modernizing its systems and is replacing the current IPAS solution.
The project will also allow the Department to move seven (7) source systems off
Microsoft Access databases into a new data capture solution to provide consistent,
reliable data to a new data warehouse. The new early warning system will allow the
Department to evaluate the performance of subordinate behavior, based on statistical
analysis, and if necessary, take and record appropriate action using this tool.
OPD uses a number of data mining tools for various reports. The current tools are
not intuitive. As a result, data mining and the resulting reporting are left to staff that
take extended periods of time to learn the complex series of instructions to retrieve
data from these systems. This means data gathering and reporting is typically left to
just a few key people.
Recognizing the need to disseminate risk management data throughout the department,
the department would like to utilize an intuitive program, which would open this data to
all employees at every level of computer expertise from the novice to the power user.
1.1 Scope of Services

The City is seeking a vendor to replace the Oakland Police Departments currently Early
Warning System, the Internal Personnel Assessment System (IPAS), with a new Early
Warning System (IPAS2). The scope of the services required is:
Provide a complete business intelligence solution utilizing a Microsoft platform to
report on early warning activities as defined by this RFP. This includes:
Early Warning System Request for Proposal Page / 1

o Data Warehouse - The Data Warehouse will contain two areas:
o Staging, where the initial physical copy of source system data occurs, and
Subject Areas, where data is organized into dimensional models based on the
business processes.
o Extract-Transform-Load tools and processes ETLs will extract the data from
source systems, organize the data into a business perspective and upload to
subject areas while managing concurrency, maintaining data integrity and
indices.
o Presentation Layer - Provide a variety of analysis and reporting products and
tools for use by end users, including Reports, Cubes, Drill Thurs, Queries, and
Metrics.
o Workload management tools, including dashboards and work queues.
Automate the work of the PAS Admin Unit as follows:
o Define Peer Groups based on user-defined business rules
Define and categorize threshold activities based on business rules.
Provide reporting on outliers and threshold activities.
Identify high risk individuals based on business rules.
Audit and monitor individuals on the PAS program.
Provide a data capture solution utilizing a Microsoft Platform, that will:
o Replace 7 existing MS Access databases used to capture source system data.
Canine Deployment
Use of Force
Internal Affairs Division (IAD)
Case Evaluation Report (CER)
OC Checkout (Oleoresin Capsicum (OC) Spray)
Vehicle Pursuit
Vehicle Collision
Replace existing Supervisory Notes data capture functionality in the current IPAS2
Data Capture Solution
Provide a new data source for PAS Reporting and Monitoring with the IPAS2 Data
Capture Solution.
Provide stability and scalability for source data, with the ability to add new data
sources over time.
o Provide workflow engine for process automation and prompt notifications.
Provide implementation activities that include:
o Solution design and implementation
o Data Conversion from source systems and IPAS thresholds.
o Unit Testing and System Testing

o Technical Documentation
o End User Training and Documentation
o Warranty and Support Services.
Bidders requiring detailed information on Early Warning and Intervention Systems
should review a publication called, Early Intervention Systems for Law Enforcement
Agencies A Planning and Management Guide by Samuel Walker PHD, available via
the following link: http://cops.usdoj.gov/files/ric/Publications/e07032003.pdf
1.2 Procurement Timeline

The following is the City of Oaklands estimated timeline for the procurement process:
Activity Anticipated Timeline
MANDATORY Pre-proposal Meeting January 7, 2014
Deadline for Questions January 10, 2014
RFP Closing Date/Time January 31, 2014 at 2:00 PM
Presentations 3 weeks after closing date
Reference Checks 1 week after presentation
Notification of Successful Bidder February 28, 2014
Contract Commences 1 month after notification
1.3 The Contract

The City of Oakland intends to enter into an Agreement with the Contractor based on
the terms provided below. Bidders are invited to seek clarifications to the Terms and
Conditions. The City will consider all written requests for clarifications. The City may
also take into consideration comments made during discussions at the Mandatory Pre-
proposal Meeting.
Bidders are encouraged to review the Terms and Conditions in their entirety to be sure
they fully understand the details and requirements of this Project. Bidders are
responsible for ensuring they have a complete understanding of the terms and
conditions of this RFP and this Project.
1.4 Project Timeline

The initial Contract, which includes the implementation of IPAS2, is anticipated to
commence in early 2014. It is anticipated that this project will be completed within 18
months. The initial Contract term will cover the IPAS2 design, testing, training,
implementation, Warranty Period and the first years maintenance and support. The City
reserves the right to extend the Contract with the successful Vendor on the same terms
and conditions, but is under no obligation to do so.

The City reserves the right to contract with the successful Vendor for additional work
related to this Project which may not have been included in this RFP but is under no
obligation to do so.

2 IPAS Overview
2.1 IPAS Definition
IPAS is an acronym for the OPDs Internal Personnel Assessment System. This system
was developed by the City of Oakland (City) through the collaboration of the OPD and
the Citys Department of Information Technology (DIT) staff to support the PAS
program.
The Personnel Assessment System (PAS) is a pro-active, non-disciplinary, early
identification and intervention program designed to identify and positively influence
conduct, correct performance-related problems and to recognize exemplary
performance. OPD has deployed this system to collect, manage and report information
relating to the Negotiated Settlement Agreement (NSA) requirements regarding the
OPD employee performance. IPAS provides supervisors, commanders, and managers
to review their subordinates performance as it relates to these standards.
IPAS is a Client/Server data retrieving, storing, and reporting computer system. It
consists of three parts, the IPAS data integration framework, the IPAS relational
database repository and the IPAS reporting portal.
The IPAS integration framework is the Extraction, Transformation, and Loading
(ETL) process which connects the various OPD existing applications and pulls the
required data needed for the IPAS operations, analysis, and reporting. It is
implemented in Microsoft SQL Server Integration Services (SSIS).
The IPAS database repository system connects to and pulls data from various OPD
operational databases and application sources. In this way, it provides a centralize
data view from different OPD databases and computer applications and works as a
repository of critical data for IPAS.
The other component of the IPAS system is the SuperViewer reporting portal. The
SuperViewer is a secure, web-based intranet application for providing the detail
reports to the OPD Supervisors. The SuperViewer also provides the Supervisory
Notes functionality which allows supervisors to capture notes about the performance
of subordinate. Employees have view only access to their own Supervisory Notes.
2.2 Current IPAS Solution

The current IPAS solution is made up of a number of computer systems and manual
processes. This section contains an overview of the computer systems in use to
perform the personnel assessment processes within OPD. The system is comprised of
a combination of COTS products in conjunction with several custom applications using
a variety of technologies (detailed in this section).

2.3 System Context
The following diagrams show the network topology and physical deployment of the
various servers throughout the IPAS system to give context regarding network
connectivity, infrastructure, and operational boundaries.
City of Oakland
IPSS 2009 Network Overview
150FOP City Internet
IAD
Sprint EVDO
EOC 150 Frank
1605 MLK 1GB
Ogawa Plz
DS3
1GB
Eastmont
1GB
DS3
911
Police
Municipal
Administration
Service Center Microwave
Figure 1: City of Oakland IPSS 2009 Network Overview

I-PAS
SYSTEM CONTEXT
IPASDB
I-PAS Backbone
IPASAPPS
IAD DB
IPASTEST
IAD Network
IAD
Firewall
I-PAS
Firewall
I-PAS Network
OPD Network
Document
Server
OPD Backbone
Oakland
City
OPD Supervisors
Firewall LRMS
(Web Client)
Oakland
City Network I-PAS Admin
BISERVER
(Web and BI Client)
Oracle
E-Business
Active
IPSS Backup
Directory
Figure 2: I-PAS System Context
2.3.1 Data Context

IPAS combines data from 22 different dimensions and 12 different source systems to
providing reporting for the OPD. The following table depicts the 22 dimensions, data
sources and their association with various applications:
Dimensions # Dimension Name Application/DB

1 Use of Force Investigations Internal Affairs Database (IAD)
4 OIS Firearm Discharge
6 Citizen complaints
7 Civil Suits
8 Financial Claims
9 In-Custody Injury/Complaint
10 Results of AOI
12 Criminal Arrest and Charges

Dimensions # Dimension Name Application/DB
18 RRN
19 Criminal Cases Dropped
21 Use of Force Use of Force
2 OC Checkout OC Database
3 Canine Deployment Canine Database
5 Vehicle Pursuit Vehicle Pursuit Database
22 Vehicle Collisions Collision
11 Awards & Commendations PDB
14 Assign & Rank History
15 Training History TMS & Power DMS
16 Line of Duty Injury Injury Database Via PDB
17 Sick Leave Oracle Personnel Via PDB
13 Arrest LRMS
20 Other Supervisory observations IPAS
and concerns

The figure below shows the IPAS system overview:
Figure 3: IPAS System Overview

The following diagram shows the layout of the various data sources to the IPAS system
to give context regarding the source system definitions in the later sections of this
document. Items shaded in light red are scheduled to be replaced within the scope of
the IPAS2 application.
Use of Force
Internal Affairs
(IAD)
Case Evaluation
Report (CER)
OC Checkout
Canine
Deployment
Vehicle SSIS
I-PAS
Pursuit ETL
Personnel
(PDB)
Training (TMS)
Training
(Power DMS)
LRMS
Collision
Figure 4: Various Data Sources to the IPAS system

The relevant external data sources to the Personnel application (PDB) are listed in
diagram below.
Line of Duty
Injuries
SSIS Personnel
ETL (PDB)
Oracle
E-Business Suite
Figure 5: External Data Sources to the Personnel application (PDB
2.3.2 IPAS Data Model Screen

The IPAS data model screen shows the database tables that are used to build the IPAS
reports and ad-hoc queries. Each table contains only the data that has been extracted

from the sources for the sole purpose of providing reporting capability. Additional
attributes are added from time to time as more reporting requirements are identified.
Any of the information contained in the tables can be combined for reporting purposes,
however drill-down capacity into specifics and event cross-referencing is not possible.
Figure 6: Master Name Index in IPAS

A Master Name Index in IPAS is used to uniquely identify officers. All event reporting is
based on Officer ID (Serial Number), which remains a requirement of the new solution.
2.3.3 IPAS Reports

The PAS Admin Unit uses the Open Source Archon tool, developed by DIT, to run peer
group reports, threshold reports and to provide reporting on the 22 dimensions currently
supported by IPAS.
2.3.4 Ad-Hoc Queries

The IPAS application uses the Hummingbird BI SERVER reporting toolset to generate a
series of ad-hoc queries from the central IPAS data repository. At this time only the
PAS Admin Unit can generate Ad Hoc queries, however the future state will expand this
capability to additional roles within the organization.
2.3.5 IPAS Superviewer

The SuperViewer is accessed through a secure, web-based intranet application
designed to provide a single sign-on access to retrieve information from the IPAS
database repository. The SuperViewer allows supervisors to access canned reports
directly from the database repository for subordinate staff members.

Supervisors/commanders/managers take into account relevant and appropriate PAS
information when reviewing and considering any of the following personnel actions:
Conducting PAS Activity Reviews;
Commendation or award recommendation;
Promotions;
Transfers;
Special assignments;
Twice Monthly Performance Reviews;
Semi-Annual Supervisor Performance Reviews;
Annual and Probationary Performance Appraisals; and
Determinations of appropriate discipline for sustained misconduct.
Additionally, the Supervisory Notes functionality is part of the SuperViewer. This
functionality allows a supervisor to enter and view information about the performance of
subordinate staff. Employees have access to view their own supervisory notes file
electronically.
2.3.6 Outlier Identification

Every 8 weeks the PAS Admin Unit generates a histogram to perform peer group
comparisons over an 18 month period. During this analysis, the PAS Admin Unit
identifies outliers for further review.
2.3.7 Threshold Reports

PAS thresholds are measured in an 18 month period. This period, referred to as a
rolling window, will include all activity in PAS from the date of the threshold report back
to a date 18 months prior. Among other types of analysis, the PAS Admin Unit will look
for individuals who have met a Single Event Threshold criteria (most serious event
types), and will select them for review.
2.3.8 PAS Activity Reviews

When an OPD employee has exceeded a Single Event PAS Threshold, or has been
verified as an outlier, the PAS Admin Unit shall conduct a PAS Activity Review. This
review shall include a review of all PAS dimensions.
2.4 IPAS Technical Descriptions

2.4.1 Use of Force
User Interface Technology Microsoft Access 2003
Database Technology Microsoft SQL Server 2000
Approximate Number of Users 3 (read/write)
3 (read only)
Approximate Number of Tables and Fields 5 tables

Extracted to IPAS 55 fields
Approximate Number of Records Extracted to 15,000
IPAS
2.4.2 Internal Affairs Database (IAD)

User Interface Technology Microsoft Access 2003 and
Microsoft Access Server 2010
Approximate Number of Users 35
IPAS
2.4.3 CER (Case Evaluation Report)

IPAS
2.4.4 OC Checkout
Approximate Number of Tables and Fields 1 table
IPAS
2.4.5 Canine Deployment


IPAS
2.4.6 Vehicle Pursuit

IPAS
Note: records from this data source are added to the records from the Vehicle Collision
data source.
2.4.7 Personnel (PDB)

User Interface Technology Microsoft Access 2003 with
VB 6.0 extensions
IPAS
2.4.8 Training (TMS)

User Interface Technology Microsoft Visual FoxPro
IPAS
Note: records from this data source are added to the records from the Training (Power
DMS) data source.

2.4.9 Training (Power DMS)
User Interface Technology COTS
IPAS
Note: records from this data source are added to the records from the Training (TMS)
data source.
2.4.10 Law Records Management System (LRMS)

User Interface Technology COTS with customization /
configuration by Motorola
IPAS
2.4.11 Oracle Personnel

User Interface Technology Oracle ERP E-Business Suite
Database Technology Oracle 11i
Approximate Number of Users City-wide
Approximate Number of Records Extracted to 2,200,000
IPAS
Note: records from this data source are extracted to IPAS after first being imported into
the PDB application. From the IPAS perspective, this data can be considered part of the
PDB application.
2.4.12 Vehicle Collision


IPAS
Note: records from this data source are added to the records from the Vehicle Pursuit
data source.
2.4.13 IPAS
User Interface Technology ASP.NET 2.0, C#
Database Technology Microsoft SQL Server 2008 R2
2.5 PAS Program Functional Description

2.5.1 PAS Users
This section details the user groups and a description of how they use the system:
User Class User Type Description
Oakland Police Chief, Deputy Interested in viewing aggregated
Department Chiefs, statistics across entire organization.
Executive Commanders Interested in viewing information and
statistics about subordinates
Access to prompted reports, drill
through reports and queries.
View canned reports generated
through published Ad Hoc Reporting
or other information products.
Oakland Police Supervisors Interested in viewing information and
Department statistics about subordinates.
Operations Access to prompted reports, drill
through reports and queries.
OPD Staff Employees Interested in viewing information and
statistics about themselves.

User Class User Type Description
Oakland Police Systems Interested in viewing aggregated
Department - PAS Administrators statistics across entire organization.
Admin Unit Author Ad Hoc reporting.
Need access to all information
products including cubes.
Need access to all data at the lowest
level of detail.
Typically interested in data anomalies
and data clean-up.
Department of Systems Typically interested in data anomalies
Information Administrators and data clean-up.
Technology Provides IT support for source
systems and ETL processes.
2.6 PAS Workflows

The following section provides a description of current workflows related to the PAS
Program. It is anticipated that a business process re-engineering exercise will take
place in advance of the IPAS2 system (and separate from the IPAS2 Technology
Project and RFP), to streamline processes, ensure efficiency, decrease cycle times and
maintain stable, foreseeable process outcomes and high levels of quality within the PAS
Program.
2.6.1 Peer Group Identification

Peer Group Assignment
Phase 1
Individual
Assignment to
Personnel System
Start
Organization/ranik/
Civilian and Sworn Categories based
etc.
on organization and rank. Peer
(PDB)
Groups based on current assignment
Peer Group
Assignment based
on Business Rules
Change of Outlier
NO
Assignment Identification
Validate Data is
PAS Admin Unit
uploading correctly
from source systems
YES
Review Peer Group
Identify Outliers at
Assignment over 18
95th Percentile
months
Manual Comparison
with Prior Peer
Generate Histogram Groups
System
Use Peer Group and

IPAS
Source System
Events to create
Histogram
Histogram generated using
Archon (every 8 weeks)

Peer groups are assigned in the Personnel Database System (PDB) based on current
assignment (even if the individual was in a different assignment for 17 of the past 18
months). Currently, no history of peer group assignment is maintained in IPAS and over
time comparisons using the IPAS System are not possible.
Assignments to Peer Groups in the Personnel Database (PDB) are maintained using a
mapping table of assignment to peer group.
Peer group assignment is used by the PAS System for the purpose of generating the
Histogram (in Archon) used to identify Outliers based on peer group comparison using
the following criteria:
Number of threshold events for each individual within the peer group.
Outlier cut-off percentage high end (currently 95%) based on events for the
individuals within the peer group.
Outlier cut-off percentage low end (currently 5%) based on events for the individuals
within the peer group.
Peer groups may be manually manipulated by the PAS Admin Unit in accordance with
business rules, after the Outlier Identification process has been executed in the IPAS
System. The manual allocation to business rules is based on the following:
Assignment to peer group based on longest assignment within the last 18 month
period.
Assignment to peer group based on type of assignment during past 18 months (eg.
If individual was assigned to the Crime Reduction Team (CRT) during the past 18
months, they will be automatically evaluated against other individuals in CRT during
the past 18 months, due to the high event count for this group).
The manual allocation to peer groups is not tracked in any system; therefore reporting
on manual peer group reassignment is not possible using the IPAS system.

2.6.2 Outlier Identification Workflow
Outlier Identification
Phase 1
Peer Group
Exclusion
Assignment
Warranted?
Process PAS Threshold
Response Sub-
Process
Assessment based on documented NO
business rules (12 different exclusion
YES
PAS Admin Unit
criterion)
Individual entered Strategy Reassessment

Entered on
on Exclusion List Requested (if 3
Notification List if
based on exclusion notifications have already
already on program
criteria been submitted
Outlier Database
Create one entry for

each threshold met
individual can be entered multiple

times
PAS Histogram
Threshold percentile
Spreadsheet
cutoffs for each peer

Tracking
group and
thresholds created
Figure 7:
Following the Outlier identification, and the manual peer group assignment process, the
PAS Admin Unit will apply elimination criteria to employees who have met or exceeded
the 95% cut-off within their assigned or adjusted peer groups. Criteria include
individuals already on the IPAS Program. This information is external to the IPAS
System; therefore reporting on this data is completely manual.
Outlier Identification is manually tracked for auditing and reporting purposes.

2.6.3 Threshold Response Workflow
Threshold Response Workflow
Phase 1
Review Panel
PAS Activity
Outlier PAS Activity Review

Review and Validate
Identification Panel Response
PAS Activity Report Intervention
process Documented
Identified
PAS Activity Report

Prepare PAS Activity
Identification of reviewed by PAS
PAS Admin Unit
Review and Report

Single Event Supervisor
YES
Threshold (weekly
query) NO
PAS Threshold
Notification
Memorandum sent
Chain of Command
Management Review PAS Change to

Referral (multiple Threshold
Response/Feedback Response?
sources) Notification
Memorandum
Sent to DC and Captain and

BFO Admin entered into PAS Panel Response
DB and tracked Reviewed
PAS Notification
DB
Notification
Notification Created
Updated/Closed
Monthly Report
PAS Activity
Supervisory
Variety of tracking Decision entered Monitoring/
spreadsheets updated into spreadsheet Intervention
Sub-Process
Figure 8:
There are three mechanisms for triggering a PAS Activity Review and Report. These
are:
Outcome of the Outlier Identification Process
A Single Event Threshold has been met
A referral from Chain of Command for a Review.
The Outlier Identification Process is run by the PAS Admin Unit every 8 weeks.
Additionally, they will manually run a weekly query in IPAS to check for Single Event
Thresholds. The Single Event Thresholds are a subset of events identified as high
risk and when an individual has even just one of them, a PAS Activity Review is
required.
The Chain of Command can request a PAS Activity Review and Report at any time.
The PAS Activity Review and Report is conducted by the PAS Admin Unit with input
from the immediate supervisor of the individual. The PAS Review and Report is
completed on paper and goes through a variety of review cycles which are tracked
using paper processes and recorded in spreadsheets. Notifications are sent by the
PAS Admin Unit to the Chain of Command manually using email systems and tracked in

an Access database. The PAS Admin Unit is responsible for all of the tracking, email
notifications and reporting resulting from this process.
Once a disposition has been identified, it is recorded in a spreadsheet and the
Supervision Monitoring/Intervention Process begins.
All of the tracking and reporting is subject to regular audits by the PAS Admin Unit.
2.6.4 Supervisory Monitoring/Intervention Workflow

Supervisory Monitoring/Intervention Workflow
Phase 1
Date/Time/Location,
Attendees, Summary,
Description of at-risk behavior Within 7 Days. Type of Strategy, Start Date, Location,
Threshold being addressed/response/ Completion Date, Progress, Changes, Description of At-Risk
Response Plan/Timelines Behavior being addressed/ Affect of strategy
Process
PAS Strategy
Create PAS Strategy Hold follow-meetings Final Follow up
Supervisor
Monitor PAS Confirmation

Confirmation Report in accordance with meeting report with
Create Disposition Strategies Report
schedule recommendation
Conduct Disposition Meeting/Follow- Up
Meeting Meeting Report
Extend Program
Extensions in 3
month increments
additional follow up
required.
Command
Chain of
Review and Approve

Disposition Follow- Review and Approve
up Report PAS Strategy
Confirmation Report
PAS Admin
Unit Staff
Audit Disposition follow up Audit PAS Intervention Strategy NO Send Overdue Notice for
Archive PAS
Report (content assessment/ Archive Review Report (content assessment/ Reports that have not
Set Schedule for Intervention
policy compliance/NSA Disposition Reqport policy compliance/NSA been received by due
Meetings Strategy Report
Compliance) Compliance) date
PAS Review
Review PAS
Review Disposition
Panel
Intervention
Follow-up Report Release?
Strategy Report
End
PAS Notification Db
Various tracking sheets updated.
Report Receipt and

Meeting Date/
Comments
PAS Receipt Log
Report Receipt and

Meeting Date
Figure 9:
The Supervisory Monitoring/Intervention Process is arranged and tracked by the PAS
Admin Unit and executed by the employees supervisor.
Essentially, the supervisor must arrange a series of tasks (which will include recurring
meetings), and document the ongoing meetings and task progress. This information is
sent to the PAS Admin Unit who will document it all into a series of spreadsheets (and
the Notifications Access database) for tracking and follow-up purposes.

All of the tracking and reporting is subject to regular audits by the PAS Admin Unit.
2.6.5 Supervisory Notes Workflow
Supervisory Notes
Phase
NO
Timelines for Annual Review
PAS File Supervisory Corrective

NO NO
Supervisor
Review Observations Action?

Start
YES YES Annual Performance

YES Evaluation
Create Supervisory
Notes Record
SNF Paper File
Add supporting
Documentation to
paper SNF file
Supervisory
Create/Update IPAS
Update Supervisory Update Corrective
Notes
Supervisory Notes
Observations Action
File
Update PAS File

Review PAS File
IPAS
Review Record
Figure 10:
Currently, the Supervisory Notes are entered directly into the IPAS System using the
Superviewer functionality. There are policy requirements around what should be
entered when and each entry is categorized and typed for reporting purposes. Users
are required to access the system to review Supervisory Notes regarding an employee
in the course of regular business workflows (e.g. proposed transfers), and they must
record that they have reviewed the information.
Limitations of the Superviewer are that it does not provide search or filtering
functionality, which means that there can be multiple pages of information that the user
will need to scroll through to find what they are looking for. Performance speed is also
an issue.

When users log on to the Superviewer, they must indicate their purpose for accessing
the system from a list of values. This includes the PAS Admin Unit who access this
system daily.
A report is created regularly detailing user access and the reason for access.
2.6.6 Audit Process Workflow

Audit Process Workflow
Phase
Report Audits for

Start
NSA Sub-Tasks
Corrections
Made?
Audit System Status NSA Arrest Audit
Audit training Audit Record Counts Custodian of Record Monthly Review of
View for import failures (Resisting/Battery
PAS Admin Unit
history all of Dimensions Single Event Weekly Backlog Custodian of Record Civil Suits received
(Date Validation) on Officer) LMRS Arrest Audit CRIMS Arrest Audit IPAS Usage
Threshold Audity Report (Dates of last Single Event Audit from City Attorneys
report entered) Office
NO
Notify DIT of any YES
Discrepancies
Threshold
Response
Workflow Blank Field and
Unknown Person IPAS Full Access Unsaved Supervisory Custodian of Record
Reason Audit Incorrect Dates Key Word Search
Audit Audit Notes Cross Audit
Audit
Daily Audits Weekly Audit Monthly Audit Quarterly Audit

YES
IPAS
Threshold
Event Found?
SuperViewer
Daily Audits
Spreadsheet
Arrest/NSA Arrest/
Audit
Training History
results entered in
Spreadsheet
PAS Discrepancy
Database
Update
Discrepancies
DIT Error Log
Update Errors
Notification and
Request Log
Unresolved
Bi-weekly report to
PAS Unit Chain of
Command YES
Custodian of
Record Unit
Demotion, 10 day
Provide data for
suspension or
Custodian of Record
reinstatement after
Cross-Audit
termination
Figure 11:
The PAS Admin Unit does a tremendous amount of manual data validation and auditing
which is tracked in a series of audit spreadsheets and logs. These spreadsheets and
logs are made available to the Monitor in accordance with the Negotiated Settlement
Agreement.

3 Proposal Submittal Requirements
Submit ten (10) hard copies of proposal as well as electronic files on CDs. The
proposals are due at the Department of Contracts and Compliance, Office of the City
Administrator, 250 Frank H. Ogawa Plaza, Suite 3341, Oakland, CA 94612 and time
stamped no later than 2:00pm, Friday, January 31, 2014
Proposals submitted to the above address after 2:00pm will not be accepted.
Proposals submitted to another location by 2:00pm will not be accepted.
All proposals submitted via US Mail or common carrier must be delivered in a sealed
package with the project name, submittal date, time and location of the proposals on the
outside of the package or on the documents.
3.1 Evaluation
The evaluation of proposals will be conducted by an Evaluation Committee. The
Evaluation Committee will evaluate the Bidders based on the committees view of the
Bidders capability to provide the fabric compilation and complete Early Warning
Intervention system solution in order to fulfill the requirements identified in Appendix A,
B, C and D through the following evaluation stages: Proposal Content, Presentations
and Reference checks. The overall scoring allocation will be as follows:
Proposal Content 65%
Presentation 25%
Reference Checks 10%
Total 100%
3.2 Evaluation Stage One Proposal Content

The following are Mandatory Criteria. Proposals must clearly demonstrate that they
meet these criteria or they will not receive further consideration.
Mandatory Criteria
1. The proposal must be received at the Closing Location before the specified
Closing Date and Time using the delivery method identified in the Summary of
Key Information.
2. The Proposal must be in English.
3. The Proposal must include a Transmittal Letter
4. For LBEs/SLBEs (Prime and Sub-Contractors), submit a copy of current
business license and date established in Oakland.
5. Completed Schedule E: Project Consultant Team
6. Completed Schedule O: Campaign Contribution Limits

Proposals meeting the Mandatory Criteria will be further assessed against the following
additional criteria.
Criteria Points
Available
1. Company Profile (section 3.3.3) 5
2. Company Qualifications (section 3.3.4) 5
3. Proposed Solution (section 3.3.63.3.5) 20
4. Project Approach and Organization (section 3.3.6) 20
5. Methodology and Tools (section 3.3.6.2) 10
6. Project Personnel (section 3.3.7) 15
7. Maintenance and Support (section 3.3.8) 10
7. References (section 3.3.9) 5
8. Proposal Costing (Section 3.3.10) 10
Total Points 100
The following sub-sections detail all of the proposal requirements Bidders are to submit.
To ensure their proposal receive full consideration during the evaluation, Bidders should
develop each section of their proposal based on the criterion being assessed and fully
respond to all criteria. In addition, proposals that are concise and easily understandable
will convey an expectation to the Evaluation Committee that the Bidder will deliver
concise and easily understandable deliverables if selected.
3.3 Required Proposal Elements and Format

3.3.1 Transmittal Letter
Addressed to Deanna Santana, City Administrator, Office of the City Administrator,
City Hall, 1 Frank H. Ogawa Plaza, 3rd Floor, Oakland, California, 94612. (Please
do not submit proposals to this address).
Signed by an officer of the consultant. In case of Joint Venture or other joint-prime
relationship, and officer of each venture partner shall sign.
3.3.2 Executive Summary

Provide a summary of your proposal including the proposed solution, architecture,
approach, team and how your proposal aligns with the Citys objectives. The
Executive Summary shall not exceed five (5) pages in length.
3.3.3 Company Profile
3.3.3.1 Prime Contractor

Provide an overview of the firm acting as the prime contractor. Please include the
following:
Incorporated name
Headquarters location
Corporate history
Executive leadership (including reporting relationship to the proposed project
manager)
Annual revenue and profit (3 years)
Description of products and services provided
List of previous projects with the City of Oakland
List of previous projects in the State of California
3.3.3.2 Sub-Contractor(s)
Sub-Consultants (if used): list addresses, telephone numbers and areas of
expertise of each. Briefly describe project responsibility of each team member.
Identify which contractors are MBE, WBE, Local Business Enterprises (LBE) and
Small Local Business Enterprises (SLBE). Additionally, for LBEs/SLBEs submit a
copy of current business license and date established in Oakland.
3.3.4 Company Qualifications

Provide lists of past projects meeting each of the following:
Bidder must have designed, developed and implemented three (3) systems within
the past five (5) years with overall complexity similar to IPAS2.
Bidder must have designed, developed and implemented three (3) systems within
the past five (5) years using Microsoft SharePoint and InfoPath, using MS-SSRS.
Bidder must have managed at least two (2) projects with a services budget in excess
of $1,000,000 within the past five (5) years.
Bidder must have managed at least three (3) projects for a city, county or state
government agency within the past five (5) years.
Bidder must have at least three (3) years experience maintaining and supporting a
product of similar size and complexity to that of IPAS2.
Bidder should have designed, developed and implemented two (2) business
intelligence systems within the past five (5) years.
Bidder should have completed a public safety application, i.e. law enforcement
solution within the past five (5) years.
Bidder should have experience providing support in at least a Tier 3 Role, for at least
two (2) clients, within the past five (5) years.

Bidder should have at least three (3) years of experience maintaining and supporting
a similar application in a City setting.
3.3.5 Proposed Solution
3.3.5.1 Solution Description

Provide an overview of your IPAS2 Solution, including the Business Intelligence
component and the Source System Data Collection component.
Describe how your solution meets or exceeds the requirements identified in
Appendix A Functional Requirements. Make sure to identify any tools that will be
used to meet the requirements.
Describe how your solution meets or exceeds the requirements identified in
Appendix D Source System Requirements. Make sure to identify any tools that will
be used to meet the requirements.
Provide a description of the proposed application architecture including the following
topics:
o BI Tools
o ETL Strategy
o Source Data Capture Tools
o Reporting tools
o Security and Access Control
The bidder must provide a description of how they will meet the ETL requirements
defined in Appendix B Technical Requirements, including the following topics:
o Source System Data Extract (Replaced as part of IPAS2 Project)
o Current Source Systems not being replaced:
LRMS/RMS
Oracle ERP
Vision Tek
TMS
Power DMS
Personnel Database (PDB)
Please identify any limitations of your solution. Please specify any requirements that
cannot be met.
3.3.5.2 Technical Architecture

Provide a description of how your solution will adhere to the reference architecture
outlined in Appendix E Technical Requirements.
Provide a diagram and description of your proposed hardware and infrastructure
level software. Include hardware and software specifications for development, test,
training and production environments.

Describe how the proposed technical architecture achieves the availability and fault
tolerance requirements listed in Appendix B Technical Requirements.
3.3.5.3 Data Conversion

Provide your proposed approach for data conversion identified in Appendix C
Implementation Requirements, specifically conversion of source system event data.
3.3.5.4 Value Added Recommendations

Provide any details about how your solution can deliver additional benefits to the
City that have not been specifically requested in this RFP
3.3.6 Project Approach and Organization
3.3.6.1 Project Approach

Present your concept of the approach and organization required for this project.
Indicate your understanding of the critical project elements and your understanding
of the IPAS 2 Objectives.
Identify how your approach will meet the requirements identified in Appendix C
Implementation Requirements and identify any limitations of your approach.
Describe your approach to the following:
o Requirements Confirmation
o Solution Design Activities
o Development Activities
o Testing Activities
o Training Activities
o Knowledge Transfer
o Implementation Approach
Describe any assumptions and constraints
Provide a project schedule outlining timelines, activities, dependencies and
resources.
Describe how you intend to interface with City Project Manager and Citys
Department of Information Technology staff and the Oakland Police Department and
the Estimated Time Commitment for City Resources.
3.3.6.2 Methodology and Tools

Describe the methodology and tools that will be used during the project to manage
the following:
Project Management
Software Development
Risk and Issues Management

Scope Management
Defect Management
Communication Management
Configuration Management
3.3.7 Project Personnel

The Proposal must include the proposed key resources, using the table provided
below (or a similar representation of the same information). It is anticipated that the
vendor team resources will be the same throughout the project and where resources
must be changed, a succession plan will be developed by the Vendor, for a resource
that is equally or better qualified than the one being replaced.
Provide the resource names and the percentage of Full Time Equivalent (FTE) for
the duration of the project. Note, FTE cannot exceed 100%.
Key Resources Proposed Resource Name FTE %

Project Manager *
Technical Architect *
Data Architect *
Lead Business Analyst *
Software Developer*
Database Designer*
The proposal must include a resume for each key resource. Resumes should be
provided in a table format and should not exceed 3 pages per resume. Tables
should contain the following:
Resource Name
Resource Role Please provide details of the resources role on the project
team.
Areas of Knowledge Please provide details of the skills and abilities the
individual has that are relevant to this project.
Resource Capability Please provide details of projects, role and experience
and Experience that are relevant to this project.

Resources Degrees, Please provide details of the degree, diploma,
Diplomas or certificate or designation, Issuing Institution or
Professional Association and the date conferred or awarded.
Designations Held or
Earned
3.3.8 Maintenance and Support

Provide a description of how you will meet the application maintenance support
requirements outlined in Appendix C Implementation Requirements.
3.3.9 References
Provide corporate references from similar projects using table format provided. Use
one table per reference project containing the following information:
Project Name
Dates of Project
Total Project Budget
Identify any resources
proposed for IPAS2
Project who were
assigned to the
reference project and
their roles
Description of services
provided (200 words
max)
Contact
Client Contact Phone e-mail
Name
Information:
3.3.10 Project Costing

Bidders must submit their pricing using the Appendix I - Pricing Form, or a similar
representation of the same information to submit their pricing for the Services and
Materials described in the RFP. Prices submitted must be in USD.
3.3.11 Proposal Validation

Submittals are validated using the following RFP Checklist.
a) Schedules (Required with submission)
1. Schedule E - Project Consultant Team

2. Schedule O - Campaign Contribution Limits
b) Other schedules must be submitted prior to full contract execution and are available
at
http://www2.oaklandnet.com/Government/o/CityAdministration/d/CP/s/FormsSchedu
les/index.htm
c) Addenda - Proposal and Acknowledgment of all Addenda if issued, please provide
signed addenda and submit with proposal.
d) Proprietary Information: All responses to the RFQ become the property of the City.
To withhold financial and proprietary information, please label each page as
"confidential" or "proprietary".
e) Public Records Act or Sunshine Ordinance: Although a document may be labeled
"confidential" or "proprietary", information is still subject to disclosure under the
Public Records Act or Sunshine Ordinance, and is, at the City's discretion, based on
the potential impact of the publics interests whether or not to disclose "confidential"
or "proprietary" information.
3.3.12 Rejection of Proposals

The City reserves the right to reject any or all proposals, whether or not minimum
qualifications are met, and to modify, postpone, or cancel this RFP without
liability, obligation, or commitment to any party, firm, or organization. The City
reserves the right to request and obtain additional information from any candidate
submitting a proposal. A proposal may be rejected for any of the following
reasons:
Proposal not received at designated time and date.
Proposal not containing the required elements, exhibits, nor organized in the
required format.
Proposal considered not fully responsive to this RFP.
3.4 Evaluation Stage Two Presentations

The City may request further presentations from any or all Bidders at its discretion.
Presentations will be held at the Office of the City Administrator, City Hall, 1 Frank H.
Ogawa Plaza, Oakland, California, 94612 (room to be confirmed). The City will provide
Bidder(s) a minimum of one weeks notice of what is to be presented and who should
attend the presentation. At the Citys discretion, a demonstration of the proposed
solution may be requested.
During the presentation, the time will be allocated equally between the teams
presentation and a question-and-answer period. The teams should be prepared to
discuss at the interview their specific experience providing services similar to those
described in the RFP, project approach, estimated work effort, available resources, and
other pertinent areas that would distinguish them. It is critical that the resources

proposed as the Project Manager and Technical Architect be substantially involved in
the Bidders presentation.
Bidders will not have the opportunity to amend their proposal. The intent is for the City
to ensure a complete understanding of what has been proposed to better evaluate the
response.
3.4.1 Presentation Evaluation

Presentations will be evaluated as follows:
Criteria Points Available
1. Presentation Alignment with Proposal Content 10
2. Solution Demonstration (if requested) 20
3. Overall Solution/Approach 40
4. Presence of Key Resources 10
5. Responses to Interview Questions 20
Total Points 100
3.5 Evaluation Stage Three Reference Checks

Only the two bidders with the highest scores will be subject to reference checks.

4 Contract Negotiations and Award
4.1 Contract Negotiations
The completion of this evaluation process will result in the contractor being numerically
ranked. The contractor ranked first will be invited to participate in contract negotiations.
Should the City and the first ranked contractor not be able to reach an agreement as to
the contract terms within a reasonable timeframe, the City may terminate the
negotiations and begin negotiations with the contractor that is next in line.
4.2 Fixed Price

The contract amount (including reimbursements) shall be a not to exceed amount, to be
established based upon a mutually agreeable Scope of Services and fee schedule. The
City also requests that a rate table for resources be provide as part of this response.
4.3 Hold-Back
The City will withhold the final 10% of contract amount pending successful completion of
work.
4.4 Contract Award

Upon successful completion of the negotiations, the City Administrator will award of the
contract to the selected contractor.
4.5 Professional Services Agreement

A sample City standard professional services agreement is included in the RFP as
referenced as Attachment A Sample Agreement. The selected contractor will be
required to enter into a contract that contains similar terms and conditions as in the
standard agreement. Please note that the City Attorneys Office is typically not inclined
to make any modifications to the standard agreement terms and provisions.
4.6 Notice to Proceed

Upon award the City will issue a Notice to proceed.
4.7 Evaluation and Audit

The selected contractor and its other members will be required to maintain auditable
records, documents, and papers for inspection by authorized local, state and federal
representatives. Therefore, the contractor and its other members may be required to
undergo an evaluation to demonstrate that the contractor uses recognized accounting
and financial procedures.

5 General Terms and Conditions
5.1 City of Oakland Tax Certificate
The successful Bidder selected for this service shall obtain or provide proof of
having a current City of Oakland Business Tax Certificate.
5.2 Rejection of Bids

The City Council reserves the right to reject any and all bids.
5.3 The Citys Local and Small Business Enterprise Program

Due to the results of a market availability analysis, the Citys 50% Local and
Small local Business Enterprise Program was waived for this RFP only.
5.4 The Citys Living Wage Ordinance

This Agreement is subject to the Oakland Living Wage Ordinance. The Living Wage
Ordinance requires that nothing less than a prescribed minimum level of compensation
(a living wage) be paid to employees of service Contractors (contractors) of the City and
employees of CFARs (Ord. 12050 1, 1998). The Ordinance also requires submission
of the Declaration of Compliance attached and incorporated herein as Declaration of
Compliance Living Wage Form; and made part of this Agreement, and, unless specific
exemptions apply or a waiver is granted, the contractor must provide the following to its
employees who perform services under or related to this Agreement:
a) Minimum compensation Said employees shall be paid an initial hourly wage rate
of $11.96 with health benefits or $13.75 without health benefits. These initial
rates shall be upwardly adjusted each year no later than April 1 in proportion to the
increase at the immediately preceding December 31 over the year earlier level of the
Bay Region Consumer Price Index as published by the Bureau of Labor Statistics,
U.S. Department of Labor. Effective July 1st of each year, Contractor shall pay
adjusted wage rates.
b) Health benefits Said full-time and part-time employees paid at the lower living
wage rate shall be provided health benefits of at least $1.79 per hour. Contractor
shall provide proof that health benefits are in effect for those employees no later
than 30 days after execution of the contract or receipt of City financial assistance.
c) Compensated days off Said employees shall be entitled to twelve compensated
days off per year for sick leave, vacation or personal necessity at the employee's
request, and ten uncompensated days off per year for sick leave. Employees shall
accrue one compensated day off per month of full time employment. Part-time
employees shall accrue compensated days off in increments proportional to that
accrued by full-time employees. The employees shall be eligible to use accrued
days off after the first six months of employment or consistent with company policy,
whichever is sooner. Paid holidays, consistent with established employer policy,

may be counted toward provision of the required 12 compensated days off. Ten
uncompensated days off shall be made available, as needed, for personal or
immediate family illness after the employee has exhausted his or her accrued
compensated days off for that year.
d) Federal Earned Income Credit (EIC) - To inform employees that he or she may be
eligible for Earned Income Credit (EIC) and shall provide forms to apply for advance
EIC payments to eligible employees. For more information, web sites include but
are not limited to: (1) http://www.irs.gov and
http://www.irs.gov/individuals/article/0,,id=96466,00.html
e) Contractor shall provide to all employees and to Contracts and Compliance, written
notice of its obligation to eligible employees under the Citys Living Wage
requirements. Said notice shall be posted prominently in communal areas of the
work site(s) and shall include the above-referenced information.
f) Contractor shall provide all written notices and forms required above in English,
Spanish or other languages spoken by a significant number of employees within 30
days of employment under this Agreement.
g) Reporting Contractor shall maintain a listing of the name, address, hire date,
occupation classification, rate of pay and benefits for each of its employees.
Contractor shall provide a copy of said list to the Office of the City Administrator,
Contracts and Compliance Unit, on a quarterly basis, by March 31, June 30,
September 30 and December 31 for the applicable compliance period. Failure to
provide said list within five days of the due date will result in liquidated damages of
five hundred dollars ($500.00) for each day that the list remains outstanding.
Contractor shall maintain employee payroll and related records for a period of four
(4) years after expiration of the compliance period.
h) Contractor shall require subcontractors that provide services under or related to this
Agreement to comply with the above Living Wage provisions. Contractor shall
include the above-referenced sections in its subcontracts. Copies of said
subcontracts shall be submitted to Contracts and Compliance.
5.5 Equal Benefits Ordinance

This Agreement is subject to the Equal Benefits Ordinance of Chapter 2.32 of the
Oakland Municipal Code and its implementing regulations. The purpose of this
Ordinance is to protect and further the public, health, safety, convenience, comfort,
property and general welfare by requiring that public funds be expended in a manner so
as to prohibit discrimination in the provision of employee benefits by City Contractors
(contractors) between employees with spouses and employees with domestic partners,
and/or between domestic partners and spouses of such employees. (Ord. 12394 (part),
2001)
The following contractors are subject to the Equal Benefits Ordinance: Entities which
enter into a "contract" with the City for an amount of twenty-five thousand dollars
($25,000.00) or more for public works or improvements to be performed, or for goods or

services to be purchased or grants to be provided at the expense of the City or to be
paid out of moneys deposited in the treasury or out of trust moneys under the control of
or collected by the city; and Entities which enter into a "property contract" pursuant to
Section 2.32.020(D) with the City in an amount of twenty-five thousand dollars
($25,000.00) or more for the exclusive use of or occupancy (1) of real property owned
or controlled by the city or (2) of real property owned by others for the citys use or
occupancy, for a term exceeding twenty-nine (29) days in any calendar year.
The Ordinance shall only apply to those portions of a Contractors operations that occur
(1) within the City; (2) on real property outside the City if the property is owned by the
City or if the City has a right to occupy the property, and if the contracts presence at
that location is connected to a contract with the City; and (3) elsewhere in the United
States where work related to a City contract is being performed. The requirements of
this chapter shall not apply to subcontracts or sub-contractors.
The Equal Benefits Ordinance requires among other things, submission of the attached
and incorporated herein as Schedule N-1, Equal Benefits-Declaration of
Nondiscrimination form. For more information, see
http://library.municode.com/HTML/16308/level2/TIT2ADPE_CH2.32EQBEOR.html#TO
PTITLE
5.6 Prompt Payment Ordinance

Section 2.06.070 Prompt Payment Terms Required in Notices Inviting Bids, Requests
for Proposals/Qualifications and Purchase Contracts
This Agreement is subject to the Prompt Payment Ordinance of Oakland Municipal
Code, Title 2, Chapter 2.06. The Ordinance requires that, unless specific exemptions
apply. Contractor and its subcontractors shall pay undisputed invoices of their
subcontractors for goods and/or services within twenty (20) business days of
submission of invoices unless the Contractor or its subcontractors notify the Liaison in
writing within five (5) business days that there is a bona fide dispute between the
Contractor or its subcontractor and claimant, in which case the Contractor or its
subcontractor may withhold the disputed amount but shall pay the undisputed amount.
Disputed payments are subject to investigation by the City of Oakland Liaison upon the
filing of a compliant. Contractor or its subcontractors opposing payment shall provide
security in the form of cash, certified check or bond to cover the disputed amount and
penalty during the investigation. If Contractor or its subcontractor fails or refuses to
deposit security, the City will withhold an amount sufficient to cover the claim from the
next Contractor progress payment. The City, upon a determination that an undisputed
invoice or payment is late, will release security deposits or withholds directly to
claimants for valid claims.
Contractor and its subcontractors shall not be allowed to retain monies from
subcontractor payments for goods as project retention, and are required to release
subcontractor project retention in proportion to the subcontractor services rendered, for
which payment is due and undisputed, within five (5) business days of payment.
Contractor and its subcontractors shall be required to pass on to and pay

subcontractors mobilization fees within five (5) business days of being paid such fees by
the City. For the purpose of posting on the City's website, Contractor and its
subcontractors, are required to file notice with the City of release of retention and
payment of mobilization fees, within five (5) business days of such payment or release;
and, Contractors are required to file an affidavit, under penalty of perjury, that he or she
has paid all subcontractors, within five (5) business days following receipt of payment
from the City, The affidavit shall provide the names and address of all subcontractors
and the amount paid to each.
Contractor and its subcontractors shall include the same or similar provisions as those
set forth above in this section in any contract with a contractor or subcontractor that
delivers goods and/or services pursuant to or in connection with a City of Oakland
purchase contract.
Prompt Payment invoice and claim forms are available at the following City of Oakland
website:
http://www2.oaklandnet.com/Government/o/CityAdministration/d/CP/s/FormsSchedules/
index.htm or at Contracts and Compliance, 250 Frank H. Ogawa Plaza, Suite 3341,
Oakland, CA 94612. Invoice and claim inquiries should be directed to Vivian Inman,
City of Oakland Prompt Payment Liaison, 510-238-6261 or email
vinman@oaklandnet.com.
5.7 Non-Discrimination/Equal Employment Practices

Contractor shall not discriminate or permit discrimination against any person or group of
persons in any manner prohibited by federal, state or local laws. During the
performance of this Agreement, Contractor agrees as follows:
a) Contractor and Contractors sub-contractors, if any, shall not discriminate against
any employee or applicant for employment because of age, marital status, religion,
gender, sexual preference, race, creed, color, national origin, Acquired-Immune
Deficiency Syndrome (AIDS), AIDS-Related Complex (ARC) or disability. This
nondiscrimination policy shall include, but not be limited to, the following:
employment, upgrading, failure to promote, demotion or transfer, recruitment
advertising, layoffs, termination, rates of pay or other forms of compensation, and
selection for training, including apprenticeship.
b) Contractor and Contractors Sub-contractors shall state in all solicitations or
advertisements for employees placed by or on behalf of Contractor that all qualified
applicants will receive consideration for employment without regard to age, marital
status, religion, gender, sexual preference, race, creed, color, national origin,
Acquired-Immune Deficiency Syndrome (AIDS), AIDS-Related Complex (ARC) or
disability.
c) Contractor shall make its goods, services, and facilities accessible to people with
disabilities and shall verify compliance with the Americans with Disabilities Act by
executing Declaration of Compliance with the Americans with Disabilities Act,
attached hereto and incorporated herein.

d) If applicable, Contractor will send to each labor union or representative of workers
with whom Contractor has a collective bargaining agreement or contract or
understanding, a notice advising the labor union or workers representative of
Contractors commitments under this nondiscrimination clause and shall post copies
of the notice in conspicuous places available to employees and applicants for
employment.
e) Contractor shall submit information concerning the ownership and workforce
composition of Contractors firm as well as its sub Contractors and suppliers, by
completing the Ownership, Ethnicity and Gender Questionnaire.
f) The Project Contractor Team attached and incorporated herein and made a part of
this Agreement, Exit Report and Affidavit, attached and incorporated herein and
made a part of this Agreement.
g) All affirmative action efforts of Contractors are subject to tracking by the City. This
information or data shall be used for statistical purposes only. All Contractors are
required to provide data regarding the make-up of their sub Contractors and agents
who will perform City contracts, including the race and gender of each employee
and/or Contractor and his or her job title or function and the methodology used by
Contractor to hire and/or contract with the individual or entity in question.
h) The City will immediately report evidence or instances of apparent discrimination in
City or Agency contracts to the appropriate State and Federal agencies, and will
take action against Contractors who are found to be engaging in discriminatory acts
or practices by an appropriate State or Federal agency or court of law, up to and
including termination or debarment.
i) In the recruitment of sub Contractors, the City of Oakland requires all Contractors to
undertake nondiscriminatory and equal outreach efforts, which include outreach to
minorities and women-owned businesses as well as other segments of Oaklands
business community. The City Administrator will track the Citys MBE/WBE
utilization to ensure the absence of unlawful discrimination on the basis of age,
marital status, religion, gender, sexual preference, race, creed, color, national origin,
Acquired-Immune Deficiency Syndrome (AIDS), AIDS-Related Complex (ARC) or
disability.
j) In the use of such recruitment, hiring and retention of employees or sub Contractors,
the City of Oakland requires all Contractors to undertake nondiscriminatory and
equal outreach efforts which include outreach to minorities and women as well as
other segments of Oaklands business community.
5.8 Arizona and Arizona-Based Businesses

Contractor agrees that in accordance with Resolution No. 82727 C.M.S., neither it nor
any of its subsidiaries, affiliates or agents that will provide services under this
agreement is currently headquartered in the State of Arizona, and shall not establish an
Arizona business headquarters for the duration of this agreement with the City of
Oakland or until Arizona rescinds SB 1070.

Contractor acknowledges its duty to notify Contracts and Compliance Division, Office of
the City Administrator if its Business Entity or any of its subsidiaries affiliates or agents
subsequently relocates its headquarters to the State of Arizona. Such relocation shall
be a basis for termination of this agreement.
5.9 Pending Dispute Disclosure Policy

Contractors are required to disclose pending disputes with the City of Oakland or
Redevelopment Agency when they are involved in submitting bids, proposals or
applications for a City or Agency contract or transaction involving professional services.
This includes contract amendments. Contractor agrees to disclose, and has disclosed,
any and all pending disputes to the City prior to execution of this agreement. The City
will provide a form for such disclosure upon Contractors request. Failure to disclose
pending disputes prior to execution of this amendment shall be a basis for termination of
this agreement.
5.10 City of Oakland Campaign Contribution Limits

This Agreement is subject to the City of Oakland Campaign Reform Act of Chapter 3.12
of the Oakland Municipal Code and its implementing regulations if it requires council
approval. The City of Oakland Campaign Reform Act prohibits Contractors from making
campaign contributions to Oakland candidates between commencement of negotiations
and either 180 days after completion of, or termination of, contract negotiations. If this
Agreement requires Council approval, Contractor must sign and date an
Acknowledgement of Campaign Contribution Limits.
5.11 Nuclear Free Zone Disclosure

Contractor represents, pursuant to the combined form Nuclear Free Zone Disclosure
Form that Contractor is in compliance with the City of Oaklands restrictions on doing
business with service providers considered nuclear weapons makers. Prior to
execution of this Agreement, Contractor shall complete the combined form attached
hereto.
5.12 Sample Professional Services Agreement

This Agreement is subject to the attached Sample Professional Service Agreement.
5.13 Insurance Requirements

The Contractor will be required to provide proof of all insurance required for the work
prior to execution of the contract, including copies of the Contractors insurance policies
if and when requested. Failure to provide the insurance proof requested or failure to do
so in a timely manner shall constitute grounds for rescission of the contract award.
The Contractor shall name the City of Oakland, its council members, directors, officers,
agents, employees and volunteers as additional insured in its Comprehensive
Commercial General Liability and Automobile Liability policies. If Contractor submits the

ACORD Insurance Certificate, the additional insured endorsement must be set forth on
a CG20 10 11 85 form and/or CA 20 48 Designated Insurance Form (for business
auto insurance).
Please Note: A statement of additional insured endorsement on the ACORD insurance
certificate is insufficient and will be rejected as proof of the additional insured
requirement.
Unless a written waiver is obtained from the Citys Risk Manager, Contractors must
provide the insurance as found at: http://cces.oaklandnet.com/cceshome. A copy of
the requirements are attached and incorporated herein by reference. Liability insurance
shall be provided in accordance with the requirements specified.
When providing the insurance, include the Project Name and Project Number on the
ACORD form in the section marked Description of Operations/Locations.
When providing insurance, the Certificate Holder should be listed as: City of Oakland,
Contracts and Compliance, 250 Frank H. Ogawa Plaza, Suite 3341, Oakland, CA
94612.
5.14 City Contractor Performance Evaluation

At the end of the project, the Project Manager will evaluate the Contractors
Performance in accordance with the City Contractor Performance Evaluation program.
5.15 Violation of Federal, State, City/Agency Laws, Programs or

Policies
The City or Agency may, in their sole discretion, consider violations of any programs
and policies described or referenced in this Request for Proposal, a material breach and
may take enforcement action provided under the law, programs or policies, and/or
terminate the contract, debar contractors from further contracts with City and Agency
and/or take any other action or invoke any other remedy available under law or equity.
5.16 Contractors Qualifications

Contractor represents that Contractor has the qualifications and skills necessary to
perform the services under this Agreement in a competent and professional manner
without the advice or direction of the City. Contractors services will be performed in
accordance with the generally accepted principles and practices applicable to
Contractors trade or profession. The Contractor warrants that the Contractor, and the
Contractors employees or sub-Contractors are properly licensed, registered and/or
certified as may be required under any applicable federal, state and local laws, statutes,
ordinances, rules and regulations relating to Contractors performance of the Services.
All Services provided pursuant to this Agreement shall comply with all applicable laws
and regulations. Contractor will promptly advise City of any change in the applicable
laws, regulations or other conditions that may affect Citys program. This means
Contractor is able to fulfill the requirements of this Agreement. Failure to perform all of
the services required under this Agreement will constitute a material breach of the

Agreement and may be cause for termination of the Agreement. Contractor has
complete and sole discretion for the manner in which the work under this Agreement is
performed. Prior to execution of this agreement, Contractor shall complete the
Independent Contractor Questionnaire, Part A , attached hereto.
5.17 Staff Available for Questions

The following City staff are available to answer questions:
Contracts and Compliance Manager: Deborah Barnes, (510) 238-6270
5.18 Responses
All responses to the RFP become the property of the City.
5.19 Limitations
The RFP does not commit the City to award a contract or to pay any cost incurred in the
preparation of the proposal.
5.20 Proposal Evaluation

The City reserves the sole right to evaluate each proposal and to accept or reject any or
all proposals received as a result of the RFP process.
5.21 Right to Modify, Suspend or Terminate

The City reserves the unqualified right to modify, suspend, or terminate at its sole
discretion any and all aspects of the RFP and/or RFP process, to obtain further
information from any and all Contractor teams and to waive any defects as to form or
content of the RFP or any responses by any Contractor teams.
5.22 Service Provider

The City may require a service provider to participate in negotiations and submit any
technical information or other revisions to the service providers qualifications as may
result from negotiations.
5.23 Public Record

Once a final award is made, all RFP responses, except financial and proprietary
information, become a matter of public record and shall be regarded by the City as
public records. The City shall not in any way be liable or responsible for the disclosure
of any such records or portions thereof if the disclosure is made pursuant to a request
under the Public Records Act or the City of Oakland Sunshine Ordinance.
5.24 Fair Political Practices Act

The Fair Political Practices Act and/or California Government Code Section 1090,
among other statutes and regulations may prohibit the City from contracting with a

service provider if the service provider or an employee, officer or director of the service
providers firm, or any immediate family of the preceding, or any sub-Contractor or
contractor of the service provider, is serving as a public official, elected official,
employee, board or commission member of the City who will award or influence the
awarding of the contract or otherwise participate in the making of the contract. The
making of a contract includes actions that are preliminary or preparatory to the selection
of a Contractor such as, but not limited to, involvement in the reasoning, planning and/or
drafting of solicitations for bids and RFQs, feasibility studies, master plans or
preliminary discussions or negotiations.
END OF RFP

Appendix A - Functional Requirements
1. Functional Requirements
1.1 Purpose of Document
This document describes the functional requirements for the Second Generation Early
Warning System (EWS) for the Oakland Police Department. The EWS project will
replace the current Internal Personnel Assessment System (IPAS) with a new solution
(IPAS2). The new IPAS2 solution will be used across the entire Oakland Police
Department (OPD) to evaluate thresholds and personnel history based on events.
The document provides definitions of how thresholds will be defined and measured and
the response to a threshold activity.
2. Business and Project Context

2.1 Background
In 2003, the City of Oakland agreed to a variety of reforms in a negotiated settlement
agreement (NSA). The compliance to the NSA is overseen by a federal judge who
appointed an independent monitoring team (IMT) who provides quarterly reporting on
how the OPD is doing.
To meet the terms of the NSA, the OPD implemented the IPAS System which provides
data to the PAS Admin Unit for the purpose of complying with all of the reporting and
data requirements of the NSA/IMT. Recently, the Court appointed a Compliance
Director to provide additional oversight to the OPD.
Due to advances in technology and limitations within the current IPAS System, it is
anticipated that IPAS2 will provide more sophisticated reporting and analysis tools and
provide the Department and the IMT with confidence that the data and the processes
around gathering and reporting on the data, are stable and reliable. Additionally, the
IPAS2 solution will provide operational support for the OPD to collect, monitor and
report on data beyond the scope of the NSA.
The new IPAS2 solution will be a Business Intelligence System with a data warehouse
that allows users to identify officers and civilians whose performance exhibits early
indications of at-risk issues, and then to provide interventions, usually counseling or
training, to correct those performance problems. Additionally, the tool will provide
identification of officers and civilians who are performing well, and may be referred for
commendations or other types of positive intervention.
2.2 Objectives
The objectives of this solution will be to provide a robust, reliable and scalable reporting
and analysis system for the Oakland Police Department
Early Warning System Appendix A Page / 43

The IPAS2 Solution will provide a stable platform from which to expand the reporting
and analysis capabilities of the current solution to include data from additional sources.
The reliability, scalability and stability of the data provided by the system will assist the
PAS Program to report accurate data to the OPD in accordance with the NSA and
departmental requirements.
2.3 Scope
This document provides the requirements for the IPAS2 System and related reporting
and analysis capability. These requirements do not contain the data collection
requirements for the existing source systems which are also in scope for the IPAS2
project.
The requirements for the following source systems are included in Appendix D of this
RFP. Replacement of this functionality with a new data capture solution will allow the
Microsoft Access programs that currently provide this functionality, to be
decommissioned:
1. Canine Deployment
2. Internal Affairs Division (IAD)
3. Use of Force
4. Case Evaluation Report (CER)
5. OC Checkout
6. Vehicle Pursuit
7. Collision
2.4 Assumptions
The IPAS2 solution will meet the constraints of the technology requirements identified in
Appendix B. The solution will provide a new data warehouse, ETL processes and
reporting and analysis tools.

3. Context and Business Services Overview
3.1 Context Diagram
Training History
Training (DMS)
(TMS)
Policy/Procedure Audit Records Training History
Personnel Database
(PDB)
Field Based
Reporting System
Assignments/Roles, etc
Stop Data IPAS2

Arrest Data/Calls For Service LRMS
Views Presentation
ETL Data Warehouse
Layer
Document
Management
Notifications Source Data
Solution
IPAS2 DATA COLLECTION SOLUTION
Index OC Checkout Supervisory Notes Vehicle Canine
Security & Audit

Data
Index PAS Activity Report Internal Affairs Case Evaluation
Use of Force
and Monitoring Division (IAD) Report
Figure 12:
Note: The scope of these requirements is the IPAS2 Data Warehouse, ETL, and
presentation layer. The IPAS2 Data Collection Solution requirements are identified in
Appendix D IPAS2 Source System Requirements. The Field Based Reporting
System will provide source system data in IPAS2 that is not available in the current
IPAS Solution. Implementation of a new Document Management Solution is out of
scope for this project.
3.2 Personnel Assessment Subject Area

IPAS2 is a Business Intelligence Solution that provides analysis and reporting on an
OPD Personnel Assessment subject area. The framework for personnel assessment
uses a three-step process:

1. Define a peer group (sample or cohort) of employees with similar risk characteristics
using business rule criteria over time.
2. For each employee in the peer group, evaluate measures based on the number and
types of events attributed to the employee, over a defined period of time, to
determine if the measure is of statistically significant difference when compared to
other employees in the peer group. If this is the case, the employee is identified as
an outlier. Certain events indicate an immediate need for personnel assessment
review independent of the peer group statistical averages.
3. For each outlier, evaluate their risk profile based on business rules criteria to assess
whether they have met the threshold for a personnel assessment review.
4. The implementation of this framework requires the definition of the following terms:
5. Sample Period (also known as the reference period): The period of time where the
events occurred.
6. Peer Group: A group of employees with similar risk characteristics during the
sample period, based on role assignment.
7. Events: Operational events that are associated with an employee, including events
associated with heightened risk.
8. Exclusion Criteria: Mitigating circumstances that negate the need for a personnel
assessment.
3.2.1 Sample Period

The sample period is currently defined as the past 18 months based on query date.
However, this should be configurable.
3.2.2 Peer Group Selection Criteria

The assignment of an employee to the correct peer group is based on assignments
during the sample period. Criteria for peer group assignment are as follows:
1. Assignment category civilian or sworn
2. Employee Rank
3. Assignment role patrol, supervisor, canine, etc.
4. Duration of time in role during sample period.
5. Ranking of assignment
6. Specialty assignments
The source system for these criteria is the Personnel Data Base (PDB).
3.2.3 Events Definition

Events (or threshold events) are select operational activities that may indicate
performance risk, either singularly or in combination. Events are extracted from the
source systems into the data warehouse. Categories for event evaluation are:
Event Type Normative Comparison and Relational Threshold or Single Event
Threshold
3.2.4 Exclusion Criteria

Exclusion criteria are a set of business rules or conditions applied to outliers to
determine if a personnel assessment is required based on mitigating factors (e.g., a
new personnel assessment is not needed if an assessment is already underway).
3.3 IPAS2 Components

IPAS2 is comprised of three main components:
1. Business Intelligence Solution: Data Warehouse, ETL Tools and Processes, Query
and Reporting tools. Threshold related functions are also processed on the data
warehouse.
2. Source Systems: Stand-alone systems that provide assignment and event data.
3. IPAS2 Data Collection Solution: SharePoint application that supports the following:
4. Conversion of seven (7) existing MS Access databases to a series of modules that
to collect IPAS2 data.
5. Replacement of current IPAS Supervisory Notes Functionality.
6. Addition of new IPAS2 Assessment Reports and Monitoring solution. This
functionality will allow users to create IPAS Activity Reports, create and track
disposition recommendations and findings, create and track tasks for individuals on
the PAS Monitoring program.
In accordance with the reference architecture outlined in Appendix B Technical
Requirements, data from the IPAS2 Data Collection Solution will be extracted to the
Data Warehouse and will provide reporting and analysis through IPAS (including
notifications and data).

3.3.1 Business Services
Id Program Services/Mandate/Role of the Program Client
Area Area
S01 Personnel Responsible for the administration of the OPD, Monitor
Assessment Departments Early Identification and
System Intervention Program. The unit monitors all
(PAS) personnel recommended for supervisory
Administratio monitoring and intervention through the
n Unit Departments PAS policy process. The unit
maintains confidential files for all actions
taken to fulfill the requirements of the PAS
policy. The PAS Administration Unit
provides support to the Police Department
in the following key areas:
Administration and oversight of the
Departments Personnel Assessment
System policy;
Providing tools to commanders,
managers and supervisors to enable
them to assess the performance of
subordinate units, supervisors and
personnel to determine if they are
engaging in exceptional, at-risk or
substandard performance;
Providing assistance to commanders,
managers and supervisors in analyzing
and assessing the performance of their
assigned personnel;
Developing reports for supervisors,
managers, commanders, bureau deputy
chiefs and the Chief of Police as
needed;
Monitoring the quality of, and assist in
making corrections to, information
maintained in the Departments Internal
Personnel Assessment System (iPAS).
S02 City Responsible for the provision of Information OPD, Public
Department Technology Services to the City which Safety, City
of Information includes the Oakland Police Department.
Technology Houses the technical infrastructure required
to support IT systems and services. Also
responsible for contracting with vendors to
provide IT services.

3.4 Business Processes
3.4.1 Business Process Diagram
IPAS2
Assign Identify Single

Define Peer Refer to PAS
Employees to Define Threshold Event Threshold Identify Outliers
Group Program
Peer Group Met
Figure 13:
3.4.2 Business Process Summary

ID Process
P01 Define Peer Group
P02 Assign Employees to Peer Group
P03 Define Threshold
P04 Identify Single Event Threshold Met
P05 Identify Outliers
P07 Refer to PAS Program
3.5 IPAS2 Business Processes

The following set of processes provides a high level overview of the conceptual to-be
state for the IPAS2 solution. These processes were used to elicit required functionality
in the new IPAS2 solution. The focus for the development of the workflows was on
reduction of time spent on manual processes and the provision of increased analysis,
reporting and auditing capability from all data sources and also about the PAS Program
itself.

3.5.1 Define Peer Group
Define Peer Groups
Phase 1
PAS Admin
Unit
Define Peer Group Define Peer Group

Start Define Peer Groups End
Criteria Ranking
System
IPAS2
Set Peer Group

Create Peer Groups Rank Peer Groups
Criteria
Figure 14:
The Define Peer Group process requires the ability to configure the rules that cause an
employee to be assigned to a peer group based on user-supplied criteria and ranking.
3.5.2 Assign Employees to Peer Group
Assign Employees to Peer Group
Phase 1
Personnel
Individual
System
(PDB)
Assignment to
Start
Organization/rank/
etc.
Peer Group
System
IPAS2
Assignment based
on Business Rules
Figure 15:
IPAS2 will manage the Assign Employees to Peer Group process based on a series of
business rules. This will eliminate a tremendous amount of manual process from the
PAS Admin Unit and also provide peer group data for analysis purposes.
3.5.3 Define Threshold

Define Thresholds
Phase 1
PAS Admin Unit
Classify Data into

Start End
Threshold Types
System
Organize Data into

IPAS2
Event Dimension
Source Systems
Upload Source Data
Figure 16:
It is anticipated that the event source data will be organized into event dimensions. A
user-defined process to further classify the data into, threshold events and single
threshold events is required. Additionally, a user-defined process to set exclusion
criteria for outliers is required.
3.5.4 Identify Single Event Threshold Met

Identify Single Event Threshold Met
Phase 1
PAS Admin Unit
Notification Single PAS Review

Start Event Thresholds and Report
Met Process
System
IPAS2
Identify Single Event

Threshold Met
Systems
Source
(DW)
Data Uploaded from

Source
Figure 17:
When source system data is uploaded, the system will validate the data against the
threshold classification to see if a single event threshold has been met. This will be a
nightly process that will run after the source system ETL processes have completed
If the threshold has been met, a notification is sent to the PAS Admin Unit.
The PAS Admin Unit will complete the PAS Review and Report in the IPAS2 Data
Collection Solution see Appendix D IPAS2 Source Data Collection Requirements.

The PAS Review and Report data will be source data for PAS reporting and analysis on
referrals, reports and outcomes.
It is requirement that the notification process will use a work queue tool to identify
individuals requiring a PAS review and report.
3.5.5 Identify Outliers

Identify Outliers
Phase 1
PAS Admin
Define Sample Schedule Outlier

Start
Period Identification Query
Unit
Notification PAS Refer to PAS

Review Required PAS Program
YES
Assign Employees to Get events for Exclusion Criteria PAS Review

Identify Outliers
Peer Groups employees Applied Required?
System
IPAS2
NO YES
End
Supervisor
Notification PAS
Review Required
Figure 18:
The PAS Admin Unit will define the sample period and the reporting schedule for the
Outlier Identification Process. IPAS2 will allow the scheduling of the Identify Outliers
process on a recurring basis (possibly monthly), and will also provide the ability to run
ad hoc Identify Outliers process runs as required.
The process will assign individuals to peer groups, get event data for each individual
and compare event data within the peer group to identify outliers within the peer group.
The exclusion sub-process will determine who will be referred to the PAS program
based on the application of business rules.
When an individual is identified for referral to the PAS Program, a notification is sent to
the PAS Admin Unit. It is requirement that the notification process will use a work
queue tool to identify individuals requiring a PAS review and report.
The PAS Admin Unit will complete the PAS Review and Report in the IPAS2 Data
Collection Solution see Appendix D IPAS2 Source Data Collection Requirements.
The PAS Review and Report data will be source data for PAS reporting and analysis on
referrals, reports and outcomes.
3.5.6 Refer to PAS Program

Refer to PAS Program
Chain of Command
Start
Create PAS Program
Referal
Identify Single
Execute Scheduled
Event
Processes
Threshold Met
IPAS2
Add PAS Referral to

PAS Admin Unit
Work Queue
Identify
Outliers
PAS Admin
Unit
View PAS Admin

Unit Work Queue
IPAS2 Data
Collection
Solution
Upload PAS Report

Create PAS
Data to IPAS2 Data End
Report
Warehouse
Figure 19:
The Refer to PAS Program process provides the ability for the chain of command to
refer an individual for a PAS Referral based on activities or observations that may be
outside the threshold and outlier evaluation processes. All referrals to the program will
be routed to a work queue tool that will be provided in the solution. The PAS Admin
Unit will complete the report in the IPAS2 Data Collection Solution and data regarding
the report and outcomes will be provided back to IPAS2 through the Data Warehouse
for Analysis and Reporting.
3.5.7 Reporting and Analysis

The PAS Admin Unit and other user groups require the ability to generate canned
reports and ad hoc reports. IPAS2 will also provide the ability to generate ad hoc
queries, drill down capacity, KPI reporting and Dashboard Reports.
3.5.8 Audit Processes

The current manual auditing process outlined in the IPAS Overview State section of the
RFP will be replaced with automated processes and reporting capability.

4.1 Overview
This section is organized into sub-sections based on required functionality.
4.2 Source Data

Source systems will provide the data that will be extracted into the Data Warehouse.
The list of current source systems is:
1. Legacy Records Management System (LRMS) (note: there is currently a project
underway to replace this system)
2. Personnel Database (PDB)
3. Canine Deployment*
4. Use of Force*
5. Internal Affairs Division (IAD)*
6. Case Evaluation Report (CER)*
7. OC Checkout (Oleoresin Capsicum (OC) Spray)*
8. Vehicle Pursuit*
9. Collision*
10. Training History (TMS)
11. Power DMS (Training Policy/Procedures)
*Source Systems to be replaced with IPAS2 Data Collection System as part of this RFP.
Please see Appendix D IPAS2 Source System Requirements.
The OPD would like to add new data currently collected in the following systems:
12. Field Based Reporting (FBR System) Stop Data (will be incorporated into the new
RMS)
13. LRMS - Calls for service data (will be incorporated into the new RMS)
The OPD would like to add new data sources in the future (not within scope of this
project). These include but are not limited to:
14. Telestaff Staff Schedule data
15. PDRD Personal video recorder device data
There are additional information sources that provide key data that are not currently
collected in any system (not within scope of this project). These include but are not
limited to:
16. Training History Training Officer
17. Failure to qualify data (weapon)
18. Civil Law Suits (directly from the City Attorney)
4.3 Peer Groups

Correct peer group Assignment provides the key to successful threshold comparisons.
The inflexibility in the current solution results in a lot of manual adjustments and the

inability to analyze the same individual against past peer group assignments and
different peer groups defined by the user, (e.g., the ability to compare canine officer with
their assigned peer group (Patrol group C), and also with other canine officers across
other peer groups).
The starting point for peer group assignment will be based on the longest assignment
for an employee within an 18 month period:
18 Month Sample Period

Assmnt 1 Assmnt 2 Assmnt 1
14 Months 3 months 5 days
In the example above, Assignment 1 would be selected as the peer group for the
sample employee during the sample period because that is where the employee was
assigned for the majority of the sample period.
However, the assignment type may influence the sample if the employee was in an
assignment at any point over the 18 month period where an increased number of events
are acceptable (i.e. the Critical Response Team). If the employee had a high number of
events due to this assignment, it would skew the data for the peer group upwards and
potentially identify the individual as an outlier. To avoid this, it is necessary to rank
assignment types, so that the employee would be evaluated against others in the
Critical Response Team peer group instead. The system should be able to track the
percentage of time within each group as indicated in requirement F-5 below.
Some officers have desk assignments or other assignments that could also influence
the peer group sample. This may mean that an employee is assign to Patrol C for the
18 month period but was on desk assignment for the duration. In this case, the officer
may be assigned to a peer group with other officers on desk assignments for
comparison.
Additionally, data problems or specialty assignments (rifle officer, SWAT, field training
officer) may result in one officer being assigned to 3 different assignments over the
same time period.
Currently peer group assignments are categorized as sworn and civilian, however the
thresholds are the same for both categories. Being able to specify different event
thresholds for each category would make more sense.
5.24.1 4.3.1 Peer Group Requirements

The IPAS2 solution will:
No. Requirement

No. Requirement
F-1 Provide ability to create and configure rules for assigning

employees to peer group types based on rank, assignment,
specialty and shift.
F-2 Allocate users to create and configure rules for assigning
employees to peer groups in accordance with user defined
business rules such as length of time in assignment and
ranking of assignment by type.
F-3 Provide ability to rank assignments to manage situations where
employees have worked in more than one assignment for
exactly the same period of time.
F-4 Maintain a history of all assignments over time to support peer
group assignment over a specified time period based on
assignments during that period.
F-5 Provide ability to allocate individual employees events to peer
groups using a weighted average of events based on
assignment at the time of the event.
F-6 Support peer group analysis over time queries.
F-7 Support comparisons between peer groups
F-8 Provide ability to customize event thresholds for peer group
categories and types e.g. civilian versus sworn.
F-9 Provide ability to query events for a specific timeframe and
assign events to correct peer group for selected time frame.
4.4 Thresholds
The main objective for this functionality is to automate the function to provide
accurate and predictable results based on the threshold definition and the
exclusion criteria used to eliminate employees for referral for a PAS Activity
Review.
Threshold identification will become a new data source in IPAS2 that will provide
data for analysis and reporting regarding thresholds met, exclusions granted,
exclusions by type, PAS reviews, etc.
4.4.1 Thresholds Requirements

No. Requirement
F10 Support threshold definition based on a sub-set of dimensions

and event types.

No. Requirement
F-11 Support categorization of threshold events (i.e. single event

threshold triggers).
F-12 Support system trigger of single threshold event met evaluation.
F-13 Support notification to PAS Admin Unit when individuals have
met single event threshold.
F-14 Allow threshold values to be configurable by the PAS Admin
Unit (e.g., 95% as the definition of outlier for a particular
threshold)
F-15 Allow thresholds to have effective dates (i.e., the date range
where the particular threshold is evaluated for a particular peer
group)
F-16 Allow the period of evaluation (e.g. 18 months) to be
configurable
F-17 Allow thresholds to be assigned to particular peer groups.
4.5 Outliers
The main objective for this functionality is to automate the function to provide
accurate and predictable results based on the outlier definition and the exclusion
criteria used to eliminate employees for referral for a PAS Activity Review.
Outlier identification will also become a new data source in IPAS2 that will
provide data for analysis and reporting regarding threshold events, outliers
identified, exclusions granted, exclusions by type, PAS review, etc.
4.5.1 Outliers Requirements

No. Requirement
F-18 Support the outlier identification percentage cut-off (both on the

high end and the low end i.e. 95% and <5%). NOTE:
Percentage is subject to change.
F-19 Provide ability to apply exclusion criteria to individuals identified
as outliers within peer group.
F-20 Provide ability to normalize the data based on number of
employees in peer group, number of events, number of arrests,
etc.
F-21 Provide ability to set exclusion criteria, such as event met while
currently on PAS Program, number of times event type since
release from PAS program, etc.

No. Requirement
F-22 Provide ability to set warning criteria (i.e. when individual is

close to reaching the statistical outlier percentage) and trigger
notifications before PAS Activity Review is warranted.
F-23 Support normative threshold comparisons (e.g., number of
complaints/number of arrests).
F-24 Ability to have a different set of threshold criteria for sworn and
civilian staff.
F-25 Support the scheduling of peer group threshold evaluation
comparisons.
F-26 Support ad hoc threshold evaluation comparisons.
F-27 Provide ability to include/exclude certain individuals from
threshold processing based on certain characteristics (e.g.
canine handler, desk assignments, etc.)
F-28 Provide ability to see threshold response based on threshold
type (single event, referral, outlier met).
F-29 Support notification to PAS Admin Unit when PAS Report and
Referral is required.
4.6 Queries and Reporting

The IPAS2 solution will be required to provide a variety of information products
(cubes, reports, drill-throughs, and metrics) to provide a variety of reporting and
analysis capability. The following list should not be considered comprehensive
but does provide a representative list of the type of queries the OPD requires.
4.6.1 Queries and Reporting Requirements

The IPAS2 solution and its data structures will support the following queries:
No. Requirement
Employees who met the threshold based on the defined outlier

F-30 percentage
F-31 Employees who met a single event threshold.
Employees who were excluded from PAS Review based on
F-32 elimination criteria.
Employees who had a PAS activity review and what the
F-33 outcome of the review was.
F-34 Progress of employees in the PAS Program over time.
F-35 Progress of employees who were released from the PAS

No. Requirement
program over time, e.g. thresholds met since release.
Provide ability to query PAS Review Recommendations over
F-36 time, by report, by a group of reports, by recommender.
Provide ability to query and report on employees with zero
F-37 event counts.
Provide ability to query PAS Review Report recommendations
over time by supervisor, chain of command, PAS Panel
F-38 versus final disposition.
Provide ability to report on tasks by type, by status, by
F-39 supervisor, by employee, by date range.
Support definition and reporting on Key Performance
F-40 Indicators (KPIs).
F-41 Support KPI analysis over time.
F-42 Provide dashboard reporting based on user role.
Provide drill through capacity to allow access to more details
F-43 about data presented.
F-44 Provide Squad by Squad reporting
Provide a command view threshold comparisons squad by
F-45 squad
Provide ability to free-form the comparisons between different
F-46 individuals and groups.
Provide centralized control of reporting to facilitate publishing
F-47 and distribution of data.
Provide ability to execute queries based on type of staff (eg.
F-48 sworn, civilian)
Provide ability to query training recommendations as a result of
F-49 IAD investigations.
Provide ability to query on status of IAD case and status of
F-50 allegation.
F-51 Provide ability to query training history by training class.
F-52 Provide ability to query training non-compliance
Provide ability to query individuals in the PAS Program and
F-53 thresholds met.
Provide ability to query on number of canine deployments
F-54 requested versus deployed.

No. Requirement
Provide ability to query performance of supervisors based on

F-55 performance of subordinates.
Provide ability to identify individuals with low threshold % and
F-56 positive supervisory notes entries.
Provide ability to filter collision data and related complaint data
F-57 by preventable and non-preventable collisions.
Provide ability to filter pursuit data by injuries caused by OPD
F-58 and injuries caused by Suspect Vehicle.
F-59 Provide reporting on Level 4 use of Force parameters.
Provide ability to filter pursuit data by officers involved in the
F-60 pursuit and witnesses.
Provide ability to normalize activities to a single event (e.g.
non-preventable collision identified in the Collision data source,
could also be included in the IAD data source, Complaints data
F-61 sourceetc).
Support comparisons of supervisors based on the performance
F-62 of subordinate staff.
Provide ability to query supervisory notes entries based on key
F-63 word search.
4.6.2 Event Cross Referencing

No. Requirement
F-63 Provide ability to link events in IPAS2 based on unique

identifiers e.g. officer serial number, report ID number, date.
F-64 Provide ability to report on multiple officers involved in a single
event (e.g. 3 officers involved in a single complaint).
F-65 Provide ability to view related events and documentation (i.e.
drill through to report or other media in the Document
Management Solution)
5. Data Requirements
The objectives of this section are to define & describe the data requirements to
be supported.
5.1 Data Architecture

The data architecture requirements are outlined in Appendix B Technical
Requirements.
5.2 Historical Data

Historical Data is required for analysis and trending purposes. Historical and
current source system data will be loaded into the data warehouse from all
source systems. See Appendix C Implementation Requirements for source
data conversion requirements.
5.3 Data Refresh Requirements

Data will be extracted from the source systems nightly. All ETL processes must
complete overnight to support this requirement.
5.4 Source Data

The requirements for the source systems that will be replaced with the IPAS2
Data Capture Solution which can be found in Appendix D, however additional
source data refinements, beyond the current data elements have been identified
as requirements for the new solution. These requirements are captured here for
reference.
5.4.1 Source Data Requirements

No. Requirement
F-66 Include awards and commendations data from PDB

F-67 Include stop data from Vision Tek (Field Based Reporting
System)
F-68 Include calls for service data (LRMS)
F-69 Include training history data (training officer, class, # of years
experience as an officer, etc.)
F-70 Include number of reports that an officer writes.
6. Non-Functional Requirements
The objectives of this section are to List and describe each individual non-
functional requirement that must be supported by the system. The non-functional
requirements for a system are typically constraints on the functional requirements
that is, not what the system does, but how it is being done (how quickly, how
efficiently, how easily from the users perspective, etc.). Other non-functional
requirements may be required characteristics that are not part of the systems
functionality, e.g. conformance with legal requirements, scalability,
interoperability.

6.1 Usability Requirements
The standard usability requirements are:
Non- Description
Functional
Requirement
Number
NF01 Solution must ensure data integrity at source wherever
possible.
NF02 If validation of data integrity is not possible at source, system
must ensure data integrity during ETL processes.
NF03 Solution must support notifying system administrators when
data integrity or upload issues occur.
NF04 Systems should be intuitive and simple to use with common
user interface experience (navigation, buttons, help/error
messages)
NF05 Solution must be evolvable - allow for new source systems to
be integrated easily.

Appendix B - Technical Requirements
1. Technical Requirements
This section describes the technical requirements for IPAS2.
1.1 Reference Architecture

The vendor will propose a solution based on the latest versions of Microsoft SharePoint,
InfoPath, and SQL Server. In addition to solving the immediate problems facing OPD
with the current IPAS system and its data collection applications, the goal of the new
architecture is to provide a platform upon which the OPD can migrate additional existing
line of business applications.
As such, the underlying premise of the defined architecture is to make use of as much
out of the box functionality as possible, making use of custom code / extensions only
when absolutely necessary. It is expected that the vast majority of the required
functionality of the IPAS2 system and the replacement source systems will be
implemented with out of the box functionality.
The workflow requirements of the new systems will be implemented with the integrated
workflow services provided with SharePoint, and all processes and systems will be
designed to support long-running, fault tolerant execution.
Additionally, the system must be maintainable and extendable by OPD resources.
Adding data fields to data capture systems must be possible using the standard tools
available with the infrastructure outlined below.
Figure 20: iPAS2 Infrastructure

The vendor must specify proposed physical hardware and infrastructure components /
software needed to support the successful implementation of this solution (to be
acquired by the City). The proposed solution must be scalable to accommodate an
Early Warning System Appendix B Page / 63

increase in the number of users of the system or an increase in the number of
transactions processed by the system.
1.2 Security
Since much of the information in the IPAS system is sensitive in nature, a chain of
command model has been implemented to allow access to data based on the users
assignment within OPD. This chain of command is modeled within the PDB application,
and the IPAS2 solution will adhere to this authorization model with some minor changes
as described below. The following diagram shows how the IPAS system currently
implements data visibility based on assignment.
1) All access to data will be Top-Down and not Bottom-up.

2) Chief of Police, the Office of Inspector General, IAD Commander and the PAS Coordinator will be
able to view all information within the OPD Organization
3) Deputy Chief, Captains, Lieutenants, Sergeants, Officers and Civilians cannot view information
regarding their supervisors.
4) Deputy chief, Captains, Lieutenants and Sergeants will be able to view all information on
assigned subjects.
5) Special Operations personnel will not be able to gain access to Field Operations data or vice
versa. There is to be no access across different divisions.
6) Members can view his/her personal data.
Figure 21: Information Security Access Hierarch by Assignment

Additionally, it is expected that the IPAS2 system allow an administrator to configure a
rank such that every rank equal or above has a view of all ranks below. That is, if the
rank chosen is Lieutenant, then any Lieutenant using the system will be able to see all
data of all Sergeants and Officers within the system, regardless of Chain of Command.
Under the same circumstances, a Captain using the system will be able to see all data
of all Lieutenants, Sergeants, and Officers within the system.
The IPAS system allows special assignment of data access permissions on an as-
needed basis. It is expected that the IPAS2 system will continue to allow this capability
to allow users access to data outside of their chain of command when required and
approved.
Finally, it is expected that the IPAS2 system allow the assignment of users to roles
which define their data visibility characteristics outside of the Chain of Command.
Among other reasons, this role-based authorization will allow the granting of
permissions to employees outside of the Chain of Command (external users, monitors,
compliance directors, etc.).
1.3 General
No. Requirement
E-1 Utilize the most recent release of Microsoft technologies including
SharePoint, InfoPath, SQL Server, SQL Server Integration Services,
SQL Server Analysis Services, and SQL Server Reporting Services.
E-2 Follow City-provided graphic and design standards.
E-3 Provide the ability to maintain multiple operating environments for
development, test, training and production.
1.4 Performance, Uptime, and Scalability

No. Requirement
E-4 Respond in less than two (2) seconds in key user scenarios.
E-5 Support 25 concurrent editors and 100 concurrent readers.
E-6 Retain its performance levels when adding additional users, functions,
and data.
E-7 Be scalable and adaptable to meet future growth and expansion
needs.
E-8 Be compatible with deployment in a high availability infrastructure
including clustered database servers and load balanced web /
application servers.

1.5 Longevity / Maintainability
No. Requirement
E-9 Use the latest release of Microsoft SQL Server to store all data.
E-10 Utilize naming conventions and standards for data elements, entities
and tables, programs, report names, etc.
E-11 Allow for the use of utilities for database performance monitoring and
tuning that comply with industry standards.
E-12 Support online modifications to database structures with minimal user
downtime.
E-13 Allow data retention schedules on a per data source basis.
E-14 Default to a 5 year data retention schedule for all data sources unless
otherwise stated.
E-15 Allow functionality and associated business rules to be configured
and re-configured through tools that do not require code
modifications.
E-16 Be highly configurable, providing ability to reposition and rename field
labels, remove or turn-off unused fields, maintain data, and allow
addition of custom-defined fields.
E-17 Provide the ability to create and modify edits and business rules
which determine the acceptability or correctness of data.
1.6 Backup / Restore

No. Requirement
E-18 Support industry-standard database backup and recovery tools
required to support organization database recovery plan and
procedures.
1.7 Audit and Security

No. Requirement
E-19 Authenticate users before any access is allowed to protected
resources.
E-20 Interface with OPD's Active Directory for authentication.

No. Requirement
E-21 Provide the ability to use a single user sign-on for all modules with
security configured for each module.
E-22 Selectively trim the user interface based on user security such that a
user is only presented with actions they are permitted to perform and
data they are allowed to access.
E-23 Provide a user-friendly mechanism to configure authorization by an
OPD administrator.
E-24 Support data restriction based on the organizational hierarchy
obtained from the PDB system.
E-25 Support the ability to view/update data for employees below the
logged-on user in the chain of command.
E-26 Support the ability to view/update data for employees with a rank at
or below a system administrator specified rank.
E-27 Provide an efficient, flexible way to control and administer multiple
levels of authorization.
E-28 Encrypt data transmitted between clients and servers using Secure
Socket Layer (SSL), Transport Layer Security (TLS), or another
industry standard mechanism.
E-29 Provide the ability to define user roles and user groups and associate
these with user accounts.
E-30 Allow restriction of rights, privileges, and access at the user and
group level.
E-31 Display the last date and time the user logged onto the system at the
time of logon.
E-32 Allow revocation of the access privileges of a user without requiring
deletion of the user.
E-33 Allow assigning multiple roles to one user.
E-34 Detect and log unauthorized attempts to access the system.
E-35 Detect and log unauthorized attempts to access sensitive or
confidential data.
E-36 Not store sensitive data (such as connection strings, encryption
certificates, passwords, etc.) in code.
E-37 Store sensitive data (such as connection strings, encryption
certificates, passwords, etc.) securely using industry-standard
encryptions means.

No. Requirement
E-38 Not log sensitive data (such as connection strings, encryption
certificates, passwords, etc.) in clear text.
E-39 Validate all input parameters are (including form fields, query strings,
cookies, and HTTP headers).
E-40 Maintain an audit trail of errors and exceptions.
E-41 Minimize information disclosure to the end user in case of an
exception.
E-42 Record or capture activities such as authenticated access,
configuration changes, privileged access (i.e., use of administrative
rights), and change of rights and privileges.
E-43 Record or capture information about access attempts including
authorized / unauthorized, user ID, workstation, date, time,
transaction (menu, screen, file, object), and attempted type of access
(read, modify, etc.).
E-44 Provide a viewable, searchable history of all audit information.
E-45 Provide the ability to archive audit information for a user-definable
time period.
1.8 Data Integration (ETL)

No. Requirement
E-46 Provide all services needed to transform, standardize, migrate and
load source-system electronic data using Microsoft SSIS.
E-47 Monitor timeliness of data transfers and alert users if certain time
limits have been exceeded.
E-48 Provide the ability to evaluate incoming data for validity and
completeness, and reject data that is not valid.
E-49 Provide alerts when data has been rejected.
E-50 Be designed and implemented such that all data transfer processes
ensure data is not lost or corrupted in the face of network outages,
source system maintenance, hardware failures, etc. The bidder will
provide specific details on how the proposed solution will meet this
requirement.
E-51 Identify and manage duplicate data
1.9 Supplemental Tools

No. Requirement
E-52 Integrate with the OPD Microsoft Exchange infrastructure to distribute
alerts and notifications.
E-53 Provide Ad Hoc reporting / querying tools.
E-54 Ensure compatibility with OPDs existing SAP Crystal Reporting tools.
E-55 Provide monitoring tools to identify performance problems,
bottlenecks, failures, etc.
1.10 Physical Environments

No. Requirement
E-56 Be implemented within physical infrastructure allowing the upgrade
and replacement of physical hardware with minimal reconfiguration of
IPAS2.
E-57 Allow the seamless addition of physical hardware to alleviate
performance bottlenecks.
E-58 Be reasonably fault tolerant using techniques such as redundant
power supplies, redundant network switches, RAID disk
configuration, etc.
E-59 Be at least 99.5% available using techniques such as AlwaysOn SQL
Server clustering, multiple web and application servers, etc.
E-60 Be designed with business continuity and disaster recovery in mind.
2. Interface Requirements
2.1 Machine Interfaces
This application requires machine interfaces for:
IPAS2 Source Data Collection Solution
An object repository for file storage (new case management solution to be
determined)
Standalone Source Systems as previously identified.
2.2 Human Interfaces

From a technology perspective the following are required:
Must be accessible via the web.

Must be accessible from outside the OPDNet network with appropriate security
measures (VPN)
Must be accessible via mobile device.
Must provide Dashboard reporting
Must provide a Work Queue for managing workflow and notification for user groups.

Appendix C - Implementation Requirements
1. Implementation Requirements
1.1 Overview
Vendors are required to present their concept of the project approach and organization
required for this project, indicating their understanding of the critical project elements
and the IPAS 2 objectives. Additionally, vendors are required to describe the
methodology and tools that will be used to complete identified project components. The
implementation requirements will identify what the City considers necessary to support
a single implementation of the IPAS2 solution. It is anticipated that vendors will use this
information to assist in the development of their response, and as input to the
development of the project schedule
These requirements are explicitly different from the Functional and Technical
Requirements and are related to the Project Management and Implementation activities
related to those requirements. It is anticipated that the Project Management and
Implementation Requirements will be considered in the Approach in the Bidders RFP
response, but the actual requirements will be addressed during the Project.
1.2 Project Management Requirements

The Vendor is encouraged to consider the Project Management approach within the
project phases below and should structure activities and deliverables within these
phases.
Figure 22:
Specific requirements related to Project Management are captured in the requirements
tables below. The Project Manager for the City will be the primary point of contact for
the Vendor Project Manager. Sierra Systems will lead the City Project Team and will be
responsible for the overall Project Management of the IPAS2 Project
1.2.1 Planning Activities

No. Requirement
G-1 Vendor will execute a Project Kick-Off meeting with the key project
stakeholders
Early Warning Intervention System Appendix C Page / 71

No. Requirement
G-2 Vendor will develop a Development Plan that will integrate with the
overall Project Management Plan that will developed by Sierra
Systems. This final plan will be submitted for review and approval by
the City during the Inception Phase. Major sections of the Project
Management Plan, that will be developed by Sierra will include:
Project Description
Scope Management
IPAS2 Development Plan (Vendor)
Schedule Management
Team Management
Communication Management
Assumptions & Constraints
Quality Plan
Deliverable Review and Approval Procedures
Risk Management Plan
Change Management Plan
Issue Management Plan
Deliverable Review Process
G-3 Vendor will create a detailed project schedule for development
activities
1.2.2 Execution & Controlling Activities

No. Requirement
G-4 Vendor will baseline the project schedule at the beginning of the
execution phase
G-5 Vendor will schedule weekly development status meetings
G-6 Vendor will send out weekly status reports which will include an
updated Project Schedule with task level percent complete
G-7 Vendor will submit deliverables as defined within the deliverable
review process
1.2.3 Project Closing Activities

No. Requirement
G-8 Vendor will complete a lesson learned report as part of the Project
Exit Criteria
G-9 Vendor will identify Project Close Out activities during the Planning
Phase of the Project

1.3 Implementation Requirements
The Implementation Requirements are viewed as a risk management tool providing
activities that contribute to the overall success of the project. These Requirements also
provide the Vendor with activities needed as part of a larger Implementation Strategy
that will be created by Sierra Systems.
1.3.1 Change Management

No. Requirement
G-10 Vendor will support the Change Management activities related to
system and IPAS2 implementation changes that will lead by the City
Project Team.
1.3.2 Communication
No. Requirement
G-11 Vendor will prepare a Communication Plan which identifies activities
for the Implementation Phase
G-12 During development of the Communication Plan, the Vendor will
identify the communication mechanisms
1.3.3 Training
No. Requirement
G-13 Vendor will deliver one Train the Trainer session for IPAS2 Users
G-14 Vendor will deliver one Train the Trainer session for System
Administrators
G-15 Vendor will provide a Training Strategy that supports a train-the-
trainer model of training delivery for both system administrators and
end users. The training strategy must also outline the approach to
knowledge transfer for DIT employees required to support the IPAS2
solution. The Training Strategy must outline:
The type and number of sessions provided
The length of each session
Subject Matter to be covered in training
Tools and technology requirements for training
G-16 Vendor will conduct Knowledge Transfer activities in accordance with
the approved Training Strategy
1.3.4 System Documentation

No. Requirement

No. Requirement
G-17 Vendor will provide preliminary versions of Help, System, Operations,
User, and Training Documentation for the purpose of testing these
documents.
G-18 Vendor should provide copies of existing end-user system and
administrator (client) training materials, user guides, and user
manuals from similar projects as samples of what will be developed
for the proposed IPAS2 Software Solution.
G-19 Vendor will prepare the IPAS2 System Administration Document
deliverable. The Bidder is required to prepare an IPAS2 User Manual
as part of this project
G-20 Vendor will prepare the IPAS2 Systems Documentation deliverable
G-21 Vendor will prepare a Technical Architecture diagram and ERD as
part of the IPAS2 System Documentation
G-22 Vendor will prepare the IPAS2 User Guide deliverable.
1.3.5 Integration Testing

No. Requirement
G-23 Vendor is responsible for executing and managing integration testing
G-24 It is recommended that Integration Testing utilize a phased approach
to test Dimensions as they are available
G-25 Vendor will prepare an Integration Test summary report as exit criteria
from the Integration Test phase
G-26 Vendor will prepare specific Integration Test scenarios and scripts
prior to the release of each configuration iteration. The City will be
responsible for developing User Acceptance Test Scripts and the
Vendor should not assume these will be available for Integration
Testing
G-27 Vendor is responsible for regression testing functionality released in
earlier iterations
G-28 Vendor shall provide documentation, in the form of the Requirements
Traceability Matrix, to show that all requirements have been tested
during Integration Testing.
1.3.6 User Acceptance Testing

No. Requirement
G-29 The City will execute User Acceptance Testing

No. Requirement
G-30 At the start of User Acceptance Testing, Vendor will establish a formal
software release strategy for IPAS2
G-31 Vendor will support the UAT process and execution
G-32 Vendor will outline specifically the approach and strategy for User
Acceptance Testing. It is anticipated that UAT will last for 40 days for
this project. Both the IPAS2 solution and the Source Systems will be
tested during this period
1.3.7 Infrastructure (Hardware & OS Software)

No. Requirement
G-33 Vendor will create the IPAS2 Infrastructure Plan outlining the
hardware and software needs of IPAS2. The plan will include a bill of
material detailing each required infrastructure component.
G-34 Vendor will support the Citys acquisition of hardware, software and
licenses in accordance with the IPAS2 Infrastructure Plan.
G-35 Vendor will work with the City to install and configure hardware and
software in the OPD environment in accordance with the
Infrastructure Plan.
G-36 Vendor will work with the City to review the current data center and
infrastructure needs. Vendor will document any deficiencies noted in
the IPAS2 Infrastructure Plan during the Inception Phase of the
project
G-37 Vendor will manage all environments through the completion of the
system warranty period
1.3.8 Establish Software Environments

No. Requirement
G-38 The IPAS2 project will utilize, at a minimum, Development, Test, User
Acceptance Test and Production environments at the City Data
Center. Access to these environments for OPD testing will be
established by the Vendor
G-39 Vendor will identify which infrastructure could or should be virtualized
G-40 Vendor will support the City installation of the hardware and software
environments
G-41 Vendor will utilize a structured Release Approach to promote builds
and patches between environments

1.3.9 Data Conversion
No. Requirement
G-42 Vendor will prepare the Data Conversion Plan deliverable. This Plan
will outline data source (source system or IPAS), data mappings, as
well as conversion specific tasks, phasing and testing approach.
G-42 Data Conversion activities will convert data from the current IPAS
system as well as the Source Systems identified in the Technical
Requirements
G-43 With the exception of the Arrest dimension, Vendor will convert all
records in the current IPAS system including any additional fields for
the dimension that are added in IPAS2
G-44 Vendor will convert Arrest dimension data only for records entered
into the source system after the implementation of the CRIMS
interface (scheduled for early 2014).
G-45 Vendor will use source systems to convert data for all new IPAS2
dimensions (i.e., dimensions not in the current IPAS) as identified in
the Technical Requirements
G-46 The Data Conversion Plan must minimize impact on existing IPAS
source system operations
G-47 Using the Data Conversion Plan as a blueprint, Vendor will develop
the data conversion scripts and procedures to apply the data
migration rules and convert the data to the new IPAS2 format.
G-48 Vendor will perform at least three test executions of each source
system conversion and provide test conversion results to the City
G-49 Vendor will identify, document, and resolve any issues or questions,
and facilitate the conversion process.
G-50 If manual data review and re-entry is required, vendor will work with
the City to expedite the manual process.
1.3.10 Configuration Management

No. Requirement
G-51 Where possible the Vendor should consider iterative development
and configuration of the solution
G-52 Where possible the Vendor should consider parallel configuration
activities to reduce the overall timelines for the project
G-53 The Vendor will ensure that the Configuration Management solution
(TFS) is utilized during the project, including for source code
management and defect tracking

No. Requirement
G-54 Vendor will provide a Release Strategy outlining the release
processes to be used to provide builds to testing, training and
production environments.
1.3.11 Production Cut-Over

No. Requirement
G-55 The Vendor will prepare the Production Cutover Plan outlining
activities including:
Production environment establishment
Environment readiness confirmation
Application deployment
Application readiness confirmation
Production data conversion
Production back-up procedures
Review of City technical operational readiness
Final production readiness confirmation
G-56 Vendor will execute the tasks included in the approved Production
Cutover Plan
G-57 Vendor will be onsite for the Production Cut-Over
G-58 The Vendor will establish the required processes to provide
production bug fixes within timelines established by the City and well-
communicated fashion
G-59 The Vendor will establish the required process to provide production
solution releases in a timely and well-communicated fashion
G-60 The Vendor will establish production issue escalation procedures for
production problem identification, isolation and resolution.
G-61 The Vendor will establish the required process and software to allow
OPD to initiate Vendor technical support requests
G-62 Vendor shall assign an on-site team to provide warranty and post-
implementation support services for 12 weeks after the system goes
live. During this period when there are no defects the resources will
work on enhancements
1.3.12 Warranty and Support

No. Requirement

No. Requirement
G-63 Vendor will warrant the application for any defects for a period of 90
days after the Production Cut-Over. Responses to warranty issues
will be subject to the Response Services Agreement in Appendix J.
G-64 Vendor will provide production support for IPAS2.
All production issues will be recorded in the Citys trouble ticket
system. IPAS2 trouble tickets will be automatically routed to Vendor
and triaged by the Vendor and will categorize tickets as one of the
following:
Desktop and other non-application issues will be forwarded back
to the City by the Vendor and addressed by City resources
Application issues will be addressed by the Vendor subject to the
Draft IT Agreement in Appendix E.
Support activities provided by the vendor will be based on the ITIL
Framework principles and procedures for warranty and support
activities
G-65 Vendor will provide IPAS2 Support for a period of two years following
the warranty period
G-66 Vendor will, at the Citys option, provide three additional one year
periods of IPAS2 Support
G-67 Vendor will deploy fixes to the IPAS2 test environment for City testing
prior to production deployment
G-68 For problem resolutions requiring software or database updates,
Vendor will provide deployment packages to the City for the City to
deploy to the production system. Vendor will use scripted procedures
wherever practical in such deployment packages.
G-69 Vendor will prepare a Knowledge Transfer Plan, including a skill
assessment and gap analysis of current City resources, during the
first six months of the support period
G-70 During the support period, Vendor will provide weekly checks of
system logs and advise the City of any required corrective action
G-71 During the support period, Vendor will provide quarterly reviews of
current release status of all third-party infrastructure IPAS2
components and provide upgrade recommendations to the City
G-72 Vendor will provide additional support for activities including system
changes, enhancements and infrastructure support as requested by
the City (Vendor will include a hourly rate card will be included in the
Pricing Schedule)

No. Requirement
G-73 Vendor will provide additional on-site support as requested by the City
(Vendor will include a hourly rate card will be included in the Pricing
Schedule)
1.3.13 Backup and Recovery Strategy

No. Requirement
G-74 Vendor will prepare the IPAS2 Backup and Recovery Strategy for the
overall IPAS2 solution
G-75 The IPAS2 Backup and Recovery Strategy will include all
components required to support continued operations of IPAS2
G-76 The IPAS2 Backup and Recovery Strategy will provide a
recommended Disaster Recovery Strategy for the overall IPAS2
solution as part of this RFP response

Appendix D IPAS2 Source System Requirements
1. Introduction
1.1 Purpose of Document
The purpose of this document is to describe completely, accurately and unambiguously
the detailed business information requirements of the Oakland Police Department
(OPD), with particular attention to those that are to be supported by the IPAS2 Data
Collection Solution.
2. Business and Project Context

2.1 Background
One of the key components of the IPAS System is the data that is supplied by multiple
source systems. In the majority of these systems, the data is collected mainly for the
purpose of supporting the IPAS2 reporting requirements. As a result, the solutions have
been created by OPD and DIT resources in a series of Microsoft Access systems.
Issues have been identified with reliability, scalability and stability of these systems, and
a need for more data from an operational perspective, therefore replacement of the
systems as part of the IPAS2 Project is required. Replacement of the functionality
supported by these source systems with a new data capture solution will allow the
Microsoft Access programs that currently provide this functionality, to be
decommissioned.
2.2 Objectives
The objectives of this solution will be to decommission the current Microsoft Access
systems, eliminate reliance on manual forms and processes by allowing direct data
entry into the solution rather than capturing data on paper forms and retyping into the
solution, and to provide better data collection and reporting in the IPAS2 Solution.
The IPAS2 Data Collection solution will also provide a stable platform to expand the
capacity of data collection beyond the currently collected data and will support the
addition of other data sources and source system replacement over time.
The reliability, scalability and stability of the data provided by the system will assist the
PAS Program to report accurate data to the OPD to meet departmental requirements.
2.3 Scope
The IPAS2 Data Capture Solution will provide a system that will support data entry of
the workflows and data needs currently managed in the in-scope systems identified
below.
The scope of the IPAS2 Data Collection Solution includes the following:
Early Warning Intervention System Appendix D Page / 80

Standardization of the data capture tool across multiple business areas within the
department,
Replacement of the following Microsoft Access Systems:
o Canine Deployment
o Internal Affairs Division (IAD)
o Case Evaluation Report (CER)
o OC Checkout
o Vehicle Pursuit
o Collision
o Supervisory Notes
o PAS Reporting and Monitoring
o Use of Force
Role-based access to forms and workflows
Task List interaction
Notification via email
Nightly uploads of data to the IPAS2 Data Warehouse
The following source systems are out of scope for this RFP:
Personnel Database (PDB)
Telestaff
Legacy Records Management System (LRMS)
Field Based Reporting System (FBR)
Training History (TMS)
Training (DMS)
Oracle Personnel
Line of Duty Injury
2.4 Assumptions
The IPAS2 data capture solution will meet the constraints of the technology
requirements identified in Appendix B.

3. Context and Business Services Overview
3.1 Context Diagram
The following context diagram depicts the interactions to be supported by the IPAS2
Data Collection Solution.
Case Evaluation
Vehicle Canine
Report (CER)
Requests/Deployment
Pursuits/Collisions
Reports
Incidents
Use of Force
Creates
Referrals
Supervisory Notes
Internal Affairs
Complaints
Division (IAD)
Summary Info.
IPAS2 Data Collection Solution
PAS Activity Report
Report Request
and Monitoring
OC Checkout Inventory
Reports & Tasks
Views
Document
Management IPAS2 Data
Data Extract
Solution Warehouse
Figure 23:

3.1.1 Business Services
Id Program Services/Mandate/Role of the Program Area Client
Area
S01 Bureau of The Bureau of Field Operations is the largest Public
Field component of the Oakland Police Department.
Operations Patrol personnel provide day-to-day police
services that include response to emergency
and non-emergency calls for service and critical
incidents, conducting preliminary investigations
and evidence collection, engaging in
community-oriented problem solving, and
crime-fighting efforts.
In addition to patrol officers, community policing
officers, crime response team
officers, neighborhood enhancement team
officers, foot patrol officers, police service
technicians, and police evidence technicians
are all a part of the Bureau of Field
Operations team.
S02 Internal The Internal Affairs Division of the Oakland Public
Affairs Police Department is committed to protecting
Division and defending the constitutional rights of all
community members, as well as the integrity of
the Department and individual
members/employees.
IAD provides professional service to every
member of the community by conducting
thorough, impartial, and ethical investigations
regarding allegations of misconduct and policy
failures within the Department.

Area
S03 PAS Admin Responsible for the administration of the Oakland
Unit Departments Early Identification and Police
Intervention Program. The unit monitors all Department,
personnel recommended for supervisory Monitor
monitoring and intervention through the
Departments PAS policy process. The unit
maintains confidential files for all actions taken
to fulfill the requirements of the PAS policy. The
PAS Administration Unit provides support to the
Police Department in the following key areas:
Administration and oversight of the
Departments Personnel Assessment
System policy;
Providing tools to commanders, managers
and supervisors to enable them to assess
the performance of subordinate units,
supervisors and personnel to determine if
they are engaging in exceptional, at-risk or
substandard performance;
Providing assistance to commanders,
managers and supervisors in analyzing and
assessing the performance of their assigned
personnel;
Developing reports for supervisors,
managers, commanders, bureau deputy
chiefs and the Chief of Police as needed;
Monitoring the quality of, and assist in making
corrections to, information maintained in the
Departments Internal Personnel Assessment
System (iPAS).

Area
S04 Criminal The Criminal Investigation Division (CID)
Investigatio serves as the main investigative branch of the
ns Division Department. Officers assigned to CID conduct
follow-up investigations for criminal cases and
respond to crime scenes when requested. Each
case is reviewed for solvability factors and
assigned to an investigator for follow-up based
on the type of crime. The CID has five units
within the division:
Felony Assault & Gangs
Homicide
Robbery & Burglary
Theft & Field Services Unit
Youth & Family Services
S05 Property The Property Unit receives and stores all public
Unit property that comes into the possession of the
Oakland Police Department. This consists of
evidence exhibits, safekeeping articles or
simply found items.
The Property Unit is also responsible for
dispensing equipment to police offices,
including Oleoresin Capsicum (OC spray).
S06 Canine Unit The Canine Unit is part of the Special Public, OPD
Operations Division and is responsible for
acquiring and training canines for OPD as well
as, oversight of the canine program There are
approximately 14 Canine Teams at OPD.
Canines undergo significant training prior to
certification followed by ongoing structured
training with specially trained canine handlers.
Officers who are part of a canine team are
assigned to patrol units but they have a special
designation that identifies them as a canine
handler.
The appropriate deployment of a police canine
enhances the safety of officers and citizens and
increases the Departments ability to capture
criminals and locate items of evidence. Police
canines complete their tasks in a far shorter
time than officers could perform such duties.

Area
S07 Training Responsible for Training Activities including OPD
Division vehicle training. The Department Safety Officer
is currently assigned to training and in that role
has some record keeping duties related to
Vehicle Collisions.
S08 Traffic The Traffic Operations Section (TOS) focuses Public
Operations on vehicle enforcement and traffic safety. The
Section TOS provides support to area commanders
through traffic enforcement (motor vehicle
violations and DUI checkpoints), traffic
investigations, and vehicle abatement. The
TOS receives traffic concerns from a variety of
sources, including community members,
accident data, and officer observations. In
2012, the Citys Parking Enforcement was
moved to Departmental authority and placed
under the Traffic Operations Section.
S09 City Responsible for the provision of Information OPD, Public
Department Technology Services to the City which includes Safety, City
of the Oakland Police Department. Houses the
Information technical infrastructure required to support IT
Technology systems and services. Also responsible for
contracting with vendors to provide IT services.
3.2 Business Processes
3.2.1 Business Process Diagram

IPAS2 Data
Collection System
Case Evaluation Internal Affairs Supervisory PAS Reporting System

Vehicle Canine Use of Force OC Tracking
Report Division (IAD) Notes and Monitoring Administration
Record Case Record Vehicle Request Canine Record Use of Receive Create Record OC Create PAS
Evaluation Pursuit Deployment Force Complaint Supervisory Note Checkout Report
Review
Record Vehicle Monitor PAS
Supervisory
Collision Activity
Notes
Figure 24:

3.2.2 Business Process Summary
ID System Process Frequency Time to
Complete
P01 Case Evaluation Record Case 200/Month 10 Minutes
Report Evaluation
P02 Vehicle Record Vehicle Pursuit 70-120/year 7 Days
P03 Vehicle Record Vehicle 140/year 4-5 Months
Collision
P04 Canine Request Canine 350/year 10 Minutes
Deployment
P05 Use of Force Record Use of Force 103/month Varies
P06 Internal Affairs Receive Complaint 1259/year 180 Days-
Division (IAD) 1 yr
P07 Supervisory Notes Create Supervisory 13,500/year 10-25
Note Minutes
P08 Supervisory Notes Review Supervisory <13,500/year 30 Minutes
Notes
P09 OC Checkout Record OC Checkout 200/year 10 Minutes
P10 PAS Reporting and Create PAS Report Every 8 1-2 Hours
Monitoring weeks
P11 PAS Reporting and Monitor PAS Activity Ongoing Varies
Monitoring
P12 System Administration Update Code Tables Ongoing TBD

3.2.3 Business Process Model Create Case Evaluation Report
P01 Create Case Evaluation Report
Description The process outlines the steps to create a Case
Evaluation Report
Motivation DA makes a decision regarding a case.
Source Documents Case Evaluation Report is prepared by OPD

Investigators (22 fields)
Supplemental Criminal Cases Dropped (IAD)
Documents
Create Case Evaluation Report
Phase 1
Arrest Suspect,
Arresting
Start
Officer
Create Case Notified of CER

Decision
Supervisor
Arresting
Officer
Notified of CER
Decision
Receives Case
Investigator
Information
Walks Case over to

DA Receives
Charge/No Charge
Decision
Investigator
Supervisor
Reviews and
END
Approves Report
NO
IPAS2 Data
Collection
Solution
Create Case
Evaluation Report Update CER Send Notications IAD Concern? YES Referral sent to IAD
Figure 25:

3.2.4 Business Process Model Record Vehicle Pursuit
P02 Record Vehicle Pursuit
Description The process outlines the steps for recording a vehicle
pursuit.
Motivation Completed whenever an officer is involved in a pursuit
activity.
Source Documents J4 Report (20 Fields)
Supplemental CHP187 (50 boxes per pursuit sent to CHP monthly).

Documents Witnesses who show up do supplemental reports and
they get entered into db.
Vehicle Pursuit Process
Start
Officer
Vehicle Pursuit
Notified of Outcome
Occurs
No
Supervisor
Review Board
Creates Pursuit Supervisor Reviews
Required? (level
Record and enters finding
2&3)
YES
Department
Coordinator
Safety
Convene Pursuit No End

Discipline?
Review Board
NO
Command
Chain of
Review Pursuit Yes

Record
Collection Solution
IPAS2 Data
Pursuit Record Pursuit Record Pursuit Outcome IAD Complaint

Level 1 Pursuit? Referred to IAD
Created Updated Entered Process
YES
Figure 26:

3.2.5 Business Process Model Record Vehicle Collision
P03 Record Vehicle Collision
Description The process outlines the steps for recording a vehicle
collision.
Motivation Completed whenever collision occurs with a city
vehicle.
Source Documents CHP555 Form (45 Fields)
Supplemental FBR Report

Documents Statements
Map
Yearly report
Risk management reports monthly (5 commanders
produced different ways)
Outside agency report if officer outside city limits
Video, Audio, Pictures if Available
Vehicle Collision Process
Start
Employee
Vehicle Collision Agrees with

Occurs Finding?
YES
No
Responding
Officer
Information entered
into FBR
Investigator
Traffic
Investigates
Collision signs off
Department
Coordinator
Safety
Reviews Collision Coordinate and

Information and End Preventable? YES Hold Accident End
Enters Finding Hearing Board
Command
Chain of
Reviews Collision
Information and Chief Signs Off
Finding NO
IPAS2 Data
Collection
Solution
IAD Complaint
Collision Record Finding Record Results Entered Discipline? Process
Created Created
YES
Figure 27:

3.2.6 Business Process Model Record Canine Deployment
P04 Record Canine Deployment
Description The process outlines the steps for recording a Canine
Request and Deployment.
Motivation Completed whenever a canine officer is requested and
deployed
Source Documents Deployment Record (15-16 Fields)
Supplemental Canine Spreadsheet

Documents Use of Force Reports
Offense Reports
Supplemental Reports
Monitors receive quarterly reporting on deployments.
Subject to public record requests.
Canine Deployment Process
Requestor (Field Supervisor/
Start Available?
Dispatch)
Request Canine Yes Canine Handler

Handler NO Attends
Request Handler
External to No End
Dept?
Canine Handler
Canine Handler
Canine Handler and
enters Details of Dog Bite? No End
Canine Deployed
Deployment
YES
Coordinator
Canine
Request
Information
Provided.
Supervisor
Canine
Use Of Force
YES Notified of Dog Bite Use of Force? Yes
Process
IPAS2 Data
Collection
Solution
Records Request
and Deployment Dog Bite? No End No
Information
Figure 28:

3.2.7 Business Process Model Record Use of Force
P05 Record Use of Force
Description The process outlines the steps for recording when a use
of force occurs.
Motivation Completed whenever a reportable UoF occurs
Source Documents Crime report (Approximately 100 Fields)

UoF Report
Supplemental reports
Statements
Supplemental Board Report
Documents Incident report
Crime Report
Pursuit Record
Collision Record
Any other records relating to use of force
Video, PDRD, Phone Records

Record Use of Force
Start
Sergeant on Scene
NO
Calls into Comm

Creates Use of Extension Supervisor Report
Centre to report
Force Record Requested? Completed
Use of Force
Function
Notification
End
regarding outcome
Comm Centre
YES
Use of Force Log
Entry Made
NO
Use of Force
Coordinator
Use of Force Coordinate Use of

Notification Force Review Board
Chain of Command
Reviews Use of
Use of Force Extension
Extension Granted YES Extension Granted Force Finding &
Notification Requested
Enters assessment
NO YES
IPAS2 Data
Collection
Solution
Use of Force Record Level 1 Use of Use of Force Record Supervisor Section Captains Section Use of Force Discipline? NO End
Completed Final Outcome
Initiated Force? Created Completed Review Board?
NO
YES
Internal Affairs
YES
Division
IAD Receive
IAD Complaint
Complaint
Process
Process
Figure 29:
3.2.8 Business Process Model Receive IAD Complaint

P06 Receive Complaint
Description The process outlines the steps for receiving and
investigating an IAD complaint
Motivation Completed whenever a complaint is received
Source Documents Variety of sources of complaints, calls, letters, in

person, electronic referrals, contact through
communication logs and call outs (approximately 70
fields to complete the intake of a complaint)
Supplemental Use of Force Reports
Documents Offense Reports
Additional Information Reports
Field Contact

P06 Receive Complaint
Case Information
Communication Logs
Other
There is no officer involved
in Service Complaints.
Receive IAD Complaint
Start
IAD Staff
Refer to
Receive Complaint
Receive Receive Notice Service appropriate
by Phone, Fax, YES End
Electronic of Level 1 Use of Complaint? division for
Mail, other
Referral Force response
Investigator
Traiining or
Further
IAD
Investigate No Discipline
Create Finding Action?
Complaint Required?
NO
No
Command
Chain of
Daily Updates to Notification

Chain of Notifications
YES Received
Command Received
Review Input Input Investigation

Accept Input Finding Data Updates to file End
Electronic YES Complaint Data
Referral?
Referral Data
NO
Enter Reason
Referral Not End
Accepted
Accepting referral data

populates complaint with
available data. Otherwise
data is manually entered.
Figure 30:

3.2.9 Business Process Model Create Supervisory Notes
P07 Supervisory Notes
Description The process outlines the steps to create supervisory
notes.
Motivation Completed whenever supervisor observes an event
requiring a supervisory note.
Source Documents A variety of events can trigger a supervisor to make an
entry (incident report, accident, letter of appreciation,
etc).
Approximately 18 fields to enter a supervisory note.
To Supplemental Same as above.
Documents
Create Supervisory Notes Process
Start
Supervisor
Observes or
receives Reviews Employee Addendum
information No End
Feedback Created?
regarding staff.
YES
Employee
Provides
Notified of Entry NO End
Feedback?
YES
IPAS2 Data
Collection
Solution
Search for Enter Reason for Creates Supervisory Entry Created that
Employee accessing Records Notes Record relates to original
Entry
Figure 31:

3.2.10 Business Process Model Review Supervisory Notes
P08 Review Supervisory Notes
Description The process outlines the steps review supervisory notes
when a triggering event occurs.
Motivation Completed an event occurs that requires review of
supervisory notes.
Source Documents Personnel Change
To Supplemental
Documents
Review Supervisory Notes Process
Start
Supervisor
Event occurs that

triggers request to Reviews
review Supervisory Supervisory Notes
Notes
Employee
IPAS2 Data Collection
Generate entries to
Search Supervisory Enter Reason for Tracks and Records
Select Employee review based on End
Notes Review Access
search criteria
Solution
Figure 32:

3.2.11 Business Process Model Record OC Checkout
P09 Record OC Checkout
Description The process outlines the steps for recording an OC
Checkout.
Motivation Completed whenever an officer picks up or drops off
an OC canister.
Source Documents Equipment Control Card and Spreadsheet (10-16
fields)
Supplemental Supervisor Approval Letter
Documents Produce manual weekly reports from spreadsheets.
Monthly reports produced from Access.
OC Checkout Process
YES
Start
Officer
Returns Old OC Receives OC New Canister

Request OC Canister End No Returns old Canister
Canister Canister Required?
Supervisor
Training
Officer/
Supervisor Reviews
and Approves YES
Request
Property Unit
Equipment return
requested due to Yes Provide
expiry, retirement, Receives Old OC Request return of Receives Old
replacement
medical Canister OC Canister Canister
canister
Supervisor
Canister Request Record Canister Record Canister
Approval NO End
Created Data data
Required?
Request return of
OC Canister
Figure 33:

3.2.12 Business Process Model Create PAS Report
P10 Create PAS Report
Description This process outlines the steps for creating a PAS Report
Motivation Single Event Threshold has been met, or a Referral
has been received or individual is a confirmed Outlier.
Source Documents Supervisory Notes
IPAS Threshold Information
Referral Information
Supplemental
Documents
Create PAS Report
Phase 1
IPAS2 Data Collection
Populate Report User Name and Final Disposition

System
Notification PAS Final Disposition

with Data from IPAS Report Updated recommended Updated
Review Required Entered
Subject Area Disposition Entered
Start
PAS Admin Unit
Update PAS report PAS Activity Report

with analysis and reviewed by PAS
recommendations Supervisor
PAS Review
PAS Activity Review

Panel Response Notification of
Panel
Review and Validate Documented & Final Disposition

PAS Activity Report Report Completed
Supervisor
Review Report,
Confirm/ Notification of Appeal
Notification of
Recommend Disposition Submitted?
NO Disposition
Disposition
Referral for PAS

End
Review
Command
YES
Chain Of
Review Report,
Referral for PAS Confirm/ Notification of
Review Recommend Disposition
Disposition
Chief Of
Police
Decision on Appeal End
Figure 34:

3.2.13 Business Process Model Monitor PAS Program Activity
P11 Monitor PAS Program Activity
Description This process outlines the steps for monitoring PAS
Program Activity
Motivation PAS Report Disposition results in Supervisory
Monitoring and or Intervention.
Source Documents PAS Report
Supplemental Meeting Notes

Documents Training Disposition
Other
Supervisory Monitoring/Intervention Workflow
Phase 1
Start
May Result in another

Task New threshold met
review and/or updates to
Outlier Task Data Uploaded incomplete Due during PAS Program
existing tasks, and input to
Identification from Source Date minus n extension or release
and Threshold days? assessment
Response
Process
YES
Released from
Supervisory Program Extended
Program
Monitoring/
Intervention
Disposition
PAS Review
Panel
Receives Task Receives

Extension Approved Release Approved
Notification Notification
NO
PAS Admin
Unit Staff
Create, Configure Receives Task Receives Extension Granted Released

and Assign Tasks Notification Notification
No
Command
Chain of
Receives Task Assessment for

Released YES
Notification Release or Extension
YES
Immediate &
Second Line
Supervisors
Task Review Request

Monitor and Update Record Meeting Notification of Notification of
Notified of Tasks Meetings with Release or
Tasks Information Extension Release
Employee Extension?
NO
Figure 35:

3.2.14 Business Process Model Manage Code Tables
P12 Manage Code Tables
Description This process outlines the steps for managing code tables
in the IPAS2 Data Collection Solution
Motivation Keeping code tables current.
Maintaining a history of code table values
Source Documents None
Supplemental None
Documents
Manage Code Tables
Phase 1
Administrator
Code Table Update

Start
System
Request
IPAS 2 Data
Collection
System
Code table Updated
Figure 36:

3.3 Process to Use Case Mapping
ID Process Use Case
P01 Record Case Evaluation UC01 - Search Record
UC02 - Retrieve officer information
UC03 - Record Case Evaluation
UC04 - Create IAD Referral
UC05 - Send Notification
UC35 Print Record
P02 Record Vehicle Pursuit UC01 - Search Record
UC02 - Retrieve Employee Information
UC06 - Record Vehicle Pursuit
UC31 - Route Record to Another User
UC35 Print Record
P03 Record Vehicle Collision UC01 - Search Record
UC02 - retrieve officer information
UC07 - Record Vehicle Collision
UC35 Print Record
P04 Request Canine UC01 - Search Record
Deployment
UC02 - Retrieve officer information
UC08 - Record Canine Information
UC09 - Record Canine Request
UC35 Print Record
P05 Record Use of Force UC01 - Search Record
UC02-Retreive officer information

ID Process Use Case
UC10 - Record Use of Force
UC11 Investigate Use of Force
UC12 Approve Use of Force Investigation
Recommendation
UC13 Record Use of Force Distribution and Form
Links
UC14 Request Use of Force Investigation
Extension
UC15 Track Use of Force Investigation
UC16 Create Chronological Log
UC35 Print Record
P06 Record IAD Complaint UC01 - Search Record
UC17 - Search IAD Complaint
UC18 - Receive IAD Complaint
UC19 - Create IAD Complaint Record
UC20 - Record IAD Complaint Finding
UC16 Create Chronological Log
UC35 Print Record
P07 Create Supervisory Note UC01 - Search Record
UC21 - Create Supervisory Note
UC35 Print Record
P08 Review Supervisory UC01 - Search Record

ID Process Use Case
Notes UC02 - Retrieve Employee Information
UC22 - View Supervisory Note
UC23 Review /Append Supervisory Note
UC35 Print Record
P9 Record OC Checkout UC01 -Search Record
UC24 - Create OC Inventory
UC25 - Request OC Checkout
UC26 - Record OC Checkout
UC35 Print Record
P10 Create PAS Report UC01 - Search Record
UC27 - Create PAS Report Request
UC28 - Create PAS Report
UC35 Print Record
P11 Monitor PAS Activity UC01 -Search Record
UC29 Create PAS Disposition Strategy
UC30 Record PAS Meeting
UC31 End PAS Monitoring
UC35 Print Record
P12 System Administration UC33 - Update Code Table
UC34 - Audit User Activity

4.1 Actor List
Actor Goals & Responsibilities
OPD Supervisor Responsible for reviewing/monitoring activity of subordinate
staff.
Chain of Command Supervisors at all levels of organization, Sergeant, Lieutenant,
Captain, Deputy Chief, Chief. Increasing levels of authority
responsible for reviewing/monitoring/approving activity of
subordinate staff.
Form Creator Any person at OPD responsible for creating Forms in IPAS2.
Form Recipient Any person at OPD responsible for reviewing, approving or
creating a finding and entering this information into a form,
sometimes within mandated timelines.
OPD Staff Responsible for creating, reviewing, searching, approving
forms at OPD. Includes both civilian and sworn staff.
IAD Staff Internal Affairs Division Staff (sworn and civilian).
Responsible for receiving/entering complaints, documenting
investigation, findings and disciplinary action.
IAD Investigator Sworn staff responsible for conducting and documenting IAD
investigations.
Traffic Investigator Sworn staff responsible for conducting and documenting
investigations.
Department Safety Responsible for department safety concerns. Duties include
Officer reviewing collision investigations and determining a finding.
Duties also include coordination of Accident Hearing Board
and documenting outcomes.
Canine Handler Responsible for training and working with a canine.
Canine Coordinator Responsible for responding to canine requests and
coordinating deployments and supervising program.
Comm Centre Responsible for communicating with officers in the field.
Maintains Use of Force Log.
Division Commander Responsible for reviewing and approving UOF reports.
UOF Coordinator Receives use of force information, and creates the Use of
Force Finding for Level 2-4 Use of Force.
Property Unit Responsible for acquiring, tracking and issuing OC Canisters
to officers.

Actor Goals & Responsibilities
PAS Admin Unit Responsible for the IPAS System, Creation of PAS Reports
and Monitoring PAS Activity.
PAS Review Panel Responsible for reviewing PAS Activity Reports and
determining the disposition.
IPAS2 System System responsible for collecting all source data related to
Case Evaluation Reports, Vehicle Collisions and Pursuits,
Canine Requests, Internal Affairs Division Complaints, Use of
Force Activity, PAS Reports and Monitoring, and Supervisory
Notes.
Officer Responding Officer responding to a collision requiring investigation.
4.2 Use Cases

4.2.1 Use Case Diagram
The following diagrams depict the entire set of functionality that the system will deliver:

System
Search <<extends>>
Record Print Record
OPD Staff
Create Case <<Uses>> Retrieve

Evaluation Employee
Investigator Information
<<extends>>
Create IAD
IPAS2 System
Referral
<<extends>>
<<uses>>
Send
<<extends>>
Record Notification
Responding Vehicle <<extends>>
Officer Collision
OPD Supervisor
<<extends>>
Record
Traffic Pursuit Route Record
Investigator to Another
<<Uses>> User
Record
Canine
Information
Department <<Uses>> Canine Coordinator
Safety Officer
Record
Canine
Request
Investigator Canine Handler
Figure 37:

System
Record Use
of Force
<<extends>> Print Record
Comm Centre
<<uses>>
Investigate <<uses>> Send

Use of Force Notification
OPD
Supervisor
<<extends>> <<uses>>
<<uses>>
Request UOF
Retrieve
Investigation
Employee
Extension
Information
<<uses>>
Chain of <<extends>> <<extends>>

Command Route Record
to Another
Approve UOF
User
Investigation
<<extends>>
<<uses>>
UOF <<extends>>
Coordinator
Print Record
Create
<<uses>>
Chronological
Log
Create IAD
Referral
Track Use of
Force
Investigation
Record UOF
Distribution
& Form Links
Figure 38:

System
Search IAD <<extends>>
Complaint Print Record
IAD Staff
Receive IAD
Complaint
<<Uses>> Retrieve
Employee
Information
<<extends>>
Create IAD
Complaint Send
<<extends>> Notification
<<uses>>
<<extends>>
Record IAD
Complaint Create
IAD Investigator Chronological
Finding
Log
<<extends>>
IAD Commander <<Uses>> Retrieve

Review/ Employee
Append Information
Supervisory
Note <<extends>>
OPD Supervisor Send
Notification
Create
Supervisory <<extends>>
Note
OPD Staff
Figure 39:

System
Create OC
Inventory
Property Unit Send
<<extends>>
Notification
Request OC
Checkout <<extends>>
Route Record
OPD Staff to Another
User
Record OC
Checkout
OPD Supervisor
Request PAS
Report Chain of
Command
IPAS2 System
Create PAS
Report
PAS Review
Create PAS Panel
PAS Admin Unit
Disposition
Strategy <<extends>>
<<extends>>
Record PAS
<<extends>>
Meeting
Send
<<extends>>
Notification
<<extends>>
End PAS
Monitoring
Figure 40:

System
Update Code
Tables
System
Administration
Audit User
Activity
Figure 41:
4.2.2 UC01 Search Record

4.2.2.1 Use Case Table
Use Case Name: Search Record
Description: This use case describes the requirements for search
capability for the source system data.
Version: v.01
Actors: OPD Staff
Pre-conditions: User must have access to the search functionality
Post-conditions: Screen is populated with data for the selected record

1. User enters search criteria:
Main flow
a. Record Type (Mandatory Field)
b. Serial Number (Invoke UC02 Retrieve
Employee Information)
c. Last Name
d. First Name
e. RD Number
f. Use of Force Number
g. Key Word Search value
h. Create Date From Date
i. Create Date To Date
j. Event Date From Date
k. Event Date To Date
2. System returns a list of records that match search

criteria in the following format:
a. Officer Serial Number
b. Officer Last Name, First Name
c. RD Number
d. Use of Force Number
e. Create Date
f. Event Date
g. Linked to other record indicator?
h. Linked to other record type(s)
3. Actor selects record to view:
4. System displays data for the selected record in the
relevant form.
a. Vehicle Pursuit in the Vehicle Pursuit Form
b. Vehicle Collision in the Vehicle Collision Form.
c. Case Evaluation Report in the Case Evaluation
Form.
d. Canine Request in the Canine Request Form
e. Use of Force in the Use of Force Form
f. OC Checkout in the OC Checkout Form
g. Supervisory Note in the Supervisory Note form
h. PAS Report in the PAS Report Form
i. PAS Disposition Strategy in the PAS Strategy
Form
j. PAS Meeting in the PAS Meeting Form
EF1 starts at MF2:
Exception Flow 1
1. System does not find any records that match the search
criteria.
2. System advises user that no records found.

1. User must have security permissions to view records
Business Rules:
based on record type.
2. User must have security permissions to view records
based on department hierarchy security model (i.e. user
can only see records of subordinate staff based on
record type).
3. Users must enter at least one search criteria to generate
record search.
Technical Role-based access to records must be supported.
Requirements: When user selects record to view, system will display
the information in the same form used to capture the
data (e.g. if canine record is selected, system must
display canine data on the canine data collection form.
System must provide ability to view a record and return
to search results without re-executing search.
Audit records must be created for all searches. Data to
be collected is:
Date/time
Record Type
Record Data
Serial Number of reviewer
Duration record was open for viewing.
Issues/Notes:
4.2.2.2 Use Case Activity Diagram

System
Search
Record
OPD Staff
<<extends>>
Print Record
Figure 42:
4.2.3 UC02 - Retrieve Employee Information

Use Case Name: Retrieve Employee Information
Description: This use case describes the requirements for retrieving
employee information when creating a record in the IPAS2
Data Collection Solution. This use case is used by any use
case describing the creation of a new form of any type
where a serial number is entered.
Version: v.01
Actors: OPD Staff
1. User must have permission to create employee data.
Pre-conditions:
2. User is creating a form that requires employee data.
1. System will populate employee fields with available
Post-conditions:
employee information
2. System is ready to accept additional form data.

Use Case Name: Retrieve Employee Information
1. Actor enters serial number into IPAS2 Data Collection
Main flow
System
2. System retrieves the following data:
a. Last name, First Name
b. Rank (if required by form)
c. Assigned Shift (if required by form)
d. Assigned Area (if required by form)
e. Assigned Beat (if required by form)
f. Date of Hire (if required by form)
g. Date of Birth (if required by form)
h. Supervisor Name and Serial Number (if required
by form)
3. System Calculates Age of employee (if required by
form)
1. Age of officer is calculated based on date of birth and
Business Rules:
record created date.
Technical System must retrieve assignment data from the PDB
Requirements: database. This can be achieved by accessing
assignment records from the IPAS Data Warehouse.
If employee is not an officer, some fields will not apply.
Issues/Notes: It is assumed that some standardization of employee
information will occur during design so that most of the
data retrieved will be the same across forms except for
member vs employee data forms.
System
Retrieve
Employee
Information
OPD Staff
Figure 43:
4.2.4 UC03 Record Case Evaluation

Use Case Name: Record Case Evaluation
Description: When a case is created an investigator will be required to
take the case to the District Attorneys office to make a
charge/no charge decision. The result of this decision is
entered into the IPAS2 system for tracking and reporting.
Version: v.01
Actors: Investigator, OPD Supervisor
1. Suspect has been arrested
Pre-conditions:
2. Case has been created.
3. The Investigator receives the case and walks it over to
the DAs office where the charge/no charge decision is
made.
4. Decision is received by investigator in person or by
email.
1. Arresting Officer and Supervisor are notified of charge
Post-conditions:
approval outcome.

1. Form Creator completes the Case Evaluation Report
Main flow
Section 1:
a. Officer Serial Number (Invoke UC02 Retrieve
b. Officer Last Name, First Name
c. Shift
d. Beat
e. Report Date
f. RD Number
g. Arresting Officer Supervisor Serial (Invoke UC02
Retrieve Employee Information)
h. Arresting Officer Supervisor Last Name, First
Name
i. Supervisor Reviewing Report Serial Number
(Invoke UC02 Retrieve Employee Information)
j. Supervisor Reviewing Report Last Name, First
Name
k. Name of Suspect #1
l. Felony or Misdemeanor check box
m. Offenses (code, short description)
n. Arrest Date/Time (24 hour clock)
o. List charges: (Code, Short Description)
p. Charges requested by investigator checkboxes:
None*, 849b PC* Felony, Misdemeanor* - If *,
then user must provide a reason.
q. Charge(s) approved checkboxes: None*, 849b
PC* Felony, Misdemeanor* - If *, then user must
provide a reason.
r. Name of DA
s. List charges: (Code, Short Description)
2. Form Creator completes the Case Evaluation Report
charging Details Section (checkboxes select all that
apply):
a. Lack of Corpus (T1)
b. Lack of Sufficient Evidence (T2)
c. Inadmissible Search and Seizure (T3)
i. Evidence establishing Corpus
unreasonably seized.
ii. Questionable consent
iii. Questionable execution (search warrant)
iv. Questionable knock and notice
v. Questionable PC for arrest/officer not
present
vi. Questionable search and seizure problem
vii. Questionable search of person
viii. Questionable search of vehicle
Early Warning Intervention System ix. Questionable stop/detection
Appendix D Page / 116
d. Victim Unavailable/Decline to Testify (T4)
e. Witness Unavailable/Decline To Testify (T5)
EF1 begins at MF Step 3
Exception Flow 1
3. If MF3C boxes are checked, then invoke UC04 Create
IAD Referral
4. Enter Serial Number, Last Name and First name of
officer generating the referral
5. Enter referral comment.
MF1 resumes at Step 4.
1. A Case Evaluation Report is completed for all cases
Business Rules:
referred to the DAs office.
Technical System must allow users to create the record over time
Requirements: and maintain a status of the record.
System must assign a unique identifier to the Case
Evaluation Record.
System must track serial number, last name, first name
of user creating the record.
System must track create/update date/time.
Issues/Notes:
System
Record Case
Evaluation
OPD
Investigator <<Uses>> Supervisor
<<extends>> Retrieve
Employee
Information
Send
Notification
<<extends>>
Route Record
to Another
User
Figure 44:
4.2.5 UC04 Create IAD Referral

Use Case Name: Create IAD Referral

When user creates a Collision Record, a Pursuit Record, a
Description:
Use of Force Record, Case Evaluation Report and
information indicates that a complaint must be sent to IAD,
system generates a referral containing data from the record
for review by IAD.
v.01
Version:
IPAS2 Solution, OPD Staff,
Actors:
1. User enters data into IPAS2 Data Collection System
Pre-conditions:
2. User indicates that a referral must be sent to IAD
3. User provides a referring comment.
1. Referral is sent to IAD.
Post-conditions:
1. System sends the following data to IAD:
Main flow
a. Serial Number of Officer named on report
b. Last Name and First Name of Officer named on
report
c. Record Type generating the referral
i. Use of Force
ii. Collision
iii. Pursuit
iv. Case Evaluation Record
d. Reason for referral (based on data entered on
initiating record)
i. Level 1 Use of Force
ii. Collision with Preventable Finding
iii. Pursuit with Disciplinary Action Required
iv. Pursuit falling outside MOR
v. Case Evaluation Record where charging
details include selection of Inadmissible
Search and Seizure (T3) Checkboxes.
e. RD Number (if available)
f. CAD Number (if available)
g. Serial Number of person generating the referral
h. Last Name and First Name of person generating
the referral
i. Referring Comment entered by person
generating the referral.
2. Referral is sent to IAD for review.

Exception Flow 1 EF1 starts at MF1
1. OPD Staff receives a complaint.
2. OPD Staff creates a complaint referral to IAD
including the following data;
a. Date of Complaint
b. Incident Date
c. Incident Time
d. Street Number
e. Street Name
f. Apt #
g. Cross Street
h. Type
i. City
j. State
k. Zip
l. Beat
m. Who Made The Complaint
n. How Was the Complaint Made
o. From Where
p. Additional Complaint Categories
i. RMM/Notification
ii. Communication Log
iii. CPRB
iv. Legal Claim/Lawsuit
v. Accident/Pursuit
q. Complainant Information (1 or many)
i. First Name
ii. Middle initial
iii. Last name
iv. DOB
v. Gender
vi. Race
vii. Street Number (address 1 or many)
viii. Type
ix. Apt #
x. City
xi. State
xii. Zip
xiii. Address Type
xiv. Phone (phone one or many)
xv. Phone Type
xvi. Email
xvii. Statement Taken
1. Audio
2. Written
3. Video
Early Warning Intervention System r. Summary of Complaint Appendix D Page / 119
i. Text Field for complaint description
s. Involved Personnel
Business Rules: 1. All instances of Level 1 Use of Force are referred to IAD
to investigate.
Technical Data is provided from contents of record initiating the
Requirements: referral.
It is required that all referrals to IAD will be received in a
format that allows the user to accept the information and
it will populate the IAD Complaint form with the data
from the referring form.
Provide ability to upload documents and media to a
document management solution and provide links to the
document/media from the source systems based on
unique identifiers.
Provide word processing capability for data entry,
including spell check.
Issues/Notes: Data mapping from the referring form to the IAD
Complaint form will be required during design.
System
Create IAD
Referral
IPAS2 System
Figure 45:
4.2.6 UC05 Send Notification

Use Case Name: Send Notification
System sends notification to officers named on a report to
Description:
advise them that a report has been completed. Users will
access the report to view the details and take action if
required.

Use Case Name: Send Notification
v.01
Version:
IPAS2 System, OPD Staff
Actors:
1. Report has been completed where officer names and
Pre-conditions:
serial numbers have been provided
2. A Notification is required.
1. Actor is notified they must review a particular record for
Post-conditions:
information or action.
1. OPD Staff indicates notification is to be sent.
Main flow
2. OPD Staff sets timeline for notification (eg. 5 days prior
to due date, immediately, etc.)
3. OPD Staff sets recipient of notification (or confirms
recipient if defaulted based on serial numbers entered)
4. IPAS2 System sends a notification to identified officers
and supervisors.
5. Notification contains record information and a method to
access and view the report.
6. User Accesses notification record and uses links to
access the source record for action or review.
EF1 begins at MF6
Exception Flow 1
6. User does not access notification record within set
timelines.
7. System notifies notification initiator that notification has
not been viewed.
Business Rules:
Technical The mechanism for receiving notifications is not
Requirements: prescribed. This should be decided during design.
Provide ability to set notifications for tasks based on
timelines, e.g. 5 days before due date.
Provide ability to set notifications for tasks based on
status, e.g. overdue.
Provide ability to set recipients for notifications.
Provide ability to view and action notifications.
Provide ability to notify others when a notification has
not been viewed or actioned.
Issues/Notes:

System
Send
Notification
IPAS2 System OPD Staff
4.2.7 UC06 Record Vehicle Pursuit

Use Case Name: Record Vehicle Pursuit
Describes the requirements for capturing details about a
Description:
vehicle pursuit.
v.01
Version:
OPD Supervisor, Department Safety Coordinator
Actors:
1. Pursuit occurs
Pre-conditions:
2. Pursuit is called into Communication Centre
3. Supervisor completes initial investigation of pursuit
1. Pursuit record is complete
Post-conditions:

1. OPD Supervisor completes the CHP187 form (external
Main flow
to system)
2. OPD Supervisor records pursuit details:
a. RD Number
b. Incident No.
c. Incident Date
d. Day of Week
e. Initiating member serial number (Invoke UC02
f. Initiating member Last name, first name
g. Date of Pursuit Report
h. Initiating Cause
3. User indicates Level of Pursuit (1-3)
4. If Level 2 or 3 completes the following
a. Initiating Officer Supervisor Serial Number
(Invoke UC02 Retrieve Employee Information)
b. Initiating Officer Supervisor Last Name, First
Name
c. Officers assignment at time of incident
d. On-Duty Area Commander at time of incident
e. Patrol Area where incident occurred
f. Date of 3304 Expiration (calculated based on 1
year from pursuit date)
5. Invoke UC33 Route Record to Another User to send
the record to the Department Safety Coordinator for
Review and finding.
6. Department Safety Coordinator reviews and enters the
following:
a. Review for Compliance
7. If Pursuit Board Required, Department Safety
Coordinator will enter the following
a. Pursuit Hearing Board Date/time
b. Pursuit Hearing Board Location
c. Serial Number, Last Name, First Name of each
Board Member
8. System sends meeting notice to Board Members and
Officer Supervisor with date/time and location of the
Pursuit Board and the Pursuit Information.
9. Following the Board, the Department Safety Coordinator
will enter the following data following the Pursuit Board:
a. Date of RB Report
b. Review Board Finding
c. Related IAD Case Number
10. Invoke UC05 Send Notification to notify the Officer
Supervisor that a Pursuit Record has been completed.

AF1 starts at MF Step 4.
Alternative Flow 1
4. If Level 1 completes the following
a. Time incident started
b. Time incident terminated
c. Location incident started
d. Location incident terminated
e. Scene Visited by Supervisor (Y/N)
f. Reporting Supervisor Serial Number (Invoke
UC02 Retrieve Employee Information)
g. Reporting Supervisor Last Name, First Name
h. Property Damage and or Injuries
i. Compliance Finding
MF resumes at MF Step 5
AF2 Starts at MF Step 9c
Alternative Flow 2
c. If the Review Board Finding requires a referral to
IAD, Invoke UC04 Create IAD Referral
d. Enter Serial Number, Last Name and First name
of officer generating the referral (Invoke UC02
e. Enter referral comment
f. Send Referral to IAD
MF resumes at MF Step 10
1. Supervisors have 7 days to complete investigation after
Business Rules:
a pursuit has occurred.
Technical
Requirements:
Issues/Notes: There are three types of pursuit 1 is the most serious,
3 is the least serious.
The review of a pursuit is to determine if the pursuit was
in or out of compliance.
If discipline is required by the Pursuit Review Board, the
file is referred to IAD.
A training bulletin must go out after each board meeting
that lists the training notes from the pursuit finding. This
may be data this is generated from the finding into a
report that can be pushed to the department.

System
Record
Pursuit
<<Uses>> Department
<<Uses>> Safety
OPD Coordinator
Supervisor
Send Retrieve
Notification Employee
Information
<<Uses>>
<<Uses>>
Route Record
to Another
Create IAD User
Referral
Figure 46:
4.2.8 UC07 Record Vehicle Collision

Use Case Name: Record Vehicle Collision
Describes the requirements for capturing a vehicle collision
Description:
and recording a finding.
v.01
Version:
Responding Officer, Traffic Investigator, Department Safety
Actors:
Coordinator
1 An accident occurs where an OPD vehicle is involved.
Pre-conditions:
2 An accident report is created in the Field Based Report
System by an investigator (not involved person)
3 A Traffic Investigator reviews the report.
Post-conditions: 1. Collision investigation record will be created.

1. Accident information is entered into Field Based
Main flow
Reporting System (FBR) by the Responding Officer.
2. IPAS2 Data Collection System receives the following
data from FBR
a. Date form created
b. Serial Number and name of Responding Officer
c. Date of incident
d. Time of incident
e. Location of incident
f. IAD Tracking Number (when available)
g. RD Number
h. Agency
i. Vehicle Information
i. Number
ii. License
iii. VIN
iv. Marked
v. City/Leased
j. Driver Information
i. Serial Number (Invoke UC02 Retrieve
ii. Last Name, First Name
iii. Age
iv. Years of Service (calculated based on
date of hire)
v. Safety Belt
vi. Air Bag
vii. Supervisor Serial Number (Invoke UC02
viii. Supervisor Last Name, First Name
ix. Watch
x. Assignment
k. Passenger Information
i. Serial Number (Invoke UC02 Retrieve
ii. Last Name, First Name
iii. Age
iv. Years of Service (calculated based on
date of hire)
v. Safety Belt
vi. Air Bag
vii. Injured?
l. Investigator at fault? Or Not at Fault?
the record to the Traffic Investigator for Review:.
4. Traffic Investigator enters the following;
Early Warning Intervention System a. Date of Review Appendix D Page / 126
b. Serial Number and Name of Traffic Investigator
AF1 starts at MF7
Exception Flow 1
7. If Primary Collision Factor is Preventable, the following
is to be completed by the Department Safety Officer:
a. Disciplinary Process
i. Date Sent Out
ii. Date Returned Completed
iii. Scheduled for Accident Hearing Board?
iv. Accident Hearing Board Date/time
v. Accident Hearing Board Location
vi. Serial Number, Last Name, First Name of
each Board Member
8. System sends meeting notice to Board Members,
Officer and Supervisor with date/time and location of the
Accident Board and the Collision Information.
9. After the hearing is complete, the following data is
entered:
a. Accident Hearing Board Finding
b. Case Completed and Filed?
c. Forwarded to IAD?
10. If forwarded to IAD, Invoke UC04 Create IAD Referral
a. Enter Serial Number, Last Name and First name
of officer generating the referral
b. Enter referral comment
c. Send Referral to IAD
1. Officer must be notified of any disciplinary action within
Business Rules:
one year of event.
Technical It is required that the accident data that is entered into
Requirements: the Field Based Reporting System is sent to the IPAS2
Data Collection System at MF Step1. There is currently
duplication of data entry with the current process
accident report entered in FBR, Traffic Coordinator
signs printed version of report, Data Safety Coordinator
re-keys all the information again into Collision db.
There may be updates to this process through the
design phase based on technical requirement.
Issues/Notes: There may be timelines required based on different
sections of form completed.
that lists the training notes from the collision finding.
This may be data this is generated from the finding into
a report that can be pushed to the department.

System
Record
Collision
Department
Responding <<Uses>> <<Uses>> Safety
Officer Coordinator
Send Retrieve
Notification Employee
Information
Traffic
Investigator
<<Uses>>
<<uses>>
Route Record
to Another
User
Create IAD
Referral
4.2.9 UC08 Record Canine Information

Use Case Name: Record Canine Information
This use case describes the requirements for capturing
Description:
information about a specific dog.
v.01
Version:
Canine Coordinator, Canine Handler
Actors:
1 Dog has been acquired by OPD.
Pre-conditions:

1. Information is available that describes the dog.
Post-conditions:
1. Canine Coordinator captures the following
Main flow
information about the dog:
a. Name of Dog
b. Breed of Dog
c. Date of Birth
d. Date of Acquisition
e. Vendor
f. Vet Name
g. Vet Address
h. Vet Phone Number
i. Microchip Number
j. Completed Basic Training?
k. Certified/Decertified?
l. Date of Certification
m. If certified, Badge Number
n. Deployable? Y/N
o. Designation type
2. Canine Coordinator captures following information
about the dog assignment:
a. Canine Handler Serial Number (Invoke UC02
b. Canine Handler Last Name, First Name
c. Date of Assignment to Handler
3. Canine Handler or Canine Coordinator enter training
records as training occurs.
a. Date of Training
b. Type of Training
c. Exposed Subject?
d. Exposed Evidence?
e. Individual Training?
f. Supervised Training?
g. Hours of Training
4. Dog Retired? Y/N
5. If Yes, Retired Date
6. Retired Reason
7. Dog Died? Y/N
8. If Yes, Date of Death
9. Circumstances of death
AF1 begins at MF step 2
Alternative Flow 1
2. Dog Returned? Y/N
3. If Yes, Returned Date
4. Returned Reason

1. Dogs must be certified before they can be deployed.
Business Rules:
2. Dogs must have ongoing training of different types
Technical Dogs must have a unique identifier in the system.
Requirements: Dogs must have a badge number (or serial number) for
tracking purposes in use of force records.
Issues/Notes: Dogs do not currently have a badge number but it has
been identified as a requirement that dogs are assigned
a badge number when they are certified.
Currently use of force incidents only look at the canine
handler irrespective of dog, however, being able to
isolate activity of dog from activity of handler will be
required for analytics and reporting.
System
Record
Canine
Information
Canine
Coordinator <<Uses>>
Retrieve
Employee
Information
Figure 47:
4.2.10 UC09 Record Canine Event

Use Case Name: Record Canine Event
Description: This use case describes the requirements for capturing a
request for a canine team and the deployment information.

v.01
Version:
OPD Supervisor, Canine Coordinator, Canine Supervisor
Actors:
1 Request for Canine Team is received over radio.
Pre-conditions:
2. Information is captured about canine requests and
Post-conditions:
deployments
1. Supervisor checks to see if Canine Team is on duty.
Main flow
2. Supervisor checks the Dog type of on duty dogs.
3. Canine Handler assesses if search is appropriate or
feasible.
4. After search is completed, record will be updated by
Canine Handler:
a. Requesting Agency
b. Requested by
c. Request Date/Time
d. RD Number (if available)
e. Type of Search requested
f. Location of Search
g. Deployed (Y/N)
h. Serial Number of Canine Handler (Invoke
i. Last name, First Name of Canine Handler
j. Serial Number of Canine
k. Name of Canine
l. Serial Number of Handlers Supervisor
(Invoke UC02 Retrieve Employee
Information)
m. Last Name, First Name of Handlers
Supervisor
n. Serial Number of person authorizing search
o. Last Name, First Name of person authorizing
search
p. Location of Search (can be multiple)
q. Type of searches used (can be multiple)
r. Found Suspect (Y/N)
s. Found Evidence (Y/N)
t. Evidence Type
u. Evidence Quantity
v. Did Bite Occur?
w. If Yes, Use of Force Report Number
x. Comments

AF1 begins at MF5
Alternative Flow 1
5. Did another canine team provide assistance?
6. If yes,
a. Serial Number of Canine Handler (Invoke
b. Last name, First Name of Canine Handler
c. Serial Number of Canine
d. Name of Canine
e. Serial Number of Handlers Supervisor
(Invoke UC02 Retrieve Employee
Information)
f. Last Name, First Name of Handlers
Supervisor
g. Serial Number of person authorizing search
h. Last Name, First Name of person authorizing
search
MF resumes at MF5
EF1 begins at MF4g:
Exception Flow 1
g. If Deployed =No,
Enter Reason request was not fulfilled
EF2 begins at MF2
Exception Flow 2
2. Supervisor requests Canine team from external agency.
3. Information about request/deployment is forwarded to
Canine Coordinator.
4. Canine Coordinator receives and records following
information about request:
a. Requesting Agency
b. Requested by
c. Request Date/Time
d. RD Number (if available)
e. Type of Search requested
f. Location of Search
g. Deployed (Y/N)
h. Responding Agency
i. Canine Team information (text)
j. Type of searches used (can be multiple)
k. Found Suspect (Y/N)
l. Found Evidence (Y/N)
m. Evidence Type
n. Evidence Quantity
o. Did Bite Occur?
p. If Yes, Use of Force Report Number
q. Comments

1. If a bite occurs, investigation will be completed by
Business Rules:
sergeant on scene within 7 business days.
Technical Canine records where a bite occurs must be cross
Requirements: referenced with related Use of Force Record.
Issues/Notes:
System
Record
Canine
Request Canine
Handler
Canine
Coordinator <<Uses>>
Retrieve
Employee
Information
Figure 48:
4.2.11 UC10 Record Use of Force

Use Case Name: Record Use of Force
This use case describes the requirements for recording a
Description:
use of force.
v.01
Version:
Comm Centre
Actors:

1 Use of Force occurs in field.
Pre-conditions:
2 Use of Force is called into OPD Communication Centre
3 Supervisor is called.
4 If Use of Force Level 1, IAD is called.
1. Use of Force is recorded and assigned a unique
Post-conditions:
identifier.
1. Communication Centre enters Use of Force into the Use
Main flow
of Force Log. Log entries are as follows (invoke UC02
Retrieve Employee Information):
a. UOF Level
b. Incident Number
c. CAD Number
d. Supervisor or Commander Reporting Use of
Force Serial Number
e. Last Name, First Name
f. Time Received
g. RD Number (if available)
h. Area
i. Beat
j. UOF Date/Time
k. Primary Officer involved Serial Number
l. Last Name, First Name
m. Primary Officers Division Commander Serial
Number
n. Last Name, First Name
o. Level of Force and Description
p. Comments
q. Serial Number of Person making entry
r. System Populates Last Name First Name
2. System Creates a UOF record with this data and
assigns a unique identifier.
3. Invoke UC05 Send Notification to notify Chain of
Command, BFO and UOF Coordinator that a use of
force record was created.
AF1 begins at MF3
Alternative Flow 1
3. If Use of Force Level 1 send notification to IAD of Use of
Force and invoke UC04 Create IAD Referral to send a
referral to IAD.
1. Log Entries must be created immediately.
Business Rules:
Technical System must allow the creation of hyperlink to related
Requirements: documents and forms.
All entries into use of force system are tracked on the
chronological log.

Issues/Notes: Level 4 use of force is less serious (pointing a firearm)
and has a simple workflow associated.
Level 1-3 are more serious with one being the most
serious.
System
Record Use
of Force
<<Uses>>
Comm Centre
<<uses>> Retrieve
Employee
Information
Send
Notification
<<uses>>
Create IAD
Referral
Figure 49:

4.2.12 UC11 Investigate Use of Force
Use Case Name: Investigate Use of Force
Description:
use of force investigation.
v.01
Version:
OPD Supervisor, Use of Force Review Board
Actors:
1 Use of Force Incident is recorded by OPD
Pre-conditions:
Communication Centre
2 Use of Force Record is created
1. Use of Force investigation is recorded, with
Post-conditions:
recommendations created and ready for review.

1. Use of Force Investigator enters the following data into
Main flow
the UOF Report
a. UOF Location
b. Are there injuries (Y/N)
c. If yes, who were the injured parties
d. Reporting member serial number
e. Reporting member last name, first name
f. Subject Information for each subject
i. Name
ii. Sex
iii. Race
iv. DOB
v. Address
vi. City
vii. Zip
viii. Contact number
g. Employee Information for each employee
i. Name
ii. Force Types
iii. Force Sub Type
iv. Supervisor Serial, last name, first name
v. Division Commander Serial, Last Name,
First Name
vi. In custody (Y/N)
h. Witness Information for each witness
i. Name
ii. Sex
iii. Race
iv. DOB
v. Address
vi. City
vii. Zip
viii. Contact number
2. OPD Supervisor enters Assessment and Compliance
Data
a. Was the original detention or subsequent arrest
lawful?
b. Was the type and amount of force objectively
reasonable and used proportional to the
resistance encountered?
c. Was the type and amount of force related to a
legitimate law-enforcement objective the
member/employee was attempting to achieve?
d. Was the force reasonable de-escalated?
e. Was verbal persuasion used to attempt to resolve
the situation without force?
Early Warning Intervention System f. Any no response requires a narrative
Appendixresponse.
D Page / 137
3. OPD Supervisor completes the recommendation section
The following recommendation is based on the facts
1. Level 2-3 use of force investigations have associated
Business Rules:
timelines that must be completed within 16 calendar
days (7 days for supervisor, 4 days for commander, 16th
day to BFO).
2. Level 4 must be completed by the end of the next shift
not to exceed 5 calendar days.
3. Level 1 use of force is completed by IAD and within IAD
timelines and is excluded from this process.
4. Discipline must be imposed within 1 year of incident or it
cannot be imposed.
5. Supervisors and Commanders can apply for an
extension but extension cannot exceed 1 year timeline
for imposition of discipline.
chronological log.
serious.

System
Investigate
Use of Force
<<Uses>>
OPD
Supervisor
<<uses>> Retrieve
Employee
Information
Send
Notification
<<uses>>
Create IAD
Referral
Figure 50:
4.2.13 UC12 Approve Use of Force Investigation

Recommendation
Use Case Name: Approve Use of Force Investigation Recommendation

This use case describes the requirements for approving a
Description:
use of force investigation recommendation
v.01
Version:
Division Commander, UOF Coordinator
Actors:
1 Use of force investigation recommendations are entered
Pre-conditions:
and routed to Chain of Command for review/approval
through Division Commander.

1. Use of Force review is complete.
Post-conditions:

1. Division Commander completes the Command Review
Main flow
and Endorsement Section:
a. I reviewed the Offense and Supplemental
Reports for completeness, accuracy and quality?
b. I directed further investigation or additional
investigation resources (If yes, provide details).
c. The use of force was in compliance, or
d. The use of force was out of compliance
i. (IAD Notified (level 2 and 3)
ii. The investigation revealed criminal
misconduct and the appropriate
commander has been notified in
accordance with the provision of DGO M-
4.1.
e. AND/OR
f. Recommendations/Comments regarding tracking
and/or tactical issues?
g. The investigation revealed training and/or tactical
issues.
i. If a 1-2 incident, document for review by
the appropriate Board.
ii. If a level 3 incident, Division Commander
shall ensure training is conducted and/or
training is requested from the Training
Division when it cannot be accomplished
at the division level.
iii. Comments (Document the circumstances,
and the person and date of referral to the
Training Division).
2. Division Commander enters comments.
3. Division Commander enters Serial Number, Last Name,
First Name, Date and Time of report review.
4. Invoke UC033 Route Record to Another User to
forward information to Use of Force Coordinator to set
up the Force Review Board.
5. Use of Force Coordinator enters the following
information:
a. Scheduled for Force Review Board?
b. Force Review Board Date/time
c. Force Review Board Location
d. Serial Number, Last Name, First Name of each
Board Member
6. System sends meeting notice to Board Members,
Officer and Supervisor with date/time and location of the
Force Review Board and the Report Information.
7. After the hearing is complete, the following data is
Early Warning Intervention Systementered: Appendix D Page / 141
a. Force Review Board Finding
b. Case Completed and Filed?
EF1 begins at MF4.
Exception Flow 1
4. Level 4 use of force does not require Force Review
Board.
5. UOF Coordinator reviews information for completeness
and creates and updates documentation as necessary.
Business Rules:
day to BFO).
cannot be imposed.
chronological log.
serious.
that lists the training notes from the UOF finding. This
may be data this is generated from the finding into a
report that can be pushed to the department.

System
Approve Use
of Force
Investigation
UOF
Coordinator
<<Uses>>
Division
Commander
<<uses>> Retrieve
Employee
Information
Send
Notification
<<uses>>
Create IAD
Referral
4.2.14 UC13 Record Use of Force Distribution and Form Links

Use Case Name: Record Use of Force Distribution and Form Links
Description:
use of force distribution and form links.
v.01
Version:
UOF Coordinator
Actors:
1 Use of Force Record is Created
Pre-conditions:
1. Use of Force is recorded and investigated.
Post-conditions:

Use Case Name: Record Use of Force Distribution and Form Links
1. UOF Coordinator enters the following:
Main flow
a. IAD Received Entire UOF Report?
b. Risk Management Advised?
c. Firearms Discharge Control Number?
d. IAD Case Number?
e. Use of Force Coordinator Serial Number
f. Use of Force Coordinator Last Name, First Name
2. Create links to Use of Force documents.
3. Create links to Use of Force videos
4. Create links to Use of Force photos.
1.
Business Rules:
chronological log.
Issues/Notes:
System
Record UOF
Distribution
& Form Links
UOF
Coordinator
Figure 51:
4.2.15 UC14 - Request Use of Force Investigation Extension

Use Case Name: Request Use of Force Investigation Extension
Description: This use case describes the requirements for requesting an
extension to the timelines for a Use of Force Investigation.

Use Case Name: Request Use of Force Investigation Extension
v.01
Version:
OPD Supervisor, Division Commander, Chain of Command
Actors:
1 Use of Force investigation is in progress
Pre-conditions:
2 Use of Force timelines have not been exceeded.
1. Use of Force mandated timelines are extended.
Post-conditions:
1. OPD Supervisor or Division Commander accesses form
Main flow
and requests extension form request.
2. System populates the following fields:
a. Date of Incident
b. Incident Number
c. RD Number
d. Level
e. Member/Employee Serial Number, Last Name,
First Name
f. Subject Last Name, First Name
g. Extension Request Number
h. Date of Request
i. Requested by Serial Number, Last Name, First
Name,
3. OPD Supervisor or Division Commander enters reason
for extension request
request to a specific captain.
5. Chain of Command receives request and opens record
6. System records:
a. Captain Serial Number
b. Captain Last Name, First Name
7. Captain indicates extension is approved.
8. If yes, Captain enters new Due Date
9. Invoke UC05 Send Notification to send notification to
UOF Investigator that extension request has been
granted.
EF1 begins at MF7
Exception Flow 1
7. Captain indicates that extension is not approved.
8. Invoke UC05 Send Notification to send notification to
UOF Investigator that extension request has not been
granted.
1. Due date must be in the future to request an extension.
Business Rules:
Technical All entries into use of force system are tracked on the
Requirements: chronological log.
Issues/Notes:

System
Request UOF
Investigation
Extension Division
Commander
OPD
Supervisor <<Uses>>
<<Extends>>
Route Record Chain of

Command
to Another
User
Send
Notification
Figure 52:
4.2.16 UC15 Track Use of Force Investigation

Use Case Name: Track Use of Force Investigation
This use case describes the requirements tracking a use of
Description:
force investigation in accordance with mandated timelines.
v.01
Version:
IPAS2 System, UOF Coordinator
Actors:
1 Use of force incident record has been created.
Pre-conditions:
1. Use of Force tracking to timelines is recorded.
Post-conditions:

1. System populates date of incident
Main flow
2. System enters number of days granted by extension
3. System populates due date to commander
4. System populates due date to IAD
6. System populates due date for IAD Investigation
7. System populates due date to BOS
8. UOF Coordinator enters date Use of Force Review
Board is scheduled
10. System populates due date for Use of Force Review
Board
11. UOF Coordinator enters date Use of Force Review
Board is held
12. System populates due date for Use of Force Review
Board report
13. UOF Coordinator enters date Report received by OCOP
14. UOF Coordinator enters date Approved by Chief
15. UOF Coordinator enters date received by IAD
16. UOF Coordinator enter date task assigned to DC
17. System populates number of days extended by OCOP
18. System populates due date for task
19. UOF Coordinator enters date all tasks completed
20. UOF Coordinator enters date UOF investigation is
closed.
Business Rules:
day to BFO).
cannot be imposed.
Technical All entries into use of force system are tracked on the
Requirements: chronological log.

serious.
System
Track Use of
Force
Investigation
UOF
Coordinator
IPAS2
Figure 53:
4.2.17 UC16 - Create Chronological Log

Use Case Name: Create Chronological Log
This use case describes the requirements for creating a
Description:
chronological log
v.01
Version:
IPAS2 System, OPD Staff
Actors:
1 Form created that requires a chronological log.
Pre-conditions:
2. All significant events related to a form is recorded.
Post-conditions:

Use Case Name: Create Chronological Log
1. System creates chronological log with initial entry
Main flow
containing the following information.
a. Log type
b. Link to record unique id (use of force number,
IAD complaint number)
c. Incident Number
d. RD Number
e. Serial Number, Last Name, First Name of
employee
f. Last Name, first name of subject(s) (if available)
g. Create Date
h. Log type Record Created
2. OPD Staff enters record on chronological log.
3. OPD Staff creates entries on related Use of Force or
IAD Complaint Form.
4. System automatically updates chronological log with
summary of data created by OPD Staff.
1. Use of Force records require a chronological log of
Business Rules:
entries made into the record.
2. IAD records require a chronological log of entries made
into the record.
3. Chronological records cannot be modified or deleted
once created and saved.
Technical All entries into use of force record and IAD record are
Requirements: tracked on an associated chronological log.
IAD security constraints prevent sharing of chronological
logs created by the IAD complaint process from being
shared with anyone who does not have IAD Access
security profile.
System will auto-generated log entries based on defined
business rules.
User can manually create log entries.
Issues/Notes: Mapping will be required between record entries and
system generated chronological log types.

System
Create
Chronological
Log
IPAS2 System
OPD Staff
Figure 54:
4.2.18 UC17 - Search IAD Complaint

Use Case Name: Search IAD Complaint
This use case describes the requirements for searching IAD
Description:
complaints.
v.01
Version:
IAD Staff
Actors:
1 User must have permission to view IAD records.
Pre-conditions:
1. User will retrieve a list of IAD records that meet search
Post-conditions:
criteria.

Use Case Name: Search IAD Complaint
1. IAD staff enters search criteria for IAD search:
Main flow
a. Employee/Member Serial Number
b. Last Name
c. First Name
d. Incident From Date
e. Incident To Date
f. RD Number
g. Incident Number
h. IAD Number
i. Create From Date
j. Create To Date
k. Complainant Last Name
l. Complainant First Name
m. Search by Address Data Elements:
i. Street Number
ii. Street Name
iii. Type
iv. Apt #
v. Cross Street
vi. Type
vii. City
viii. State
ix. Zip
x. Address Contains
2. System returns records matching search criteria.
3. IAD Staff selects record to view.
AF1 begins at MF2
Alternative Flow 1
2. System does not find any records matching search
criteria
3. System notifies user that no records found matching
search criteria.
1. Must be able to search on minimal address data
Business Rules:
corner of? Between block 1100 and 1200 etc.
Technical IAD data is highly sensitive and must be portioned in a
Requirements: way that provides data protection/security.
Address Contains functionality is meant to be a general
search across address data elements for a word match.
Issues/Notes:

System
Search IAD
Complaint
IAD Staff
4.2.19 UC18 Receive IAD Complaint

Use Case Name: Receive IAD Complaint
This use case describes the requirements for receiving a
Description:
complaint.
v.01
Version:
IAD Staff
Actors:
1 OPD Staff have created a record and referred the record
Pre-conditions:
to IAD.
1. Record is available to accept as a Complaint or close.
Post-conditions:

1. IAD Staff access incoming referrals.
Main flow
2. IAD Staff views referral data
b. Incident Date
c. Incident Time
d. Street Number
e. Street Name
f. Type
g. Apt #
h. Cross Street
i. Type
j. City
k. State
l. Zip
m. Beat
n. Who Made The Complaint
o. How Was the Complaint Made
p. From Where
q. Complainant Information (1 or many)
i. First Name
ii. Middle initial
iii. Last name
iv. DOB
v. Gender
vi. Race
viii. Type
ix. Apt #
x. City
xi. State
xii. Zip
xiii. Address Type
xv. Phone Type
xvi. Email
1. Audio
2. Written
3. Video
r. Summary of Complaint
i. Text Field for complaint description
ii. Complaint withdrawn?
iii. Criminal case?
iv. Criminal referral?
v. Type of Offense
vi. Force Related?
Early Warning Intervention System vii. Injury? Appendix D Page / 153
viii. Bias related?
ix. Retaliation related?
AF1 begins at MF3
Alternative Flow 1
4. IAD Staff does not accept referral
5. System closes referral with status of not accepted
6. IAD Staff enters the reason the status was not accepted.
AF2 begins at MF5
Alternative Flow 2
5. System recognizes that data relates to existing IAD
Complaint Form based on matching identifiers provided
(RD Number, Incident Number, IAD Number, Use of
Force Number)
6. Officer validates records match and selects the data to
copy over.
7. System updates IAD Complaint Form with available
data.
MF resumes at MF7.
1. System will not automatically create/update IAD
Business Rules:
Complaint Forms unless an IAD Staff member accepts
the electronic information.
Technical IAD Complaint Form generated from a referral will
Requirements: create a link to referring form.
System must match on unique identifiers - RD Number,
Incident Number, IAD Number, Use of Force Number
to update an existing complaint form.
Issues/Notes: New process implemented at OPD to provide
Informational Business Cards to potential complainants
to provide information about making a complaint. When
cards are handed out the officer, calls it into the Comm
Centre to be recorded on a spreadsheet for tracking
purposes by IAD. It is possible that this process may be
required to be tracked in IPAS at a future date.
System
Receive IAD
Complaint
IAD Staff

Figure 55:
4.2.20 UC19 Create IAD Complaint

Use Case Name: Create IAD Complaint
This use case describes the requirements for creating an
Description:
IAD Complaint Form.
v.01
Version:
IAD Staff
Actors:
1 User must have permission to create IAD records.
Pre-conditions:
1. IAD complaint is created and ready for investigation
Post-conditions:

1. IAD Staff enters the following complaint data:
Main flow
b. Incident Date
c. Incident Time
d. Intake Date
e. 3304 Start Date
f. Street Number
g. Street Name
h. Type
i. Apt #
j. Cross Street
k. Type
l. City
m. State
n. Zip
o. Beat
p. OPD Complaint Category
q. Who Made The Complaint
r. How Was the Complaint Made
s. From Where
t. IAD Registered
u. Disposition
v. Additional Complaint Categories
i. RMM/Notification
ii. Communication Log
iii. CPRB
iv. Legal Claim/Lawsuit
v. Accident/Pursuit
w. Complainant Information (1 or many)
i. First Name
ii. Middle initial
iii. Last name
iv. DOB
v. Gender
vi. Race
viii. Type
ix. Apt #
x. City
xi. State
xii. Zip
xiii. Address Type
xv. Phone Type
xvi. Email
Early Warning Intervention System 1. Audio Appendix D Page / 156
2. Written
3. Video
1. 3304 timeline is one year less a day from incident date
Business Rules:
for investigation, finding and notification of any
disciplinary action, unless supervisor or other
recognized staff member could not have known about
the incident until a later date. In those circumstances,
the 3304 start date can be set to date the incident
became known by recognized authority .
2. 180 day timeline tracks the timeline from the date the
complaint is created until the complaint is investigated
and approved by an authorized role.
Technical System Assigns an Intake Number and a Case Number.
Requirements: Chronological logs entries are created based on record
updates and user entries.
System must support tracking of 3304 and 180 days
timelines.
System must allow user to overwrite start date of the
3304 start date based on business rules.
IAD data is protected data that is highly secure. Must
be able to partition the data and restrict access to
approved staff.
Issues/Notes:

System
Create IAD
Complaint
<<Uses>>
IAD Staff <<Uses>>

Retrieve
Employee
Send Information
Notification
<<extends>>
Create
Chronological
Log
Figure 56:
4.2.21 UC20 Record IAD Complaint Finding

Use Case Name: Record IAD Complaint Finding
This use case describes the requirements for entering an
Description:
IAD Complaint investigation and finding.
v.01
Version:
IAD Investigator, IAD Commander
Actors:
1 IAD Complaint has been created.
Pre-conditions:
1. IAD investigation and finding has been created for an
Post-conditions:
IAD Complaint.

1. Investigator is assigned.
Main flow
2. Date assigned is generated.
3. System calculates and displays key dates
a. Date of complaint
b. 3304 Expiration Date
c. Date of Incident
d. Date Case Number Assigned
e. Date Investigator Received Case
f. Investigation due date
4. IAD Investigator enters the Recommend Findings
a. Findings
b. Discipline
c. Days
d. MOR Detail
e. Synopsis
f. Discipline Confirmed
g. Discipline Letter
5. IAD Investigator enters the Discipline
a. Comments
b. Recommendations
c. Mitigating factors
i. Factors
ii. Comments
d. Aggravating Factors
i. Factors
ii. Comments
e. Final Disposition
f. Final Comments
6. IAD Investigator enters corrective Action
a. Officer Serial Number
b. Last Name, First Name
c. Assigned Date
d. Assigned To
e. Serial Number
f. Due Date
g. Return Date
h. Action Taken By
i. Serial Number
j. Action Date
7. IAD Investigator enters Tracking Information
a. ITS indicator
b. Date Intake Complete
c. Discipline Imposed?
8. System populates Investigation Completion Date
9. System populates approval Date
10. IAD Investigator enters the letter date field
11. Invoke UC05 Send Notification to Appendix
Early Warning Intervention System notify theDIAD
Page / 159
Commander that the Complaint is ready for review.
12. IAD Commander reviews the complaint and approves
AF1 begins at MF4
Alternative Flow 1
4. IAD Investigator elects to Administratively Close the
Complaint.
5. IAD Investigator enters the Admin Close Date
6. IAD Commander enters the Approval Date
7. IAD Investigator enters the Letter Date
MF resumes at MF11.
AF2 begins at MF4
Alternative Flow 2
4. IAD Investigator elects to File the Complaint.
5. IAD Investigator enters the Filed Date
6. IAD Commander enters the Approval Date
7. IAD Investigator enters the Letter Date
8. MF resumes at MF11.
AF3 begins at MF4
Alternate Flow 3
4. IAD Investigator elects to enter a summary finding.
5. IAD Investigator enters the summary finding Date
6. IAD Commander Approves the summary finding.
MF resumes at MF11.
AF4 begins at MF4
Alternate Flow 4
4. IAD Investigator elects to enter a CC.
5. IAD Investigator CC
MF resumes at MF11.
EF1 begins at MF8
Exception Flow 1
8. IAD investigator opts to Toll the discipline
9. IAD Investigator enters Tolling start date
10. IAD Investigator enters Tolling type
11. IAD Investigator enters Tolling Days
12. IAD Investigator enters By Who
13. System Calculates and displays number of days since
date of incident until todays date.

1. The 3304 expiration date defaults to one year less a day
Business Rules:
from the incident date, unless supervisor or other
recognized staff member could not have known about
the incident until a later date. In those circumstances,
the 3304 start date can be set to date the incident
became known by recognized authority and expiry date
will be one year less a day from that date.
2. 180 day timeline tracks the timeline from the date the
complaint is created until the is investigation approved
by an authorized role
3. Chronological logs entries are created based on record
updates and user entries.
4. Even when records toll they cannot exceed 3304
expiration date.
Technical IAD data is protected data that is highly secure. Must
Requirements: be able to partition the data and restrict access to
approved staff.
Issues/Notes:
System
Record IAD
Complaint
Finding <<Uses>>
IAD <<Uses>> IAD

Investigator Retrieve Commander
Employee
Send Information
Notification
<<extends>>
Create
Chronological
Log
Figure 57:

4.2.22 UC21 Create Supervisory Note
Use Case Name: Create Supervisory Note
This use case describes the requirements to create
Description:
supervisory notes.
v.01
Version:
OPD Staff
Actors:
1 OPD staff would like to create a note about staff within
Pre-conditions:
the OPD organization.
1. Supervisory note record is created.
Post-conditions:
1. OPD staff one or more of the following search criteria:
Main flow
a. Serial Number
b. Last Name
c. First Name
2. System retrieves list of staff matching the search
criteria.
3. OPD Staff selects staff to create entry about and system
provides a data entry screen to enter the information.
4. OPD Staff enters the following:
a. Supervisory Note Category (if entry is Report
Review Notice, then user must indicate whether
the supervisor note is positive or negative).
b. Supervisory Note Type
c. Reference Number Type
d. Reference Number (ie. RD Number, UOF #, etc)
e. Date of occurrence
f. Assignment at time of Occurrence (autopopulated
based on date of occurrence).
g. Start date
h. Completion date
i. Summary
j. Supporting documentation detail
k. IPAS disposition
5. System populates the following
a. User serial number
b. Last Name, First Name
c. User Assignment
d. Date/Time of Entry
6. Invoke UC05 Send Notification, to advise employee
that a supervisory note has been created about them.
Business Rules:

Use Case Name: Create Supervisory Note
Technical
Requirements:
Issues/Notes: Supervisory notes can be created for any staff member
by any other staff member. However, staff can only see
supervisory note entries for themselves or staff at a
subordinate level.
System
Create
Supervisory
Note
OPD Staff
<<extends>>
Send
Notification
Figure 58:
4.2.23 UC22 - Review/ Append Supervisory Note

Use Case Name: Review / Append Supervisory Note
This use case describes the requirements for viewing and
Description:
appending a supervisory note.
v.01
Version:
OPD Staff, OPD Supervisor
Actors:

1 A supervisory note record has been created about
Pre-conditions:
employee
2 Employee accesses supervisory note (through search or
via link in notification)
1. Employee response to Supervisory Note is related to
Post-conditions:
original entry.
1. OPD Staff reviews supervisory note entry.
Main flow
2. OPD Staff indicates they would like to append a
comment to the note.
a. Response or rebuttal?
b. Appended Information
1. System records OPD staff information:
a. Date/Time of Review
b. Record Reviewed
c. Serial Number of OPD Staff
d. Last name, first name of OPD Staff
4. Invoke UC05 Send Notification to notify staff member
creating the original entry that an appended record has
been created.
AF1 begins at MF1
Alternate Flow1
1. OPD Staff is notified that a rebuttal or response has
been appended to a supervisory note entry they have
created.
2. OPD Staff reviews the entry.
5. OPD Staff indicates they would like to append a
comment to the note.
a. Response or rebuttal?
b. Appended Information
2. System records OPD staff information:
a. Date/Time of Review
b. Record Reviewed
c. Serial Number of OPD Staff
d. Last name, first name of OPD Staff
3. Invoke UC05 Send Notification to notify staff member
creating the rebuttal or response entry that an appended
record has been created.
1. Staff can append information to any supervisory note
Business Rules:
entry that has been made about them.
Technical The appended record(s) must be related to the original
Requirements: record for viewing and searching purposes.

Issues/Notes: This is potentially a circuit that could continue with the
comments going back and forth between employees,
however business practice will address this and no
specific system constraints are required.
System
Review/
Append
Supervisory
Note
<<Extends>> OPD
OPD Staff
<<Uses>> Supervisor
Search
Send Record
Notification
Figure 59:
4.2.24 UC23 Create OC Inventory

Use Case Name: Create OC Inventory
This use case describes the requirements for creating an
Description:
inventory of OC canisters in the system for tracking
purposes.
v.01
Version:
Property Unit
Actors:
1 OC Canisters are received by the property unit
Pre-conditions:
1. OC Inventory is logged in the system for tracking
Post-conditions:
purposes.

Use Case Name: Create OC Inventory
1. Property Unit logs the receipt of the OC Canister
Main flow
from the supplier:
a. Date Received
b. Type of Canister (large/small)
c. Serial Number of Canister
d. Expiry Date of Canister
e. Received by Serial number
f. Received by Last Name, First Name
1. All canisters must be tracked.
Business Rules:
2. All canisters must be monitored for expiry and replaced
when expired.
Technical All canisters must be assigned a system tracking
Requirements: number.
Issues/Notes:
System
Create OC
Inventory
Property Unit
Figure 60:
4.2.25 UC24 Request OC Checkout

Use Case Name: Request OC Checkout
This use case describes the requirements to check out an
Description:
OC Canister.
v.01
Version:
OPD Officer, OPD Supervisor
Actors:

1 User is eligible to receive an OC Canister
Pre-conditions:
1 OC Inventory will be updated with all transactions.
Post-conditions:
1 Officer completes an OC Checkout Request:
Main flow
a. Serial Number of Officer (Invoke UC02 Retrieve
b. Last Name First Name of Officer
c. Type of Transaction Requested:
i. New Issue
ii. Exchange
iii. Return
d. If exchange or return provide the following:
i. Reason for exchange or return
ii. Type of Canister (large/small)
iii. Serial Number of Canister to be returned
2 If new issue, a supervisor approval is required. Invoke
UC33 Route Record to Another User to notify the
officers supervisor that an approval is required.
3 Invoke UC05 Send Notification to notify the Property
Unit that the Request has been initiated.
AF1 begins at MF Step 1d, ii
Alternative Flow 1
ii. If reason for exchange return is empty
enter RD Number where use of force was
recorded for cross-reference purposes.
MF resumes at MF step 1d, ii
AF2 begins at MF Step 1d, iii
Alternative Flow 2
iii. No serial number provided
iv. Reason serial number is not provided
MF resumes at MF step 2
AF3 begins at MF Step 2
Alternative Flow 3
2 If new issue, a supervisor approval is required. Invoke
UC33 Route Record to Another User to notify the
officers supervisor that an approval is required.
3 Supervisor enters the following:
a. Supervisor Serial Number (Invoke UC02
b. Supervisor Last Name, First Name
c. OC Checkout Approved?
d. Type and quantity of canisters approved
e. Date
1. Invoke UC05 Send Notification to notify the Property
Unit that the Request has been Approved.

2. Academy graduates can receive canisters without
Business Rules:
returning a canister. All other officers can only
exchange a canister.
3. Canisters can only be exchanged for a canister of the
same type (small for small, large for large).
4. Canisters can be returned without exchanging if they are
leaving the force.
5. When a canister is a new issue or an exchange for a
different type of canister (eg. small for large), a
supervisor must approve the exchange.
Technical System must validate serial number of canister to be
Requirements: returned against serial number of canister issued to
officer.
Issues/Notes: Sometimes a serial number cannot be read on a
returned canister. Users must track that a partial
number can only be viewed. May be possible over time
to do partial matches based on canister assignment
records.
System
Request OC
Checkout
OPD Officer <<Uses>> OPD

Supervisor
<<Uses>>
Send
Notification
Route Record
to Another
User
Figure 61:
4.2.26 UC25 Record OC Checkout


Use Case Name: Record OC Checkout
This use case describes the requirements for checking out
Description:
an OC Canister and updating the OC Inventory
v.01
Version:
OPD Officer, OPD Supervisor, Property Unit
Actors:
1 OC Checkout Request has been created.
Pre-conditions:
1. OC Inventory is updated.
Post-conditions:
1. OPD Officer goes to property to request OC Canister
Main flow
2. Property Unit staff checks system for request
information
3. OPD Officer provides canister for exchange
4. Property Unit staff validates that canister serial number
matches number identified on request.
5. Property Unit staff validates supervisor approval has
been received if required.
6. Property unit staff accepts the canister and indicates in
the system that the canister has been received, reason
for return and date of return.
7. Property unit staff issues new canister of same type
returned and captures the following information:
a. Date Issued
b. Type of Canister (large/small)
c. Serial Number of Canister
d. Received by Serial number (Invoke UC02
e. Received by Last Name, First Name
f. Property Unit Staff Serial Number
g. Property Unit Staff Last Name, First Name
AF1 begins at MF step 7
Alternative Flow 1
7. If reason for return is because the canister has been
used, validate that related RD Number has been
provided on request for cross-reference purposes.
MF resumes at MF step 7
EF1 begins at MF step 6
Exception Flow 1
6. If supervisor signature is required but has not been
received, respond to the following:
a. Does a safety issue occur if canister is not
issued immediately?
b. Indicate if canister issued prior to receiving
Supervisor Approval.
7. Invoke UC05 Send Notification to advise supervisor
that canister has been issued prior to approval.
MF resumes at MF step 6.

Use Case Name: Record OC Checkout
EF1 begins at MF1
Exception Flow 2
1. Canister return is requested by Property Unit based on
expiration of canister, retirement of officer or medical
leave of officer.
2. Canister data is recorded when received.
1. Supervisor approval is required for new issues or
Business Rules:
change of canister type.
Technical
Requirements:
Issues/Notes: If an officer is going on patrol, they must have a canister
so even if supervisor approval has not been received,
the workflow must accommodate approval after the
canister has been issued. An officer cannot be at risk
because the approval has not been received.
System
Record OC
Checkout
OPD
OPD Officer Supervisor
Property Unit
Figure 62:
4.2.27 UC26 Create PAS Report Request

Use Case Name: Create PAS Report Request
This use case describes the requirement for requesting a
Description:
PAS Activity Report.
Version: v.01

Chain of Command, IPAS2
Actors:
1 OPD Staff has met a threshold or has been identified as
Pre-conditions:
an outlier.
2 OPD Chain of Command is aware of a potential issue
with staff that requires investigation.
1. PAS report request is received by PAS Admin Unit.
Post-conditions:
1 IPAS2 identifies that a PAS Report is required based on
Main flow
coded business rules.
2 IPAS2 notifies the IPAS2 Data Collection System that a
PAS Report is Required with the following details:
a. Date PAS Report Requested
b. Requestor IPAS2 System
c. Personnel Serial Number (Invoke UC02
d. Personnel Last Name, First Name
e. Personnel Rank
f. Assigned Peer Group
g. Reason for Request
h. Threshold Met?
i. Type of Threshold met
j. Period of Assessment From and To Dates
k. Outlier %
l. Event Count during period
AF1 begins at MF1
Alternative Flow 1
1 Chain of Command identifies that a PAS Report is
required and completes the following details:
a. Date PAS Report Requested
b. Requestor Serial Number (Invoke UC02
c. Requestor Last Name, First Name
d. Last Name, First Name of Personnel referred
for PAS Report
e. Serial Number of Personnel referred for PAS
Report
f. Personnel Rank
g. Relationship to Requestor
h. Reason for request
1 PAS Reports will be completed on all staff who have
Business Rules:
been referred by Chain of Command or who have been
identified as needing a PAS Report by the PAS2
Solution.

Technical The IPAS2 Solution will assess the requirements for
Requirements: PAS review based on coded business rules. Referrals
will come from the reporting system to the data capture
solution for review and action by the PAS Admin Unit.
It is required that task list functionality will be provided in
the solution to receive incoming referrals, and to allow
users to accept the request and create the PAS report.
Issues/Notes:
System
Request PAS
Report
IPAS2 System Chain of

Command
Figure 63:
4.2.28 UC27 Create PAS Report

Use Case Name: Create PAS Report
This use case describes the requirements for generating
Description:
and capturing data in a PAS Report.
v.01
Version:
PAS Admin Unit, PAS Review Panel, Chain of Command
Actors:
1 A PAS Report has been requested.
Pre-conditions:
1. PAS Report is complete and a disposition has been
Post-conditions:
recorded.

1 PAS Admin Unit receives request for PAS Report
Main flow
2 PAS Admin Unit selects to create report
3 Invoke UC05 Send Notification to notify personnel and
supervisor that a PAS Report will be completed./
4 System populates the following:
a. Member/Employee Last Name, First Name
b. Member/Employee Serial Number
c. Supervisor Serial Number
d. Supervisor Last Name, First Name
e. Reviewer Serial Number
f. Reviewer Last Name, First Name
g. Report Create Date
h. Performance Activities Identified
i. Performance Activity Type
ii. Performance Activity Event (can be
multiple)
iii. Performance Activity Source
i. For each performance Activity Type Provide
Event Detail
5 For each Performance Activity Event Type, PAS Admin
Unit will provide Analysis commentary based on event
review and discussion with supervisor.
6 PAS Admin Unit will provide a Summary of All Events
7 PAS Admin Unit will provide a summary of all previous
PAS Reviews.
8 PAS Admin Unit will enter a Finding
9 Invoke UC05 Send Notification to alert PAS
Supervisor that report is ready for review.
10 PAS Supervisor reviews report and approves content.
11 Invoke UC05 Send Notification to alert PAS Review
Panel that report is ready for review.
12 PAS Review Panel Reviews Report and enters
recommended disposition
a. Disposition type
b. Recognition
c. Supervisory Monitoring
d. Intervention
e. No Action
13 Invoke UC05 Send Notification to alert Chain of
Command, Personnel and Supervisor of PAS Report
Completion and Disposition.
14 Chain of Command reviews report and provides
response.
15 PAS Review Panel finalizes disposition.
16 PAS Review Panel enters held by date for disposition
meeting.
17 PAS Review Panel enters recommended
Early Warning Intervention System strategies.
Appendix D Page / 173
18 Invoke UC05 Send Notification to Supervisor and
Chain of Command to provide details of Disposition
Alternative Flow 1
9. PAS Supervisor reviews report and does not agree with
disposition.
10. PAS Supervisor changes report and updates made by
PAS Admin Unit.
MF resumes at MF Step 11.
Alternative Flow 2
14. Chain of command reviews report and does not agree
with disposition.
15. Alternate disposition is recorded
16. Serial number of reviewer is recorded
17. Last Name, First Name of reviewer is recorded
18. Role of Reviewer is recorded
19. Invoke UC05 Send Notification to notify Pas Review
Panel of review and alternate disposition.
EF1 begins at MF2
Exception Flow1
2. PAS Admin Unit elects not to create the PAS Review.
The following information is captured:
a. Date
b. Serial Number, Last Name, First Name of
person creating the entry
c. Reason PAS Review is not being completed.
EF2 begins at MF15
Exception Flow 2
3. Chief is asked to review disposition.
4. Chief makes final decision on disposition.
MF resumes at MF15.
1 Chief makes final decision on exception cases.
Business Rules:
Technical Performance events are captured in source systems
Requirements: and updated to the IPAS2 data warehouse. The
warehouse is the source of the event data summarized
in the report.
Reviewer identifying data (serial number, last name, first
name, will be security protected information that is only
available to staff who have security privileges).
Reviews can be put on hold at any time due to medical
or other reasons. Tolling and tracking will be required if
a review is placed on hold.
Issues/Notes:

System
Create PAS
Report
Chain of
PAS Admin <<Uses>> Command
Unit
Send
Notification
PAS Review
Panel
Figure 64:
4.2.29 UC28 Create PAS Disposition Strategy

Use Case Name: Create PAS Disposition Strategy
This Use Case describes the requirement for creating and
Description:
modifying strategies assigned to a PAS Subject based on a
PAS Review with Disposition type of Supervisory
monitoring and/or intervention
v.01
Version:
OPD Supervisor
Actors:
1 PAS Review has been completed
Pre-conditions:
2 PAS Subject has been placed on supervisory monitoring
and or intervention.
1. Strategies have been assigned to PAS Subject for
Post-conditions:
tracking and monitoring.

1 OPD Supervisor retrieves PAS Review Report and
Main flow
indicates that they will be creating strategies for
monitoring.
2 System Defaults Strategies based on recommended
strategies in PAS Report.
3 OPD Supervisor selects one or more strategies to
assign to the officer.
4 OPD Supervisor sets start date of each strategy
5 OPD Supervisor sets end date of each strategy (where
appropriate)
6 OPD Supervisor identifies location of strategy (where
appropriate)
7 OPD Supervisor enters completion date when strategy
has been completed.
8 OPD Supervisor enters comments related to each
strategy (optional)
9 Invoke UC05 Send Notification to alert PAS Admin
Unit and Chain of Command that strategies have been
set for PAS Subject.
AF1 begins at MF Step 9:
Alternate Flow 1
9 OPD Supervisor indicates if strategy requires a recurring
meeting
10 OPD Supervisor sets recurring schedule for meeting
including meeting subject, date/time, location, duration,
invitees based on serial number, last name, first name
combination.
11 System sends meeting requests to invitees and updates
calendar/task list with this information.
EF1 starts at AF Step 12
Exception Flow 1
12 OPD Supervisor changes meeting data.
13 System sends updates to invitees and updates
calendar/task list with this information.
EF1 resumes at MF Step 9.
Business Rules:

Technical Ability to create meetings, including recurring meetings,
Requirements: and ability to track them is required.
Strategies can include training and counseling.
Strategies will have different attributes depending on the
type of strategy set.
System must be able to derive status of strategy
planned, in progress, outstanding, completed, etc.
When strategy is disposition or follow-up meetings,
system must schedule meeting and invite participants.
Issues/Notes:
System
Create PAS
Disposition
Strategy
OPD
Supervisor
<<extends>>
Send
Notification
4.2.30 UC29 - Record PAS Meeting

Use Case Name: Record PAS Meeting
This use case describes the requirement for recording the
Description:
details of a disposition or follow-up meeting

v.01
Version:
OPD Supervisor, Chain of Command, PAS Admin Unit
Actors:
1 PAS Report has been completed
Pre-conditions:
2 Disposition including Recognition, Supervisory
Monitoring and or Intervention has been finalized.
3 Strategies have been set.
4 Invitees to meeting are advised of meeting (should be in
calendar or other technology based on strategies set).
5 Meeting has been held.
1. Information from meeting has been collected.
Post-conditions:
1 OPD Supervisor selects scheduled meeting task for
Main flow
selected member/employee.
2 OPD Supervisor indicates that the scheduled meeting
was held.
3 System generates the following data:
a. Serial number of PAS Subject
b. Last Name, First Name of PAS Subject
c. Date and time of Meeting
d. Location of Meeting
e. Meeting Type
i. Disposition
ii. Follow up
iii. Strategy Confirmation
f. Attendees Serial Number, Last Name, First
Name
4 Report Creator adds the following information.
a. PAS Subject Left Meeting & Meeting
Continued?
b. Summary of Meeting
i. Description of At-Risk Behavior being
addressed.
ii. Effect of implemented strategy
5 Invoke UC33 Route Record to Another User to
forward record to Chain of Command for
review/approval.
6 Invoke UC05 Send Notification to PAS Admin Unit to
advise that PAS Meeting record was created.
MF1 begins at MF Step 2
Alternative Flow 1
2. OPD Supervisor indicates that the scheduled meeting
was postponed.
3. OPD Supervisor enters date/time of new meeting.

EF1 begins at MF step 2.
Exception Flow 1
1. OPD Supervisor indicates that the scheduled meeting
was not held.
2. OPD Supervisor enters reason the meeting was not
held.
3. OPD Supervisor enters comments
MF Resumes at MF Step 5.
Business Rules:
Technical
Requirements:
Issues/Notes:
System
Record PAS
Meeting
Chain of
OPD <<Uses>> Command
Supervisor <<Uses>>
Send Route Record

Notification to Another
User
PAS Admin
Unit
Figure 65:
4.2.31 UC30 End PAS Monitoring

Use Case Name: End PAS Monitoring
This use case describes the requirements for ending a PAS
Description:
Monitoring.
v.01
Version:
OPD Supervisor, Chain of Command, PAS Admin Unit,
Actors:
PAS Review Panel
1 Member/Employee is on supervisory monitoring and/or
Pre-conditions:
intervention.
2 Member/Employee has completed assigned strategies

Use Case Name: End PAS Monitoring
1. PAS Monitoring/Intervention is ended.
Post-conditions:
1 OPD Supervisor submits request to Chain of Command
Main flow
to end PAS Monitoring
2 OPD Supervisor provides reason for request.
3 Invoke UC05 Send Notification to notify Chain of
Command and PAS Admin Unit that end of PAS
Monitoring has been requested for member/employee.
4 Chain of Command approves request.
5 Invoke UC05 Send Notification to PAS Review Panel
to advise end of PAS Monitoring is recommended.
6 PAS Review Panel ends PAS Monitoring.
7 Invoke UC05 Send Notification to PAS Admin Unit,
Chain of Command and OPD Supervisor to advise of
End of PAS Monitoring.
AF1 begins at MF1
Alternative Flow 1
1 OPD Supervisor submits request to Chain of Command
and PAS Admin Unit to extend PAS Monitoring
2 OPD Supervisor provides reason for request.
3 OPD Supervisor provides extension term requested.
4 Invoke UC05 Send Notification to notify Chain of
Command and PAS Admin Unit that extension of PAS
Monitoring has been requested for member/employee.
5 Chain of Command recommends request.
6 Invoke UC05 Send Notification to PAS Review Panel
to advise extension of PAS Monitoring is recommended.
7 PAS Review Panel extends PAS Monitoring.
8 Invoke UC05 Send Notification to PAS Admin Unit,
Chain of Command and OPD Supervisor to advise of
extension of PAS Monitoring..
EF1 begins at MF6 and AF7
Exception Flow 1
4. PAS review panel does not approve request.
5. Invoke UC05 Send Notification to PAS Admin Unit,
Chain of Command and OPD Supervisor to advise
request has not been granted.
1 Extensions can only be granted in 3 month increments.
Business Rules:
Technical
Requirements:
Issues/Notes:

System
End PAS
Monitoring
PAS Review
OPD <<Uses>> Panel
Supervisor <<Uses>>
Send Route Record

Notification to Another
User
PAS Admin
Unit
Figure 66:
4.2.32 UC31 - Route Record to Another User

Use Case Name: Route Record to Another User
This use case is used by any use case that requires routing
Description:
of information to an individual or group defined by the user
who is creating the record.
v.01
Version:
Form Creator, Record Recipient
Actors:
1. Data is entered into system that requires review or
Pre-conditions:
action by another user.
1. Information will be provided to recipient indicating that a

Post-conditions:
form requires review or action.

Use Case Name: Route Record to Another User
1. Form Creator indicates that the form is to be sent to
Main flow
another user to complete an action (e.g. review,
approval, enter finding, etc).
2. Form Creator selects record recipient based on role
(supervisor, deputy chief, etc.).
3. Form Creator saves Record Recipient details.
4. Request is sent to Record Recipient indicating:
a. Date/Time Sent
b. Record Type
c. Action required
d. Due Date (if required)
e. Form Creator Serial Number, Last Name, First
Name
Business Rules:
Technical It is anticipated that the solution will provide a task list of
Requirements: some type to receive this information so that the user
can view and action items assigned to them for follow-
up or review.
Form Creator requires a mechanism to see Forms they
have sent that have not been actioned.
Form Creator should be able to go into the Form and
change the Record Recipient if action is not taken within
timelines.
Issues/Notes: Notifications are insufficient when response is required
within timelines and supervisors may be away or
unavailable. This use case provides the ability for the
user to select the user they want to send requests to.
System
Route Record
to Another
User
Record
Form Creator Recipient
Figure 67:

4.2.33 UC32 - Update Code Table
Use Case Name: Update Code Table
This use case describes the requirements for maintaining
Description:
and updating code tables in IPAS2 Data Collection System.
These code tables will be used in several screens to
populate drop down lists.
v.01
Version:
System Administrator
Actors:
1. Changes required to existing code table
Pre-conditions:
Post-conditions: 1. Change to code table has been made.
2. Historical information is preserved.
Main flow 1. System Administrator accesses code table by
selecting the appropriate code table within the Code
Table screen.
2. System Administrator adds a new code table value:
a. Code
b. Description
c. Effective Date
d. Expiry Date (if applicable)
3. System Administrator expires an existing code table
value
a. a. Enter expiry date
Business Rules: 1. Codes must be unique within tables.
2. Codes cannot be deleted must be expired.
Technical System must maintain a history of code table values for
Requirements: selected code tables. For some tables it is important to
know when the code was in effect for data mining
purposes, not just whether the code is currently effective
or expired.
Some code tables will require at least one active
value. Specific code table business rules will be
identified during design/development.
Issues/Notes: It is anticipated that all code tables will be managed
through a single screen and will apply a consistent
format for code tables across the application

System
Update Code
Tables
System
Administrator
Figure 68:
4.2.34 UC33 Audit User Activity

Use Case Name: Audit User Activity
This use case describes the requirements for audit
Description:
capability in the IPAS2 data collection solution
v.01
Version:
System Administrator
Actors:
1. User must have permission to access audit records.
Pre-conditions:
1. User will retrieve a list of records accessed by user.
Post-conditions:
1. System Administrator creates a query to identify what
Main flow
records were accessed and/or changed by a specific
user. Parameters are:
a. User ID
b. Date Range
c. Record Type (All is allowed)
2. System provides a list of records accessed by user with
date and time of access.
1. Auditable records must be maintained to know what
Business Rules:
data is accessed by whom.
Technical It is not required that all audit functionality is built into
Requirements: the solution but there must be a mechanism to access
audit information who accessed the form, update
date/time, fields updated, etc.
Issues/Notes:

System
Audit User
Activity
System
Administrator
4.2.35 UC34 - Print Record

Use Case Name: Print record
This use case describes the requirements for printing a
Description:
data collection form.
v.01
Version:
OPD Staff
Actors:
1. User must have permission to access the record
Pre-conditions:
1. System will print a form record.
Post-conditions:
1. OPD staff selects the record they would like to print.
Main flow
2. OPD staff selects the print option.
3. System prints record to default printer.
Business Rules:
Technical All data collection forms must be printable.
Requirements:
Issues/Notes:

System
Print Record
OPD Staff
Figure 69:

5 Data Requirements
5.1 Reporting Requirements
Name Description Fields
Case Evaluation Report Print of Case Evaluation Form All fields on data
collection form
Vehicle Pursuit Report Print of Vehicle Pursuit Form All fields on data
collection form
Vehicle Collision Report Print of Vehicle Collision Form All fields on data
collection form
Canine Request and Print of Canine Request Form All fields on data
Deployment Report collection form
Use of Force Report Use of Force Form All fields on data
collection form
IAD Complaint Report IAD Complaint Form All fields on data
collection form
OC Inventory Report OC Inventory for current date All fields on data
collection form
OC Checkout Report OC Checkout Report lists all All fields on data
checkout out requests for collection form
selected timeframe.
PAS Report Print of PAS Report for an All fields on data
individual collection form
PAS Strategy Report Print of all PAS Strategies set for All fields on data
an individual. collection form

5.2 Non-Functional Requirements
Non- Description
Functional
Requirement
Number
NF01 Method of adding forms to the solution must follow a
standard process.
NF02 Form solution must be flexible so that changes can be made
easily.
NF03 Solution should not allow unauthorized users to
create/modify forms.
NF04 Online forms should be intuitive and easy to use.
NF05 Wherever possible, online forms must validate user-entered

data at point of entry.
NF06 If data cannot be validated when entered, it must be
validated when saved.
NF07 Online forms should be intuitive and easy to use.
NF08 Solution must be scalable to allow for the addition of 25-50

forms over time.
NF09 Solution must be evolvable - allow for new capabilities or
technologies to be integrated easily.
NF10 Solution must prevent system time outs due to inactivity with
unsaved data entered.

Appendix E Draft IT Agreement and Instructions to Offerors
PROFESSIONAL SERVICES
AGREEMENT
BETWEEN THE CITY OF OAKLAND
AND ________________________________________
Early Warning Intervention System Appendix E Page / 189

TABLE OF CONTENTS
1. Definitions
2. Priority of Documents
3. Conditions Precedent
4. Statement of Work
5. Initial Term
6. City Requirements and Project Deliverables
7. Contractor Warranty and Indemnification of Services
8. Payment
9. Acceptance
10. Proprietary or Confidential Information of the City
11. Ownership of Results
12. Change Notices
13. Liquidated Damages for Contractors Unexcused, Untimely Performance
14 Limitation on Liability
15. Performance Bond)
16. Indemnification
17 Termination
18. Dispute Resolution
19 Commencement, Completion and Close-out
20. Bankruptcy
21, Assignment
22. Agents/Brokers
23. Publicity
24. Conflict of Interest
25. Validity of Contracts
26. Governing Law
27. Headings
28. Construction
29. Waiver
30. Independent Contractor
31. Attorneys Fees
32. Counterparts
33. Remedies Cumulative
34. Severability/Partial Invalidity
35. Access
36. Entire Agreement of the Parties
37. Modification
38. Notices
39 Right to Offset
40 No Third Party Beneficiary
41. Survival
42. Time is of the Essence

43. Authority
EXHIBITS
Exhibit 1 Statement of Work

Exhibit 2 Bill of Materials
Exhibit 3 Maintenance Agreement
Exhibit 4 Contractors RFP Proposal and Project Proposal Presentation
Exhibit 5 Contract Compliance Provisions
1. Business Tax Certificate

2. Inspection of Books and Records/Right to Audit
3. Non-Discrimination/Equal Employment Practices
4. Americans with Disabilities (ADA Requirements)
5. Local, Small Business Enterprise Program (LSBE)
6. Other Applicable Ordinances
7. City of Oakland Campaign Contribution Limits
8. Insurance
9. Political Prohibition
10. Religious Prohibition
Exhibit FiveCity Schedules

1. Schedule B-2 -Arizona Resolution
2. Schedule C-1_P_U_V - Combined Form
a. Schedule C-1 - Compliance With The Americans With Disabilities Act
b. Schedule P - Nuclear Weapons Proliferation Ordinance
c. Schedule U - Compliance Commitment Agreement
d. Schedule V - Affidavit Of Non-Disciplinary Or Investigatory Action
3. Schedule D - Ownership, Ethnicity and Gender Questionnaire
4. Schedule E - Project Consultant Team Form
5. Schedule K Pending Dispute Disclosure Form
6. Schedule M -
a. Part A - Independent Employer Questionnaire Vendor completed
b. Part B - Independent Employer Questionnaire -- Requesting Department
completed
7. Schedule N - Declaration Of Compliance With Living Wage Ordinance
(Professional Services and Design Build Projects only)
8. Schedule N-1 - Equal Benefits Declaration Of Nondiscrimination
9. Schedule O - Disclosure of Campaign Contributions Form
10. Schedule Q - Professional & Specialized Services Insurance Requirements

AGREEMENT TO PROVIDE
PROFESSIONAL SERVICES AND RELATED PRODUCTS
BETWEEN THE CITY OF OAKLAND
AND ________________________________________
This Agreement to provide Professional Services and Related Products as applicable and
as set for with specificity herein [Agreement] is entered into as of the date when fully
executed below between___________________________, a
______________________corporation (Contractor) and the City of Oakland (City), a
municipal corporation, One Frank H. Ogawa Plaza, Oakland, California 94612, who agree
as follows:
RECITALS
This Agreement is made with reference to the following facts and objectives:
A. WHEREAS, the City Council has authorized the City Administrator to enter into
contracts for professional or specialized services if the mandates of Oakland City
Charter Section 902(e) have been met; and
B. WHEREAS, Contractor is the developer or distributor of software products, hardware
and provides related professional services [Services]; and
C. WHEREAS, City is part of and provides information technology services to the various
City departments, offices, and programs; and
D. WHEREAS, City wishes to acquire Contractors Services as specifically set forth in this
Agreement, including the Statement of Work [SOW] attached hereto and
E. WHEREAS, the following Exhibits and Schedules are attached to and incorporated by
reference into this Agreement:
Exhibit 1 Statement of Work
Exhibit 2 Bill of Materials
Exhibit 3 Maintenance Agreement
Exhibit 4 Performance Bond
Exhibit 5 Contractors RFP Proposal and Project Proposal Presentation
Exhibit 6 Contract Compliance Provisions
Exhibit 7 City Schedules
NOW THEREFORE, THE PARTIES TO THIS Agreement COVENANT AND AGREE AS

FOLLOWS:

1. Definition
a. Acceptance as used herein shall mean the acceptance of Services by City in
writing in accordance as provided in Section [INSERT] and Section [INSERT] of
Exhibit 1, the Statement of Work [SOW] confirming that the Services and
Deliverables comply in all material respects with the Specifications.
b. Acceptance Certificate as used herein shall mean the document substantially
in the form of Attachment 1 to the SOW which City shall issue to Contractor when
Contractor satisfactorily completes the Testing and Acceptance provisions for
Contractors Deliverables or Services; an Acceptance Certificate must
accompany each invoice Contractor submits to City;
c. Payment as used herein shall mean Citys payment to Contractor for
Deliverables or Services pursuant to an invoice accompanied by an Acceptance
Certificate indicating City has accepted the invoiced Deliverables or Services as
provided in Section INSERT] and Exhibit 1;
d. Special Circumstances as used herein means the post September 11, 2001
demands to develop and deploy a comprehensive technology interface that
integrates key City of Oakland, Port of Oakland, and third party stakeholder
systems that require the automation of primary safety and security related tasks
and identification of specific countermeasures to various threat scenarios which
are essential to enhanced safety and security of the City/Port environments;
e. OTHERS AS THE PARTIES DEEM APPROPRIATE, E.G. DELIVERABLES,
SERVICES, SPECIFICATIONS, REQUIREMENTS, TECHNICAL TERMS;
2. Priority of Documents
In the event of conflicting provisions as between the following documents, except
as otherwise expressly stated, the provisions shall govern in the following order:
the Amendments to this Agreement, Change Notices (as defined in Section
[INSERT] of this Agreement) in reverse chronological order of adoption, this
Agreement and its Exhibits. The Exhibits shall govern in numerical order as set
out in this Agreement.
3. Conditions Precedent
a Contractor must provide City with the following before the Agreement will
become effective:
(1). A copy of Contractors City of Oakland Business Tax License which
must be kept current for the duration of the Agreement and shall be
attached to this Agreement as part of Exhibit 5
;

(2). A completed set of the City of Oakland Schedules which shall be
attached to this Agreement as Exhibit 5;
(3) A copy of Contractors Performance Bond which shall be attached t

to this Agreement as Exhibit 4 and incorporated herein by this reference.
.
b. Contractor and City must complete and agree upon and execute a Statement of
Work before the Agreement will become effective and which shall be attached to
this Agreement and incorporated herein by this reference.
4. Statement of Work
Contactor agrees to perform the services (Services) and provide the
deliverables (Deliverables) specified in EXHIBIT 1 the Statement of Work,
which is attached to this Agreement and incorporated herein by this reference.
5. Initial Term
The Initial Term of this Agreement shall start when it is executed in full by all
Parties and end upon the satisfactory completion of all tasks set forth in the
SOW, and the provision of all Services called for hereunder, unless extended by
the written Agreement of the Parties or sooner terminated as provided herein.
6. City Requirements for Project Deliverables

a. As is set forth with specificity in the Statement of Work [Exhibit 1], this Project will
require Contractor to provide the Services necessary to complete the Design-
Build-Maintain Technology Linkage System (TLS) including, but not limited to the
integration, enhancement, development, configuration, and maintenance of the
specified systems (existing and new) relative to the DAC.
b. This Project is part of the post September 11, 2001 demands to develop and
deploy a comprehensive technology interface that integrates key City of Oakland,
Port of Oakland, and third party stakeholder systems that require the automation
of primary safety and security related tasks and identification of specific
countermeasures to various threat scenarios which are essential to enhanced
safety and security of the City/Port environments [Special Circumstances]
c. Contractor will be responsible for the entire Scope as set forth in Exhibit 1,, the
SOW, including, but not limited to being solely responsible for coordinating the
activities of all team members, and ensuring that the Scope is fulfilled to the
Citys satisfaction in accordance with this Agreement.

d. Contractor must provide a turnkey solution for the Project at a firm, fixed price
which shall, in no event, exceed [INSERT].
7. Contractor Warranty and Indemnification of Services

a. In recognition of Citys reliance on its Services and the Special Circumstances of
this Project, Contractor warrants that its Services will be suitable for the purpose
intended and fully meet Citys Requirements. Subject to Section [INSERT}
[Limitation on Liability], Contractor agrees to fully indemnify City for all liabilities,
claims, losses, damages and expenses, including without limitation, reasonable
attorneys fees, arising from any failure by Contractor in the performance of the
Services as required hereunder.
b. Contractor acknowledges that City is a provider of public and municipal services
to the public and residents of the City of Oakland and that Citys reliance on and
use of Contractors Deliverables will be vital to: (a) the business operations of the
City; (b) the orderly and efficient provision of public and municipal services by the
City; and (c) the health and safety of Citys residents; and therefore, that any
unauthorized interruption of Citys business and operations could result in
substantial liability to City. In recognition of Citys status as a provider of such
public and municipal services, Contractor warrants and represents that
Contractor shall not at any time during the term of this Agreement and thereafter
render the Software unusable or inoperable, take possession of the Deliverables
provided to City by Contractor or Contractors subcontractors or in any way
deliberately take actions limiting Contractors liability under this Agreement. If
Contractor takes any such actions, Contractor shall be liable for and indemnify
City for all liabilities, claims, losses, damages and expenses, including without
limitation, reasonable attorneys fees, arising from Contractors actions the
Services and Deliverables (a) will be free from defects in design, workmanship
and materials, delivered to City hereunder; (b) will conform in all material
respects to the Specifications
c. Contractor represents that it will use all reasonable efforts, including appropriate
testing, to ensure that the Software does not contain viruses, contaminants, or
other harmful code that may harm the Software, City systems or other City
software.
d. Contractor represents that it owns or has the unencumbered right to license
and/or assign to City, as provided in this Agreement, the Deliverables and all
results of Services delivered to City hereunder, including all required Intellectual
Property Rights therein
e. Contractor represents that it has the requisite experience, certifications, skills and
qualifications necessary to perform the Services in: (i) a timely, competent, and
professional manner, and (ii) accordance with applicable governmental
requirements, statutes, regulations, rules and ordinances including, without
limitation, applicable data privacy laws and regulations (Law);

f Except for the express representations and warranties made in this Agreement,
the Contractor makes no representation, acknowledgement, condition or
warranty of any kind whatsoever under this Agreement or otherwise, including
without limitation, any statutory, express, implied or other warranties or any
warranty of merchantability or fitness for any particular purpose regarding any
Services, deliverable or any other product delivered to the City under this
Agreement.
8. Payments.
a. Upon performance of the Services (as defined in Section 6 of this Agreement and
in the Statement of Work) and the completion of each Deliverable (as defined in
Section 6 of this Agreement and in the Statement of Work) which City has
previously Authorized (as defined in Section 8(c) of this Agreement), and Citys
Acceptance (as defined in Section 8(c) of this Agreement) of that Deliverable,
Contractor will invoice City for the Services and Deliverable. The invoice must be
accompanied by an Acceptance Certificate (as defined in Section 9.3(b) of this
Agreement) for the Services or Deliverable being invoiced. City will pay
Contractors invoice within thirty (30) days of Citys receipt of Contractors
invoice. All such payments from the City shall be in immediately available funds
and in U.S. dollars. Any amounts invoiced for Deliverables for which City has
provided its Acceptance which City has not paid within 30 days of Citys receipt
of Contractors invoice shall accrue interest at the rate of six percent (6%) per
annum until paid in full.
b. For the purposes of this Agreement:
(i) Authorized shall mean that the City has reviewed the proposed project
plan [Project Plan] with Contractor during the bi-weekly meetings
between the Parties as set out in the Statement of Work attached to this
Agreement as Exhibit 1 (SOW) and has provided written approval to
Contractor to continue providing the Services and Deliverables
contemplated under the Project Plan.
(ii) Acceptance or Accepted shall mean that the City has reviewed the
Authorized Services or Deliverables upon Contractors completion of same
and accepted them, in writing, in accordance with Section 14 of this
Agreement and as provided in the SOW.
c. Contractor acknowledges and agrees that City shall have no obligation
whatsoever to pay Contractor for any Services or Deliverables performed which
have not been Authorized by the City as contemplated herein. Contractor further
acknowledges and agrees that City shall have no obligation whatsoever to pay
Contractor for any Services or Deliverables it has not Accepted as provided
herein (Acceptance, Section 14).

9. Acceptance
9.1 Unless otherwise agreed in writing, the Parties agree that:
(a) When Contractor completes each Authorized Deliverable (Deliverable),

the City shall have five (5) Business Days, or such longer period of time as
the Parties may agree upon or as is set out in the SOW (the Acceptance
Period), from the Citys receipt of the Deliverable to review and either
provide its Acceptance of the Deliverable and an Acceptance Certificate or
written notice of its rejection setting out in detail the reasons why such
Deliverable failed to be Accepted in accordance with Section 14.2 of this
Agreement;
(b) For each Deliverable, when corrective action is required by the Citys
written notice of deficiencies, Contractor shall have five (5) Business
Days, or such longer period of time as the Parties may agree upon, to
correct the deficiencies City has identified as provided herein [Corrective
Action Period];
(c) For each Deliverable, Contractor shall be given at least two opportunities
to correct the deficiencies identified by the City, unless the Parties
otherwise mutually agree;
(d) Contractor shall correct any deficient Deliverables for which the City has
delivered written notice to Contractor as set out in subsection 14.1(b)
above such that the Deliverable complies with the requirements set out
under this Agreement,
(e) If Contractor fails to remedy a deficient Deliverable after both opportunities

to remedy as set out in subsection 14.1(d) above, then such failures shall
constitute a material default of this Agreement; and
(f) Changes to Deliverables for which the City has provided Acceptance will
be handled through the Change Notice process set out at Section 11 of
this Agreement and Contractor will start no work on any change until the
Parties have approved and executed any applicable Change Notice.
9.2 Upon delivery by Contractor of any Deliverable and within the Acceptance
Period, the City shall review such Deliverable to determine if such Deliverable
meets the applicable Acceptance Criteria as set out in the SOW, and
(a) if such Deliverable meets the applicable Acceptance Criteria or is

otherwise, used or acted upon by the City, the Deliverable will be deemed
Accepted on such date unless City has given notice to Contractor that it
needs to use or act upon the Deliverable in order to determine whether or
not it is acceptable,

(b) if such Deliverable does not meet the applicable Acceptance Criteria, the
City will provide written notice by no later than the end of the Acceptance
Period to Contractor setting out reasonable particulars of any deficiency
and Contractor will, within the Corrective Action Period, re-work the
Deliverable to meet the applicable Acceptance Criteria, or
(c) if the City fails to provide written notice rejecting the Deliverable, or fails to
respond to Contractor in writing by the end of the Acceptance Period, then
the City will be deemed to have Accepted such Deliverable.
(d) Once the City Accepts a Deliverable under the terms of this Section 14,
including its subparts, City will issue Contractor an Acceptance Certificate
which must accompany Contractors invoice to City for that Deliverable.
9.3 For the purposes of this Agreement:
a. Acceptance Criteria means reasonable and objective criteria jointly established
and agreed to in writing by the City and Contractor describing the criteria for the
completion and acceptability of Deliverables all as more particularly set out in the
SOW;
b. Acceptance Certificate means a certificate authorized and signed by the City indicating
that the City has Accepted the specific Deliverable or Service to which the Acceptance
Certificate relates,
10. Proprietary or Confidential Information of the City

10.1 Confidentiality Obligations. Confidential Information shall mean all proprietary or
confidential information disclosed or made available by the other Party pursuant
to this Agreement that is identified as confidential or proprietary at the time of
disclosure or is of a nature that should reasonably be considered to be
confidential, and includes but is not limited to the terms and conditions of this
Agreement, and all business, technical and other information (including without
limitation, all product, services, financial, marketing, engineering, research and
development information, product specifications, technical data, data sheets,
software, inventions, processes, training manuals, know-how and any other
information or material), disclosed from time to time by the disclosing Party to the
receiving Party, directly or indirectly in any manner whatsoever (including without
limitation, in writing, orally, electronically, or by inspection); provided, however,
that Confidential Information shall not include the Content that is to be published
on the website(s) of either Party.
10.2 Each Party agrees to keep confidential and not disclose to any third party and to
use only for purposes of performing or as otherwise permitted under this
Agreement, any Confidential Information. The receiving Party shall protect the
Confidential Information using measures similar to those it takes to protect its
own confidential and proprietary information of a similar nature but not less than
reasonable measures. Each Party agrees not to disclose the Confidential

Information to any of its Representatives except those who are required to have
the Confidential Information in connection with this Agreement and then only if
such Representative is either subject to a written confidentiality agreement or
otherwise subject to fiduciary obligations of confidentiality that cover the
confidential treatment of the Confidential Information.
10.3 Exceptions.
The obligations of this Section 9 shall not apply if receiving Party can prove by
appropriate documentation, where appropriate, that such Confidential Information
(i) was known to the receiving Party as shown by the receiving Partys files at the
time of disclosure thereof, (ii) was already in the public domain at the time of the
disclosure thereof, (iii) entered the public domain through no action of the
receiving Party subsequent to the time of the disclosure thereof, (iv) is or was
independently developed by the Contractor without access to or use of the
Confidential Information; (v) was provided to the Contractor by a third party who,
to the best of the Contractors knowledge, was not bound by any confidentiality
obligation related to such Confidential Information; or (vi) is required by law or
government order to be disclosed by the receiving Party, provided that the
receiving Party shall (i) notify the disclosing Party in writing of such required
disclosure as soon as reasonably possible prior to such disclosure, (ii) use its
commercially reasonable efforts at its expense to cause such disclosed
Confidential Information to be treated by such governmental authority as trade
secrets and as confidential.
10.4 Contractor acknowledges that City is subject to public disclosure laws and that
City will comply with requests for information (RFI), as it is required to do under
the federal Freedom of Information Act, California Public Records Act, City of
Oakland Sunshine Act or judicial or administrative court order. Contractor
acknowledges that an RFI may pertain to any and all documentation associated
with Citys use of Contractor Services. Contractor further acknowledges that it is
obligated to assist and cooperate with City by producing all documentation that is
responsive to the RFI so that City may comply with its statutory obligations. City
agrees to give Contractor as timely written notice as possible of the RFI such that
Contractor may oppose the RFI or exercise such other rights at law as Contractor
believes it has. However, Contractor must produce all RFI responsive
documents to City and City will comply with the RFI unless, within the time frame
established by the statute, judicial or court order under which the RFI is made,
Contractor procures a Temporary Restraining Order or similar injunctive relief
from a court or other tribunal of competent jurisdiction ordering City not to comply
with the RFI pending final determination of Contractor protest of the RFI.
Contractor further agrees to accept Citys tender of defense and to defend City
and pay all City costs of defense in any litigation brought against City with
respect to City not complying with an RFI that Contractor protests and will hold
City harmless against any claims, attorneys fees, damages, fines, judgments, or
administrative penalties, which may arise from any such actions.

11. Ownership of Results
Any interest of Contractor or its Subcontractors, in specifications, studies,
reports, memoranda, computation documents in drawings, plans, sheets
prepared by Contractor or its Subcontractors under this Agreement shall be
assigned and transmitted to the City. However, Contractor may retain and use
copies for reference and as documentation of its experience and capabilities.
12. Change Notices

(a) Upon fifteen (15) days' written notice to Contractor, City shall have the right to
request changes in the provision of any future Deliverables under this Agreement
by delivering to Contractor a change notice ("Change Notice"), provided that any
and all such changes shall be subject to Contractor's written consent. Each
Change Notice may specify changes to the Software Contractor is to provide
hereunder and the manner in which Contractor is to provide the Software, If any
Change Notice causes an increase or decrease in the price or the time required
for performance under this Agreement, an equitable adjustment jointly agreed
upon by City and Contractor shall be made and the Agreement shall be modified
in writing accordingly.
(b) Change Notices issued under this Agreement must be accepted or rejected in
writing by Contractor within ten (10) days of Contractors receipt of its issuance.
Notwithstanding as may be otherwise provided here in, if for any reason
Contractor should fail to timely accept or reject a Change Notice in writing, such
Change Notice shall be deemed accepted.
13. Liquidated Damages for Contractors Unexcused, Untimely Performance

Contractors failure to complete the Work within the time allowed will result in the
City sustaining damages and the assessment by City of Liquidated Damages.
(a) Excusable Delays (Force Majeure)
If Contractor or City experiences an Excusable Delay Event, Contractor or City
shall, within ten (10) days after first becoming aware of each such event, give
written notice of the delay to the other party and describe any impact the
Excusable Delay may have upon the Schedule. If the foregoing Notice(s) are
issued, or in the absence thereof from the City, then Contractor shall be entitled
to a day for day extension to the Schedule corresponding to the number of days
of delay directly caused by the Excusable Delay Event.
b) Schedule of Liquidated Damages.
City and Contractor recognize that time is of the essence in the performance of
this Agreement and that City will suffer financial loss in the form of contract
administration expenses (including project management and consultancy

expenses), delay and loss of public use, if Contractor does not complete its
Services and the Deliverables associated therewith within the respective times
specified in this Agreement and in the SOW, plus any extensions that are
allowed in accordance with this Agreement. Contractor and City agree that
because of the nature of the Services as provided by this Agreement, it would be
impractical or extremely difficult to fix the amount of actual damages incurred by
City because of the delay in completion or timely delivery of the Services.
Accordingly, City and Contractor agree that Contractor shall pay City the
following liquidated damages measures:
(i) Deliverables: $500.00 for each calendar day that expires after the time
specified in the Scope of Work for Contractor to provide and for City to
accept the Deliverables specified in the SOW.
(ii) Milestones: $1,000.00 for each calendar day that expires after the time
specified in this Agreement for Contractor to complete the Milestone set
forth in this Agreement and to complete all of the Services, excluding all
inexcusable delay events
14. Limitation on Liability

(a) Either party's liability to the other party for any and all liabilities, claims or
damages arising out of or relating to this Agreement, howsoever caused and
regardless of the legal theory asserted, including breach of contract or warranty,
tort, strict liability, statutory liability or otherwise, shall not, in the aggregate,
exceed $4Million or the total value of this Agreement, whichever is greater.
(b) In no event shall either party be liable to the other for any punitive, exemplary,
special, indirect, incidental or consequential damages (including, but not limited
to, lost profits, lost business opportunities, loss of use or equipment down time,
and loss of or corruption to data) arising out of or relating to this Agreement,
regardless of the legal theory under which such damages are sought, and even if
the parties have been advised of the possibility of such damages or loss.
(c) This limitation of liability shall not apply to all actions, demands, or claims by any
third party for death, bodily injury, damage to tangible property in connection with
or arising under this Agreement, nor to any intentional misconduct, recklessness,
or gross negligence or to Contractors Confidentiality (Section 10) and
indemnification (Section 16) obligations as set forth in this Agreement.
15. Performance Bond

Prior to this Agreement being effective and binding on the City, Contractor shall
file with City Clerk and with the City representative to whom Notices should be
sent as is specified below in Section [INSERT] (Notices) a Corporate surety
bond, in the form of a Performance Bond, in the penal sum of 100% of the total
contract amount of this Agreement to guarantee both faithful performance of

Contractors Services and a source of revenue for the City to complete the
Services under this Agreement should Contractor default or become insolvent.
Citys representative shall attach a copy of the Bond to this Agreement as Exhibit
4. Contractor must keep the Performance Bond current for the duration of this
Project.
16. Indemnification
(a) General Indemnification. Contractor shall indemnify, hold harmless, and (at
Citys request with Counsel acceptable to City), defend City, its Council
members, directors, officers, employees, agents, servants, and independent
contractors (each of which persons and entities are collectively referred to herein
as Indemnitees) from any and all actions, causes of actions, claims, injuries
(including, without limitation, injury to or death of an employee of Contractor or
any of its structures), liabilities (of every kind, nature and description), losses,
demands, debts, liens, obligations, judgments, administrative fines, damages,
(incidental or consequential) costs, expenses, and attorneys fees (collectively
referred to herein as Actions) caused by or arising out of:
(1) any grossly negligent (passive or active) or willful acts or omissions in the
course of performance by Contractor under this Agreement,
(2) any claim for personal injury (including death) or property damage to the
extent based on the strict liability or caused by any negligent act, error or
omission of Contractor;
(b) Proprietary Rights Indemnity. Contractor shall indemnify, defend, save and hold
harmless Indemnitees from any and all Actions arising out of claims that the
Software, infringes upon or violates the Intellectual Property Rights of others. If
the Software will become the subject of an Action or claim of infringement or
violation of the Intellectual Property Rights of a third party, City, at its option shall
require Contractor, at Contractors sole expense to: (1) procure for City the right
to continue using the Software; or (2) replace or modify the Software so that no
infringement or other violation of Intellectual Property Rights occurs, if City
determines that: (A) such replaced or modified Software will operate in all
material respects in conformity with the then-current specifications for the
Software; and (B) Citys use of the Software is not impaired thereby.
Contractors obligations under this Agreement will continue uninterrupted with
respect to the replaced or modified Software as if it were the original Software.
(c) For the purposes of the indemnification obligations set forth herein, the term
Contractor includes, without limitation, Contractor, its officers, directors,
employees, representatives, agents, servants, sub consultants, and
subcontractors.
(d) Contractor acknowledges and agrees that it has an immediate and independent
obligation to indemnify and defend Indemnitees from any Action which potentially
falls within this indemnification provision, which obligation shall arise at the time
an Action is tendered to Contractor by City and continues at all times thereafter,

without regard to any alleged or actual contributory negligence of any
Indemnitee. Notwithstanding anything to the contrary contained herein,
Contractors liability under this Agreement shall not apply to any Action arising
from the sole negligence, active negligence or willful misconduct of an
Indemnitee.
(e) City shall give Contractor prompt written notice of any Action and shall fully
cooperate with Contractor in the defense and all related settlement negotiations
to the extent that cooperation does not conflict with Citys interests.
Notwithstanding the foregoing, City shall have the right, if Contractor fails or
refuses to defend City with Counsel acceptable to City, to engage its own
counsel for the purposes of participating in the defense. In addition, City shall
have the right to withhold payments due Contractor in the amount of reasonable
defense costs actually incurred. In no event shall Contractor agree to the
settlement of any claim described herein without the prior written consent of City.
(f) All of Contractors indemnification obligations hereunder are intended to apply to
the fullest extent permitted by law (including, without limitation, California Civil
Code Section 2782) and shall survive the expiration or sooner termination of this
Agreement.
(g) Contractors indemnification obligations hereunder shall not be limited by the
Citys insurance requirements contained in Schedule B hereof, or by any other
provision of this Agreement.
17. Termination
(a) Termination for Breach. If Contractor breaches any material obligation under this
Agreement and fails to cure the breach within 30 days of receipt of written notice
from City of said breach, City may terminate the Agreement and, at its option: (i)
subject to the Limitation on Liability (Section 14), recover all direct damages it
incurs as a result of Contractors breach; (ii) require that Contractor repay City all
monies City has paid Contractor under this Agreement or (iii) retain the portion
of Contractors Deliverables that the City has accepted and paid Contractor for
and complete performance of the Agreement with another vendor. In the event
City elects to complete performance of the Agreement with another vendor,
Contractor shall remain liable for any increase in costs to City of completing the
Agreement in excess of the price City would have paid Contractor for completing
the Agreement.
(b) Contractor may terminate this Agreement if City breaches a material provision of
the Agreement and does not cure the breach within 30 days of written notice
from Contractor of said breach. In such event, Contractor will be entitled to
payment for Deliverables which City has accepted in accordance with the Testing
and Acceptance provisions of this Agreement.
(c) Bankruptcy. Either party may immediately terminate this Agreement if (i) the
other party files a petition for bankruptcy or has filed against it an involuntary
petition for bankruptcy which is not dismissed within 60 days of its filing, (ii) a

court has appointed a receiver, trustee, liquidator or custodian of it or of all or a
substantial part of the other partys property, (iii) the other party becomes unable,
or admits in writing its inability, to pay its debts generally as they mature, or (iv)
the other party makes a general assignment for the benefit of its or any of its
creditors.
(d) Termination for Convenience by City. City may terminate this Agreement for any
reason at any time upon not less than sixty (60) days' prior written notice to
Contractor. After the date of such termination notice, Contractor shall not perform
any further services or incur any further costs claimed to be reimbursable under
this Agreement, any Purchase Order, Change Order, or Change Notice without
the express prior written approval of City. As of the date of termination, City shall
pay to Contractor all undisputed amounts then due and payable under this
Agreement.
(e) Transition Services after termination. In connection with the expiration or other
termination of this Agreement or the expiration of this Agreement, Contractor
may provide transition services as requested by City. Such transition services
shall be subject to the pricing provided in this Agreement or any amendment
thereto.
18. DISPUTE RESOLUTION

a. If dispute or disagreement among the Parties arises with respect to either Partys
performance of its obligations hereunder, or any provision of or interpretation of
the Agreement, the Parties agree in good faith to attempt to resolve such dispute
or disagreement (a Dispute) prior to submitting the Dispute to mediation,
arbitration or litigation in accordance with this Section 18. Such resolution efforts
shall involve the City Administrator of the City of Oakland and an executive
officer of Contractor, together with such other persons as may be designated by
either Party.
b Any Party may commence said resolution efforts by giving notice, in writing, to
any other Party. Such notice shall include at least a description of the Dispute
and any remedial action that the Party commencing the resolution procedure
asserts would resolve the Dispute. Upon receiving such notice, the Party against
whom the Dispute is brought shall respond in writing within five (5) Business
Days. The Parties shall then meet and confer in a good faith attempt to resolve
the Dispute.
c If the Dispute has not been resolved within five (5) Business Days after the
Subsection 18.b. notice is given, and unless the Party initiating the Dispute does
not wish to pursue its rights relating to such Dispute or desires to continue the
Pre-Mediation Dispute Resolution, then such Dispute will be automatically
submitted to mediation. The mediation will be conducted in Alameda County by
a single mediator selected by the Parties to the Dispute by mutual agreement or
by the use of the Commercial Arbitration Rules of the American Arbitration

Association for selecting an Arbitrator [AAA RULES] The Parties to the Dispute
shall evenly share the fees and costs of the mediator. The mediator shall have
twenty (20) Business Days from the submission to mediation to attempt to
resolve such Dispute. If the Dispute is not resolved within that time period, the
parties will be entitled to pursue such matter by demanding arbitration under the
AAA RULES or instituting litigation.
19. Commencement, Completion and Close-out
It shall be the responsibility of the Contractor to coordinate and schedule the work
to be performed so that commencement and completion take place in accordance
with the provisions of this Agreement.
Any time extension granted to Contractor to enable Contractor to complete the work
must be in writing and shall not constitute a waiver of rights the City may have
under this Agreement.
Should the Contractor not complete the work by the scheduled date or by an
extended date, the City shall be released from all of its obligations under this
Agreement.
Within thirty (30) days of completion of the performance under this Agreement,
Contractor shall make a determination of any and all final costs due under this
Agreement and shall submit a requisition for such final and complete payment
(including without limitations any and all claims relating to or arising from this
Agreement) to the City. Failure of the Contractor to timely submit a complete and
accurate requisition for final payment shall relieve the City of any further obligations
under this Agreement, including without limitation any obligation for payment of
work performed or payment of claims by Contractor.
20. Bankruptcy.
All rights and licenses granted to City pursuant to this Agreement are, and shall
be deemed to be, for purposes of Section 265(n) of the U.S. Bankruptcy Code,
licenses of rights to intellectual property as defined under Section 101 of the
U.S. Bankruptcy Code. In a bankruptcy or insolvency proceeding involving
Contractor, the parties agree that City, as licensee of such rights, shall retain and
fully exercise all of its rights and elections under the U.S. Bankruptcy Code, and
the provisions thereof shall apply notwithstanding conflict of law principles. The
parties further agree that, in the event of the commencement of a bankruptcy or
insolvency proceeding by or against Contractor under the U.S. Bankruptcy Code,
City shall be entitled to a complete duplicate of any such intellectual property,
including the source code for Contractors Licensed Software which Contractor
has placed in escrow as required under this Agreement and all embodiments of
such intellectual property, to which City would otherwise be entitled under this
Agreement, and the same, if not already in Citys possession, shall be promptly
delivered to City (a) upon any such commencement of a bankruptcy proceeding
upon written request therefore by City, unless Contractor elects to continue to
perform all of its obligations under this Agreement, or (b) if not delivered under

(a) above, upon rejection of this Agreement by or on behalf of Contractor upon
written request therefore by City. If, in a bankruptcy or insolvency proceeding
involving Contractor, the provisions of the U.S. Bankruptcy Code referenced
above are determined not to apply, City shall nevertheless be entitled to no less
than the protection offered by the provisions of the U.S. Bankruptcy Code with
respect to its entitlement to and rights to the use and possession of all intellectual
property to which City has been granted rights under this Agreement
notwithstanding the bankruptcy or insolvency of Contractor.
21. Assignment
Contractor shall not assign or otherwise transfer any rights, duties, obligations or
interest in this Agreement or arising hereunder to any person, persons, entity or
entities whatsoever without the prior written consent of the City and any attempt to
assign or transfer without such prior written consent shall be void. Consent to any
single assignment or transfer shall not constitute consent to any further assignment
or transfer. In the event that Contractor assigns this Agreement in compliance with
this provision, this Agreement and all of its provisions shall inure to the benefit of
and become binding upon the parties and the successors and permitted assigns
of the respective parties.
22. Agents/Brokers
Contractor warrants that Contractor has not employed or retained any
subcontractor, agent, company or person other than bona fide, full-time
employees of Contractor working solely for Contractor, to solicit or secure this
Agreement, and that Contractor has not paid or agreed to pay any subcontractor,
agent, company or persons other than bona fide employees any fee,
commission, percentage, gifts or any other consideration, contingent upon or
resulting from the award of this Agreement. For breach or violation of this
warranty, the City shall have the right to rescind this Agreement without liability
or, in its discretion, to deduct from the Agreement price or consideration, or
otherwise recover, the full amount of such fee, commission, percentage or gift.
23. Publicity
Any publicity generated by Contractor for the project funded pursuant to this
Agreement, during the term of this Agreement or for one year thereafter, will make
reference to the contribution of the City of Oakland in making the project possible.
The words City of Oakland will be explicitly stated in all pieces of publicity,
including but not limited to flyers, press releases, posters, brochures, public service
announcements, interviews and newspaper articles.

City staff will be available whenever possible at the request of Contractor to assist
Contractor in generating publicity for the project funded pursuant to this Agreement.
Contractor further agrees to cooperate with authorized City officials and staff in any City-
generated publicity or promotional activities undertaken with respect to this project.
24. Conflict of Interest

(a) Contractor
The following protections against conflict of interest will be upheld:
(1) Contractor certifies that no member of, or delegate to the Congress of
the United States shall be permitted to share or take part in this
Agreement or in any benefit arising there from.
(2) Contractor certifies that no member, officer, or employee of the City
or its designees or agents, and no other public official of the City who
exercises any functions or responsibilities with respect to the
programs or projects covered by this Agreement, shall have any
interest, direct or indirect in this Agreement, or in its proceeds during
his/her tenure or for one year thereafter.
(3) Contractor shall immediately notify the City of any real or possible
conflict of interest between work performed for the City and for other
clients served by Contractor.
(4) Contractor warrants and represents, to the best of its present
knowledge, that no public official or employee of City who has been
involved in the making of this Agreement, or who is a member of a
City board or commission which has been involved in the making of
this Agreement whether in an advisory or decision-making capacity,
has or will receive a direct or indirect financial interest in this
Agreement in violation of the rules contained in California
Government Code Section 1090 et seq., pertaining to conflicts of
interest in public contracting. Contractor shall exercise due
diligence to ensure that no such official will receive such an
interest.
(5) Contractor further warrants and represents, to the best of its
present knowledge and excepting any written disclosures as to
these matter already made by Contractor to City, that (1) no public
official of City who has participated in decision-making concerning
this Agreement or has used his or her official position to influence
decisions regarding this Agreement, has an economic interest in
Contractor or this Agreement, and (2) this Agreement will not have
a direct or indirect financial effect on said official, the officials
spouse or dependent children, or any of the officials economic
interests. For purposes of this paragraph, an official is deemed to

have an economic interest in any (a) for-profit business entity in
which the official has a direct or indirect investment worth $2,000 or
more, (b) any real property in which the official has a direct or
indirect interest worth $2,000 or more, (c) any for-profit business
entity in which the official is a director, officer, partner, trustee,
employee or manager, or (d) any source of income or donors of
gifts to the official (including nonprofit entities) if the income totaled
more than $500 in the previous 12 months, or value of the gift
totaled more than $350 the previous year. Contractor agrees to
promptly disclose to City in writing any information it may receive
concerning any such potential conflict of interest. Contractors
attention is directed to the conflict of interest rules applicable to
governmental decision-making contained in the Political Reform Act
(California Government Code Section 87100 et seq.) and its
implementing regulations (California Code of Regulations, Title 2,
Section 18700 et seq.).
(6) Contractor understands that in some cases Contractor or persons
associated with Contractor may be deemed a City officer or
public official for purposes of the conflict of interest provisions of
Government Code Section 1090 and/or the Political Reform Act.
Contractor further understands that, as a public officer or official,
Contractor or persons associated with Contractor may be
disqualified from future City contracts to the extent that Contractor
is involved in any aspect of the making of that future contract
(including preparing plans and specifications or performing design
work or feasibility studies for that contract) through its work under
this Agreement.
(7) Contractor shall incorporate or cause to be incorporated into all
subcontracts for work to be performed under this Agreement a
provision governing conflict of interest in substantially the same
form set forth herein.
(b) No Waiver
Nothing herein is intended to waive any applicable federal, state or local
conflict of interest law or regulation
(c) Remedies and Sanctions
In addition to the rights and remedies otherwise available to the City under
this Agreement and under federal, state and local law, Contractor
understands and agrees that, if the City reasonably determines that
Contractor has failed to make a good faith effort to avoid an improper
conflict of interest situation or is responsible for the conflict situation, the
City may (1) suspend payments under this Agreement, (2) terminate this
Agreement, (3) require reimbursement by Contractor to the City of any
amounts disbursed under this Agreement. In addition, the City may

suspend payments or terminate this Agreement whether or not Contractor
is responsible for the conflict of interest situation.
25. Validity of Contracts

The Oakland City Council must approve all Agreements greater than $15,000. This
Agreement shall not be binding or of any force or effect until signed by the City
Manager or his or her designee and approved as to form and legality by the City
Attorney or his or her designee.
26. Governing Law

This Agreement shall be governed and construed in accordance with the laws of
the State of California, without reference to its conflicts of laws principles. Any
action or proceeding to enforce the terms of this Agreement shall be brought in
the courts of Alameda County, Oakland, California and each party agrees to
waive any objections to personal jurisdiction and venue in the courts of Alameda
County, Oakland, California.
27. Headings
Headings and captions used to introduce Sections and paragraphs of this
Agreement are for convenience, only, and have no legal significance.
28. Construction
(a) Except as provided in Section 15 (b) above, acceptance or acquiescence

in a prior course of dealing or a course of performance rendered under
this Agreement or under any Change Order, or Change Notice, shall not
be relevant in determining the meaning of this Agreement even though the
accepting or acquiescing party has knowledge of the nature of the
performance and opportunity for objection.
(b) The language in all parts of this Agreement and any Purchase Order,
Change Order, or Change Notice, shall in all cases be construed in whole,
according to its fair meaning, and not strictly for or against, either
Contractor, City regardless of the drafter of such part.
29. Waiver
No covenant, term, or condition of this Agreement may be waived except by written
consent of the party against whom the waiver is claimed and the waiver of any term,
covenant or condition of this Agreement shall not be deemed a waiver of any

subsequent breach of the same or any other term, covenant or condition of this
Agreement.
30. Independent Contractor

(a) Rights and Responsibilities
It is expressly agreed that in the performance of the services necessary to
carry out this Agreement, Contractor shall be, and is, an independent
contractor, and is not an employee of the City. Contractor acknowledges
and agrees that all of Contractors employees and subcontractors are
under the sole direction and control of Contractor and City shall have no
authority over or responsibility for such employees and subcontractors of
Contractor. Contractor has and shall retain the right to exercise sole
direction and supervision of the services, and full control over the
employment, direction, compensation and discharge of all persons
assisting Contractor in the performance of Contractors services
hereunder. Contractor shall be solely responsible for all matters relating to
the payment of his/her employees, including compliance with social
security, withholding and all other regulations governing such matters, and
shall be solely responsible for Contractor's own acts and those of
Contractors subordinates and employees. Contractor will determine the
method, details and means of performing the services described in
EXHIBIT 1
(b) Contractors Qualifications
Contractor represents that Contractor has the qualifications and skills
necessary to perform the services under this Agreement in a competent and
professional manner without the advice or direction of the City. This means
Contractor is able to fulfill the requirements of this Agreement. Failure to
perform all of the services required under this Agreement will constitute a
material breach of the Agreement and may be cause for termination of the
Agreement. Contractor has complete and sole discretion for the manner in
which the work under this Agreement is performed. Contractor shall
complete and submit to City, Schedule M-Independent Contractor
Questionnaire, prior to the execution of this Agreement.
(c) Payment of Income Taxes
Contractor is responsible for paying, when due, all income taxes, including
estimated taxes, incurred as a result of the compensation paid by the City to
Contractor for services under this Agreement. On request, Contractor will
provide the City with proof of timely payment. Contractor agrees to
indemnify the City for any claims, costs, losses, fees, penalties, interest or
damages suffered by the City resulting from Contractors failure to comply
with this provision.

(d) Non-Exclusive Relationship
Contractor may perform services for, and contract with, as many additional
clients, persons or companies as Contractor, in his or her sole discretion,
sees fit.
(e) Tools, Materials and Equipment
Contractor will supply all tools, except those tools, materials, equipment
specified herein, if any, required to perform the services under this
Agreement.
(f) Cooperation of the City
The City agrees to comply with all reasonable requests of Contractor
necessary to the performance of Contractors duties under this Agreement.
(g) Extra Work
Contractor will do no extra work under this Agreement without first receiving
prior written authorization from the City.
31. Attorneys Fees

If either party commences an action or proceeding to determine or enforce its
rights hereunder, the prevailing party shall be entitled to recover from the losing
party all expenses reasonably incurred, including court costs, reasonable
attorneys' fees and costs of suit as determined by the court.
32. Counterparts
This Agreement may be executed in any number of identical counterparts, any
set of which signed by both parties shall be deemed to constitute a complete,
executed original for all purposes.
33. Remedies Cumulative

The rights and remedies of City provided in this Agreement shall not be exclusive
and are in addition to any other rights and remedies provided by law, including
the California Uniform Commercial Code.
34. Severability/Partial Invalidity

If any term or provision of this Agreement, or the application of any term or
provision of this Agreement to a particular situation, shall be finally found to be
void, invalid, illegal or unenforceable by a court of competent jurisdiction, then
notwithstanding such determination, such term or provision shall remain in force
and effect to the extent allowed by such ruling and all other terms and provisions
of this Agreement or the application of this Agreement to other situation shall
remain in full force and effect.

Notwithstanding the foregoing, if any material term or provision of this Agreement
or the application of such material term or condition to a particular situation is
finally found to be void, invalid, illegal or unenforceable by a court of competent
jurisdiction, then the Parties hereto agree to work in good faith and fully
cooperate with each other to amend this Agreement to carry out its intent.
35. Access
Access to Citys premises by Contractor shall be subject to the reasonable
security and operational requirements of City. To the extent that Contractors
obligations under this Agreement or any Purchase Order, Change Order, or
Change Notice, require the performance of Services or Work by Contractor on
Citys property or property under City's control, Contractor agrees:
(i) to accept full responsibility for performing all Services or work in a safe
manner so as not to jeopardize the safety of City's personnel, property,
or members of the general public; and
(ii) to comply with and enforce all of City's regulations, policies, and
procedures including, without limitation, those with respect to security,
access, safety and fire protection, Citys policy against sexual
harassment, and all applicable state and municipal safety regulations,
building codes or ordinances.
36. Entire Agreement of the Parties

This Agreement supersedes any and all Agreements, either oral or written,
between the parties with respect to the rendering of services by Contractor for
the City and contains all of the representations, covenants and Agreements
between the parties with respect to the rendering of those services. Each party
to this Agreement acknowledges that no representations, inducements, promises
or Agreements, orally or otherwise, have been made by any party, or anyone
acting on behalf of any party, which are not contained in this Agreement, and that
no other Agreement, statement or promise not contained in this Agreement will
be valid or binding.
37. Modification
Any modification of this Agreement will be effective only if it is in a writing signed
by all parties to this Agreement.

38. Notices
If either party shall desire or be required to give notice to the other, such notice shall be
given in writing, via facsimile and concurrently by prepaid U.S. certified or registered
postage, addressed to recipient as follows:
(City of Oakland) _________________________

_________________________
_________________________
_________________________
cc: (name)
Deputy City Attorney
1 Frank Ogawa Plaza, 6th Fl.
Oakland, CA 94612
(Contractor) _________________________
_________________________
_________________________
_________________________
Any party to this Agreement may change the name or address of representatives
for purpose of this Notice paragraph by providing written notice to all other
parties ten (10) business days before the change is effective.
39. Right to Offset
All claims for money or to become due from City shall be subject to deduction or
offset by City from any monies due Contractor by reason of any claim or
counterclaim arising out of this Agreement or any Purchase Order, Change
Order, or Change Notice or any other transaction with Contractor. To the extent
that there are amounts due to the City and to a state or federal funding agency,
and the amount of the offset is insufficient to pay such amount in full, the amount
of the offset shall be prorated between the City and such state or federal funding
agency in proportion to the amounts due them.

40. No Third Party Beneficiary
This Agreement shall not be construed to be an agreement for the benefit of any
third Party or parties, and no third party or parties shall have any claim or right of
action under this Agreement
41. Survival
Sections (2, 7, 8, 9, 10, 14, 15, 17, 26 and 40) of this Agreement, along with any
other provisions which by their terms survive, shall survive the expiration or
termination of this Agreement.
42. Time is of the Essence

The Special Circumstances of this Agreement require Contractors timely
performance of its obligations under this Agreement. Therefore, time is of the
essence in the performance of this Agreement.
43. Authority
Each individual executing this Agreement or any Purchase Order, Change Order
or Change Notice, hereby represents and warrants that he or she has the full
power and authority to execute this Agreement or such Purchase Order, Change
Order or Change Notice, on behalf of the named party such individual purports to
bind.
SO AGREED:
City of Oakland, Contractor

a municipal corporation
_________________________________ ________________________________
(City Administrators Office) (Date) (Signature)
(Date)
_________________________________ _________________________________
(Department Head Signature) (Date) Business Tax Certificate No.

Approved as to form and legality:

___________________________________
Resolution Number
____________________________________
(City Attorneys Office Signature) (Date)
END OF PROFESSIONAL SERVICES CONTRACT SAMPLE

Instructions to Respondents Regarding the Citys Proposed Contract
Exceptions to or waivers of the terms and conditions are not encouraged. However, if
respondents believe them necessary, the following procedure must be followed in all
such circumstances. Failure to comply with these procedures will disqualify the
submission.
Generally
A. All exceptions to or waivers of the terms and conditions taken must be
accompanied by a separate request, in writing, setting forth the grounds for the
requested exception or waiver.
B The written requests must accompany the proposal and are subject to the rules
for timely responses of proposals.
C. The City reserves the right to reject responses based upon a Respondents
exceptions to or requested waiver of the Citys terms and conditions.
Respondents attention is specifically directed to the following:
1. Contract Terms and Conditions
a. Performance Bond
The City of Oakland City Council requires a Performance Bond for all City
contracts to establish a source of revenue for completing the project in
question should a vendor become insolvent. The City Administrator has
the discretion to waive this requirement pursuant to a vendors request for
such waiver, in writing, which establishes to the City Administrators
satisfaction, that the vendor is sufficiently solvent such that the Bond is not
needed. The City Administrators decision as to whether or not to waive
the Bond requirement is final.
b. Liquidated Damages for Contractors Unexcused Untimely Performance
Where time is of the essence in the performance of the contract,
Liquidated Damages are required to incent the vendors timely
performance. Liquidated Damages are assessed only for the vendors
unexcused delays in meeting the agreed upon progress objectives for the
contract. Exceptions to this provision are rarely granted and must be
based upon an alternative that, in the Citys sole discretion, incents and
assures the timely performance of the contract. Exceptions not granted
will disqualify the proposal from further consideration.
2. Contract Compliance Provisions
The Citys Contract Compliance provisions have been established by the
Contract Compliance Department. All exceptions taken to those provisions will
require a written request to grant the exception and should be submitted to:

Deborah Lusk-Barnes
Manager, Contracts & Compliance, Office of the City Administrator
250 Frank Ogawa Plaza, Suite 3341
Oakland, Ca. 94612
(510) 238-6270 dbarnes@oaklandnet.com
The request for each exception taken must accompany the Respondents
submittal and must clearly set forth why the exception should be
granted. Contract Compliance will review each requested exception and has the
sole discretion to grant it or not. Exceptions not granted will disqualify the
proposal from further consideration.
3. City Schedules
The Citys Schedules have been established pursuant to City Council action, are
mandatory and must be completed without modification and submitted with your
proposal. Failure to do so will disqualify the proposal from further consideration.

Appendix F - Schedule Q Insurance Requirements
INSURANCE REQUIREMENTS
PROFESSIONAL AND SPECIALIZED SERVICES AGREEMENTS
(Revised 08/01/11)
a. General Liability, Automobile, Workers Compensation and Professional Liability
Consultant shall procure, prior to commencement of service, and keep in force for
the term of this contract, at Consultant's own cost and expense, the following
policies of insurance or certificates or binders as necessary to represent that
coverage as specified below is in place with companies doing business in California
and acceptable to the City. If requested, Consultant shall provide the City with
copies of all insurance policies. The insurance shall at a minimum include:
i. Commercial General Liability insurance shall cover bodily injury, property
damage and personal injury liability arising from premises operations,
independent Consultants, products-completed operations personal &
advertising injury and contractual liability. Coverage shall be at least as broad
as Insurance Services Office Commercial General Liability coverage
(occurrence Form CG 00 01)
A. Coverage afforded on behalf of the City, Councilmembers, directors,
officers, agents and employees and volunteers shall be primary
insurance. Any other insurance available to the City
Councilmembers, directors, officers, agents and employees and
volunteers under any other policies shall be excess insurance (over
the insurance required by this Agreement).
B. Limits of liability: Consultant shall maintain commercial general
liability (CGL) and, if necessary, commercial umbrella insurance
with a limit of not less than $2,000,000 each occurrence. If such
CGL insurance contains a general aggregate limit, either the
general aggregate limit shall apply separately to this
project/location or the general aggregate limit shall be twice the
required occurrence limit.
ii. Automobile Liability Insurance. Consultant shall maintain automobile
liability insurance for bodily injury and property damage liability with a limit of
not less than $1,000,000 each accident. Such insurance shall cover liability
arising out of any auto (including owned, hired, and non-owned autos).
Coverage shall be at least as broad as Insurance Services Office Form
Number CA 0001. .
Early Warning Intervention System Appendix F Page / 218

iii. Worker's Compensation insurance as required by the laws of the State of
California. Statutory coverage may include Employers Liability coverage with
limits not less than $1,000,000 each accident, $1,000,000 policy limit bodily
injury by disease, $1,000,000 each employee bodily injury by disease. The
Consultant certifies that he/she is aware of the provisions of section 3700 of the
California Labor Code, which requires every employer to provide Workers'
Compensation coverage, or to undertake self-insurance in accordance with the
provisions of that Code. The Consultant shall comply with the provisions of
section 3700 of the California Labor Code before commencing performance of
the work under this Agreement and thereafter as required by that code.
iv. Professional Liability/Errors and Omissions insurance appropriate to the
Consultants profession with limits not less than $2,000,000 each claim and
$2,000,000 aggregate. If the professional liability/errors and omissions
insurance is written on a claims made form:
a. The retroactive date must be shown and must be before the date of the
contract or the beginning of work.
b. Insurance must be maintained and evidence of insurance must be
provided for at least three (3) years after completion of the contract work.
c. If coverage is cancelled or non-renewed and not replaced with another
claims made policy form with a retroactive date prior to the contract
effective date, the Consultant must purchase extended period coverage
for a minimum of three (3) years after completion of work.
b. Terms Conditions and Endorsements
The aforementioned insurance shall be endorsed and have all the following
conditions:
i. Insured Status (Additional Insured): Consultant shall provide insured status
using ISO endorsement CG 20 10 or its equivalent naming the City of
Oakland, its Councilmembers, directors, officers, agents and employees and
volunteers as insureds in the Comprehensive Commercial General Liability
policy. If Consultant submits the ACORD Insurance Certificate, the insured
status endorsement must be set forth on a CG 20 10 (or equivalent). A
STATEMENT OF ADDITIONAL INSURED STATUS ON THE ACORD
INSURANCE CERTIFICATE FORM IS INSUFFICIENT AND WILL BE
REJECTED AS PROOF OF MEETING THIS REQUIREMENT; and
ii. Cancellation Notice: 30-day prior written notice of termination or material
change in coverage and 10-day prior written notice of cancellation for non-
payment;
iii. The Workers Compensation policy shall be endorsed with a waiver of
subrogation in favor of the City for all work performed by the Consultant, its
employees, agents and sub consultants.

iv. Certificate holder is to be the same person and address as indicated in the
Notices section of this Agreement; and
v. Insurer shall carry insurance from admitted companies with a Best Rating of A
VII or better.
c. Replacement of Coverage
In the case of the breach of any of the insurance provisions of this Agreement, the
City may, at the City's option, take out and maintain at the expense of Consultant,
such insurance in the name of Consultant as is required pursuant to this
Agreement, and may deduct the cost of taking out and maintaining such insurance
from any sums which may be found or become due to Consultant under this
Agreement.
d. Insurance Interpretation
All endorsements, certificates, forms, coverage and limits of liability referred to
herein shall have the meaning given such terms by the Insurance Services Office
as of the date of this Agreement.
e. Proof of Insurance
Consultant will be required to provide proof of all insurance required for the work
prior to execution of the contract, including copies of Consultants insurance
policies if and when requested. Failure to provide the insurance proof requested
or failure to do so in a timely manner shall constitute ground for rescission of the
contract award.
f. Sub consultants
Should the Consultant subcontract out the work required under this agreement,
they shall include all sub consultants as insureds under its policies or shall
maintain separate certificates and endorsements for each sub consultant. As an
alternative, the Consultant may require all sub consultants to provide at their own
expense evidence of all the required coverages listed in this Schedule. If this
option is exercised, both the City of Oakland and the Consultant shall be named
as additional insured under the sub consultants General Liability policy. All
coverages for sub consultants shall be subject to all the requirements stated
herein. The City reserves the right to perform an insurance audit during the
course of the project to verify compliance with requirements.
g. Deductibles and Self-Insured Retentions
Any deductible or self-insured retention must be declared to and approved by the
City. At the option of the City, either: the insurer shall reduce or eliminate such
deductible or self-insured retentions as respects the City, its Councilmembers,
directors, officers, agents, employees and volunteers; or the Consultant shall
provide a financial guarantee satisfactory to the City guaranteeing payment of
losses and related investigations, claim administration and defense expenses.
h. Waiver of Subrogation

Consultant waives all rights against the City of Oakland and its Councilmembers,
officers, directors and employees for recovery of damages to the extent these
damages are covered by the forms of insurance coverage required above.
i. Evaluation of Adequacy of Coverage
The City of Oakland maintains the rights to modify, delete, alter or change these
requirements, with reasonable notice, upon not less than ninety (90) days prior
written notice.
j. Higher Limits of Insurance
If the Consultant maintains higher limits than the minimums shown above, The City
shall be entitled to coverage for the higher limits maintained by the Consultant.
END OF SCHEDULE Q INSURANCE REQUIREMENT

Appendix G - Schedule E Project Consultant Team Listing
Early Warning Intervention System Appendix G Page / 222

Early Warning Intervention System Appendix G Page / 223

Appendix H - Schedule O Campaign Contributions
CONTRACTOR ACKNOWLEDGEMENT OF CITY OF OAKLAND CAMPAIGN
CONTRIBUTION LIMITS
FOR CONSTRUCTION, PROFESSIONAL SERVICE & PROCUREMENT CONTRACTS
To be completed by City Representative prior to distribution to Contractor
City Representative _________________________ Phone _______________ Project

Spec No. ________
Department ________________________Contract/Proposal Name

______________________________________
This is an ___ Original ___ Revised form (check one). If Original, complete all that
applies. If Revised, complete Contractor name and any changed data.
Contractor Name ________________________________________________ Phone

_____-_____-________
Street Address City ________________, State _____

________________________________ Zip _______
Type of Submission (check one) ___ Bid ___Proposal ___ Qualification ___ Amendment
Majority Owner (if any). A majority owner is a person or entity who owns more than
50% of the contracting firm or entity.
Individual or Business Name _______________________________________ Phone

_____-_____-________
Street Address City ________________, State _____

________________________________ Zip _______
The undersigned Contractor's Representative acknowledges by his or her

signature the following:
The Oakland Campaign Reform Act limits campaign contributions and prohibits
contributions from contractors doing business with the City of Oakland and the Oakland
Redevelopment Agency during specified time periods. Violators are subject to civil and
criminal penalties.
Early Warning Intervention System Appendix H Page / 224

I have read Oakland Municipal Code Chapter 3.12, including section 3.12.140, the
contractor provisions of the Oakland Campaign Reform Act and certify that I/we have not
knowingly, nor will I /we make contributions during the period specified in the Act.
I understand that the contribution restrictions also apply to entities/persons affiliated with
the contractor as indicated in the Oakland Municipal Code Chapter 3.12.080.
If there are any changes to the information on this form during the contribution-restricted
time period, I will file an amended form with the City of Oakland.
Signature Date
Print Name of Signer Position
To be Completed by City of Oakland after completion of the form
By
________________________________
Date Received by City: ____/____/____ _____
Date Entered on Contractor Database: ____/____/____ By

_______________________________________

Appendix I - Pricing
Bidders must use this Pricing Form, or a similar representation of the same information
to submit their pricing for the Services and Materials described in the RFP.
Vendors should propose in U.S. funds.
1. Solution and Implementation Costs

Solution and Implementation Proposed Costs
1. Requirements Confirmation and Solution Design (Fixed Price) $
(Includes project management plan (development tasks),
requirements and design plan, solution design and solution
design signoff.)
2. Solution Development Fees (Fixed Price) $
(Includes development of the overall solution up to the
migration into the Projects test environment
3. Implementation Fees (Fixed Price) $
(Includes release management plan, technical architecture,
development plan, functional complete, production
certification, production sign-off.)
4. Data Exchange Fees (Fixed Price) $
(includes data exchange requirements and design)
5. Data Cleansing, Migration and Analysis Fees (Fixed Price) $
(includes data cleansing, migration and analysis strategy and
plan)
6. Testing Fees (Fixed Price) $
(includes testing plan)
7. Training Fees Fees (Fixed Price) $
(Includes Training plan and training delivery)
8. Travel and Accommodation Expense Costs (estimate) $
(Actual costs must not exceed estimate by more than 10% )
9. Project Management for Development Activities (Fixed Price) $
(e.g. any other costs not listed above; details to support the
cost must be provided)
10. 12 Week onsite support costs after go-live $
11. Other Costs (Fixed Price) $
(e.g. any other costs not listed above; details to support the
cost must be provided)
TOTAL SOLUTION AND IMPLMENTATION COSTS $

2. Solution Maintenance and Support Costs
Solution Maintenance and Support Costs Proposed Costs
Application Maintenance Support (Fixed Price)
(Including but not limited to all Services described in RFP
Appendix F Implementation Requirements, commencing after
the Warranty Period has expired.)
During Option Year One $
During Option Year Two $
During Option Year Three $
During Option Year Four $
During Option Year Five $
TOTAL SOLUTION MAINTENANCE AND SUPPORT COSTS $
(For evaluation purposed, the sum of all 5 option years will be
used to calculated the total bid price)
The City may also choose an alternative approach to Application Maintenance. Please
complete the rate card below that may be used for services after the warranty period, at
the Citys discretion.
3. Hourly Rates for Vendor Team

Resources Rate
Project Manager $
Solution Architect $
Development Lead $
Developer $
Technical Analyst $
Business Analyst $
Test Analyst $

Appendix J - Support
As used in this RFP, the Warranty Period means the period commencing upon
issuance of the Citys Notice of Final System Acceptance and continuing for 84 days (12
Weeks) thereafter.
Contractor hereby represents, warrants and covenants to the City that, for the Warranty
Period:
The System shall perform fully in accordance with the requirements provided in
this RFP to this Agreement or any Change Orders in respect thereof.
The Contractor will provide, at its own cost and expense, all corrective measures to
remedy all deficiencies as defined below.
Corrective Measures. The Citys Project Manager shall notify the Contractors Project
Manager in writing or, if not practicable, orally of any deficiency. Upon the earlier of
(a) notice (orally or in writing) from the City, or (b) Contractors discovery of such
deficiency, the Contractor shall promptly investigate the cause of the problem and
commence corrective measures to remedy any deficiency, and shall remedy such
deficiency in accordance with the Service and Severity Levels set forth in this Appendix.
Deficiencies. The term deficiency shall mean and include, as applicable to the IPAS2
and Source Systems provided by or on behalf of the Contractor to the City: any
malfunction, error, or defect in the performance of IPAS2 as defined in the RFP
Agreement, including the provision of negligent workmanship, which results in the
System, in whole or in part, not performing in accordance with the provisions of this
Agreement.
This shall not include any defect, error, omission or deviation to the System caused by
actions of the City without the certification of the Contractor, including modification of
the application software, altering systems environment, modifications to legacy systems
or changes to the City business processes. In this context, Certification means that the
Contractor has reviewed and accepted such modifications to the System. Contractor
will provide Certification as part of the Maintenance and Support provisions of this
Agreement.
Such deficiency shall first be determined by the City Project Manager in consultation
with the Contractor, in the Project Managers reasonable judgment made in good faith.
If the Contractor subsequently disputes the City Project Managers determination, the
issue will be resolved in accordance with the Dispute Resolution Procedure as defined
in this Appendix
Approval. No deficiency shall be deemed remedied until all necessary remedial action
has been completed and approved in writing by the City Project Manager.
Services. The Contractor will provide telephone support for initial problem diagnosis 24
hours a day, seven days a week. The Contractor will provide remediation coverage for
IPAS2 and Source Systems for Severity Levels 1 or 2 as defined below 24 hours a day,

seven days a week. For other system components and Severity Levels 3 and 4,
Contractor will provide remediation coverage for eight hours a day on standard business
days.
Severity Levels
For the purpose of this RFP, Severity Levels (1 through 4) are defined as:
1. Critical: System feature or function does not work or performance is
unacceptable and a significant part of the user population cannot perform their
duties.
2. Serious: System feature or function does not work or performance is
unacceptable and there is no known or established work-around that permits the
System to work during remediation.
3. Moderate: System feature or function does not work or performance is
unacceptable and there is a known or established work-around that permits the
System to work during remediation.
4. Minor: No disruption of operation or performance.
Service Levels for Deficiency Remediation for IPAS2 and Source Systems
Severity Telephone Remediation Resolution Target

Level Call Back Initiation
Continual work, including the
Initiate reassignment of staff, to bring
Events with Two hour remediation resolution as quickly as possible.
severity Response within four hours Apply immediate system patch.
levels 1 and of Call Back.
2 24 X 7 Incorporate permanent fix into the
24 X 7 next scheduled build (release within
30 days).
Initiate
Four Hours Resolution during regular business
remediation
Events with within day work hours.
within one
severity standard
business day of Incorporate fix into the next
level 3 business day
Call Back scheduled build (release within 30
8X5 days).
8X5
Initiate
One business remediation Resolution during regular business
Events with
day within Release day work hours. Incorporate fix into
severity
Schedule the next scheduled build (release
level 4 8X5 within 30 days).
8X5


PRR 19667 - IPAS2 RFP For The Oakland Police Department IPAS System Replacement PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PRR 19667 - IPAS2 RFP For The Oakland Police Department IPAS System Replacement PDF

Enviado por

Direitos autorais:

Formatos disponíveis

CITY OF OAKLAND

OFFICE OF THE CITY ADMINISTRATOR

Request For Proposal (RFP)

Oakland Police Department

Office of the City Administrator,

DATE: December 17, 2013

Early Warning System Request for Proposal Page / i

Early Warning System Request for Proposal Page / ii

Early Warning System Request for Proposal Page / iii

Early Warning System Request for Proposal Page / iv

Early Warning System Request for Proposal Page / v

Early Warning System Request for Proposal Page / vi

Early Warning System Request for Proposal Page / vii

Early Warning System Request for Proposal Page / viii

Early Warning System Request for Proposal Page / ix

Early Warning System Request for Proposal Page / x

Early Warning System Request for Proposal Page / xi

Early Warning System Request for Proposal Page / xii

Early Warning System Request for Proposal Page / xiii

Early Warning System Request for Proposal Page / xiv

1.1 Scope of Services

Early Warning System Request for Proposal Page / 1

Early Warning System Request for Proposal Page / 2

1.2 Procurement Timeline

1.3 The Contract

1.4 Project Timeline

Early Warning System Request for Proposal Page / 3

Early Warning System Request for Proposal Page / 4

2.2 Current IPAS Solution

Early Warning System Request for Proposal Page / 5

150FOP City Internet

Figure 1: City of Oakland IPSS 2009 Network Overview

Early Warning System Request for Proposal Page / 6

Figure 2: I-PAS System Context

2.3.1 Data Context

Dimensions # Dimension Name Application/DB

Early Warning System Request for Proposal Page / 7

Early Warning System Request for Proposal Page / 8

Figure 3: IPAS System Overview

Early Warning System Request for Proposal Page / 9

Figure 4: Various Data Sources to the IPAS system

Figure 5: External Data Sources to the Personnel application (PDB

2.3.2 IPAS Data Model Screen

Early Warning System Request for Proposal Page / 10

Figure 6: Master Name Index in IPAS

2.3.3 IPAS Reports

2.3.4 Ad-Hoc Queries

2.3.5 IPAS Superviewer

Early Warning System Request for Proposal Page / 11

2.3.6 Outlier Identification

2.3.7 Threshold Reports

2.3.8 PAS Activity Reviews

2.4 IPAS Technical Descriptions

Early Warning System Request for Proposal Page / 12

2.4.2 Internal Affairs Database (IAD)

2.4.3 CER (Case Evaluation Report)

2.4.5 Canine Deployment

Early Warning System Request for Proposal Page / 13

2.4.6 Vehicle Pursuit

2.4.7 Personnel (PDB)

2.4.8 Training (TMS)

Early Warning System Request for Proposal Page / 14

2.4.10 Law Records Management System (LRMS)