• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Request For Proposal
 

Request For Proposal

on

  • 2,164 views

 

Statistics

Views

Total Views
2,164
Views on SlideShare
2,164
Embed Views
0

Actions

Likes
0
Downloads
24
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Request For Proposal Request For Proposal Document Transcript

    • Request for Proposal City of Eden Prairie 8080 Mitchell Road Eden Prairie, Minnesota 55344 May 15, 2008 The purpose this document is to set scope, requirements and expectations of potential system providers and to outline key evaluation criteria. This is a formal requirements
    • document for public issue and vendor response to aid the evaluation team in identifying vendors that the team will request to move forward to the vendor on-site demonstration. Table of Contents SECTION 1 – SUMMARY INFORMATION....................................................................................3 I. INTRODUCTION AND GENERAL INFORMATION ................................................................3 INTRODUCTION....................................................................................................................3 EDEN PRAIRIE GENERAL INFORMATION..........................................................................4 GENERAL REQUIREMENTS:...............................................................................................5 II. EXECUTIVE SUMMARY........................................................................................................7 PROJECT SCOPE:................................................................................................................7 INTERFACES:.......................................................................................................................7 PROJECT GOALS AND OBJECTIVES:................................................................................9 OPERATIONAL BUSINESS CASE:.....................................................................................12 KEY ASSUMPTIONS AND DIFFERENCES:.......................................................................15 ESTIMATED TIMEFRAME:..................................................................................................15 POLICE AND FIRE FUTURE SYSTEM...............................................................................16 .............................................................................................................................................16 PUBLIC SAFETY (POLICE AND FIRE) INTERFACE FLOWCHARTS................................16 CURRENT PAPER WORKFLOW FOR POLICE DEPARTMENT:.......................................17 SECTION 2 – GENERAL CONTRACTUAL AND LEGAL INFORMATION.................................18 GENERAL INFORMATION......................................................................................................18 PRE-PROPOSAL MEETING AND/OR SITE EVALUATION VISIT...........................................18 DEFINITIONS...........................................................................................................................19 OVERVIEW OF PROCESS .....................................................................................................22 SECTION 3 – VENDOR AND INFORMATIONAL ATTACHMENTS............................................34 ATTACHMENT A – GENERAL CONTRACT CONDITIONS....................................................35 ATTACHMENT B - VENDOR OFFER SIGNATURE AND CERTIFICATION FORM................49 ATTACHMENT C - VENDOR PROFILE AND EXECUTIVE SUMMARY..................................51 ATTACHMENT D – PERFORMANCE BOND...........................................................................53 ATTACHMENT E – SAMPLE CONTRACT..............................................................................59 ATTACHMENT F – IC-134 INSTRUCTIONS............................................................................61 ATTACHMENT H – INDEMNITY AGREEMENT......................................................................63 SECTION 4 - FUNCTIONAL REQUIREMENTS ATTACHEMENTS............................................65 ATTACHMENT I - FUNCTIONAL REQUIREMENTS DESCRIPTION......................................65 .................................................................................................................................................66 COMPUTER AIDED DISPATCH (CAD)...................................................................................66 RECORDS MANAGEMENT SYSTEM.....................................................................................92 MOBILES................................................................................................................................113 INTERFACES ........................................................................................................................128 FIRE RECORD MANAGEMENT............................................................................................138 SECTION 5 – ADDITIONAL VENDOR ATTACHMENTS...........................................................153 ATTACHMENT J - DESCRIPTION OF SERVICES................................................................153 ATTACHMENT K - PRICING..................................................................................................154 ATTACHMENT L - GENERAL SUPPORT GUIDELINES.......................................................158 ATTACHMENT M - GENERAL TRAINING GUIDELINES......................................................159 ATTACHMENT N – VENDOR/SOLUTION PROVIDER CONTACT DATA.............................160 Page | 2
    • ATTACHMENT O - VENDOR QUALIFICATIONS AND REFERENCES................................163 Section 1 – Summary Information I. INTRODUCTION AND GENERAL INFORMATION INTRODUCTION Eden Prairie is a suburban community of about 65,000 people located in the southwest corner of Hennepin County in a setting of rolling hills and picturesque lakes and creeks. Eden Prairie has a convenient location, a comprehensive system of highways, and is a short distance from downtown Minneapolis and St. Paul and the Minneapolis-St. Paul International Airport. Eden Prairie is 36 square miles and 22,594 acres. There are 17 lakes, 3 creeks, and the Minnesota River forms the southern city limits. Eden Prairie is known for its attractive residential neighborhoods, which are connected by more than 90 miles of multi-use trails and surrounded by 1,000 acres of parks and 1,400 acres of preserved land for open space. Eden Prairie is also home to a thriving business community with over 2,500 businesses. The City of Eden Prairie is soliciting proposals for the purchase of a state-of-the art, integrated Police and Fire Computer Aided Dispatch, Police and Fire Records Management, Police Mobile and Field Reporting System and Fire EMS and Building Pre- Plans system. The total Project will include the selection and acquisition of software and hardware, installation, training and maintenance costs to replace or upgrade the current system. The overall goals are as follows: • Improve service to the public • Provide shared CAD system for Police and Fire • Provide user-friendly software applications for sworn and non-sworn personnel • Provide an accurate and efficient means to access and retrieve data and statistics • Improve response times for calls for service • Provide security to ensure confidentiality and privacy of data • Provide flexibility to allow for emerging technologies • Enhance officer safety and efficiency • Provide management personnel with information and tools for evaluation purposes • Provide for future system expansion • Reduce redundant entry for both sworn and non-sworn personnel • Provide integrated solutions for data sharing • Provide a reliable, robust mobile system to improve efficiency and safety The primary criteria for vendor evaluation and consideration will be: • Application Functionality • Project Cost / Total Cost of Ownership • Technical Environment and Support • Level of Integration • System / Information Security • Project Implementation and Support • User Support and Training Page | 3
    • • References, Completeness of Proposal and Vendor Capabilities We invite you to respond to our request in our search for application providers to meet our next generation needs in communication and information technology. EDEN PRAIRIE GENERAL INFORMATION In an effort to familiarize you with our department and the needs that we have, we supply the following general information for your consideration during the proposal process: City of Eden Prairie: Population (December 2007) 65,257 Square Miles: 36 Significant Facilities: Eden Prairie Shopping Center, Parks (43) Number of Housing Units 24,999 Single Family 12,830 Multiple Family 6,703 Apartment/Rental 5,466 City Employees Full – Time 278 Part – Time and Seasonal 549 Eden Prairie Police Department Calls for Service: Over 51,000 per year Sworn Officers: 66 Mobile Units: 30 Traffic Citations: Over 15,000 per year Part I Crimes: 1,500 per year Part II Crimes: 1,600 per year Non-Criminal Calls: DL/Registration Violations: 1,500 per year average Accidents: 1,000 per year Medical and Related: 2,100 per year Alarm Responses: 1,700 per year Miscellaneous Public: 8,000 per year average Miscellaneous Officer: 5,000 per year average Eden Prairie Fire Department Fire and EMS Calls: 1,349 per year Paged Calls 1,100 per year Hazmat Condition: 121 per year average False Alarms: 318 per year EMS: 309 per year Page | 4
    • GENERAL REQUIREMENTS: System will provide seamless and comprehensive integration to the CAD, Records Management, Mobile and Field components without the need for batch updates, etc. System will interface with State and Federal agencies and comply with US Department of Justice standards for data management. System will utilize a relational database. Vendor will provide data dictionary and allow read access directly from the relational database. System will have the option of utilizing Microsoft technology and server operating system for its database and application execution. System will have the ability to support Microsoft Windows clients. Vendor will be an ESRI and Certified Microsoft Solution business partner. System application security will provide flexible access control down to the field remote level allowing specific access permissions such as update, view only, prohibit-view, etc. System will provide the ability for users to tailor system reports and create ad hoc reports and must offer user-friendly methods of preparing statistical and analytical reports. System will have the ability for users to adjust common variables such as codes, tables, report parameters, screen displays, etc., without the services of a professional programmer. System will provide for extensive one-time, single-point of entry data collection to eliminate redundancy. System will allow storage and retrieval of historical data on line. System will provide various levels of data validation at entry especially for any master files. System will provide immediate error checking for data entry elements at time of initial entry. System will allow that multiple users may access the same programs simultaneously. Vendor will provide adequate documentation of system in the form of user manuals, instructions, report format samples, screen shots, etc. Vendor will guarantee that the applications have been developed with widely accepted industry standard languages, etc. System will allow for global queries using various values, ranges, partials and wild cards. Vendor will highlight in their proposal any 3rd party software required or recommended for optimum use of their system. Page | 5
    • System will provide for multiple levels of data security control including access by user, terminal, or department and by transaction, function and/or file. System will have the ability to update a master record or file and have the modification applied throughout all areas of the system. System will provide a graphical user interface and make optimum use of menus, shortcuts, functions keys, etc. System will have a consistent design and use of controls within applications to reduce user training and system administration. System will allow for training and testing without impacting live activity or records. System will have ability to customize toolbar to launch third-party applications (current and future) in all modules (mobile, RMS, Fire RMS, CAD). Page | 6
    • II. EXECUTIVE SUMMARY PROJECT SCOPE: Applications/ Modules • Computer Aided Dispatch - CAD (Police and Fire) • Location Mapping - GIS AVL (Police and Fire) • Mobile with DVS/BCA interfaces (Police) • Field Reporting (Police and Fire) • Automated Ticket Writing (Police) • Card Swipe (Police) • Records Management (Police and Fire) • Property Management (Police) • Crime Mapping and Statistics (Police) • Administrative Reporting (Police) • Bar Coding for Property Room and Dept Equipment (Police) • Case Management/Investigations (Police) • Citation Management (Police) • Alarm Billing (Police and Fire) • Fire Inspections (Fire) • EMS Response (Fire) • EMS Billing (Fire) • Purchasing and Equipment Inventory (Police & Fire) • National Fire Incident Reporting System-NFIRS (Fire) • Personnel Management (Police & Fire) • Training Management (Police & Fire) • Equipment Management INTERFACES: Interfaces Internal Interfaces • Computer Intelligence System (CIS) • Pagers • Alarms • Reverse 911 • Fire RMS if it is not include Fire product • E-Mail • Master Clock Time Server • E911 AND TDD Interface • Motorola Toning/Alert System • Winscribe Dictation/Transcription • Card Reader System (Identisys Salamander) Page | 7
    • • Internet Web Portal (edenprairie.org) External Interfaces • Hennepin County Warrants (Mobile) • MN DPS/DMV • BCA / CJIS / NCIC • CJIS (MOC) / NIBRS (UCR) • CrimeNet CIBRS • JNET – (Hennepin County Juvenile) • MN State Courts Message Switch • Radio System (800 MHz) • CAD-to-CAD (APCO Project 36 Interface) • Dynamic Imaging (HENNRAP/MRAP) • LiveScan Fingerprinting (BCA) • Statewide Supervision System (DOC) • NFIRS • Aspen Commercial Vehicle Inspection • National Grid System (FEMA) Other Project Items • Technical and Architecture Review Page | 8
    • PROJECT GOALS AND OBJECTIVES: Page | 9
    • Goals Definition Enhanced Public Safety • Provide maximum level of safety for citizens and community for each dollar Increased Officer Safety • Provide maximum level of safety for officers and staff for each dollar Operational Efficiency/Customer • Operate department in the most cost effective way, Value to provide community with best value for dollar Page | 10
    • Enhanced Customer Service • Provide maximum non-safety service output (quality) for requestors, in most time effective manner Page | 11
    • OPERATIONAL BUSINESS CASE: Estimated Impact of change – Metrics and Intangibles Page | 12
    • Major Change Impact Goal Impacted Reduction of Double • Reduced cycle time in processing • Operational Efficiency and Triple Entry of incident records • Customer Service Data • Reduction in errors • Higher confidence in data Enhanced Information • Higher overall arrest rate • Public Safety In Squad (DVS, BCA) • Higher warrant arrests • Officer Safety • Reduction of radio traffic • Customer Service • Reduction in errors • Higher data accuracy • Clearance times • Reduction in Dispatcher time • Increased data accuracy • Reduced response time • Higher data accuracy for complex calls Field Reporting in • Increased patrol time • Public Safety Squad • More citizen contact • Customer Service • Higher arrest rate Standardization of • Increased search capability • Public Safety Data for data Sharing • Higher case clearance rate (XML/JXML) GIS/AVL • Reduction in response times • Public Safety • Reduction in backup times • Officer Safety • Higher availability (data errors due to missed clearance) Increased volume and • Better information analysis • Public Safety availability of • Better resource allocation • Officer Safety information • Increase case clearance and solvability Higher Integration of • Lower error rate • Operational Efficiency Data • Higher alarm billing • Public Safety • Higher dept revenue • Higher Clearance rates Automated Ticket • Greater officer efficiency • Operational Efficiency Writing • Improved cost effectiveness for City Enhanced Record • Immediately available incident • Customer Service Management records • Operational Efficiency • More efficient resource assignments • Better budgeting capability Page | 13
    • Enhanced Case • Better ability to track cases and • Public Safety Management caseloads • More efficient resource assignments • Higher clearance rate Upward Migration of • Reduction of need for data entry • Operational Efficiency Administrative • Increase in availability of data for • Public Safety Resource Skills report writing and statistical analysis Page | 14
    • KEY ASSUMPTIONS AND DIFFERENCES: Key Assumptions: Some key assumptions made relating to this Project include: • EPPD operates with 90% similarity to other Minnesota Police Departments • EPPD requirements are 90% industry standard • Common RFP formats will apply to this Project Key Differences: Some key differences EPPD has with other similar departments: • More traffic control and citation enforcement activity • More elderly population (EMS / medical) • Department provides internal records checks by request ESTIMATED TIMEFRAME: Below is the high-level time line. Page | 15
    • POLICE AND FIRE FUTURE SYSTEM PUBLIC SAFETY (POLICE AND FIRE) INTERFACE FLOWCHARTS Page | 16
    • CURRENT PAPER WORKFLOW FOR POLICE DEPARTMENT: An attempt has been made to construct graphic representations of the current City of Eden Prairie Police data processes and high level of workflows. It indicated paper process and electronic input and storage. Additional detail information can be obtained by request. Page | 17
    • Section 2 – General Contractual and Legal Information GENERAL INFORMATION REQUEST FOR PROPOSAL FOR EDEN PRAIRIE’S POLICE AND FIRE DEPARTMENTS ("RFP") FOR CAD, RECORDS and MOBILE PROJECT Submit proposals in a sealed envelope or package with the Vendor's name and address, RFP number and RFP title clearly marked on the outside of each sealed envelope or package. MAIL OR DELIVER ONE (1) FINAL SUBMITTAL DATE AND TIME SIGNED ORIGINAL HARD COPY, SIX (3) PAPER COPIES, AND 1 CD PROPOSALS MUST BE RECEIVED WITH MS WORD AND EXCEL NO LATER THAN: COST CHART VERSION FOR EVALUATION TEAM TO: Thursday, June 5, 2008 4:30 PM City of Eden Prairie Attention: Lisa Wu Minnesota time (Central Time Zone) per the Police and Fire RFP time clock in Purchasing Services 8080 Mitchell Road Eden Prairie, MN 55344 Late proposals will not be considered. Do not submit copies to any other person or location. CONTACT FOR RFP INQUIRIES Lisa Wu Information Technology 8080 Mitchell Road Eden Prairie, MN 55344 E-Mail: lwu@edenprairie.org PRE-PROPOSAL MEETING AND/OR SITE EVALUATION VISIT TO THE EDEN PRAIRIE POLICE DEPARTMENT AND FIRE DEPARTMENT(Optional): 8080 Mitchell Road Eden Prairie, MN 55344 May 22, 2008 9:00 AM (Minnesota Time) Page | 18
    • Please e-mail with the names of those who will attend from your company. RSVP e-mail: jmorrow@edenprairie.org Police RSVP e-mail: skoering@edenprairie.org Fire Any questions regarding about the RFP, please send email to rfp@edenprairie.org DEFINITIONS Active Event..................an event to which units are assigned and responding Alternate........................a vendor proposed solution to a requirement that may not be entirely compliant with the request as written but will offer some or all functionality of the stated requirement using another methodology (used interchangeably with “modification”) ALI.................................automatic location identification provided by 911 service provider ANI................................automatic number identification provided by 911 service provider Automatically.................defined as not requiring user or system administrator intervention Auto-populate................to fill in field data (particularly in an on-line form) using data that has already been initially entered without duplicate entry of the data Biometric.......................the science and technology of measuring and statistically analyzing biological data such as fingerprints, eye retinas, voice patterns, etc., especially for authentication purposes CAD...............................Computer Aided Dispatch System as defined in RFP Attachment I City................................defined as City of Eden Prairie, MN Client.............................defined as the purchaser of the system (City of Eden Prairie) Contract.........................the written agreement resulting from this Request for Proposal executed by the City of Eden Prairie, MN and the Contractor Contract Documents…..shall include the Contract, RFP and Specifications including Sections 1 through 5 and Attachments A through O of the RFP and any Amendments or Addendums thereto. Contractor……………….the successful proposer to this Request for Proposal who enters into a written Contract with the City of Eden Prairie Default...........................a pre-designed value, setting, definition or configuration used by a program when a value, setting, definition or configuration is not specified Department...................Police Department of the City of Eden Prairie Desirable.......................a requirement having a significant degree of importance Dynamic........................for the purposes of this RFP, the ability to update or change information live and in real time without recalling or refreshing of previous data or information, a continuous change and progression EMD..............................Emergency Medical Dispatcher or Dispatching EMS..............................Emergency Medical Services EPPD............................Eden Prairie Police Department of the City of Eden Prairie Escrow..........................Software code and documentation deposited with a neutral third party (the escrow agent) to be delivered upon fulfillment of certain conditions, as established in a written agreement Evaluation Team...........the group of people who will evaluate RFP responses and ensure that the work of the Project is completed according to an agreed to set of objectives, outcomes, outputs, people, time, cost and quality. Team will consist of IT, police, Fire operational personnel Event.............................a call for service or request for response from police, fire or EMS (used interchangeably with incident and call) Page | 19
    • Event Number...............a unique, sequential number which is automatically assigned each request for response Extracted Pricing...........an item marked for vendor reference as possibly having to be extracted from the final Contract due to budget limitations, etc. This is denoted as a reference only to vendors so that it might assist in their calculated pricing and ease the process of deduction before final Contract award if the need does, in fact, arise GIS................................a geographic information system which enables envisioning a geographic aspect of a body of data for query or analysis and presenting the results in the form of some kind of map Go live...........................the point in time that the system becomes operational and real time functionality can be achieved GUI................................Graphical User Interface Integration.....................combining separately produced components or programs to produce a common purpose or set of objectives, to unify separate programs or architectures Interface........................a set of statements, functions, options or ways of expressing program instructions for communication and supported between systems and/or other programs Local..............................defined as the user PC hardware Mobile............................an in-vehicle accessible application as defined in RFP Attachment I Modification...................a vendor proposed solution to a requirement that may not be entirely compliant with the request but will offer some or all functionality of the stated requirement (used interchangeably with “alternate”) Module..........................a generic term implying a functional application of the system such as the CAD module or the Records Management module. Must..............................a requirement that must be met in order for a proposal to receive consideration. Mandatory.....................a requirement that must be met in order for a proposal to receive consideration. Project...........................a generic term referring to the total overall scope of work as defined in the RFP to upgrade and/or replace current CAD, Records and Mobile system Project Coordinator.......a person appointed by the City of Eden Prairie for general supervision and direction of work as required by the RFP (may or may not be same as Project Consultant) Project Consultant.........a contracted consultant to the Eden Prairie Police Department Project Manager............a primary vendor representative charged with the overall scope of the contracted work to include scheduling, implementation, training, etc. Proposal........................a completed written submission to the RFP Project Site………………the Project Site shall be located at 8080 Mitchell Road, Eden Prairie. Proposer........................a person, company, partnership or corporation responding to the RFP (may be used interchangeably with “Vendor”) RMS..............................Records Management System as defined in RFP Attachment I Should...........................a requirement having a significant degree of importance (also “shall”). Specifications................a detailed requirement as set defined in RFP Attachment I System..........................a generic term meaning the total of all parts of the RFP to include CAD, Records Management, Field Reporting, Mobile and all other requested functionality as outlined in overall RFP Attachment I Validation......................a process for checking the structural integrity and correctness of data at time of entry against a predetermined criteria Vendor...........................a person, company, partnership or corporation responding to the RFP (may be used interchangeably with “Proposer”) Page | 20
    • Will................................the same as a “must” or “mandatory” requirement Page | 21
    • OVERVIEW OF PROCESS 1.1 QUESTIONS AND ANSWERS Vendors who have questions about the RFP should e-mail such questions to the Contact for RFP Inquiries by the date noted in the Tentative Schedule of Events. Additionally, Vendors may bring questions to any scheduled pre-proposal meeting or site visit. The City of Eden Prairie prefers that Vendors submit questions in advance of any pre- proposal or site visit meeting in order to facilitate appropriate responses. **All questions must be emailed to rfp@EdenPrairie.org, no calls will be accepted unless initiated by Eden Prairie RFP team** Responses to written questions which involve an interpretation or change to this RFP will be issued in writing by addendum and mailed to all parties recorded as having received a copy of the RFP. All such addenda issued by the City of Eden Prairie prior to the time that proposals are received shall be considered part of the RFP. Only additional information provided by format written addenda shall be binding. Oral and other interpretations or clarifications, including those occurring at pre-proposal meetings, site visits, routs, etc., will be without legal effect. 1.2 TENTATIVE SCHEDULE OF EVENTS Be advised that these dates are subject to change as the City of Eden Prairie deems necessary: RFP Issued 05/15/2008 Questions Mailed to City of Eden Prairie Contact for RFP 05/21/2006 Pre-Proposal Meeting / Site Visit 05/22/2008 Proposals Due 06/05/2008 Vendor Presentations and Negotiations 07/17/2008 Anticipated Date of Council Approval Sept. 2008 Anticipated Date of Award Sept. 2008 Final Complete Implementation June, 2009 1.3 EVALUATION CRITERIA AND WEIGHTS This request for proposal is not meant to favor any vendor or manufacturer. It is solely designed to provide the best value to the City in meeting the needs of public safety and Fire for the City of Eden Prairie. The City will designate an evaluation team that will consist of selected representatives of police, fire, IT, as well as field and operational personnel. The City and the evaluation team may also choose to utilize outside advisors from other public safety departments, or establish an advisory team toward such purpose. The evaluation team will make a recommendation to the City Manager who will, in turn, present the recommendation to the City Council. The Council will award a contract to the vendor whose offer yields the highest combined score in accordance with the evaluation criteria in this Section 1.3 and, when considered in its entirety, best conforms to the overall long-term interests of the City. Page | 22
    • 1.3.1 EVALUATION CRITERIA DISTRIBUTION Primary evaluation criteria will consist of the following: Application Functionality The evaluation team will rate the vendor response to each module as listed in Section (C) “Specifications and Requirements” of this RFP. A requirement should be viewed as a minimum need that must be met by the Vendor. Scores will be given for a pass / fail / or alternate response based on response and to ensure that minimum base requirements, at the least, have been satisfied. The City may eliminate any Vendor who does not fulfill all requirements and/or does not propose an acceptable alternative or modification. All responses must indicate present capability. All responses designated as alternative or modified must be accompanied by a detailed explanation stating the commitment to meet the requirement and all pertinent information relative to the alternate or modification. An acceptable alternate or modification is one that the City, at its sole discretion, deems satisfactory in meeting a requirement. The City may also, at its sole and absolute discretion, waive or convert a requirement to a desirable feature or may drop a requirement altogether from inclusion. Project Cost Using the Vendor Response Form in Attachment (E) of the RFP, the evaluation team will review the 5-year total cost of ownership for each system. The evaluation factors may include, but are not limited to, base price, cost of alternate responses or modified responses, annual maintenance, training. The City reserves the right to adjust cost proposals to reflect factors that, in the City’s judgment, would result in more accurate costs for their environment. These factors may include, but are not limited to, extracting items that are not afforded in the allotted budget for this Project, reduction of number of personnel licensed for any application proposed, reduction or extraction of various hardware options, and/or reduction of total Project scope. Technical Environment and Support This set of criteria will evaluate how well the technical infrastructure proposed meets the long-term direction of the City. Factors for evaluation may include, but are not limited to, feature set, capability for interface with current systems, standards compliance, operations system(s), suitability and flexibility of application software, hardware limitations, ease of use, capacity and ease of configuration, administration and security. Level of Integration This set of criteria will evaluate the level of integration achieved by the proposed software and hardware solutions. Preference will be given to those vendors offering a fully integrated suite of applications. Preference will also be given to those products that eliminate redundant entry and provide a seamless interaction between City public safety agencies and outside agencies. Evaluation consideration will also be given to those Vendors who have successful local installations of their applications and working interfaces to local, State and National databases. Page | 23
    • System / Information Security This set of criteria will evaluate how well the vendor meets legal mandates and public safety requirements relating to maintaining the integrity and security of internal and external criminal justice and E911 medical services information. The focus of this evaluation will be the Vendor’s ability to provide sound hardware, software and operational safeguards as set by the State of Minnesota Bureau of Criminal Apprehension (BCA) guidelines, Minnesota state government guidelines and industry best practices. Project Implementation and Support This acquisition and scope of this Project is more than a single one-time purchase. It is the establishment of a relationship with a solution provider. This set of criteria will evaluate the Vendor’s capability to implement and support the full suite of products as requested in the RFP. The City will also take into consideration the implementation plan, the overall timing and duration of the Project, the technical capacity of and experience of the Vendor, the financial standing, and the Vendor’s vision and strategy. User Support and Training Initial training and ongoing training are critical factors in the evaluation of the Vendor’s ability to deliver the final results desired in the RFP. The evaluation team will review training and support documentation within the Proposal and rate according to costs, desired and future direction. 1.4 ISSUANCE OF RFP AND AWARD PROCESS After the RFP proposal submission closure date, an award may be made on the basis of the proposals initially submitted, without discussion, clarification or modification, or on the basis of negotiation with any or all of the Vendors. Therefore, the Vendors should make sure their proposals contain the best offer. The Eden Prairie RFP Evaluation Team will choose to use a “Finalist Process”, where it determines 2-4 finalists based on evaluation criteria in 1.3.1 above. In this Finalist Process the team may request on-site demonstrations of the products, utilizing operational scenarios and controlled scoring evaluations of those finalists. In these demos and rating evaluations, the evaluation team will review each vendor with a standard set of use cases and assign a numeric value to each case based on applicability to Eden Prairie operations. The team may also utilize in-depth technical reviews and cost analysis. The team may then determine a recommended Vendor based on: Demos and Scenario Scoring 30% In-depth Technical Review 30% In-depth Cost Review 40% After the completion of the Finalist Process, and the evaluation team’s determination of a recommended Vendor, the evaluation team will make a recommendation to the City Manager, who will in turn present the recommendation to the City Council. Page | 24
    • After a notification of award has been sent to the selected Vendor, letters will be sent to all other Vendors notifying them of the outcome of the RFP process. The City will include in their evaluation Vendor references, qualifications and support as well as technical merit and cost. The City may take into consideration the Vendor’s skill, facilities, capacity, experience, responsibility, previous work record, financial standing, service and support of current clients, prompt and efficient completion of the work as described, Vendor’s vision and strategy and other factors as the City deems relevant. Issuance of this RFP does not compel the City of Eden Prairie to award. The City reserves the right to reject any or all proposals, wholly or in part; to waive any technicalities, informalities, or irregularities in any proposal at its sole option and discretion. The City reserves the right to request clarification or additional information. The City reserves the right to award a Contract in whole or in part, to award multiple contracts to multiple Vendors, to re-solicit for proposals or to temporarily or permanently abandon the procurement. If the City awards a contract, it will award the contract to the Vendor or Vendors whose proposal(s) yields the highest combined score in accordance with the evaluation criteria in Section 1.3 and, when considered in its entirety, best conforms to the overall long-term interest of the city. 1.5 PROPOSAL SUBMISSION 1.5.1 NUMBER AND DESCRIPTION OF ORIGINAL AND COPIES Mail or deliver the 4 copies of proposal sets specified on the Title Page to City of Eden Prairie, Attn: Police and Fire All-in-One Solution RFP. All documents should be 8 1/2" x 11" and all responses typed or in ink. The copies should be bound in a manner that facilitates easy handling and reading by the evaluation committee. The original and the copies must read exactly the same. Included with the paper copies must be a CD containing the MS Word version of the completed document and its attachments, with the exception of signature pages. Also included on that CD shall be the MS Excel version of the 3-year Total Cost of ownership file. Include with the proposal a table of contents that includes page number references. The table of contents should be in sufficient detail to facilitate easy reference to the sections of the RFP and response as well as separate supplemental information. 1.5.2 LATE SUBMISSION Proposals received by the City after the “Submittal Date and Time” indicated on the Title Page WILL NOT be considered. The Vendor assumes the risk of the method of dispatch chosen. Postmarking by the Submittal Date and Time shall not substitute for actual proposal receipt. 1.5.3 VENDOR'S OFFER - SIGNATURE AND CERTIFICATION FORM Have the Vendor's Offer - Signature and Certification Form (Attachment B) signed by an authorized representative of your company. Include this signed document with the original proposal and a copy of it with each copy of the proposal. Page | 25
    • 1.6 OFFER SECURITY Each proposal shall be accompanied by a cashier's check or bond with a corporate surety authorized to contract as a surety in the State of Minnesota (the “Surety”), in an amount of $50,000, payable to the City as a guaranty that the Vendor will enter into a contract with the City for the work described in the proposal, and the amount of the security of a successful Vendor shall be forfeited to the City as liquidated damages in the event that such Vendor fails to enter into a contract and furnish contractor's bond. Checks will be held during RFP process, and returned to non-successful proposers. Checks will be held for successful vendors until completion of the Project. 1.7 REQUIREMENTS OF CONTRACT AND BOND The successful bidder shall execute and deliver the Contract in the form attached hereto as Attachment E. At the same time the successful vendor shall furnish, and at all times maintain, a performance bond and a payment bond in at least the full amount of the Contract for each bond with a corporate surety satisfactory to the City in the form attached hereto as Attachment D. Personal Sureties will not be approved. 1.8 OWNERSHIP OF PROPOSAL All materials submitted in response to this request become the property of the City of Eden Prairie and may become a part of any resulting contract. Award or rejection of a proposal response does not affect this right. 1.9 RELEASE OF CLAIMS, LIABILITY AND PREPARATION EXPENSES Under no circumstances shall the City of Eden Prairie be responsible for any proposal preparation expenses, submission costs, or any other expenses, costs or damages, of whatever nature incurred as a result of Vendor's participation in this RFP process. Vendor understands and agrees that it submits its proposal at its own risk and expense and releases the City from any claim for damages or other liability arising out of the RFP and award process. 1.10 N/A SECTION REMOVED Section Removed – but paragraph held to maintain numbering consistency 1.11 DURATION OF VENDOR'S OFFER The proposal constitutes an offer by the Vendor that shall remain open and irrevocable for the period specified on the Vendor's Offer - Signature and Certification Form (Attachment B). 1.12 ERRORS AND OMISSIONS IN PROPOSALS The City of Eden Prairie shall not be liable for any errors in Vendor's proposal. Except during negotiations initiated by the City, no modifications to proposal shall be accepted from the Vendor after the Submittal Date and Time. Vendor is responsible for careful review of its entire proposal to ensure that all information, including pricing, is correct and complete. Vendors are liable for all errors or omissions contained in their proposals. Page | 26
    • 1.13 WITHDRAWING PROPOSALS Vendors may withdraw their proposal at any time prior to the Final Submittal Date and Time by submitting a written request to the Contact for RFP Inquiries indicated on the Title Page. The written request must be signed by an authorized representative of the Vendor. The Vendor may submit another proposal at any time prior to the Final Submittal Date and Time. No proposal may be withdrawn after the Final Submittal Date and Time without approval by the City. Such approval shall be based on Vendor's submittal, in writing, of an acceptable reason and at the sole discretion of the City. 1.14 ADDENDUM The City of Eden Prairie reserves the right to issue an addendum to the RFP at any time for any reason. All Vendors shall receive any and all addendums issued at the address provided by Vendor’s proposal. Addendums may be provided through the website (http:// www@edenprairie.org). 1.15 ORAL PRESENTATIONS / SITE VISITS Finalist(s) may be required to do an oral presentation and/or demonstration. Each Vendor should be prepared to discuss and substantiate any area of its proposal, its own qualifications for the services required, and any other area of interest relative to its proposal. 1.16 RESPONSES SUBJECT TO PUBLIC DISCLOSURE The City of Eden Prairie considers all information, documentation and other materials (collectively, "Materials" or "Items") submitted in response to this RFP to be of a non- confidential and/or non-proprietary nature and therefore shall be subject to public disclosure and copying after the Contract is awarded. By submitting a proposal, Vendor agrees to release the City from any liability resulting from the City’s disclosure of such information. If you believe information submitted in response to this RFP to be trade secret materials, as defined by the Minnesota Government Data Practices Act, Minnesota Statute, Section 13.37 ("MGDPA"), you must follow these instructions. (1) Clearly and conspicuously mark any materials or emails you believe to contain trade secret information; (2) Enclose such Materials in a separate envelope or separate Email, which, itself, is clearly and conspicuously marked "Confidential."; and (3) Include in the envelope or Email an opinion for each document indicating the legal basis for regarding it as trade secret under the MGDPA. Vendor also agrees to defend any action seeking release of the Materials believed to be trade secret, and indemnify and hold harmless the City, its agents and employees, from any judgments or damages awarded against the City in favor of the party requesting the Materials and any and all costs connected with that defense. Additionally, Vendor understands and agrees that in the event a request is made under the MGDPA, the City Page | 27
    • shall notify Vendor of such request but under no circumstances shall the City be required to commence or defend any action to prevent the disclosure or copying of any Materials, including Materials which the Vendor believes to be trade secret or confidential. 1.17 RESPONSIBLE PROPOSERS The City reserves the right to award contracts only to responsible proposers. Responsible proposers are defined as companies that demonstrate the financial ability, resources, skills, capability, willingness, and business integrity necessary to perform on the contract. The City's determination of whether a Vendor is a responsible proposer is at the City’s sole discretion. 1.18 NOTIFICATION OF AWARD If the City awards a contract as a result of this RFP process, the City will deliver to the selected Vendor a “Notice of Award”. The resulting contract shall consist of: (1) the terms, conditions, specifications and requirements of this RFP and its attachments, (2) any addenda issued by the City of Eden Prairie to this RFP, (3) all representations (including but not limited to, representations as to price, specifications, performance, and financial terms) made by the Vendor in its proposal and during any presentations or demonstrations for the benefit of the City, and (4) any mutually agreed upon written modifications to the terms, conditions, specifications, and requirements to this RFP or to the proposal. After a notification of award has been sent to the selected Vendor(s), letters will be sent to all other Vendors notifying them of the outcome of the RFP process. 1.19 TESTING, ACCEPTANCE AND CERTIFICATION The new system shall integrate Police/Fire/EMS Dispatch, Records, Mapping and Mobile components, along with various interfaces (the “System”). As such, the final testing and acceptance will be comprised of a number of elements involving the correlation and functionality between these various components. This will require multiple stages of testing. The City intends to join with the Vendor selected in constructing an acceptable method for testing and certification. The testing as proposed by the City should consist of the following phases: Initial Installation and Testing– The Vendor shall deliver and install the System components beginning on a date and time that is mutually agreed upon by the City and the Vendor. At such time as the installation is complete, the Vendor shall perform testing Page | 28
    • procedures relative to the system components and certify that Vendor is satisfied that the System is functional and operational per Vendor specifications. System Build (Phase 1) – After the City accepts the System as installed by Vendor, the City and Vendor shall begin any table and database build process as required. During this process, the City will test data input and output to verify that data input and resulting action and/or output perform correctly. The City shall be in close communication at all times with the Vendor to report any errors or known deficiencies. Client Testing (Phase 1) – The specifications and requirements as written in the RFP will be the first and primary source of functionality and performance of the System. The testing shall be on-going per component and shall be documented per the original RFP requirements as Pass / Fail / Modification Required / Date / Initials. System shall be able to accept and read test data for this phase and allow for deletion of test data at end of testing. System Build (Phase 2) – The Vendor shall supply and install all items designated as “Modified” within the System. Vendor shall test these modifications as required to verify performance and functionality as requested in the RFP specifications and requirements. Client Testing (Phase 2) – The testing will be completed by the City on all specifications which required modification by the Vendor. The first and primary source of functionality will be the specifications and requirements as written in the RFP against Vendor modification descriptions. Final Client Report – After Phase 1 and Phase 2 testing are complete, the City will submit to the Vendor documented areas where corrective action needs to take place. The City representative performing the Client Testing must document the failure or deficiency of the System in sufficient detail to permit reproduction by the Vendor. All failures, deficiencies or errors of the system must be corrected by the Vendor before Client Testing (Phase 3) is performed. Client Testing (Phase 3) – At this stage, the testing will be successful if the System, components and interfaces perform successfully in compliance with the specifications and requirements as outlined in the RFP for a total of 90 (ninety) days. Any testing item still outstanding as unsuccessful or deficient must be reported in writing to the Vendor. The Vendor shall have five (5) days to correct the item. The City shall retest the item within three (3) days. If the item again fails, the City shall notify the Vendor in writing and the Vendor shall again have five (5) days to correct the deficiency. This process will be repeated as many times as necessary until the ninety (90) day Phase 3 testing period is depleted. If, at this time, the Vendor fails to reach a successful resolution to the errors or deficiencies, the City shall have the right to exercise any and all rights and options to declare the Vendor in default and may exercise any or all of it’s remedies including, but not limited to, cancellation of the Contract. The City may also return the system at the Vendors cost and shall be entitled to a refund of the full amount of any payments made to the Vendor less 10% for depreciation. Upon successful completion of Phase 3 testing, the City shall give written notice to the Vendor that such testing is completed satisfactorily. The City also reserves the right to, at its discretion, extend the period for Contract compliance if so desired. Certification Testing – Upon completion of all Phase 3 testing, the City shall test the System with live data and during the normal course of business for a period of ninety (90) Page | 29
    • days. The City shall submit in writing to the Vendor the start date for this last and final series of testing. The Certification Testing shall assess that the system performs in accordance to the functionality, specification and requirements as stated in the RFP and agreed upon by Vendor, that the System can be effectively utilized by the City in its environment, actual ease of use of the System, and that the documentation is understandable and thorough. Certification Testing criteria may include the following: • Functions that access databases to test software • Function and information verification • Testing of drop down tables, command line, hyperlinks, buttons, icons, associated links and interfaces • Entry of sample transactions • Sufficient editing, modification and deletion of transactions • Processing of file maintenance functions for databases and master files • Processing and generating of reports The Certification Testing will assess if executed commands function as stated, if interfaces are complete and performing correctly, if database and workstation communications and system commands are generating appropriate responses, if the System is performing overall as stated in the specifications and requirements, and if any error messages are being generated during this final phase of testing. When the Certification Testing is complete, the City shall notify the Vendor in writing that the Contract has been fulfilled and all payments will be finalized as well as bid bonds and/ or performance bonds returned. 1.20 PAYMENT TERMS: Payment to the Vendor for the goods and services hereunder shall be made based on successful completion of the state of installation / services set forth in the following schedule: • The City of Eden Prairie shall pay the Vendor after inspection and approval by City of Eden Prairie of each of the phases listed in the schedule below. • Applications for payment may be in the form of the Vendor’s standard invoice. The application shall contain the purchase order number and contract number, an itemized list of commodities and/or services furnished, the description of each item occurring in the Contract Documents, the delivery point and the date of delivery. Invoices for any service or commodity not identified in the Contract will not be allowed. • Sales tax, if applicable, should be itemized on the invoice. • The Vendor shall invoice the City of Eden Prairie an amount equal to the percentage set forth as follows: Contract Signing 10% Initiation of Vendor Installation 10% Acceptance of Vendor Installation and Component/Module Testing 20% Page | 30
    • Completion of Client Testing Phase 1 20% Completion of Client Acceptance Testing Phase 3 (90 Days) 20% Successful Completion of Project Certification / Live 90 Day Operational Testing (90 Days) 20% • Training costs, if itemized separately in the Contract, shall be paid as incurred and at completion of training. • No payment shall constitute an acceptance of any commodity or service not in accordance with the requirements of the Contract. • Invoices shall be submitted to: City of Eden Prairie, Account Payable, Police and Fire All- in-One Project, 8080 Mitchell Road, Eden Prairie MN 55344 1.21 SUBCONTRACTING Unless otherwise agreed to in writing by the City of Eden Prairie, the successful Vendor shall be responsible for performance of any subcontractors. Use of subcontractors in the performance of the Contract is subject to City of Eden Prairie consent and Vendor shall act as primary contractor for the entire Project. The awarded vendor must ensure that any subcontractors abide by all terms and conditions of the Contract. 2.0 SOURCE CODE ESCROW The Source Code Escrow section includes terms and conditions that the City expects the Contractor for this Project to meet. The Vendor agrees to be bound by these requirements unless otherwise noted in the RFP. The Vendor may suggest alternative language to any section. Some negotiation is possible to accommodate Vendor’s suggestions. 2.1 SOURCE CODE ESCROW PACKAGE DEFINITION The term “Source Code Escrow Package” shall mean the following: A. A complete copy of the source code and executable code (in machine readable form) of the licensed software provided by the Contractor; B. A complete copy of any existing design documentation and use documentation; and/ or C. Complete instructions for compiling and linking every part of the source code into executable code for purposes of enabling verification of the completeness of the source code as provided below. Such instructions shall include precise identification of all compilers, library packages, and linkers used to generate executable code. 2.2 DELIVERY OF SOURCE CODE INTO ESCROW Contractor shall deliver a Source Code Escrow Package to the Escrow Agent. The Contractor, City and Escrow Agent shall first enter into a supplementary escrow contract. Page | 31
    • Contractor and City shall use their best efforts to enter into such an escrow contract as soon as possible after the date of this Contract, but not later than thirty (30) days following acceptance. The source code must be in escrow before final payment. 2.3 DELIVERY OF NEW SOURCE CODE INTO ESCROW When and if, from time-to-time during the term of this Contract, term of license or term of maintenance and support services, the Contractor provides the City with a maintenance release or upgrade version of the licensed software, the Contractor shall within ten (10) business days thereafter deposit with the Escrow Agent, in accordance with the escrow contract, a Source Code Escrow Package for the maintenance release or upgrade version, and shall give the City notice of such delivery. 2.4 VERIFICATION OF SOURCE CODE ESCROW PACKAGE The City, at its option and expense, may request that the completeness and accuracy of any Source Code Escrow Package be verified. 2.4.1 Such verification may be requested once per Source Code Escrow Package. 2.4.2 Such verification shall be conducted by the Escrow Agent or, upon at least ten (10) business days prior notice to Contractor, by another party (the “Verifier”) reasonably acceptable to Contractor (after full disclosure to Contractor of information reasonably requested by Contractor about the Verifier). 2.4.3 Prior to conducting the verification, the Verifier shall first execute a form of confidentiality agreement prepared by Contractor and precluding the Verifier from disclosing any information about the Source Code Escrow Package to City other than whether the Source Code Escrow Package was found to be complete and accurate. 2.4.4 Unless otherwise agreed at the time by Contractor and City, verification shall be performed on-site at Contractor’s premises, utilizing Contractor’s equipment and software, at a time reasonably acceptable to Contractor. Contractor shall make technical and support personnel available as reasonably necessary for the verification. 2.4.5 Contractor may at its discretion designate a representative to accompany the Source Code Escrow Package at all times and to be present at the verification. The Verifier will be the City’s sole representative at the verification. 2.4.6 The responsibility for the completeness and accuracy of the verification shall be solely that of the Verifier. Neither the Escrow Agent, if different from the Verifier, nor Contractor shall have any responsibility or liability to City for any incompleteness or inaccuracy of any verification. 2.5 ESCROW FEES All fees and expenses, other than verification fees, charged by the Escrow Agent will be borne by Contractor. 2.6 RELEASE EVENTS FOR SOURCE CODE ESCROW PACKAGE Page | 32
    • The Source Code Escrow Package may be released from escrow to the City, temporarily or permanently, solely upon the occurrence of one or more of the following “Escrow Release Events” described below: 2.6.1 The Contractor becomes insolvent, makes a general assignment for the benefit of creditors, files a voluntary petition of bankruptcy, suffers or permits the appointment of a receiver for its business or assets, or becomes subject to any proceeding under any bankruptcy or insolvency law, whether domestic or foreign; 2.6.2 The Contractor has liquidated its business voluntarily or otherwise and the City has compelling reasons to believe that such events will cause the Contractor to fail to meet its warranties and maintenance obligations in the foreseeable future; or 2.6.3 The Contractor voluntarily or otherwise discontinues support of the provided products or fails to support the products in accordance with its warranties and maintenance obligations. 2.7 RELEASE EVENT PROCEDURES If the City desires to obtain the Source Code Escrow Package from the Escrow Agent upon the occurrence of an Escrow Release Event, then: 2.7.1 City shall comply with the procedures set forth in the Escrow Contract to document the occurrence of the Release Event; 2.7.2 City shall maintain all materials and information comprising the Source Code Escrow Package in confidence in accordance with the section of this RPF, 1.16 of “Overview of Process”, RESPONSES ARE SUBJECT TO PUBLIC DISCLOSURE. 2.7.3 If the release is a temporary one, the City shall promptly return all released materials to Contractor when the circumstances leading to the release are no longer in effect; and 2.7.4 City shall promptly respond, fully and completely, to any and all requests for information from Contractor concerning City’s use or contemplated use of the Source Code Escrow Package. 3.0 STRUCTURE AND CONTENT OF VENDOR PROPOSAL To facilitate the evaluation of proposals, Vendors should prepare their response to this section in the format and sequence specified below and in the Attachments which are checked. Respond specifically to each question posed. Do not simply make a general reference to an attachment or brochure. Failure to comply with this stipulation could result in the proposal being rejected by the City at its sole discretion. Catalogs or brochures about the Vendor’s products or services may be included as an addendum to the proposal but not in place of specific responses to each item on the attachments checked as follows: Page | 33
    • Section 3 – VENDOR AND INFORMATIONAL ATTACHMENTS Vendor's proposal will consist of completion or acknowledgment of the following checked attachments. Unchecked attachments are intentionally omitted. ___ ATTACHMENT A – GENERAL CONTRACT CONDITIONS ___ ATTACHMENT B -- VENDOR’S OFFER – SIGNATURE AND CERTIFICATION FORM (S) ___ ATTACHMENT C -- VENDOR PROFILE AND EXECUTIVE SUMMARY ___ ATTACHMENT D – PERFORMANCE AND PAYMENT BONDS ___ ATTACHMENT E – SAMPLE CONTRACT ___ ATTACHMENT F – FORM IC-134 WITHHOLDING AFFIDAVIT FOR CONTRACTORS ___ ATTACHMENT G – CERTIFICATE OF INSURANCE ___ ATTACHMENT H – AFFIDAVIT, GENERAL WAIVER & INDEMNITY ___ ATTACHMENT I – SPECIFICATION AND REQUIREMENTS RESPONSE ___ ATTACHMENT J – DESCRIPTION OF SERVICES ___ ATTACHMENT K – PRICING ___ ATTACHMENT L – GENERAL SUPPORT GUIDELINES ___ ATTACHMENT M – GENERAL TRAINING GUIDELINES ___ ATTACHMENT N – VENDOR / SOLUTION PROVIDER GENERAL DATA ___ ATTACHMENT O – VENDOR QUALIFICATION & REFERENCES Page | 34
    • ATTACHMENT A – GENERAL CONTRACT CONDITIONS REQUEST FOR PROPOSAL FOR POLICE AND FIRE ALL-IN-ONE SOLUTION CITY OF EDEN PRAIRIE, MINNESOTA 1.0 INTERPRETATION OF PROPOSED CONTRACT DOCUMENTS If any Proposer contemplating submitting a bid for the Contract is in doubt as to the true meaning of any of the specifications or other language of the proposed RFP or Contract Documents, he/she may submit to the Contact for RFP Inquiries (see Section 2 of this Contract), a written request for an interpretation thereof. The person submitting the request will be responsible for its prompt delivery. Any interpretation of the RFP or Contract Documents will be made only by addendum duly issued and a copy of such addendum will be mailed or made available to each person receiving RFP documents and such other prospective bidders as have requested that they be furnished with a copy of each addendum. The City of Eden Prairie will not be responsible for any other explanation or interpretations of the RFP and Contract Documents. The RFP and Contract Documents are complimentary and what is required by or provided in one shall be binding as if required by or provided in all. 2.0 FORM OF CONTRACT The form of Contract to be used shall be the form prescribed and provided by the City . (See Attachment E for Sample Contract). 3.0 CONTRACTOR’S RESPONSIBILITIES The Contractor shall furnish all necessary software, hardware, wiring, peripherals, labor, training, and warranties, and shall fully complete the Project in accordance with the Proposal and Specifications for the prices bid. The Contractor shall be responsible for the entire proposed Project until its completion and acceptance. The Contractor shall be liable for any defects or substandard performance which may appear or be discovered with regard to hardware software, wiring and peripherals. 4.0 TERMINATION OF CONTRACTOR RESPONSIBILITY The Contractor’s responsibility on this Contract shall continue until final acceptance by the City of Eden Prairie, such acceptance to be made promptly after final completion of the work and final testing, and thereafter until all obligations contained in such Contract have been fully performed by the Contractor. 5.0 DISCRIMINATION ON ACCOUNT OF RACE, CREED OR COLOR, RELIGION, NATIONAL ORIGIN, DISABILITY, MARITAL STATUS, STATUS WITH REGARD TO PUBLIC ASSISTANCE, SEX OR AGE. The Contractor hereby agrees: Page | 35
    • 5.1 That in the hiring for the performance of any work under the Contract, or any subcontract, no contractor, material supplier, or vendor, shall, by reason of race, creed or color, religion, national origin, disability, marital status, status with regard to public assistance, sex or age, sexual orientation, discriminate against any person or persons who are citizens of the United States or resident aliens who are qualified and available to perform the work to which such employment relates; 5.2 That the Contractor, material supplier, or vendor shall not in any manner, discriminate against, or intimidate, or prevent the employment of any person or persons identified in 5.1 above, or on being hired, prevent, or conspire to prevent any such person or persons from the performance of work under any contract on account of race, creed or color, religion, national origin, disability, marital status, status with regard to public assistance, sex or age; 5.3 The Contractor shall furnish all information and reports required by City of Eden Prairie or by Executive Order No. 11246 and Revised Order No. 4, and by the applicable rules and regulations of the State or Federal government to ascertain compliance with the provisions of this Article; 5.4 That violation of this section shall be a misdemeanor; and 5.5 That this Contract may be canceled or terminated by the City, and all money due, or to become due under this Contract, may be forfeited, for a second or any subsequent violation of the terms or conditions of this Article. (Minn. Stat. Sect. 181.59 and Chapt. 363). 6.0 ASSIGNMENT OF CONTRACT No assignment by the Contractor of this Contract or any part thereof or of the funds to be received there under by the Contractor, will be recognized unless such assignment has had the written approval of the City of Eden Prairie, and the surety has been given due notice of such assignment and has furnished written consent thereto. In addition to the usual recitals in assignment contracts, the following language must be set forth: "It is agreed that the funds to be paid to the assignee under this assignment are subject to a prior lien for services rendered or materials supplied for the performance of the work called for in said Contract in favor of all persons, firms or corporations rendering such services or supplying such materials. 7.0 SUBCONTRACTS The Contractor shall, as soon as practicable after signing of the Contract, notify the Contact for RFP Inquiries (see Section 2 of this Contract), in writing of the names of Subcontractors, if any, proposed for the Project and the Vendor shall not employ any that the City may within a reasonable time object to as incompetent or unfit. All Subcontractors shall be bound by the terms of all the Contract Documents, but nothing contained in the Contract Documents shall create any contractual relation between any Subcontractor and the City. (Reference Attachment F “Withholding Affidavit for Contractors, Form #IC-134). Page | 36
    • 8.0 INSURANCE No Contractor or Subcontractor shall commence work under this Contract until it has obtained at its own cost and expense, all insurance required by this Article. All such insurance shall be approved by the City and maintained by the Contractor or Subcontractor, as the case may be, until final completion of the Contract. 8.1 Worker's Compensation, Unemployment Compensation and Employer's Liability Insurance The Contractor shall take out and maintain for the duration of this Contract Worker's Compensation Insurance, Unemployment Compensation Insurance and Employer's Liability Insurance as required under the laws of the State of Minnesota. 8.2 General Liability Insurance 8.2.1 Public Liability Insurance The Contractor shall take out and maintain during the life of this Contract such public liability and Property Damage Insurance as shall protect Contractor from all claims for bodily injury including accidental death as well as from all claims for Property Damage arising from operations under this Contract. The minimum limits which are required are: $1,000,000.00 in the aggregate for injuries including accidental death to any one person, for injuries including accidental death resulting from one accident and for property damage. 8.2.2 Automobile Insurance The Contractor shall carry Automobile Insurance on all automotive equipment owned, rented or borrowed in the minimum amounts of $1,000,000.00 in the aggregate for injuries including accidental death to any one person, for injuries including death resulting from any one accident, and for property damage. 8.2.3 Owner's Protective Liability and Property Damage Insurance The Contractor shall provide Owner's Protective Liability and Property Damage Insurance in the name of the City, insuring against bodily injury and property damage liability in the limits set forth above for which they may become legally obligated to pay as damages sustained by any persons, caused by accident and arising out of operations performed for the named insured by independent contractors and general supervision thereof. 8.2.4 Indemnity The Contractor agrees to hold harmless and indemnify the City, and its officers, officials, employees, servants and agents, from every Page | 37
    • claim, action, cause of action, liability, damage, expense or payment incurred by reasons of any bodily injury including death, or property damage attributable to the negligence or otherwise wrongful act or omission, including without limitation, breach of a specific contractual duty, of the Contractor or the Contractor 's agents or employees, or of anyone for whose acts any of them may be liable. Claims against Contractor for failure to obtain and keep in force the insurance required by this Contract shall not be limited by the provisions of the immediately preceding sentence. (Minn. Stat. Ch. 337). 8.3 Evidence of Insurance Insurance certificates evidencing that the above insurance is in force with companies acceptable to the City and in the amounts required shall be submitted to the City Clerk for examination and approval concurrently with the execution of the Contract, after which they shall be filed with the City Clerk. In addition to the standard information provided on the insurance certificates, each shall specifically provide that the policy will not be modified or cancelled except upon ten (10) days prior written notice to the City. 9.0 DEFENSE OF CLAIMS OR SUITS The Contractor shall indemnify and save harmless the City and all of its officers, officials, agents, servants and employees, from any and all loss, damages, expense, including cost and expense and attorney's fees of litigation arising from all suits, actions, or claims of any character, name and description, brought for, or on account of any injuries or damages received or sustained by any person, or persons or property by or from the said Contractor or Contractor’s agents or employees or by or in consequence of any neglect in safeguarding the Project, or through the use of unacceptable materials or by or on account of any act or omission, neglect or misconduct of said Contractor or Contractor’s agents or employees, or by or on account of any claims or amounts recovered for any infringement of patent, trademark or copyright, or from any claims or amounts arising or recovered under the "Worker's Compensation Law", or any other law, bylaw, ordinance, order or decree and so much of the money due the said Contractor under and by virtue of Contractor’s Contract as shall be considered necessary by the City may be retained for the use of said City, or in case no money is due Contractor’s surety shall be held until such suit or suits, action or actions, claim or claims, for injuries or damages, as aforesaid shall have been settled and suitable evidence to that effect furnished to the City. The authorized use by the Contractor of public or private property for any purpose may be considered an injury or damage to the property so used. No moneys, payable under the Contract Documents, or any part thereof except the estimate for the first month or period shall become due and payable, if the City so elects, until the Contractor shall satisfy City that he has made a satisfactory settlement for all materials and equipment used in or upon and labor done for the Project for the then preceding month. 10.0 COMPLIANCE WITH LAWS, BUILDING CODES AND REGULATIONS The Contractor is assumed to be familiar with all codes, state laws, ordinances and regulations which in any manner affect those engaged or employed in the Project, or in any Page | 38
    • way affect the conduct of the Project and no pleas of misunderstanding will be considered on account of the ignorance thereof. The provisions of such codes, laws or ordinances are deemed to be a part of these Specifications and the Contractor will be bound by the provisions thereof. The Contractor shall and also by a Surety indemnify and save harmless the City and all of its officers, officials, agents, employees and servants against any claim or liability arising from or based on the violation of any such law, ordinance, regulation or decrees, whether by the Vendor or his employees. If the Contractor shall discover any provisions in the RFP, Specifications or Contract or any direction given by a City employee or agent which is contrary to or inconsistent with any such law, ordinance, regulation or decree, Contractor shall forthwith report the inconsistency to the City of Eden Prairie in writing. 11.0 PERMITS AND LICENSES The Contractor shall procure all permits and licenses, pay all charges and fees and give all notices necessary and incidental to the due and lawful prosecution of the Project. 12.0 PATENTS, COPYRIGHTS AND PROCESSES If the Contractor requires, or the Contractor desires, the use of any design, device, material or process covered by letters, patent or copyright, trade mark or trade name, Contractor shall provide for such use by the City by suitable legal agreement with the necessary party and a copy of said agreement shall be filed with the City. The Contractor and the Surety shall indemnify and save harmless the City from any and all claims for infringement by reason of use of any such patented design, device, material or process, or any trade mark or trade name or copy right in connection with the Project to be performed under the Contract, and shall indemnify the City for any costs, expenses and damages which it may incur or suffer, including cost, expense, and attorney's fees incident to litigation by reason of such infringement, at any time during the prosecution or after the completion of the Project. 13.0 PROSECUTION OF WORK All dealings of the City will be with the Project Manager. No work on the Project shall be started until the Contract has been executed by the City and Contractor. Definite notice of intention to start work on any portion of the Project shall be given to the City at least five (5) days in advance of beginning any portion of the Project. Such starting time shall be within ten (10) calendar days after the date of receipt by Vendor of notice to proceed given by the City of Eden Prairie. The official starting time shall be taken as the date on which the Contractor is notified by the City that Contractor has fulfilled all preliminary requirements of the City. The official completion date will be calculated from the number of calendar days between the starting date and the completion date or time allowed for completion, using the official starting date as hereinbefore defined. Should the Project for any reason be discontinued temporarily, by the Contractor, with the prior consent of the City, Contractor shall notify the City at least twenty four (24) hours before again resuming operations. Page | 39
    • The Contractor shall submit, at such times as may reasonably be requested by the City, schedules which shall show the order in which the Contractor proposes to initiate the Project, with dates upon which the Contractor will start the several parts of the Project, and estimated dates of completion of the several parts. If deemed necessary by the City and by prior written approval issued by the City, Contractor shall have the right to change such schedule of operation as required. The Project shall be progress in such a manner as to insure its completion within the time set by the Contract. In case of failure to move forward the Project in such a manner as to insure its completion within the date specified, the City shall have the right to require the Contractor to place in operation such additional force and personnel as is deemed necessary. 14.0 PROJECT MANAGEMENT AND SUPERVISION The Contractor shall assign a competent Project Manager and any necessary assistants, all satisfactory to the City. The Project Manager shall not be changed or removed except with the consent of the City unless the Project Manager proves unsatisfactory to the Contractor and ceases to be an employee of the Contractor. The Project Manager shall represent the Vendor and all directions given to the Project Manager shall be as binding on Contractor. Important decisions, in the City’s sole discretion, shall be confirmed in writing to the Vendor. Other directions shall be so confirmed by the City upon written request by Contractor. The Project Manager shall give efficient supervision to the Project, using his/her best skill and attention, shall carefully study all Specifications and other instructions as written in the RFP and shall at once report to the City any error, inconsistency or omission which he/she may discover, but he/she shall not be held responsible for their existence or discovery. The Contractor will be supplied copies of the RFP Specifications and instructions. Contractor shall have said RFP Specifications and instructions available on the Project Site at all times, during the installation and finalization of the Project. Contractor shall give the Project Contractor’s constant attention to facilitate the progress thereof and shall cooperate with the Eden Prairie Police Department in setting bench marks, etc., and in all other things that are necessary for satisfactory completion of the Project. 15.0 POLICE AND FIRE ALL-IN-ONE PROJECT COORDINATOR STATUS The City shall have a Project Coordinator for general supervision and direction of the Project. The Project Coordinator is the agent of the City only to the extent provided in the Contract Documents and as authorized by the law. The Project Coordinator has authority to stop the Project whenever such stoppage may be necessary to insure proper execution of the Contract. The Project Coordinator is recognized by both parties to the Contract as the interpreter of the Contract Documents. The Project Coordinator shall, within a reasonable time, make decisions on all claims of the City, or the Contractor, on all matters relating to the execution and progress of the Project, or the interpretation of the Contract Documents. The Project Coordinator shall decide any and all questions as to quality of the Project and shall decide all questions regarding the interpretations of Specifications relating to the work that is to be paid for under the Contract. Any work not specifically specified on the specifications and RFP documentation, but which may be fairly implied, or understood, as included in the Contract, shall be done by the Contractor without extra charge, and the Project Manager shall be permitted to make such corrections and interpretations as may be deemed necessary for Page | 40
    • the fulfillment to the extent of the RFP and Specifications. In the case of any discrepancy occurring between the RFP and specifications, the decision of the Project Coordinator is final. 16.0 ACCIDENT PREVENTION Precaution shall be exercised at all times for the protection of persons (including employees) and property. The safety provisions of applicable laws and codes shall be observed. All hazards shall be guarded in accordance with the then current State and Federal O.S.H.A. laws and regulations. 17.0 FAILURE TO COMPLETE WORK ON TIME (LIQUIDATED DAMAGES) The Contractor guarantees that it can and will complete the Project within the time limit stated in the RFP and Specifications, or within the time as extended as provided elsewhere in the Contract Documents. Inasmuch as the damage and loss to the City which will result from the failure of the Contractor to complete the work within the stipulated time, will be most difficult or impossible to accurately assess, the damage to the City for such delay and failure on the part of the Contractor shall be liquidated at a daily rate for each calendar day, Sundays and holidays excluded, by which the Contractor fails to complete the work or any part thereof in accordance with the provisions hereof. Such liquidated damages shall not be considered as a penalty but as the extra cost of field and office engineering and inspection. The City will deduct and retain out of any money due or that shall become due hereunder the amount of liquidated damages, and in case those amounts are less than the amount of liquidated damages the Contractor shall be liable to pay the difference upon demand. Permitting the Contractor to continue and finish the Project or any part of it after the time fixed for its completion, or after the date to which the time for completion may have been extended, shall in no way operate as a waiver on the part of the City of any of its rights under the Contract. Neither by the taking over of the Project or by the termination of the Contract by the City shall the City forfeit the right to recover liquidated damages from the Contractor or his Surety for failure to complete the Project or Contract. 18.0 DELAYS AND EXTENSION OF TIME If the Contractor is delayed at any time in the progress of the Project by any act or neglect of the City or Project Coordinator or any employee of either, or by any other contractor employed by the City, or by changes ordered in the Project, or by strike, fire, unusual delay in transportation, unavoidable casualties or other causes beyond the Contractor 's control, or by any cause which the Project Coordinator shall decide to justify the delay, then the time of completion shall be extended for such reasonable time as the City may decide, and the decision of the City shall be binding on both parties and shall not be arbitrary or unreasonable. No such extension shall be made for delay unless claim therefore is made in writing to the Project Coordinator within seven (7) days after the period of delay shall have commenced. The Contractor shall not be entitled to extension of time for each one of several causes of delay operative concurrently, but only for the actual period of delay. The Contractor shall have no claim for damages against the City for delay in performance of the Contract due to any act or omission of the City or any of its representatives, and Contractor’s sole remedy on account thereof shall be Contractor’s right to apply to the Project Coordinator for extension of time as provided herein. Page | 41
    • 19.0 CONTRACTOR’S RIGHT TO REQUEST CHANGES If the Contractor shall discover prior to or during the Project anything in the RFP or Specifications or in supplementary directions by the Project Coordinator which in the opinion of the Contractor appears to be incorrect or an unreasonable expectation or design, he shall forthwith advise the Project Coordinator in writing of the particulars. It is understood and agreed that, if no objection is raised by the Contractor under the provisions of this paragraph, the Contractor waives any right to contest the provisions of his Contract on the basis of faulty Specifications or design. 20.0 CLAIMS AND PROTESTS If the Contractor claims any instructions or Specifications to be unfair or involve extra cost under this Contract for which Contractor would claim extra compensation, Contractor shall give the Project Coordinator written notice thereof within a reasonable time after the receipt of such instructions or Specifications, and in any event before proceedings to execute the Project. Claims shall be reviewed by the Project Coordinator and a written reply shall be provided to Contractor within fourteen (14) days of receipt. The Project Coordinator’s response shall be final. No such claim by Contractor will be valid unless so made. 21.0 THE RIGHT OF THE CITY TO DO THE WORK If the Contractor neglects to execute and complete the Project properly, or fail to perform any provision of the Contract, the City after three (3) days written notice to the Contractor, may without prejudice to any other remedy the City may have, make good such deficiencies and may deduct the cost thereof from the payment then or thereafter due the Contractor, provided, however, that the Project Coordinator shall approve both such action and the amount charged to the Contractor. 22.0 RIGHT OF THE CITY TO DECLARE CONTRACTOR IN DEFAULT In addition to those instances specifically referred to in other articles herein, the City shall have the right to declare the Contractor in default of the whole or any part of the Project if: 22.1 The Contractor becomes insolvent; or if 22.2 The Contractor makes an assignment for the benefit of creditors pursuant to the statutes of the State of Minnesota; or if 22.3 A voluntary or involuntary petition in bankruptcy be filed by or against the Contractor; or if 22.4 The Contractor fails to commence work when notified to do so by the Project Coordinator; or if 22.5 The Contractor shall abandon the Project; or if 22.6 The Contractor shall refuse to proceed with the Project when as directed by the Project Coordinator; or if Page | 42
    • 22.7 The Contractor shall without just cause reduce his working force to a number which, if maintained, would be insufficient, in the opinion of the Project Coordinator, to complete the Project in accordance with the approved Progress Schedule, and shall fail or refuse to sufficiently increase such working force when ordered to do so by the Project Coordinator; or if 22.8 The Contractor shall sublet, assign, transfer, convey or otherwise dispose of this Contract other than as herein specified; or if 22.9 A receiver or receivers are appointed to take charge of the Contractor 's property or affairs; or if 22.10 The Project Coordinator shall be of the opinion that the Contractor is or has been willfully or in bad faith violating any of the provisions of this Contract; or if 22.11 The Project Coordinator shall be of the opinion that the Contractor is or has been unnecessarily or unreasonably or willfully delaying the performance and completion of the Project; or the award of necessary subcontracts, or the placing of necessary material and equipment orders; or if 22.12 The Project Coordinator shall be of the opinion that the Project cannot be completed within the time herein provided therefore or within the time to which such completion may have been extended; provided, however, that the impossibility of timely completion is in the Project Coordinator's opinion, attributable to conditions within the Contractor 's control; or if 22.13 The Project Coordinator shall be of the opinion that the Contractor is not or has not been executing the Contract in good faith and in accordance with its terms; or if 22.14 The Project is not completed within the time herein provided therefore or within the time to which the Contractor may be entitled to have such completion extended. Before the City shall exercise its right to declare the Contractor in default by reason of the conditions set forth in items 22.1, 22.4, 22.5, 22.6, 22.7, 22.10, 22.11, 22.12, 22.13, and 22.14, he shall give the Contractor an opportunity to be heard, on two days' notice, at which hearing the Contractor may have a stenographer present; provided, however, that a copy of such stenographic notes, if any, shall be furnished to the City. 23.0 EXERCISE OF THE RIGHT TO DECLARE IN DEFAULT The right to declare in default for any of the grounds specified or referred to in Article 22 thereof, shall be exercised by sending the Contractor written notice, signed by the Project Coordinator, setting forth the ground or grounds upon which such default is declared. 24.0 QUITTING THE SITE Upon receipt of such notice the Contractor shall immediately discontinue all further operation under this Contract and shall immediately quit the site, leaving untouched all Project materials, etc. then on the site. Page | 43
    • 25.0 COMPLETION OF THE WORK AFTER DEFAULT The City, after declaring the Contractor in default, may then have the Project completed by such means and in such manner, by Contract with or without public letting, or otherwise, as it may deem advisable, utilizing for such purpose the Contractor 's instructions, Project materials, etc. remaining on the site, and also such subcontractors as it may deem advisable. Funds may be drawn from the performance bond as described in Attachment D hereto. After such completion, the Project Coordinator shall make a certificate stating the expenses incurred in such completion, which shall include the cost of re-letting and also the total amount of liquidated damages from the date when the Project should have been completed by the Contractor in accordance with the terms hereof to the date of actual completion of the Project. Such certificate shall be binding and conclusive upon the Contractor, Contractor’s Sureties, and any person claiming under the Contractor, as to the amount thereof. The expense of such completion, as so certified by the Project Coordinator shall be charged against and deducted out of such moneys as would have been payable to the Contractor, if he had completed the Project; the balance of such moneys, if any, subject to the other provisions of this Contract, to be paid to the Contractor without interest after such completion. Should the expense of such completion, so certified by the Project Coordinator, exceed the total sum which would have been payable under this Contract if the same had been completed by the Contractor, any such excess shall be paid by the Contractor to the City upon demand. 26.0 PARTIAL DEFAULT In case the City shall declare the Contractor in default as to a part of the Project only, the Contractor shall discontinue such part, shall continue performing the remainder of the Project in strict conformity with the terms of the Contract, and shall in no way hinder or interfere with any other vendors or persons whom the City may engage to complete the Project as to which the Contractor was declared in default. The provisions of the clauses herein relating to declaring the Contractor in default as to the entire Project shall be equally applicable to a declaration of partial default except that the City shall be entitled to utilize for completion of the part of the Project as to which the Contractor was declared in default only such instructions, materials, specifications, etc. as had been previously used by the Contractor on such part. 27.0 SCOPE OF PAYMENT The Contractor shall receive and accept compensation as herein provided, in full payment for furnishing all materials, labor, tools, equipment, software, hardware, royalties, fees, insurance, permits, bonds, etc., and for performing all Project work contemplated and embraced under the Contract, also for all loss or damage arising out of the nature of the Project, or from the action of the elements, until its final acceptance by the City, and for all risks connected with the prosecution of the Project, also for all expenses incurred by, or in consequence of, the suspension or discontinuance of prosecution of the Project as herein specified and for completing the Project embraced in the Contract. The Contractor shall under the Contract price furnish and pay for all materials and incidental work, furnish all accessories, and do everything which may be necessary to carry out the Page | 44
    • Contract in good faith, which contemplates everything completed, in good working order, of good material with accurate workmanship. 28.0 APPLICATION FOR PAYMENTS The Contractor shall submit to the Project Coordinator an application for each payment verified as required by law for claims against the City, and, if required, receipts or other vouchers showing payments for materials and labor including payments to subcontractors. Application for progress payments authorized by the Contract shall be submitted by the 5th day of the month following the month for which payment is requested, and, if required, the Contractor shall before the first application, submit to the Project Coordinator a schedule of values of the various parts of the Project divided so as to facilitate payments to subcontractors, made out in such form and supported by such evidence as to its correctness as the Project Coordinator may direct. In applying for payments, the Contractor shall submit a statement based upon this schedule, supported by such evidence as the Project Coordinator may direct, showing Contractor’s right to payment claimed. The Project Coordinator will examine claims for payment promptly, and his/her determination of the amount due on progress payment will be final. 29.0 PARTIAL PAYMENTS No Contract Bond, No Partial Payments If the Contractor has not provided the City with a performance and payment bond as described in Attachment D acceptable to the City for the completion and payment of the Project, no partial payments shall be made, but only one final payment shall be made pursuant to, and on all conditions stated in Article 33.0 hereof. 30.0 CERTIFICATES OF PAYMENT If the Contractor has made application as provided above, the Project Coordinator shall, not later than the date when each payment falls due; issue to the Contractor a certificate for such amount as the Project Coordinator decides to be properly due. No certificate issued or payment made to the Contractor, or partial, or entire, use, or occupancy of the Project by the City, shall be acceptance of the Project not in accordance with this Contract. 31.0 PAYMENTS WITHHELD The City may withhold from payment to the Contractor such an amount or amounts as may be necessary to cover: 31.1 Defective work not remedied. 31.2 Claims for labor or materials furnished the Contractor or subcontractor, or reasonable evidence indicating probable filing of such claims. 31.3 Failure of the Contractor to make payments properly to subcontractors or for material or labor. Page | 45
    • 31.4 A reasonable doubt that the Contract can be completed for the balance then unpaid. 31.5 Evidence of damage alleged to be caused by the Contractor in connection with the Project under the Contract for which a claim has been or will be asserted against the Contractor, the City or the Project Coordinator. The City may disburse and shall have the right to act as agent for the Contractor in disbursing such funds as have been withheld pursuant to this paragraph to the party or parties who are entitled to payment there from, but the City assumes no obligation to make such disbursement. The City will render to the Contractor an accounting of all such funds disbursed. 32.0 FINAL INSPECTION The Project Coordinator will make final testing and acceptance inspection of the Project included in the Contract or any portion thereof, as soon as practicable after notification by the Contractor that such Project is completed. If work on Project is not acceptable to the Project Coordinator at the time of his/her inspection, he/she will advise the Contractor in writing as to the particular defects to be remedied before the Project can be accepted. If, within a period of ten (10) days after such notification, the Contractor has not taken steps to speedily complete the Project as directed, the Project Coordinator may, without further notice and without in any way impairing the Contract, make other arrangements as he may deem necessary to have such Project work completed in a satisfactory manner. The cost of completing such work shall be deducted from any moneys due, or which may become due the Contractor under the Contract. 33.0 FINAL PAYMENT Upon completion of the Project and its acceptance by the Project Coordinator, the Project Coordinator will prepare a final estimate containing complete scope of each and every item of the Project performed by the Contractor, and the value thereof. Upon acceptance of said final estimate by the Contractor, the Project Coordinator will certify in writing to the City as to the completion and the Project Coordinator's acceptance of the Project, and to the entire amount and value of each and every item of the Project performed in accordance with the terms of the RFP and Contract. The action of the City and the Project Coordinator, by which the Contractor is to be bound and the Contract concluded according to the terms thereof, shall be evidenced by the aforesaid Certificate and final payment. All prior certificates or estimates upon which payments have been made are merely partial estimates and subject to correction in the final payment. Before final payment is made for the work on this Project, the Contractor, must have complied with the provisions of Minn. Stat. 290.92 requiring the withholding of State income tax for wages paid employees on this Project. Final payment will not be made until the Contractor has filed with the City a fully and duly executed Affidavit, General Waiver and Indemnity Agreement, in the form attached hereto as Attachment H and hereby made a part hereof, together with such other and additional evidence as City may request, in form and substance satisfactory to the City, that all labor, materials, software, hardware and services expended or used in the Project have been paid for in full and that no liens or other claims for such labor, materials, software, hardware or services can be made or claimed against Contractor, City or any other person or any Page | 46
    • property. In case such evidence is not furnished, the City may retain out of any amount due said Contractor a sum sufficient, in the reasonable discretion of City, but in any event not less than one and one-half times the sum determined by City to be necessary, to pay for all labor, material, software, hardware, services or other claims which are then unpaid or which are then believed by City, in its reasonable discretion, to be unpaid. 34.0 CORRECTION OF WORK AFTER FINAL PAYMENT Neither the final certificate, nor payment, nor any provision of the Contract Documents, shall relieve the Contractor of responsibility for faulty material or workmanship, and unless otherwise specified Contractor shall remedy any defects due thereto and pay for any damage to other work resulting there from which shall appear within a period of one year from the date of the inspector's final acceptance testing and report. The City shall give notice of observed defects to Contractor with reasonable promptness. All questions arising under this article shall be decided by the Project Coordinator. 35.0 NO WAIVER OF LEGAL RIGHTS The City, or its Project Coordinator, shall not be precluded or stopped by any measurement, estimate or certificate, made or given by them, or by any of their agents or employees, under any provision or provisions, of the Contract, at any time either before or after the completion and acceptance of the Project and payment thereof pursuant to any measurements, estimate or certificate, from showing the true and correct amount and character of the work performed and materials furnished by the Contractor or from showing at any time, that any such measurements, estimate or certificate is untrue or incorrectly made in any particular or that the work or materials or any part thereof do not conform in fact to RFP Specifications and the Contract, and the City shall have the right to reject the whole or any part of the aforesaid Project work or material, should the said measurement, estimate, certificate or payment be found, or be known to be inconsistent with the terms of the Contract, or otherwise improperly given, and the City shall not be precluded or stopped notwithstanding any such measurement, estimate, certificate and payment in accordance herewith, from demanding and recovering from the Contractor and his Surety such damages as it may sustain by reasons of his failure to comply with the terms of the RFP Specifications and Contract. Neither the acceptance by the City or its Project Coordinator or any of their agents or employees, nor any certificates by the Project Coordinator, for payment of money, nor any payment for, nor acceptance of the whole or any part of the Project by the City, or its Project Coordinator, nor any extension of time, nor any possession taken by the City or its employees, shall operate as a waiver of any portion of the Contract or any power herein reserved by the City, or any right to damages herein provided, nor shall any waiver of any breach of the Contract be held to be a waiver of any other or subsequent breach. 36.0 GUARANTEE / WARRANTY The Contractor shall be held responsible for any and all defects in interface and integration workmanship, materials and equipment which may be developed in any part of the Project, and upon written notice by the Project Coordinator shall immediately replace and make good without expense to the City any such faulty work and damage done by reason of same, during the period of one (1) year from the date of final acceptance of the Project. The date of the final acceptance report shall be considered the date of final acceptance. Page | 47
    • Should the Contractor fail to correct the defective work within a period of thirty (30) days of such notifications, after written notice is provided to Contractor the City may remedy the faulty interface and/or integration, charging the expense of same to the Contractor. Page | 48
    • ATTACHMENT B - VENDOR OFFER SIGNATURE AND CERTIFICATION FORM The undersigned has carefully examined all instructions, requirements, specifications, terms and conditions of this RFP; understands all instructions, requirements, specifications, terms and conditions of this RFP; and hereby offers and proposes to furnish the products and/or services described herein at the prices quoted in Vendor's proposal, and in accordance with the requirements, specifications, terms and conditions of this RFP. The Vendor also certifies: 1. Its proposal is a valid and irrevocable offer for the City of Eden Prairie’s acceptance for a minimum of 180 days from the Submittal Date and Time shown on the Title Page of this RFP to allow time for evaluation, negotiation, selection, and any unforeseen delays, and that its Proposal, if accepted, shall remain valid for the life of the Contract. 2. It is a reputable company regularly engaged in providing products and/or services necessary to meet requirements, specifications, terms and conditions of the RFP. 3. It has the necessary experience, knowledge, abilities, skills, and resources to satisfactorily perform the requirements, specifications, terms and conditions of the RFP. 4. It is aware of, is fully informed about, and is in full compliance with all applicable federal, state and local laws, rules, regulations and ordinances. 5. All statements, information and representations prepared and submitted in response to this RFP are current, complete, true and accurate. Vendor acknowledges that the City of Eden Prairie will rely on such statements, information and representations in selecting the successful Vendor. 6. It is not currently debarred or suspended from doing business with the Federal government, the state of Minnesota, or any of their respective agencies. 7. It shall be bound by all statements, representations, warranties, and guarantees made in its Proposal, including but not limited to, representations as to price, performance, and financial terms. 8. Submission of a Proposal indicates the Vendor's acceptance of the evaluation technique and the Vendor's recognition that some subjective judgments may be made by the City of Eden Prairie as part of the evaluation. 9. It understands and agrees that the City of Eden Prairie will not treat any information, document, or materials submitted by Vendor as confidential unless Vendor strictly adheres to the procedures set forth in Section 1.16 of “Overview of Process” and that such information, documents, or materials not conforming to Section 1.16 will be governed by City and Minnesota Data Practices Act (MN Statue 13). Vendor further agrees that the City of Eden Prairie may disregard confidentiality notices on fax Page | 49
    • coversheets and email headers/footers as well as copyright designations that accompany or are contained on material or documents submitted as part of Vendor’s proposal, it being understood and agreed that all material and documents not conforming to the procedures set forth in Section 1.16 will be governed by City and Minnesota Data Practices Act (MN Statue 13). Vendor Name: (Please type or print name of company) Street Address: City: State: Zip: Phone: Fax: E-Mail: I certify that I am a duly authorized representative of the Vendor listed above. The City of Eden Prairie is hereby authorized to request from any individual or company any information it deems necessary to verify any information provided by Vendor in its Proposal and to determine the capacity and responsibility of Vendor as a prospective contractor with the City of Eden Prairie. Signature: (Must be signed in full in ink by an officer of your company) Name: (please type or print) Title: (please type or print) Date: Page | 50
    • ATTACHMENT C - VENDOR PROFILE AND EXECUTIVE SUMMARY Company Profile – Attach additional pages if necessary. 1. Legal name of the Vendor: 2. Address of office which will fulfill this Contract: 3. Federal ID number: 4. Number of years in business related to RFP: 5. Type of Operation: Individual: ____ Partnership: ____ Corporation: ____ Government: ____ 6. Number of employees dedicated to fulfillment of this Contract: __________ 7. Company-wide Annual Sales Volume: __________ 8. State that you will provide a copy of your financial statements for the past two (2) years, if requested by City of Eden Prairie. 9. Is Vendor currently for sale or involved in any transaction to expand or to become acquired by another business entity? If yes, please explain the impact both in organizational and direction terms. Yes No 10. Provide any details of all past or pending litigation or claims filed against Vendor that would affect Vendor's performance under a Contract with the City of Eden Prairie. 11. Is Vendor currently in default on any loan agreement or financing agreement with any bank, financial institute, or other entity? If yes, specify date(s), details, circumstances and prospects for resolution. Yes No 12. Does any current relationship whether a relative, business associate, capital funding agreement or any other such kinship, exist between Vendor and any City of Eden Prairie employee or official? If yes, please explain relationship. Yes No Page | 51
    • 13. Are there any circumstances impacting Vendor that could affect Vendor's ability to perform under any award made through RFP process? Yes No Service and Support 1. Describe your company's service/support philosophy, how it is carried out, and how success is measured. _______________________________________________________________________ ___________________________________________________________________ 2. Describe your company's quality assurance program, its requirements and how are they measured. ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ 3. Describe your company’s philosophy for improving and upgrading to new technologies and how you anticipate helping your customers stay current with those new technologies. ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ Page | 52
    • ATTACHMENT D – PERFORMANCE BOND KNOW ALL PERSONS BY THESE PRESENTS: That ______________________________________________________________________ (Name and Address of Contractor) ________________________________________________________________as Principal, hereinafter called "Principal", and ________________________________________________ ___________________________________________________________________________ (Name and Address of Surety) as Surety, hereinafter called "Surety", are held and firmly bound unto the City of Eden Prairie, as Obligee, hereinafter called the "City", and to all claimants as hereinafter defined, in the amount of (Contract Price) ___________________________________________________________________________ Dollars ($____________________) respectively, for the payment of which sums Principal and Surety bind themselves, their heirs, executors, administrators, successors, and assigns, jointly and severally, firmly by these presents. WHEREAS, Principal has entered into a certain written Contract with the City, dated this ___________ day of ___________________________, 20_________ to: (Describe Work to be Done) ___________________________________________________________________ ____________________________________________________________________________________ __________________________________________________________________which Contract is hereby referred to and made a part hereof, and is hereinafter referred to as the "Contract". NOW, THEREFORE, THE CONDITIONS OF THIS OBLIGATION ARE SUCH, that if said Principal shall well and truly perform and fulfill all the undertakings, covenants, terms, conditions, and agreements of said Contract during the original term of said Contract and any extensions or modifications thereof, and during the life of any guaranty required under the Contract, then this obligation shall be void; otherwise it shall remain in full force and effect and the following provisions apply: 1. The Surety hereby waives notice of any modification or alteration of said Contract or any of the Contract Documents as defined and referred to in the Contract, and notice of any extension of time granted by the City. 2. In the event the price of said Contract is increased for any reason, the Principal and Surety shall furnish the City an additional bond in the sum at least of such increase within ten (10) days after demand therefore in writing from the City. 3. Whenever the Principal shall be and declared by the City to be in default under said Contract, the City having performed the City's obligations thereunder, the Surety may promptly remedy the default, or shall promptly: a. Complete said Contract in accordance with its terms and conditions; or b. Obtain a bid or bids for submission to the City for completing said Contract in accordance with its terms and conditions, and upon determination by the City and the Surety of the lowest responsible bidder, arrange for a Contract between such bidder and the City, and make available as work progresses (even though there should be a default or a succession of defaults under the Contract or Contracts of completion arranged under this subparagraph) Page | 53
    • sufficient funds to pay the cost of completion less the balance of the Contract price, but not exceeding the amount set forth in the first paragraph hereof. The term "balance of the Contract Price" as used in this subparagraph, shall mean the total amount payable by the City to the Principal under the Contract and any amendments thereto, less the amount properly paid by the City to the Principal. 4. Any suit by the City under this bond must be instituted before the expiration of two (2) years from the date on which final payment under the Contract falls due or from the date of expiration of any guaranty required under the Contract, whichever is later. In any action on this bond, the City shall be entitled to recover its reasonable attorneys' fees. IN WITNESS WHEREOF, said Principal and Surety have signed and sealed this instrument this _________ day of ____________________________, 20______. __________________________________ __________________________________ (Principal) (Surety) By_________________________________ By________________________________ Its________________________________ Its________________________________ (Seal) ACKNOWLEDGMENT FOR INDIVIDUAL STATE OF MINNESOTA ) )SS COUNTY OF HENNEPIN ) On this _________ day of ______________, 20____, before me a Notary Public within and for said County, personally appeared ____________________________________________ to me known to be the person described in, and who executed the foregoing instrument, and acknowledged that he/she executed the same as his/her free act and deed. (Seal) ________________________________________ Page | 54
    • ACKNOWLEDGMENT FOR PARTNERSHIP STATE OF MINNESOTA ) )SS COUNTY OF HENNEPIN ) On this _________ day of ______________, 20____, before me a Notary Public within and for said County, personally appeared _____________________________________________, a member of a partnership consisting of ________________________________________ __________________________________________ doing business under the firm name and style of _________________________________________________________ to me known to be the person described in, and who executed the foregoing instrument, and acknowledged that he/she executed the same as his/her free act and deed of said partnership. (Seal) ________________________________________ ACKNOWLEDGMENT FOR CORPORATION STATE OF MINNESOTA ) )SS COUNTY OF HENNEPIN ) On this _________ day of _________________, 20____, before me a Notary Public appeared _________________________________ and __________________________________to me personally known, who being by me duly sworn, did say that they are the ___________________________________ and ____________________________________ respectively of ______________________________________________________________, that the seal affixed to the foregoing instrument is the corporate seal of said corporation, and that said instrument was executed in behalf of said corporation by authority of its Board of Directors, and said _____________________________ and __________________________ acknowledged said instrument to be the free act and deed of said corporation. (Seal) ________________________________________ ACKNOWLEDGMENT FOR SURETY STATE OF MINNESOTA ) )SS COUNTY OF HENNEPIN ) On this _________ day of __________________, 20____, before me a Notary Public within and for said County, personally appeared _________________________________________, to me personally known, who, being by me duly sworn, did say that he/she is the Attorney-in-Fact of ____________________________________________________________________, that the seal affixed to the foregoing instrument is the corporate seal of said corporation, and that said instrument was signed and sealed on behalf of said corporation by authority of its corporate by-laws, and the said ______________________________________________ acknowledged that he/she executed said instrument as such Attorney-in-fact and as the free act and deed of said corporation. (Seal) ________________________________________ Page | 55
    • PAYMENT BOND KNOW ALL PERSONS BY THESE PRESENTS: That ______________________________________________________________________ (Name and Address of Contractor) _________________________________________________________________as Principal, hereinafter called "Principal", and ________________________________________________ ___________________________________________________________________________ (Name and Address of Surety) as Surety, hereinafter called "Surety", are held and firmly bound unto the City of Eden Prairie, as Obligee, hereinafter called the "City", and to all claimants as hereinafter defined, in the amount of (Contract Price) ___________________________________________________________________________Dollars ($____________________) respectively, for the payment of which sums Principal and Surety bind themselves, their heirs, executors, administrators, successors, and assigns, jointly and severally, firmly by these presents. WHEREAS, Principal has entered into a certain written Contract with the City, dated this ___________ day of ___________________________, 20_________ to: (Describe Work to be Done) ___________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ which Contract is hereby referred to and made a part hereof, and is hereinafter referred to as the "Contract". NOW, THEREFORE, THE CONDITIONS OF THIS OBLIGATION ARE SUCH, that if said Principal shall promptly make payment to all claimants as hereinafter defined, then this obligation shall be void; otherwise it shall remain in full force and effect and the following provisions apply: 1. The Surety hereby waives notice of any modification or alteration of said Contract or any of the Contract Documents as defined and referred to in the Contract, and notice of any extension of time granted by the City. 2. As used herein, "claimant" means any person doing work or furnishing skill, tools, machinery, materials, insurance premiums, equipment or supplies for the completion of said Contract or for any camp which is maintained for the feeding or keeping of workers and animals engaged under, or for the purpose of, said Contract. "Claimant" also means and includes the State of Minnesota as to taxes incurred under Minn. Stat. Section 290.92 of Chapter 297A in connection with the performance of the Contract. 3. The Principal and Surety hereby jointly and severally agree with the City that every claimant as herein defined, who has perfected that claimant's rights in accordance with the provisions of the Minnesota Statutes may sue on this bond for the use of such claimant, prosecute the suit to final judgment for such sum or sums as may be justly due, including reasonable attorneys' fees, and have execution thereon. The City shall not be liable for the payment of any costs or expenses of any such suit. 4. In the event the price of said Contract is increased for any reason, the Principal and Surety shall furnish the City an additional bond in the sum at least of such increase within ten (10) days after demand therefore in writing from the City. Page | 56
    • IN WITNESS WHEREOF, said Principal and Surety have signed and sealed this instrument this _________ day of ____________________________, 20______. __________________________________ __________________________________ (Principal) (Surety) By_________________________________ By________________________________ Its________________________________ Its________________________________ (Seal) ACKNOWLEDGMENT FOR INDIVIDUAL STATE OF MINNESOTA ) )SS COUNTY OF HENNEPIN ) On this _________ day of ______________, 20____, before me a Notary Public within and for said County, personally appeared ____________________________________________ to me known to be the person described in, and who executed the foregoing instrument, and acknowledged that he/she executed the same as his/her free act and deed. (Seal) ________________________________________ ACKNOWLEDGMENT FOR PARTNERSHIP STATE OF MINNESOTA ) )SS COUNTY OF HENNEPIN ) On this _________ day of ______________, 20____, before me a Notary Public within and for said County, personally appeared _____________________________________________, a member of a partnership consisting of ________________________________________ __________________________________________ doing business under the firm name and style of _________________________________________________________ to me known to be the person described in, and who executed the foregoing instrument, and acknowledged that he/she executed the same as his/her free act and deed of said partnership. (Seal) ________________________________________ ACKNOWLEDGMENT FOR CORPORATION STATE OF MINNESOTA ) )SS COUNTY OF HENNEPIN ) On this _________ day of _________________, 20____, before me a Notary Public appeared _________________________________ and __________________________________to me personally Page | 57
    • known, who being by me duly sworn, did say that they are the ___________________________________ and ____________________________________ respectively of ______________________________________________________________, that the seal affixed to the foregoing instrument is the corporate seal of said corporation, and that said instrument was executed in behalf of said corporation by authority of its Board of Directors, and said _____________________________ and __________________________ acknowledged said instrument to be the free act and deed of said corporation. (Seal) ________________________________________ ACKNOWLEDGMENT FOR SURETY STATE OF MINNESOTA ) )SS COUNTY OF HENNEPIN ) On this _________ day of __________________, 20____, before me a Notary Public within and for said County, personally appeared _________________________________________, to me personally known, who, being by me duly sworn, did say that he/she is the Attorney-in-Fact of ____________________________________________________________________, that the seal affixed to the foregoing instrument is the corporate seal of said corporation, and that said instrument was signed and sealed on behalf of said corporation by authority of its corporate by-laws, and the said ______________________________________________ acknowledged that he/she executed said instrument as such Attorney-in-fact and as the free act and deed of said corporation. (Seal) ________________________________________ Page | 58
    • ATTACHMENT E – SAMPLE CONTRACT CONTRACT NO____ THIS AGREEMENT, entered into this _______ day of _______________________, 20______, between the CITY OF EDEN PRAIRIE, a municipal corporation existing under the laws of the State of Minnesota, hereinafter referred to as the "City", party of the first part, and _______________________________________ of ___________________________________________________________, hereinafter referred to as the "Contractor", party of the second part, WITNESSETH: Article 1. The Contractor, for and in consideration of the payment or payments herein specified or referred to, and by the City to be made, hereby covenants and agrees to furnish all materials, all necessary tools and equipment, and to do and perform all of the work and labor necessary for the following (hereinafter referred to as the "Work"): in strict conformity with the Contract Documents as defined in the General Contract Conditions for the Work. Said Contract Documents are hereby referred to and made a part of this Contract to the same extent as if herein set forth, and the same, together with this Contract, are herein referred to as the "Contract Documents". Article 2. The Contractor agrees to commence the Work as herein provided for at the earliest practicable date and in any event not later than_________________________ ___________________________________ and to prosecute the same diligently and without delay, and to have the Work entirely completed in every respect and in full compliance and strict conformity with the Contract Documents to the satisfaction and approval, as evidenced in writing, of the _______________________________________________________________ of the City by not later than ______________________________________________. Article 3. The Contractor further agrees to make, execute and deliver to the City a payment bond executed by the Contractor and a corporate surety company authorized to do business in the State of Minnesota and approved by the City in the sum of________________________________________________________________Dollars ($ ) for the use of all persons doing work or furnishing skill, tools, machinery or materials in connection with the Work. The Contractor further agrees to make, execute and deliver to the City a performance bond executed by the Contractor and a corporate surety company authorized to do business in the State of Minnesota and approved by the City in the sum of ________________________________________________ ___________________________________________________________________ Dollars ($____________________) for the use of the City and to secure the full, prompt and faithful performance of this Contract by said Contractor. Each such bond to be in form and substance approved by the Clerk of the City and to be conditioned as required by Minnesota Statutes, Section 574.26, as amended, and this Contract shall not become effective until said bonds have been received by the Clerk of the City. Page | 59
    • Article 4. In consideration of the covenants and agreements stated above, the City agrees to pay the Contractor the sum mentioned in the Proposal or bid of said Contractor, which is made a part of this Contract and attached hereto. Installment payments, if any, on account of work done and the materials furnished by said Contractor under this Contract and actually in place in the Work, shall be made in accordance with the provisions of the General Contract Conditions. Final payment therefore shall be due and payable on or before thirty (30) days after compliance by Contractor with all of the requirements for final payment, and fulfillment of all other provisions for final payment, as set forth in the General Contract Conditions. IN WITNESS WHEREOF, the parties hereto have caused these presents to be duly executed the day and year first above written. WITNESSED BY: CITY OF EDEN PRAIRIE ________________________________ By_____________________________________ Mayor ________________________________ By _____________________________________ City Manager WITNESSED BY: ________________________________________ CONTRACTOR ________________________________ By______________________________________ ________________________________ By _____________________________________ Page | 60
    • ATTACHMENT F – IC-134 INSTRUCTIONS Please use the following link to obtain form and instructions, as they are required for this RFP http://www.taxes.state.mn.us/taxes/forms/ic134.pdf Page | 61
    • ATTACHMENT G – CERTIFICATE OF INSURANCE VENDORS - Please include Certificate of Insurance Here In Your Response Page | 62
    • ATTACHMENT H – INDEMNITY AGREEMENT AFFIDAVIT, GENERAL WAIVER AND INDEMNITY AGREEMENT WHEREAS, ________________________________________________________, (hereinafter called "Contractor") is the Contractor for the work in the City of Eden Prairie (hereinafter called "City") described as follows: (hereinafter called the "Work"), which Work has now been completed. NOW, THEREFORE, for and in consideration of the payment by City of the sum of _____________________________________________________________ Dollars ($__________________) to Contractor, being the total payment due for the Work, the receipt of which is hereby acknowledged by Contractor, Contractor hereby: 1. Certifies, warrants and represents that all labor, materials and services expended or used in the Work have been paid for in full and that no mechanic's or materialmen's liens or other claims can be made against Contractor, City or any other person or any property, for unpaid labor, materials or services expended or used in the Work; 2. Waives all claims for labor, materials and services in connection with or arising out of the Work; 3. Agrees to hold harmless and indemnify City from and against any and all claims for labor by the employees or sub-contractors, or employees of sub-contractors, of Contractor, or by any other person, and from and against all claims for supplies, materials and appliances used in connection with the Work and from and against any and all damages and expenses suffered or incurred, including attorney's fees, due to any such claims, and to immediately, upon the filing of a lien claim, satisfy the same of record; 4. Agrees that this agreement is intended to apply to all labor and materials used or expended to the date hereof and all labor, services and materials used or expended, or to be used or expended, in connection with any repair or reconstruction of the Work done or to be done under warranty or bond, whether to be done now or at a future date. IN TESTIMONY WHEREOF, Contractor has duly executed this instrument this ___________ day of ______________________, 20____. _________________________________ CONTRACTOR By _______________________________ Its _______________________________ ACKNOWLEDGMENT (INDIVIDUAL) Page | 63
    • STATE OF ______________________ ) )SS. COUNTY OF _____________________) On this _________ day of _______________________, 20____, before me, a Notary Public within and for said County, personally appeared _________________________________________ to me known to be the person described in and who executed the foregoing instrument and acknowledged that _____________________________________________________ executed the same as _________________________________ free act and deed. (Seal) ___________________________________ ACKNOWLEDGMENT (CORPORATION) STATE OF _______________________ ) )SS. COUNTY OF ______________________) On this _________ day of _________________________, 20____, before me, a Notary Public within and for said County, personally appeared _______________________________ and ____________________________________to me personally known, who, being each by me duly sworn did say that they are respectively the _______________________________ and _____________________________________ of _____________________________ ___________________________________________, the corporation named in the foregoing instrument, and that the seal affixed to said instrument is the corporate seal of said corporation, and that said instrument was signed and sealed in behalf of said corporation by authority of its Board of Directors and said _______________________________________ and ________________________________________ acknowledged said instrument to be the free act and deed of said corporation. (Seal) ___________________________________ Page | 64
    • SECTION 4 - FUNCTIONAL REQUIREMENTS ATTACHEMENTS ATTACHMENT I - FUNCTIONAL REQUIREMENTS DESCRIPTION RESPONDING TO THE RFP SPECIFICATIONS All responses must be completed on the forms as provided by City of Eden Prairie or downloaded from the City of Eden Prairie FTP site. Completed RFP’s must follow the specifications as provided in Section 1.5 (Beginning Page 21) and one copy of the RFP submission should be copied to standard CD in Microsoft Word format and attached to hardcopy submission when Vendor has completed. If a Vendor fails to submit the RFP as required by the City, it shall be grounds for disqualification. All Vendors are required to use the following guidelines when responding to each specification as outlined in the RFP: Y = Yes (The current version of the proposed software meets the specification without any modification, as of April 17, 2008.) N = No (The current proposed software does not meet the specification and cannot/will not be modified.) M = Modified (The current proposed software would require modification to meet the required specification. NOTE: For each “Modified” response, the Vendor must include an explanation and modification cost summary. All modifications, however, must be included in the final cost summary.) F = Future (This capability is planned for a future version of the product by April 2008, but is not currently available) The City of Eden Prairie has also provided a designation in the RFP marked as “EP”. This designation is defined as “Extracted Pricing”. In the event that the total RFP amount is higher than anticipated and/or higher than what is currently budgeted for the system, the City reserves the right to “extract” certain items from the RFP and/or consider as add-ons at a later date. If so warranted, this extraction will apply to all RFP responses and will be conducted before the final review and evaluation. If the “EP” designation is accompanied by italics within the written requirement, the extracted pricing designation refers to the portion of the requirement in italic only. The intent of the “EP” designation is to assist all Vendors in being able to more readily extract certain items from the RFP overall pricing in the event that they are requested to do so by the City. The City of Eden Prairie anticipates a budgetary allotment for this Project with the 5-year Cost of Ownership. The City asks your consideration of this when weighing your decision to proceed for inclusion in the RFP process. Page | 65
    • Computer Aided Dispatch Requirement Index C.1.0 CAD General C.1.1 CAD Overall C.1.2 CAD Administrator C.1.3 CAD Data Conversion C.2.0 Call Receipt and 911 Data Import C.3.0 General Dispatching C.3.1 Alert Tones C.3.2 EMD C.3.3 Mapping and Address Validation C.3.4 Unit /Squad Selection C.4.0 Dispatch & Messaging C.5.0 Call Clearing & Disposition C.6.0 Timers & Status Monitoring C.7.0 Geofile & Premise Information C.8.0 Automated Vehicle Location (AVL) & GIS C.9.0 CAD Query and Reporting COMPUTER AIDED DISPATCH (CAD) C.1.0 CAD GENERAL Y/N/M/F Comment C.1.0.1 The CAD software shall be stored locally at each workstation, to ensure continued CAD availability in the event of a network failure. C.1.0.2 The CAD system shall support TCP/IP. C.1.0.3 The CAD system shall support any static IP address. C.1.0.4 The CAD system shall generate diagnostic messages. C.1.0.5 The CAD system shall allow the user to define what system messages are presented to operators. C.1.0.6 The CAD system shall be able to report error conditions to operators and remote monitoring equipment. C.1.0.7 The system shall provide a complete on-line copy of the system and user documentation including on-line help. C.1.0.8 The on-line documentation shall be accessible by a shortcut or mouse click. C.1.0.9 The on-line help system shall be organized according to the major functions of the application. C.1.0.10 All on-line help will be indexed and users will have access to the electronic index. C.1.0.11 All on-line documentation shall be printable Page | 66
    • with accurate page numbers without users having to reformat the document. C.1.0.12 System documentation and help files shall be context sensitive. C.1.0.13 On-line documentation must be searchable based on topic or key word. C.1.0.14 Any authorized user shall be able to modify and add to the documentation files as necessary. C.1.0.15 The vendor shall supply comprehensive documentation of each change, modification, or error fix, which has been included in each version release or update. C.1.0.16 The vendor shall supply manufacturers documentation for all hardware and third- party software products as part of the system. C.1.0.17 The vendor will ensure as part of its maintenance responsibilities that the City receives a copy of each documentation release or change produced by third-party software and hardware vendors. C.1.0.18 All proposed equipment shall be new and not remanufactured. C.1.0.19 It is desired that the proposed system use server failover, clustering or mirroring to meet the requirement below. C.1.0.20 The system shall utilize a redundant server or host computer design, or a fault tolerant server or host computer design to ensure the highest level of application availability. C.1.0.21 In the event of a server/host failure, the system shall failover to the back-up server/host or otherwise automatically recover operations within thirty seconds. C.1.0.22 Once a failed server/host has been restored to operational capability, it shall automatically restart without intervention. C.1.0.23 In the event of a failure the system shall automatically notify administrators via pager. C.1.0.24 The system shall have remote management functions that allow remote system administration. C.1.0.25 The system shall have remote boot capability. C.1.0.26 The CAD system shall be designed for public safety use. C.1.1 CAD Overall C.1.1.1 The user interface shall be a Graphical User Interface (GUI) and utilize menus, shortcuts and function keys. C.1.1.2 The system shall utilize mouse, keyboard Page | 67
    • commands, command line commands or any combination. C.1.1.3 The system will allow the screen configurations to be user designed and defined and locked as defaults if so desired. C.1.1.4 The system will be capable of using biometric log on capabilities. C.1.1.5 The system will integrate messaging to other workstations to include CAD and RMS and also mobile applications. C.1.1.6 The system will archive all messages and returned requests and have both retrieval and reporting capabilities. C.1.1.7 The system will allow messages and returns to be attached to the CAD record. C.1.1.8 No message or dialog box, whether manually or automatically displayed, will cover or impede processing of an event. C.1.1.9 The system will provide data validation at the field level to detect incorrect entries and incomplete forms prior to processing C.1.1.10 The system will return the cursor to the first position of incorrect or incomplete entry and provide an explanation of the error. The system will then consecutively step through any additional errors or incomplete entries. C.1.1.11 If a field has defaulted or pre-defined values, the user shall be able to choose from only those defined values. C.1.1.12 The system must support single entry query and multiple database responses (i.e., one entry will query local database, NCIC, CJIS, etc., automatically). C.1.1.13 The system will automatically notify the dispatcher when inquiry returns are received either audibly or by some other mechanism. The returns will be color coded or in some way categorized to convey source and/or priority. C.1.1.14 The system will require user to log on using an employee number or user ID and unique password. The system should also allow for biometric log on capabilities. C.1.1.15 The system should be configured so as to allow multiple user logons at multiple workstations without shifting call load or units between stations. All stations should show identical pending and in-progress activity. C.1.1.16 The system must support multiple open windows and interfaces running actively and simultaneously within application and all Page | 68
    • other standard MS Windows XP based features. C.1.1.17 The system shall show not only all public safety units signed onto active status but also all dispatchers and non-sworn personnel who are signed on.. C.1.1.18 Any text area within the system should be of unlimited length and have standard word processing capabilities including, but not limited to, text editing, spell check, word wrap, cut/copy/paste, find and document formatting. C.1.1.19 If there are multiple pages / screens of information to display, the system will automatically make available by page up/down method in addition to scrolling and information will be displayed in chronological order with most recent first. C.1.1.20 If a drop down code table is utilized, the system will allow depressing enter key at that position and field will be auto filled. C.1.1.21 System will always display cursor at first entry position of screen on any new screen. C.1.1.22 The system will maintain logical flow and appropriate input screens. Only those screens and fields required for a particular event type will be presented to reduce tabbing and redundant screen maneuvering. C.1.1.23 The system will provide text-sensitive on line and editable help screens. C.1.1.24 The system should provide user-definable tables, screens and forms. C.1.1.25 In the event of a server failure, the dispatcher shall be able to retrieve, at a minimum, pending events, current assigned events, all units statuses, most recent event number assigned. C.1.1.26 All event numbers shall be unique and sequential. C.1.1.27 System will automatically allow for an event number restart at the beginning of every calendar year without IT personnel intervention. It will also allow an event to be assigned during one year and closed out during the next and track pertinent times and statuses. C.1.1.28 System will allow agency to determine use of duplicate or unique case numbers as opposed to event numbers. C.1.1.29 System will allow total CAD redundancy in the event of system failure. System will allow a systematic backup and archival Page | 69
    • process that does not impede CAD dispatch operations. C.1.1.30 System must have capability for System Administrator to configure screens and screen layouts as well as lock down the default screens if desired. C.1.1.31 System must provide multiple input flexibility to include function keys and other shortcut capabilities. C.1.1.32 System must have the ability to easily access other network resources while active in CAD and without interrupting CAD processes. C.1.1.33 System will have the ability to dynamically download any changes to code tables, user defines, etc. at next user log on. C.1.1.34 The system shall have the ability to select Police, Fire and EMS services. C.1.1.35 The system shall have the ability to view all open events at any position. C.1.1.36 The system shall be able to print details from any position. C.1.1.37 Each CAD workstation must be capable of all call taking and dispatching tasks. C.1.1.38 Remote workstations located at agency facilities will be used to monitor event and unit status, and generate analytical reports. C.1.2 CAD Administrator C.1.2.1 CAD Administrator will have the ability to assign identification, sign-on, passwords and privileges based on user or group of users. C.1.2.2 System will allow CAD Administrator to update and maintain personnel information. C.1.2.3 System will allow audit trail capabilities for CAD Administrator for all interfaces to include, but not limited to, State, NCIC, Mobile, E911, etc. C.1.2.4 System will allow CAD Administrator to perform training duties without effecting live events, numbering sequences or archived events. C.1.2.5 System will allow CAD Administrator to reset event numbers by the following methods: Manually Pre-Scheduled Automatically at Year End Changeover C.1.2.6 System must support the ability to establish a first event and case number as assigned after period of system down time. C.1.2.7 System must allow CAD Administrator to override and log off any dispatch terminal. C.1.2.8 System will allow the CAD Administrator the Page | 70
    • ability to observe a dispatch terminal from a remote terminal or location. C.1.2.9 System will allow CAD Administrator to set parameters for display or non-display of restricted information or fields. C.1.2.10 System will allow CAD Administrator to set priority levels on location comments and alerts and, if configured, only display by priority level at time of dispatch. C.1.2.11 System will allow CAD Administrator or designated users to update premise information including, but not limited to, contact information, alarm vendor, etc. C.1.2.12 Describe the process for the CAD System Administrator to clear system lockups. (Attachment) C.1.3 CAD Data Conversion C.1.3.1 All information must be converted fully into new application and integrated into a new product database and available as any standard data C.1.3.2 Required conversion of all current (to be defined) information residing in RMS for the following fields: Master Name Master Name Address Master Name Involvement Event Number Event Location Event Date and Time Event Type C.1.3.3 Converted information shall be able to be consolidated after conversion should the need arise. C.1.3.4 All current premise and hazard information will be converted to the new system. C.2.0 Call Receipt and 911 Data Import C.2.0.1 System must have capability to receive calls via any of the following methods: E911 Phone VOIP Caller ID Alarm 800 MHz Radio TDD E-Mail XML / JXML Format Web Interface C.2.0.2 System must provide or support capability to enter events from multiple locations to Page | 71
    • include offsite PSAP's, Mobile Units or other CAD workstations. C.2.0.3 System will have the ability to save, forward and archive pending and queued events. C.2.0.4 Caller information from caller ID should automatically populate to the event record without specific operator action. C.2.0.5 Caller information from call ID, ANI / ALI and E911 databases should automatically populate into the event record without specific operator action. C.2.0.6 System must have capability for dispatcher to manually correct or override caller ID, ANI/ALI and E911 information that is automatically populated to event record. C.2.0.7 System must have E911 interface archive capabilities so that calls may be queried by originating phone number or by pre- assigned sequence number, regardless of whether a CAD event was generated. C.2.0.8 System must validate address, cross street, intersection or commonplace name and show jurisdiction along with in and out of range. C.2.0.9 System must allow user defined source, type and priority codes. C.2.0.10 Each CAD record should contain the following: Event number Event Date and Time Event Primary Location Cross Street Additional location comments, independent from narrative information Indication of event priority (i.e., in-progress, just-occurred, recent or past occurrence) Event Revised Location Caller Name Caller Address Caller Phone Received Date and Time Lat/Long Coordinates Event Type Event Priority Event Source Event Comments and Free Form Text Field Event Disposition C.2.0.11 Must be able to dispatch with a minimum amount of data to include the following. Must be able to update events with additional information on an on-going basis Page | 72
    • without regard to unit status. Event Number Event Time and Date Unit Number(s) C.2.0.12 CAD event will be assigned a unique ID event number along with a time and date stamp based on the event initiation C.2.0.13 System must have the ability to assign manual event numbers for events that must be entered retroactively in the event of a system failure. C.2.0.14 Application must have the ability to color- code events based on agency type of Police, Fire, and/or EMS C.2.0.15 System must have ability to assign unique event numbers for Police, Fire and EMS C.2.0.16 System will have capability to reset event numbers after system outage for automatic generation while back entry is simultaneously taking place. C.2.0.17 All locations, whether in or out of city, must show agency jurisdiction C.2.0.18 System must allow dispatcher to hold an event, and to have that event reopened at any time by any dispatcher. Time must reflect original time the call was received (i.e.. off hook) and any and all holds. C.2.0.19 System must allow any dispatcher to update a record, open or closed, whether originally assigned on event or not. C.2.0.20 System must maintain an audit trail of any and all change. C.2.0.21 System shall allow access to all modules within the system with a single user ID sign- on and as defined by the System Administrator. C.2.0.22 Application must provide user defined drop down prompts for the following: Event / UCR Type Agency Code Event Source Event Priority Disposition / Service Code Disposition Type / UCR Code C.2.0.23 System must have the capability to have multiple and unlimited number of events open and active without closing or archiving events. C.2.0.24 System must have capability to copy events to other calls and events C.2.0.25 System will allow single event information entry for a combined Police, Fire and EMS Page | 73
    • event. C.2.0.26 Although System will allow single entry of all initial event information for a combined Police, Fire and EMS event, the system will automatically generate unique event numbers for each responding agency. C.2.0.27 System must have the capability to recall functions/commands used previously via 1-2 keystrokes. C.2.0.28 System will provide caution and premise information at time of address validation and present information automatically to both dispatchers and mobile units. Additionally, parcel/premise preset notes, such as hazmat and other standard items, as well as agency entered specific comments and notes will be available. C.2.0.29 Systems must provide or integrate with online scripting based on event type, and must verify that operator asked each question and response from caller. C.2.0.30 System will display all active events and statuses, both queued and dispatched, to include the following information: Event Number Agency Code Date and Time of Call Location of Event Call Source Event Type Code Priority Caller Name Caller Address Caller Phone Narrative Texting Unit Numbers Unit Statuses Badge Number Affiliations Mobile Number Affiliations Holds and Hold Timers Alarm Timers Incoming Message Text Area Mapping System Status All Interface Statuses All Event Updates C.2.0.31 System will record all changes to an event with time stamp and user ID for future query or reporting purposes. C.2.0.32 System must have CAD Application messaging interface to multiple topologies to Page | 74
    • include Mobile Data Computer (fixed), portable laptop, PDA, Pager, etc. C.2.0.33 System shall allow dispatcher to cancel or close an event at any time or during any process of the CAD application. Application will provide a specific rule-based audit trail about the event. C.2.0.34 System will allow dispatcher the capability to review events by location, date and time, event type or event number. C.2.0.35 System must have the capability to allow dispatcher to dynamically update any caution/alert or premise information for a specific location without signing out of CAD application. C.2.0.36 The system shall give the dispatcher the option to over-ride a priority. C.2.0.37 The system must dynamically update the dispatcher's pending event monitor with a summary of the event being created as soon as the location and event type are validated along with an indication that event entry is still in progress. C.2.0.38 The E911 location must be able to be utilized as the event location unless manually overridden. C.2.0.39 If the E911 location is overridden, it still must be recorded in the event record for later review. C.2.0.40 A list of pending events must be available for continuous display and be dynamically updated for all statuses. C.2.0.41 The system shall provide a visual and audible warning when a new or updated event is added to the pending event display. C.2.0.42 The system shall support a visual warning for events in the pending list when any of the following conditions occur: Event is being viewed by another dispatcher Wait time has exceeded user defined allowable maximum Supplemental information has been added to the event Event cancellation has been requested Reassigned or unassigned unit is available for assignment to event C.2.0.43 Events should be color coded to display a user definable priority. C.3.0 General Dispatching C.3.0.1 System must have the capability to dispatch by multiple criteria to include responder unit number, badge number, squad number, beat Page | 75
    • assignment, mobile number, etc. C.3.0.2 System must be able to track all personnel involvement in the event to include dispatchers, police, fire and/or EMS units C.3.0.3 System must record the time of initial call pickup, time of event assignment, time of dispatch, enroute, on scene, transport, available and in quarters for initial event and all updates to event. C.3.0.4 System must allow event to be re-activated under same event number for further follow- up and track all unit or assignment times accordingly. C.3.0.5 System must allow for status changes by multiple methods to include dispatcher or mobile unit initiation. C.3.0.6 Application must have capability to present all events in queue in a sorted manner, determined by operator C.3.0.7 Dispatcher must be able to dynamically distribute updates and/or changes as they occur to all personnel involved without having to recall the event or have personnel refresh the screen. C.3.0.8 System will allow dispatcher to enter and remove event from hold status without any loss of information C.3.0.9 System must allow reassignment of units to an event, swapping of units after initial dispatch, or cancellation of a unit or multiple units from an event using a one keystroke/function process versus canceling each one individually. C.3.0.10 System will automatically re-queue a cancelled event into the hold status area to await future assignment or final disposition. C.3.0.11 System will allow for user definable response plans which can be based on type of event, personnel resource assignment and allocation, etc. and overwritten at any time by the dispatcher. C.3.0.12 System will delineate between primary and secondary or backup units and allow the transfer or swapping between units. C.3.0.13 System must be capable of handling an event assignment over a long-term basis (i.e., 24 hours or longer) and change event date and time tracking to reflect this occurrence. Must also have capability of this same designation over a year-end period if event is active or pending. C.3.0.14 System must allow for assignment of Page | 76
    • multiple units simultaneously and also multiple departments simultaneously without leaving current dispatch input area (i.e., dispatch police and fire simultaneously from single input screen). C.3.0.15 System must allow a dispatcher to update the status of multiple units with a single keystroke. C.3.0.16 System must allow reassignment of a particular event to a particular unit based on user-define criteria and automatically assign that event to the unit when it is available. C.3.0.17 System must not allow a unit to log out of the application unless it has been cleared from all event assignments. C.3.0.18 System will have PC to mobile, mobile to PC, mobile to mobile and PC to PC text messaging capabilities. C.3.0.19 System must have the capability to create and transmit digital images and graphics files from the dispatch center to mobile units and vice versa. C.3.0.20 System must allow dispatcher to send messages to one or multiple units simultaneously based on dispatch discretion or units assigned to a particular event. C.3.0.21 System must allow user defined message priorities and flexibility of broadcasting. C.3.0.22 System must allow automatic priority assignment for high priority items. C.3.0.23 System must maintain a full audit trail of all messages sent from dispatch to mobile, from mobile to dispatch and from mobile to mobile. C.3.0.24 Operator must be able to search message text history by word and by Soundex capabilities C.3.0.25 System must provide a visual or audio validation to dispatcher that messages or dispatches were not sent or received. C.3.0.26 System must allow for creation and pre- assignment of incidents and on-going events. C.3.0.27 Duplicate event validation must be performed automatically immediately after an address, intersection, or premise has been verified and without operator action. The areas to be examined for potential duplicate events must be a user configurable and must include parameters of exact location, hundreds-block range and/or a defined radius from the incident location. Page | 77
    • C.3.0.28 The duplicate detection process must be advisory only; the operator must be able to determine whether the new event is a duplicate and whether to proceed with the entry. C.3.0.29 The operator must be able to display the complete record of any potential duplicate events by function key. C.3.0.30 The duplicate event must be able to be supplemented with the new information by function key and without retyping data. C.3.0.31 The system must have the ability to record events and schedule them for dispatch at a later date and time. C.3.0.32 The system must allow for entry of events that have been previously handled but not yet entered into the system, due to conditions such as system down time. C.3.0.33 The operator shall have the flexibility to process pending events in any sequence. C.3.0.34 Any event shall be able to be controlled from any CAD workstation. C.3.0.35 Comments must be able to be added to any unit status change, and will be recorded with the event’s and unit’s permanent record. C.3.0.36 Unit status changes do not require the display of the event record. C.3.0.37 The system must support the following event control and unit status command functions: Dispatch one or more units to an event Assign back up units to an event Replace one unit with one or more other units Have the ability to exchange two units between events Preempt a unit to service a higher priority event. If the only unit assigned to an event is preempted, the event should automatically be placed back in the pending event list Place one or more units on any user defined status Add information to a units history record, whether available or assigned to an event Enter pursuit information from several terminals concurrently Change unit location (new location must be validated against the Location Master file) Initiate a traffic stop (location must be validated against the Location Master file). C.3.1 Alert Tones C.3.1.1 System must integrate with Motorola Gold Page | 78
    • Elite tone/alert systems. (Reference: “Interfaces”) C.3.1.2 The system shall be capable of automatically generating user defined alert tones on user defined talk groups based upon event nature codes and priority codes, (i.e., in progress events, etc.) C.3.2 EMD (Emergency Medical Dispatching) C.3.2.1 System will have interface capabilities with Priority One Dispatch software. (Reference: “Interfaces”) C.3.2.2 The system shall have the ability to track the receiving and admitting capability of local hospitals C.3.2.3 The system shall include a method by which users can periodically update /reset the availability of various emergency rooms in each hospital C.3.2.4 The system shall allow only authorized users to define a hospital status, such as open, closed, reroute, trauma only, etc… C.3.2.5 Each hospital status shall have a separate color code and shall be displayed in a separate window C.3.2.6 The system shall allow the user to define question and answer sequences in association with each event type C.3.2.7 The system shall allow the user to define codes for each Q & A sequence and numbers for each individual question and answer C.3.2.8 The system shall allow the user to define instruction to accompany each question or answer C.3.2.9 The system shall allow the user to define which questions in a Q&A sequence must be answered before processing an event can continue C.3.2.10 The system shall allow the user to incorporate and copy questions, answers, or instruction, which have already been entered for one type of event to various event sequences without retyping C.3.3 Address Validation C.3.3.1 Application must validate event address and location entries against the Master Location geofile database. C.3.3.2 System will validate location based on street number, street name, street directional, street type and suite or apartment number. C.3.3.3 All locations, whether in or out of city, must show the agency jurisdiction of each Page | 79
    • address being validated within the system at time of entry. C.3.3.4 System will provide, in the case of partial address entry, multiple selections based on Soundex or phonetics and displayed as a drop down option with the most likely validation being listed first. C.3.3.5 System will allow in cases of multiple pages / screens of returned addresses (i.e., multiple dwelling or apartment listings) a simple method to page up / page down to review selections. C.3.3.6 System will allow validation with as few as one character, alpha or numeric, input. C.3.3.7 System will present valid street ranges if a correct street but incorrect street number is entered by dispatcher. C.3.3.8 System will allow a simple one keystroke method to select correct address from multiples without necessitating retyping of the location. C.3.3.9 System must allow dispatcher to dispatch without having a specific address or override any location whether in or out of jurisdiction. C.3.3.10 System must allow dispatcher override to location from E911 transferred location data also. C.3.3.11 System will allow location validation for intersections without dependence on which might be entered in the first position. C.3.3.12 System will display, based on entry of one street, all valid intersecting streets if location type chosen is intersection. C.3.3.13 System shall validate the address whether initially entered by dispatch or a mobile unit. C.3.3.14 System must allow validation to commonplace names that may / may not have an exact street address (i.e., parks, etc.) C.3.3.15 System will allow for multiple commonplace names to be used for any one location. C.3.3.16 When a commonplace name is entered for validation, system will select the validated address of that name as the correct location. C.3.3.17 System must allow user defined commonplace names or aliases to any location in the system. C.3.3.18 System must audit and report all location entries that do not validate and allow dispatcher to update location Geofile with most current information at time of event entry without changing historical records. Page | 80
    • C.3.3.19 System will allow for a change of location of an event and dynamically update the location for all signed on users. C.3.3.20 A location must be able to be validated without creating a CAD event. C.3.4 Unit /Squad Selection C.3.4.1 System will have the capability to have user defined and flexible beat plans based on criteria designated by the user. This criteria should include, but is not limited to, number of personnel on duty, special events, priority of event, etc. C.3.4.2 System will have the capability to define separate beat plans for police, fire and EMS units. C.3.4.3 System will have the capability to recommend units based on a geographic location. C.3.4.4 System will automatically designate unit assigned to any given beat as the primary unit. C.3.4.5 System will allow dispatcher override and changing of any primary unit. C.3.4.6 System will allow unlimited number of units that can be assigned to an event. This will include police, fire and EMS units. C.3.4.7 System will allow user defined flexibility for unit identification. C.3.4.8 System will provide unit recommendations, based on AVL (closest unit's) to the location of the event and by zone assignment at time of initial event entry. C.3.4.9 System will allow acceptance of recommended units with a single key or command function. C.3.4.10 System will allow a unit assignment to be pre-empted by another assignment. C.3.4.11 System will allow an assigned unit to be pre- empted from a lesser priority event to a higher priority event and will place lesser event back in the hold queue. C.4.0 Dispatch & Messaging C.4.0.1 System will allow simultaneous dispatching or messaging to multiple units. C.4.0.2 System will simultaneously dispatch police, fire and EMS units from single entry screen. C.4.0.3 System will allow for multiple methods of dispatch to include field screen entry, command line and drag and drop. C.4.0.4 System will automatically remove an event from the queued or held/pending stack once an event has been dispatched. Page | 81
    • C.4.0.5 System will allow messaging to units by multiple methods to include unit number, badge number, beat number or mobile number. C.4.0.6 System will allow messaging to units individually to by user defined groups. C.5.0 Event Clearing and Disposition C.5.0.1 System will function in such a manner that disposing of an event will automatically clear all units from the event based on department. (i.e. police disposition will not clear fire units, etc.) C.5.0.2 System will require a disposition before completely clearing an event. C.5.0.3 System will allow a disposition by any dispatcher or by a mobile unit assigned to the event. C.6.0 Timers & Status Monitoring C.6.0.1 System must provide audible and visual warning of queued events that have passed predetermined timer limits C.6.0.2 System must allow for user defined alarm times to be set by type of event, type of officer activity, unit status, and can be set individually or by groups. C.6.0.3 System will have the ability to exclude specific event types, jurisdictions, and statuses from their status monitor. C.6.0.4 System must provide for unlimited number of user defined statuses. C.6.0.5 System must provide configuration options for turning status alerts on and off. C.6.0.6 System must provide method of viewing unit status overall or selection by police, fire or EMS unit groupings. C.6.0.7 System must alert dispatcher to status changes both audibly and by color coding differences in status changes. C.6.0.8 System must record and time stamp all status changes and provide for an audit trail C.6.0.9 System should provide a display of unit number, mobile number, beat, status and location for assigned units. C.6.0.10 System should allow for unit statuses to be sorted based on a number of criteria including, but not limited to, unit number, status and same event. C.6.0.11 The software should display all units in colors associated with their activity;(i.e. yellow = enroute, etc…) C.7.0 Master Location Geofile and Premise Information Page | 82
    • C.7.0.1 Application will provide capability to create Geofile from County tax maps (ESRI/Arc View), or other designated parcel mapping. C.7.0.2 Application will utilize ESRI standard map data shape files. C.7.0.3 Application or interface will provide map change log from one map version to the next, highlighting changes and allow operators to correct information or add agency specific changes. C.7.0.4 Application or interface will allow operators to accept or reject map change from version to version. C.7.0.5 Maps will support the following data elements: Address Apartment Number Building number Street Name Commonplace Name Latitude And Longitude C.7.0.6 Operator must be able to enter, correct or override E 911 information and provide an audit trail of corrections. C.7.0.7 Operator must be able to generate a list of incorrect Geofile information along with the correct information for that data set and then forward that information for corrective entry. C.7.0.8 Application must check other open events for possible duplication of events based upon address and nearby address locations and present those to the operator for validation. C.7.0.9 Application will present icons or data points for events and same location in a manner that they will be distinguishable from each other (i.e. not overlap graphically). C.7.0.10 Operator must have capability to choose address from a range of addresses if no exact match is found in Master Location geofile database. C.7.0.11 Operator must be able to enter partial street names and application must present a list of alternative streets. C.7.0.12 Application must utilize soundex (minimum) principles in searching for partial or incorrect street names and present alternatives to operator. C.7.0.13 Application must present operator with nearest address or address ranges for addresses that do not appear in the Master Location geofile. Page | 83
    • C.7.0.14 Application must allow a location breakdown to a finite agency defined level such as address, building number, suite number, apartment number, or internal building location, etc. C.7.0.15 Application must allow agency defined preset internal address location (such as kiosks within a mall) or other non- conventional address breakdowns. C.7.0.16 Application must allow for multiple layers of agency defined elements. C.7.0.17 Application must allow for temporary map layers for events such as road closures, lane restrictions special events, etc. C.7.0.18 Application will allow premise information to be entered for: Hazmat Animal Lock Codes Alarm information C.7.0.19 Application will allow entry of temporary premise information with the start date and auto suspend upon expiration date. C.7.0.20 Application will notify operator or supervisor of pending temporary premise information expiration. C.7.0.21 Operators must have capability to assign premise information to groups of addresses, C.7.0.22 Application will allow temporary premise information for groups to have common or individual expiration dates. C.7.0.23 Operator must have ability to delete system wide premise information with a minimum of keystrokes, but with multiple acknowledgment /validation windows. C.7.0.24 System will allow method of bisecting streets or other properties for creation of user- defined beat plans, etc. C.7.0.25 The hazard file must be automatically checked during incident entry and validation. C.7.0.26 A permanent notification of the presence of hazard information must be recorded in the incident history. C.7.0.27 The actual text of the hazard must be recorded in the event history record. C.7.0.28 Hazard file records must have a purge cycle which prevents access after a preset date. C.7.0.29 Upon expiration, records must be retained for manual re-activation or deletion. C.7.0.30 Hazard file records must be able to be entered for permanent retention. C.7.0.31 System must allow multiple hazard files for a Page | 84
    • single location. C.7.0.32 An operator must be able to display all hazard data at any event or location. C.7.0.33 An operator must be able to search for all applicable hazards in the vicinity of an event or location. C.8.0. Automated Vehicle Locator (AVL) and GIS C.8.0.1 Application must provide ability to graphically display position of all vehicles and mobile units using standard GIS maps. C.8.0.2 Application must support unit display at LAN based workstations within Communications Center for agency. C.8.0.3 Application must support display of vehicle location to mobile users via wireless/cellular laptop or mobile PC. C.8.0.4 Application must support and display multiple unit types such as police, fire, EMS and other vehicle types. C.8.0.5 Location and position will include the following components: Latitude and Longitude Time Speed Direction of Travel Street Address where applicable C.8.0.6 AVL location data shall be assigned a lower priority bandwidth within supported architectures (i.e. cellular carrier, etc.) C.8.0.7 AVL must be able to support an unlimited number of vehicles. C.8.0.8 AVL shall be able to visually identify units closest to event location. C.8.0.9 Application will store historical geofile log on client server for a period of time predetermined by the application administrator. C.8.0.10 Application must be capable of identifying and correcting invalid data (i.e. noise) from vehicle position data stream. C.8.0.11 AVL must be accurate to within 30 feet or less horizontally and 50 feet vertically. C.8.0.12 AVL must distinguish Unit Status changes. C.8.1 Master Location Geofile Configuration Tool C.8.1.1 The ESRI format map data shall be stored and automatically updated locally at each workstation to ensure continued map availability in the event of a network failure. C.8.1.2 The system shall provide a configuration tool. Page | 85
    • C.8.1.3 The configuration tool shall manage access to other applications that can be launched from the map viewer. C.8.1.4 The configuration tool shall provide for the configuration of a cross reference between ALI format and GIS data structure C.8.1.5 The configuration tool shall provide for the configuration of different wireless processing methods based on classes of service. C.8.1.6 The configuration tool shall provide for the configuration of the display properties of derived wireless coverage areas. C.8.1.7 The configuration tool shall allow standard or customer provided icons to be assigned. C.8.1.8 The configuration tool shall allow the addition or deletion of GIS data layers to the data set. C.8.1.9 The configuration tool shall provide for the configuration of layer properties including minimum and maximum zoom levels for display control, labeling and rich rendering options. C.8.1.10 The configuration tool shall provide for the configuration of the GIS data coordinate system. C.8.1.11 The configuration tool shall provide for the configuration of which GIS layers and fields will be searchable for location information. C.8.1.12 The configuration tool shall allow a virtually unlimited amount of layers to be configured for automatic and manual searches. C.8.1.13 The configuration tool shall support point, polygon and line GIS layers for searching. C.8.1.14 The configuration tool shall provide for the use and customization of standardization and matching rules including minimum match score values. C.8.1.15 The configuration tool shall provide for the configuration of which GIS layers return results on evacuation zones and shall allow multiple GIS layers to be defined. C.8.1.16 The configuration tool shall provide for the configuration of general discrepancy management information, including PSAP name, type of discrepancies and statuses. C.8.2 Map Viewer C.8.2.1 The map viewer shall be stored locally at each workstation to ensure continued map availability in the event of a network failure. C.8.2.2 The map viewer shall support TCP/IP. C.8.2.3 The map viewer shall support any static or dynamic IP addressing. Page | 86
    • C.8.2.4 The map viewer shall generate diagnostic messages. C.8.2.5 The map viewer shall allow the user to define what system messages are presented to operators. C.8.2.6 The map viewer shall be able to report error conditions to operators and remote monitoring equipment. C.8.2.7 The map viewer shall be designed for public safety use. C.8.2.8 The map viewer shall support multiple methods of accessing features, including menus, toolbars, function keys, context sensitive, right click drop down menus, etc. C.8.2.9 The map viewer security shall be integrated with CAD security and not require additional log-on. C.8.2.10 The map viewer shall support limiting access to map viewer functions based on user. C.8.3 Navigation C.8.3.1 The map viewer shall allow the user to pan the map display. C.8.3.2 The map viewer shall support user ability to zoom in and out to full extent. C.8.3.3 The map viewer shall support entry and centering of manually entered latitude and longitude (X,Y) coordinates. C.8.3.4 The map viewer shall continuously geocode and display the address of the location the mouse pointer is over. The map viewer shall continuously display the x,y coordinates of the location the mouse pointer is over and shall allow the user to change projections from system (i.e. state plane) to geographies (degrees/minutes/seconds). C.8.3.5 The map viewer shall support printing of map windows. C.8.3.6 The map viewer shall support user configuration of a disclaimer message. The disclaimer message shall appear on all printed maps to protect any proprietary information such as cell coverage maps. C.8.3.7 The map viewer shall be able to display calls, coordinates of all connected mobiles, and manually entered locations. C.8.3.8 The map view shall present an organized list of all objects displayed. The map viewer shall support easy management of the data including columnar sorting, placement and adjustment of width of columns. The map viewer shall center on the current map window and any object that is double clicked Page | 87
    • from the object list. C.8.3.9 The map viewer shall permit users to display or hide any layer in the GIS data set. C.8.3.10 The map viewer shall support multiple toolbars to provide access to commonly used functions. C.8.3.11 The map viewer shall provide an optionally available locator or overview map. C.8.3.12 The map viewer shall provide access to system level messages such as application warnings or error messages. C.8.3.13 The map viewer must support 911 repeat ALI query. C.8.4 Search Capability C.8.4.1 The map viewer shall provide an interface to perform searches automatically from location information provided. C.8.4.2 The map viewer shall accept free form entry of location information. C.8.4.3 The map viewer search interface shall provide a single field of entry for location information including address, common place name, street name and intersection. C.8.4.4 The map viewer search interface shall display streets for intersection searches where only one street was entered. C.8.4.5 Ambiguous search results shall display a list of possible matches based on the entry. C.8.5 Tools C.8.5.1 The map viewer shall allow on the fly conversion of the units of measurement. C.8.5.2 The map viewer shall provide the shortest street path between two points. C.8.5.3 The map viewer shall provide the ability to select a region and display all addresses within that region (i.e. evacuation zone). C.8.5.4 The map viewer shall be able to print and export all addresses displayed on the screen or in the specified region. C.8.6 Display C.8.6.1 The map viewer must be able to automatically display emergency locations from 911 call data spill. C.8.6.2 The map viewer shall be automatically centered and apply a default zoom scale on 911 emergency display. C.8.6.3 The map viewer shall be able to display manual database requests. C.8.6.4 The map viewer shall be able to display different icons for different objects, such as landline, wireless Phase I, wireless Phase II, wireless Phase III, incidents, crimes, etc… Page | 88
    • C.8.6.5 The map viewer must be 911 wireless Phase I, Phase II and Phase III compliant. C.8.6.6 The map viewer must be able to display derived cell tower coverage, actual cell tower sector and sector coverage area. C.8.6.7 The map viewer shall be able to visually differentiate between event status and priorities. C.8.6.8 The map viewer shall use a different icon for locations with multiple objects displayed at the same location. C.8.6.9 The map viewer shall allow a user to select which object or layer to display on top. C.8.6.10 The map viewer shall display all available information on a selected object including object information and GIS data. C.8.6.11 The map viewer shall support the ability to place icons (push pins) onto a map window by manually entering a location. C.8.6.12 The map viewer shall support the ability to highlight a street by manually entering in the street name. C.8.6.13 The map viewer must support the ability of the user to manually change the location of an object. C.8.6.14 The map viewer must accept serial ALI information from a CAD feed of any 911 ANI/ ALI controller. C.8.7 Data C.8.7.1 The map viewer shall have native support of ESRI shape files and all ArcView file types. C.8.7.2 The map viewer shall provide a discrepancy management module. C.8.7.3 The discrepancy data shall include automated information that cannot be modified such as operator ID, date, time, original information. C.8.7.4 The discrepancy data shall support a variety of location sources, such as 911 ALI and GIS data. C.8.7.5 The discrepancy management module shall automatically audit key events such as creation of new and closing of events. C.8.7.6 The discrepancy data shall be stored locally at the workstation. C.8.7.7 The discrepancy data shall be able to be centrally collected and remotely stored for archiving. C.8.8 Premise Information Management C.8.8.1 The map view shall support a premise information module. C.8.8.2 A virtually unlimited amount of premise Page | 89
    • information shall be available for all locations. C.8.8.3 Premise information shall include owner, contact information, building access, text memos, hazardous materials and persons, floor plans, and other multimedia files. C.8.8.4 The map view shall automatically notify the user of the availability of premise information for a location. C.8.8.5 Premise information shall be configurable to always be available or only notify during a user configurable time range. C.9.0 CAD Query and Reporting C.9.0.1 System shall offer field screens and forms with standard, consistent, and mandatory fields to retrieve and report information on vehicles, boats, persons, articles or guns per State and National standards. C.9.0.2 System will provide flexibility of querying either by preformatted screens or command line. C.9.0.3 System will provide for easily generated, user defined reporting. C.9.0.4 System will allow any field represented in CAD or any other program (I.e., RMS) to be a searchable or reportable field. C.9.0.5 System will allow for final report design layout to be user definable. C.9.0.6 System will provide a written standardized query based on the following criteria. Query should also be capable of wild card functionality. Event Number Officer Involvement Unit Date or Date Range Location or Location Range Time of Day Event Type Event Disposition C.9.07 System will automatically query simultaneously the following when a request is submitted: CAD NCIC CJIS (State) RMS Department of Motor Vehicles (DMV) C.9.0.8 The software should provide area/section activity reports and detail listings. C.9.0.9 The software should provide activity Page | 90
    • summary reports. C.9.0.10 The software should provide building/geo listing. C.9.0.11 The software should provide a listing of CAD commands. C.9.0.12 The software should provide an event activity report. C.9.0.13 The software should provide an event breakdown by, hour, day and month. C.9.0.14 The software should provide a shift summary report. C.9.0.15 The software should provide a house watch report. C.9.0.16 The software should provide a response time report. C.9.0.17 The software should provide an officer activity report. Page | 91
    • Records Management System Requirement Index R.1.0 RMS General R.1.1 Overall R.1.2 Data Conversion R.2.0 Incident Update/Entry R.3.0 Master File R.3.1 Name R.3.2 Vehicle R.3.3 Location R.4.0 Arrest R.5.0 Juvenile R.6.0 Case Management & Investigations R.6.1 Crime Analysis R.6.2 Inquiries and Reports R.7.0 Property & Evidence R.8.0 Data Recall & Query R.9.0 Online & Printed Reports R.10.0 State & Other Mandatory Reporting R.11.0 Record Control & Distribution R.12.0 Traffic and Citation Management R.12.1 Accidents RECORDS MANAGEMENT SYSTEM R.1.0 RMS General Y/N/M/F Comment R.1.1 RMS Overall R.1.1.1 System will be comprehensive and integrated to the CAD, Mobile, and Field Reporting components. R.1.1.2 System will be integrated to the same shared databases used by CAD, Mobile and Field Reporting including, but not limited to, location geofile, master name, juvenile and property. R.1.1.3 System will allow query to master databases of names, locations, vehicles, and property from any module within RMS without entry disruption or exiting current entry area. R.1.1.4 System will provide a synopsis of RMS information on any event based on any query made to the master database files . R.1.1.5 System will also provide a synopsis of information already entered at time of event entry and modification to RMS. R.1.1.6 System will provide a means of alerting entry personnel to duplicate entries or Page | 92
    • events. R.1.1.7 System will assure that if a data element is modified on a master record in the system, the change will be recorded in all modules or locations of that record within the system. R.1.1.8 The user interface shall be a Graphical User Interface (GUI) and utilize menus, shortcuts and function keys. R.1.1.9 System will provide input flexibility and multiple methods using mouse, keyboard or function keys (or any combination) for RMS entry. R.1.1.10 System will allow screen configurations to be user designed and defined and locked as a default if so desired. R.1.1.11 System will have consistent design and use of controls, functions keys, etc. to reduce user training and system administration. R.1.1.12 System will provide data validation at the field level to detect incorrect entries and incomplete forms prior to finalization of a record. R.1.1.13 System will provide data validation for all required State and Federal interfaces before record submittal. R.1.1.14 System will allow post-validation edits to a saved record versus re-entry of the record. R.1.1.15 System will return the cursor to the first position of an incorrect or incomplete entry and provide an explanation of the error. The system will then consecutively step through any additional errors or incomplete fields. R.1.1.16 If a field has defaulted or pre-defined values, the user shall be able to choose from only those defined values. R.1.1.17 The system will require user to log on using an employee number or user ID and unique password. The system should also allow for biometric log on capabilities. R.1.1.18 System will allow an Administrator the ability to assign identification, sign-on, passwords and privileges based on individual user, group of users or both. R.1.1.19 The system should be configured so as to allow multiple user logons at multiple workstations. R.1.1.20 The system will allow for user definable permissions including, but not limited to, view only, change/update, reporting, non- Page | 93
    • viewable confidential, etc. R.1.1.21 System will allow Administrator to set parameters for display or non-display of restricted information or fields. R.1.1.22 System must support multiple open windows and interfaces running actively and simultaneously with the RMS program as well as all other standard Windows based features. R.1.1.23 Any text area within the system should be of unlimited length and have standard word processing capabilities including, but not limited to, text editing, spell check, word swap, cut/copy/paste, find and replace, document formatting and screen print. R.1.1.24 System will allow for user definable code tables throughout the RMS. R.1.1.25 If a drop down code table is utilized, the system will allow depressing enter key at a chosen position and the field will be autofilled. R.1.1.26 System will always display cursor at the first entry position of screen on any new screen. R.1.1.27 System will maintain a logical flow and appropriate input screens depending on entry type. Only those screens and fields required for a particular entry type will be presented to reduce tabbing and redundant screen maneuvering. R.1.1.28 System will provide text-sensitive on line and editable help screens. R.1.1.29 System will allow a systematic backup and archival process that does not impede records entry operations. R.1.1.30 System must have the ability to access other network resources while active in RMS and without interrupting or halting RMS processes. R.1.1.31 In the event of screen configuration or code tables changes, system will have the ability to easily and automatically download at next user log on. R.1.1.32 System will allow Administrator to perform training duties without effecting RMS records or historic information. R.1.1.33 System will allow multiple users to access or edit any one record at any given time. R.1.1.34 The RMS record will begin at the time event is received by CAD or mobile and will have a unique event number assigned at that time. Page | 94
    • R.1.1.35 All location addresses in geomaster file will be verified and standardized using initial validation from CAD. R.1.1.36 Any name or location entered into the RMS system will be validated against a single master and attached at time of initial RMS entry. R.1.1.37 RMS will serve as the central repository for all information and shall be the standard when data discrepancies occur. R.1.1.38 System will use the event number as the primary link to all RMS applications and record areas. R.1.1.39 System will interface and/or link with all applicable State, Federal and local systems and accept mandatory required parameters, including, but not limited to: NCIC/III State CJIS / CJRS CIBRS / NIBRS Minnesota MOC MN Department of Vehicle Services (DVS) State BCA Laboratory Hennepin County (TIGER) Case Transmittal Hennepin County (JNET) Juvenile Transmittal Hennepin County Warrants HennRap (Hennepin Repository of Arrest Photos) Identix Fingerprint System MRAP (Minnesota Repository of Arrest Photos) Statewide Supervision System (S3) R.1.1.40 System will guarantee that various industry standard file structures can be easily imported and exported for use both within the RMS and for outside agency mandates as required. R.1.1.41 System will allow multiple ways to query criteria of events to decide if additional data updates or modifications are necessary. R.1.1.42 If any data element is changed in one area of RMS, system will be updated and changed in all areas of RMS. R.1.1.43 All event records will be a part of the RMS regardless of disposition status including, but not limited to, cancelled events, events not assigned, events referred from or to other agencies, etc. R.1.1.44 System must have the ability to select Page | 95
    • records to archive or purge based on multiple criteria including, but not limited to, event number or range, date or range of dates, event types, etc. R.1.2 Data Conversion R.1.2.1 All information must be converted fully into new application and integrated into a new product database and available as any standard data R.1.2.2 Required conversion of all current (to be defined) information residing in RMS for the following fields: Master Name Master Name Address Master Name Involvement Event Number Event Location Event Date and Time Event Type R.1.2.3 Converted information shall be able to be consolidated after conversion should the need arise. R.1.2.4 System will have the ability to selectively redact information from a record. R.2.0 Event Update/Entry R.2.0.1 System will transfer all information from initial event previously entered by CAD or mobile into RMS at the time of event disposition including, but not limited to, completed screen fields, any reports, supplemental reports, additional comments or attachments. R.2.0.2 System will automatically propagate other modules within RMS with all initial event information to eliminate data entry redundancy. R.2.0.3 System will provide dynamic event updates to all authorized users immediately at time of disposition. R.2.0.4 System will automatically force master file lookup and subsequent attachment for name, location, vehicle and property at time of RMS entry. R.2.0.5 System will base name, location, vehicle and property records on a single master record with multiple occurrences or involvements. R.2.0.6 System will provide a method to add supplemental information to an approved report while maintaining the security of the original report. Page | 96
    • R.2.0.7 System will allow for supervisory approval. R.2.0.8 System must have capability to incorporate future on-line reporting for non-criminal activity or Part II crimes. R.2.0.9 System will have capability to track and compile reports as mandated by State and Federal government for events including, but not limited to, bias crimes, pursuit activity, discharging of handgun, use of force, bomb threats, etc. R.2.0.13 System will allow user defined narrative types within the master file. R.2.0.14 All personal identification codes within the master file shall be in compliance with State and Federal mandates (i.e. hair color, eye color, race, etc.) R.3.0 Master File R.3.1 Name R.3.1.1 System will provide a means to enter a master name record directly without initiation in another module. R.3.1.2 System will provide a means to enter an adult or juvenile name directly without assigning a case or event number (i.e., field contacts, warnings, etc.) R.3.1.3 System will provide a means to designate juveniles from adults. R.3.1.4 System will provide a means to prevent juvenile records from becoming adult records when the individual reaches age of majority (age 18). R.3.1.5 System will be NIBRS / CIBRS compliant as it relates to linking relationships to persons, criminal activity, etc. R.3.1.6 System will provide a means to tag and redact name records based on State and Federal laws pertaining to confidentiality. R.3.1.7 System will accept hyphenated names. R.3.1.8 System will have a means to seal recorded name involvement. R.3.1.9 System will have a means to expunge recorded name involvements. R.3.1.10 System will seal or expunge the name record throughout all modules of the system with a single entry. R.3.1.11 System will provide a means to seal or expunge a name record through all modules on a "per criminal charge" basis and not for total individual record. R.3.1.12 System will provide a means to consolidate or combine duplicate name records R.3.1.13 System will allow editing and updating of Page | 97
    • any personal identifiers or information for any record in the master name file. R.3.1.14 System will allow a designation between names of individuals and names of businesses. R.3.1.15 System will allow entry of names with minimum elements of first and last name. R.3.1.16 System will allow name validation lookup utilizing soundex and with minimum of one alphabetic character to initiate search. R.3.1.17 System will have date of birth and other parameters compliant with State and National configuration requirements. (i.e., MMDDYYYY) R.3.1.18 System will accept names into master name file by multiple methods including, but not limited to, manual data entry, mag or card swipe, etc. R.3.1.19 System will allow for user configurable name types and involvement types. R.3.1.20 System will have a means to audit names and generate report for consolidation and allow end user to consolidate one or multiple names in a single process. R.3.1.21 System will have capability to record personal information including, but not limited to: Last Name First Name Middle Name Date of Birth Street Address City State Zip Residence Phone Business Phone Alternate Phone Sex Race Ethnicity Citizenry Height Weight Eye Color Hair Color Social Security Number Driver License Number Driver License State Driver License Type State ID Number Page | 98
    • Federal ID Number Fingerprint Number Scars, Marks, Tattoos Arrest History Event History Case History Citation History Field Contact History Photos Warrants Aliases and Nicknames Gang Affiliations (State Defined per Statute) Known Associates Address History School History Employment History Relationship Information (Parents, etc.) Narrative R.3.1.22 System will automatically and dynamically track and calculate age and adult or juvenile status on all name entries containing date of birth. R.3.1.23 System will display age and age status (juvenile or adult) on initial screen for any name queried in the master file. R.3.1.24 System will allow manual entry of juvenile or adult status to any record in master file with or without recorded date of birth. R.3.2 Vehicle R.3.2.1 System will allow automatic population of any field within RMS that is being returned from a State or National vehicle query. R.3.2.2 When entering information manually, system will audit all entries to ensure correct number of characters in VIN, etc. and validate against all vehicles entered in internal database. R.3.2.3 System will allow vehicle make and model categories to be easily upgraded to NCIC standards and have those codes available to all users at first sign on after upgrade. R.3.2.4 System will allow for user definability of vehicle involvement codes to include, but not limited to, accidents, citations and forfeiture tracking. R.3.2.5 System will allow user definability of relationships to vehicle to include, but not limited to, owner, driver, passenger, etc. R.3.2.6 System will have the capability to record vehicle information including, but not Page | 99
    • limited to: Vehicle Make Vehicle Model Vehicle Year Vehicle Identification (VIN) Vehicle Style Vehicle Type Vehicle Color Vehicle Features Vehicle Involvement Vehicle Status Vehicle Disposition Vehicle Value Vehicle Damage Vehicle Relationship(s) Vehicle Registered Owner (See Names) License Plate Number License State License / Registration Year Vehicle Stolen / Recovered Location Vehicle Owner Notification Vehicle Forfeiture Information R.3.3 Location R.3.3.1 System will allow automatic population of initial event record with validated address from CAD or mobile. R.3.3.2 Any subsequent address entry will automatically validate against geo-based master location file if address is in local jurisdiction. System will have the ability to record location information including, but not R.3.3.3 limited to: Street Number Street Name Street Type Street Direction Suite or Apartment Number City State Zip Location Name Cross Street or Intersection Cross Street / Intersection Type Location Type Occupancy Date Property ID (PIN) Number Lat / Long Coordinates R.4.0 Arrest R.4.0.1 User must be able to utilize information from CAD event and/ or RMS to initiate the Page | 100
    • arrest record with a minimal amount of duplication of effort. (3-4 keystrokes) R.4.0.2 Arrest application should have the capability for multiple charging and varying dispositions per charge. R.4.0.3 System must be interfaced and allow for all information entered during the booking process to populate arrest fields including, but not limited to, all arrestee personal identifiers and information, charge(s) at time of arrest, disposition of arrestee, fingerprint and photo information. R.4.0.5 System must allow for user-definable searchable fields for agency specific information. R.4.0.6 System must allow clearance of multiple events with a single process. R.4.0.7 System will have the ability to record arrest information including, but not limited to: Arresting Agency (ORI) Arresting Officer Arrest / Booking Number Arrest Date Arrest Type Arrest Code (UCR / MOC) State Statute Arrest Offense Level Arrest Disposition Hold Date and Time Release Date and Time Release To / Transfer Information Release Reason Reason Held Custody Risk County of Jurisdiction Warrant Information Mandated Welfare Status Checks R.4.0.8 System will have the ability to audit entries before submittal for accuracy and completeness. R.4.0.9 System will have the ability to interface and automatically transfer arrest records including, but not limited to: CriMNet (State) State Probation and Parole (S3) Department of Public Safety Fingerprinting Driver License Revocations Intoxilyzer Results Minnesota Court Information System “MNCIS” [Odyssey] Page | 101
    • R.5.0 Juvenile R.5.0.1 When there are individual involvements of juveniles, system will comply with requirements stated in Section 3.0 Master File Name, with special notation to Subsection R.3.1.2 and R.3.1.3. R.5.0.2 System must provide that a juvenile record designation remains a juvenile record historically regardless of age. R.5.0.3 System must maintain juvenile records separately from adult master file database. R.5.0.4 System must allow security level that can restrict access to information on juveniles. R.5.0.5 System will have the ability to easily or automatically redact information from juvenile reports when release of public information is required. R.5.0.6 System will allow user definable fields if they do not exist for entry of agency mandated data to include, but not limited to: parent information, school information, diversion programs, number of times diversion used, school notifications, etc. R.5.0.7 System will allow designation of drug, alcohol, or other illegal substance involvement per each juvenile event and will provide for that information to be summarized. R.5.0.8 System must allow for a juvenile designation even if a date of birth is not available. R.5.0.9 System will provide juvenile designation in such a manner that it is immediately apparent upon viewing a record. (See Section R.3.1, Master File, Name, Subsection R.3.1.20, R.3.1.21 and R.3.1.22). R.5.0.10 System will provide a means to search for in-custody individuals by adult or juvenile status. R.6.0 Case Management & Investigations R.6.0.1 System will provide a means where the status, assignment, details and follow-up on any individual case will be clearly accessible to entire agency. R.6.0.2 System will have the ability to automatically transfer entire case file and all related data to Hennepin County or Agency Prosecutor (some scanned and digitized items included). R.6.0.3 System will provide a means to track assignment of case to any investigator. Page | 102
    • R.6.0.4 System will track timelines of each case to include, but not limited to, case assignment date and time, all follow-up dates and times, case charging date and time, case clearance date and time. R.6.0.5 System will have the ability to assign and track statuses to include, but not limited to, active, inactive, pending assignment, unassigned, cleared by arrest, cleared by formal complaint, and closed. R.6.0.6 System will have the ability to assign and schedule follow-up reminders by anyone having access to the case. R.6.0.7 System will have the ability to subset cases based on user defined criteria including, but not limited to, type of case, status of case, etc. R.6.0.8 System will have the ability to apply user defined solvability factors to any case. R.6.0.9 System will allow unlimited text narrative and attachment of any industry standard file format to be imported into a case file. R.6.0.10 System will allow searching and sub- setting certain file types to merge with standardized notification documents (i.e., victim notifications, etc.). R.6.0.11 System will have a user defined notification capability. (i.e., notify property manager when case assigned, etc.). R.6.0.12 System will have the ability to restrict, either temporarily or permanently, certain data elements within a case file or an entire case file. R.6.0.13 System will have the ability to track monetary transactions as well as forfeiture transactions. R.6.0.14 System will have the ability to track access and time stamp access to any case. R.6.0.15 System will have the ability to set user defined time parameters for archiving a case based on mandatory State and/or Federal requirements. R.6.1 Crime Analysis Capabilities R.6.1.1 System will have the ability to provide basic crime analysis based on raw data including, but not limited to: Activity Type (UCR, MOC or NIBRS based) Activity Type (User Defined) Time of Day Day of Week Combination Time of Day / Day of Week Date Range Page | 103
    • Address Range of Addresses Method of Operation Comparisons Time Comparisons (i.e., Year / Year) Level of Crime Case Clearance by Type Case Status by Type Frequency of Criminal Activity by Type Property Types Property Values Gang or Other Affiliations R.6.1.2 System will have the ability to pin map any analysis run on selected criteria. R.6.2 Inquiries and Reports R.6.2.1 System will have the capability to query on any field or combination of fields entered into the system. R.6.2.2 System will have the ability to produce alarm invoicing based on alarm counts per year and using sliding fee scale. R.7.0 Property & Evidence R.7.0.1 System will allow upgradeable tables based on mandatory fields required by NCIC and State agencies. R.7.0.2 System will provide complete audit trail and ability to track any movement or change in status for any piece of property or evidence. R.7.0.3 System will provide automatic validation against all internal and external databases based upon entry of certain unique identifiers. R.7.0.4 Utilizing the validation above, system will provide a means to match stolen property with recovered property. R.7.0.5 System will alert entry personnel if like property is found based on serial number, make and model, etc., or a combination of identifiers. R.7.0.6 System will provide for every piece of property or evidence a complete tracking of chain of custody / property movement to include, but not limited to: Date and Time of Receipt Person Receiving Date and Time of Release Person Releasing Reason for Release Date and Time Returned or other Disposition R.7.0.7 System must allow entry and updating of Page | 104
    • property to an event or case file by either in-house or mobile personnel. R.7.0.8 System must also interface property records with agency master name, master location, and master vehicle databases and allow user to view, add, delete and/or edit. R.7.0.9 System must allow entry of the following information, including but not limited to: Event Number Event Sequence Number (or auto- sequencing). Activity Code Property Record Type Property Type Released To Released From Property Make Property Model Property Size Property Color Property Serial, License or Unique Identifier Property Year Quantity Value Dates (Stolen, Recovered, Flagged, Transferred) Property Inventoried Location R.7.0.10 System will provide a means to easily replicate entries, if desired, when only minimal information changes (i.e. same property with different serial numbers only). R.7.0.11 System will automatically calculate total values, weights, etc. if multiple like items are listed in one property record. R.7.0.12 System will assure that all property objects can be queried by criteria including, but not limited to: Property Type Property Make Property Model Property Serial / Unique Identifier Date and Times Event Number Case File Number Location Bin / Tag Number Citation Number Property Status Person / Agency Holding Narrative Page | 105
    • R.7.0.13 System will provide the capability to enter property record types including, but not limited to: Stolen Property Stolen and Recovered Property Recovered Property Lost Property Damaged Property Evidentiary Property Property for Safekeeping Found Property R.7.0.14 System will have some means of notifying property clerk/manager if property disposition is changed (i.e. ready to release, etc.). R.7.0.15 System will have some means of automatically calculating days property held and notifying property clerk/manager if overdue or ready for disposition. R.7.0.16 System will allow user-definable status changes and reasons for release, etc. R.7.0.17 System will be capable of obtaining and archiving electronic signatures. R.7.0.18 System will integrate with bar coding hardware and software. R.7.0.19 System will integrate with State and Federal systems including, but not limited to, State CJRS and CRIS, NCIC, etc. R.8.0 Data Recall & Query R.8.0.1 System will have the ability to query on any field (or multiple of fields) and for any data set that has been entered into the system, including narratives. R.8.0.2 System will have the flexibility to search information in a number of ways including, but not limited to: Equal values Greater than, greater than or equal to Less than, less than or equal to Range of values Averages Counts Sums Wild card entries Soundex R.8.0.3 System will have the ability to search and print information in the form of summary data. R.8.0.4 System will have the ability to show number of records searched and number of records returned. Page | 106
    • R.8.0.5 System will have the ability to limit the number of records searched through user prompts and filters. R.8.0.6 System will have the ability to save and/or archive searches or queries for future use by compiler or others with appropriate access. R.8.0.7 System will have the ability to conduct basic queries to include all master files (names, locations, vehicles) while in any area or module of the system. R.8.0.8 System will allow for the ability to run a query interactively or to schedule the query for non-peak usage times. R.8.0.9 System will provide adequate processing capabilities for priority queries and searches run during normal or peak business hours. R.8.0.10 System will provide adequate interface to allow the capability to search all system records, files and modules using one search process. R.8.0.11 System will provide for extraction of search results into multiple Windows based industry standard formats including, but not limited to, Word, Excel, Access, PowerPoint, Mail Merge, etc. R.8.0.12 System will provide ability to query from any CAD, Records or Mobile application. R.8.0.13 System will have the ability to query not only user supplied data items, but also on returns from outside agencies, etc. (i.e., license plate returns, driver registration information, etc.) R.8.0.14 System will provide multiple methods to initiate a query or search including but not limited to: Allowing a user to choose fields, define the sort order and apply filters for records displayed. Allowing a user to filter the records displayed in a list. Allowing the user to search for a record based on information in a single field. R.8.0.15 System must provide some method of displaying search results in a browseable list. R.8.0.16 System must provide the ability to additionally subset a completed search and re-search the subset. R.9.0 Online & Printed Reports R.9.0.1 System will provide a non-technical, easy Page | 107
    • way for any user to run a report or create an ad hoc report. R.9.0.2 System must allow any query to be recorded into a reporting format and allow for use of a graphics editor to create line, bar, pie charts, etc. R.9.0.3 System must provide for some type of "ad hoc" reporting using English-like commands. R.9.0.4 System must allow flexibility of user defined report appearance including, but not limited to: Page Headings Column Headings Column Widths Page Numbering Sorting within a report Totaling and Sub-Totaling Variable font, margins, lines per page, page width Print to screen, print to printer, or both R.9.0.5 System must allow option of printing statistical data or totals only R.9.0.6 System will have the ability to save reports for future use by compiler or others with appropriate access. R.9.0.7 System will provide for exporting of report into multiple Windows based industry standard formats including, but not limited to, Word, Excel, Access, PowerPoint, Mail Merge, etc. R.9.0.8 System will support comparative arguments including, but not limited to: Include Exclude And Or Equal to Greater than, greater than or equal to Less than, less than or equal to Range of values R.9.0.9 System will have the capability to support the comparative arguments for both alpha and numeric values. R.9.0.10 System will allow selection by multiple values for a field or matching fields from multiple files. R.9.0.11 System will have the ability to merge reports. R.9.0.12 System will have ability to schedule report generation by day, day and time, day of Page | 108
    • week or intervals. R.9.0.13 System will have a simple means for a user to cancel a report at any time i.e., to save or better allocate resources, due to errors in field input in report request, etc. R.9.0.14 System must allow reports to be saved in common file formats that can be sent electronically and easily read on most PC's. R.9.0.15 System must support standard SQL report writing software (i.e. Crystal Reports, Access, ASP.Net etc.) R.9.0.16 System must provide a number of standard generic reports that might be used by any agency (i.e., daily activity report). R.9.0.17 System should have the ability to generate reports based on, but not limited to: Part 1 Crimes Part 2 Crimes Non-Criminal Activities Audit reports for State entries R.9.0.18 System will provide a non-technical, easy way for any user to run a report or create an ad hoc report. R.10.0 State & Other Mandatory Reporting R.10.0.1 System must support reporting to the National Incident Based Reporting System standards. R.10.0.2 System must support reporting to the State CJIS and CJRS systems by use of MOC (Minnesota Offense Codes). R.10.0.3 System must support reporting to the State using IBRS (Incident Based Reporting) standards. R.10.0.4 System must provide an open architecture allowing for reporting to any State or National agency as may be required in the future. R.10.0.5 (See "Interface" section) R.11.0 Record Control & Distribution R.11.0.1 System will have a user-defined ability to make automatic notifications based on change or entry of data criteria including, but not limited to: Notify Based on Case Type Notify Based on Case Status Notify Based on Juvenile Involvement Notify Based on Task Force Involvement Notify Based on Public versus Non-Public Notify Based on External Mandatory Reporting Page | 109
    • Notify Based on Sealed Record R.11.0.2 System should have the user defined ability to set parameters for victim notifications. R.11.0.3 System should have a means of document tracking any release of report to any outside agency or others. R.12.0 Traffic and Citation Management R.12.1 Accidents R.12.1.1 System must allow for MN State accident reports to be written and drawn using the DVS web site electronic forms and automatically downloaded into the Police RMS. R.12.1.2 System must provide that all information collected including, but not limited to, persons, vehicles, will be auto-populated into the RMS. R.12.1.3 System will allow integration of accident scene photos and accident reconstruction drawings to be attached to an event. R.12.1.4 System will have the capability to capture DL photo and driver information and automatically populate appropriate fields in the Police RMS. R.12.1.5 System will have the capability to allow any part of an accident report to be done manually and then added to previously electronically submitted data (i.e., add diagramming later, etc.) R.12.1.6 System will allow for change in diagrams and will provide an audit trail of any changes or edits. R.12.1.7 System will have the capability to do lookups against the Master Name and Master Vehicle files for previously entered individuals and vehicles. R.12.1.8 System will have the capability to capture information at a squad level and populate all necessary information into RMS R.12.1.9 System will support use of all captured information for use in statistical reports including, but not limited to, frequency of location, vehicle types, seat belt usage, injuries, type of roadway, causes, alcohol or substance involvement, use of helmets, etc. R.12.1.10 System will be able to provide data for traffic management purposes including integration for pin mapping. R.12.2 Impounds and Towing R.12.1.10 System will be able to provide data for Page | 110
    • traffic management purposes including integration for pin mapping. R.12.2.1 System will have the ability to track tows, impounds, vehicle forfeitures, and repossessions. R.12.2.2 System will allow a date and/or time notification to be set for impounds for forfeiture, impounds held as evidence, etc. R.12.2.3 System will provide audit trail of impounds, notification of owners and dispositions. R.12.2.4 Impounds and tows will be integrated into the Vehicle Master for query and reporting capabilities. R.12.3 Citations and Warnings R.12.3.1 System must provide the capability of capturing citation information using either a remote field unit or an internal LAN PC. R.12.3.2 System will be integrated and perform a lookup in both Master Name and Master Vehicle files to eliminate redundant entry. R.12.3.3 System will allow user to overwrite / update current master name or vehicle information and system will attach new information as most recent. R.12.3.4 System will allow for multiple offense charges on one single citation. R.12.3.5 System will allow for entry of multiple officers / badge numbers to a single citation and denote primary and secondary assignment. R.12.3.6 System will allow entry of officer field notes but will provide a means to redact those notes from offender or public copies. R.12.3.7 System will allow a method of "copy over" for multiple citations written simultaneously to a single offender. This function should copy over all but additional charge information to eliminate redundancy. R.12.3.8 System will allow for integration of bar code, card swipe or other technology for gathering driver information and automatically transmit and populate citation fields in the RMS module and transmit citation data to State Court System. R.12.3.9 System will allow for issuance and printing of a citation from a remote unit. R.12.3.10 System will allow for information that is returned from a State DL record inquiry to automatically populate the citation fields. R.12.3.11 System will allow the driver license photo to be attached to the citation record and transmitted to RMS. Page | 111
    • R.12.3.12 System will provide the ability to enter, track and audit all court assignments and dispositions with regard to a citation. R.12.3.13 System will provide user-definable screens and fields and allow fields to be disabled for ease of entry and flow. (i.e., parking complaint versus speed complaint). R.12.3.14 System will allow entry of warnings that do not have an identifying number. System will allow attachment to an individual or a vehicle. Page | 112
    • Mobiles Index M.1.0 Mobile General M.1.1 Mobile Overall M.2.0 Dispatch Receipt M.3.0 Mobile Data Searches M.3.1 External - National/State/County M.3.2 Internal - Agency RMS M.4.0 Field Reporting M.5.0 Mobile Mapping/AVL M.6.0 Messaging M.7.0 Mobile Reports / Notifications M.7.1 Citations M.7.2 Accidents M.7.3 Alarms M.7.4 Field Contacts / Warnings M.8.0 Equipment and Peripheral Integration M.8.1 Magnetic/Bar Code Reader M.8.2 Digital Photo Integration M.8.3 Printer MOBILES M.1.0 Mobile General Y/N/M/F Comment M.1.1 Mobile Overall M.1.1.1 System must interface to and allow flexibility of various types of mobile hardware including, but not limited to, tablets, modular mobiles, fixed Mobile Data Computer, portable laptop, PDA, Pager, etc. M.1.1.2 System must be capable of interfacing to LAN or WAN and any type of wireless communication including, but not limited to: CDMA GPRS 800 MHz EVDO 1, 2, 3, 4G, etc. M.1.1.3 System will be capable of multi-protocol support and assure that all protocols can be combined into a seamless network. M.1.1.4 System will allow for future voice response input and text to speech output as well as multi-media file formats. M.1.1.5 The user interface shall be a Graphical User Interface (GUI) and utilize menus, shortcuts and function keys. M.1.1.6 System must be designed or have user configurability for task buttons and font size Page | 113
    • for readability and ease of use for the conditions of the mobile environment. M.1.1.7 System will allow integration with standard Microsoft Windows program applications and allow those applications to be run on the same hardware as (and in conjunction with) police, fire or EMS applications. M.1.1.8 System will allow multiple forms of navigation including, but not limited to, touch screen, mouse, function key, programmed key, icon, tabbing, etc. M.1.1.9 System will allow promptable user-defined tables, screens and forms. M.1.1.10 The system will provide text-sensitive on line and editable help screens. M.1.1.11 System will allow updates to all user defined tables, etc. to be dynamically downloaded at next mobile logon subsequent to system update. M.1.1.12 System will allow, within any field that has a drop down table or for fields validating against a master file, the ability to type in a single or a string of characters and immediately place cursor at that alphabetic location within the table. M.1.1.13 The system will require user to log on using an employee number or user ID and password. The system should also allow for future biometric log on capabilities. M.1.1.14 System will allow remote log on for support and maintenance. M.1.1.15 System will allow mobile application to be run from a personal computer in a LAN environment for training, screen modifications, etc. M.1.1.16 System will allow system administration in the mobile environment either for an individual unit or by mobile groups. M.1.1.17 System will allow flexibility of screen layouts in the mobile environment with a simple method to return to fixed, defaulted screens. M.1.1.18 System will make available all unread messages and responses at the time of individual's or unit's next log on. M.1.1.19 System will allow dispatchers to log mobiles on and off the system from CAD. M.1.1.20 System will perform a validation that will not allow multiple or duplicate log on for a single device. M.1.1.21 System will provide a means to access, without overtaxing bandwidths, commonly used data, including but not limited to: Page | 114
    • Minnesota State Statutes Local Ordinances and Code Department Manual Agency Personnel Lists Roll Call Informational Data Floor Plans M.1.1.22 System will provide both a visual and audible notification of any incoming traffic including, but not limited to, dispatches, dispatch updates, messages, returns, etc. M.1.1.23 System will automatically force the display of any dispatch or dispatch update to over- display anything currently on the mobile screen. M.1.1.24 System will allow dispatch information to dynamically display without loss of information or placement in current program or without leaving current program to access and view the dispatch. M.1.1.25 System must provide a means to designate message types or message priorities. M.1.1.26 System must allow agency to define what events and processes within mobile application receive audio and visual alerts. M.1.1.27 System will provide a mechanism for both mobile user and CAD dispatcher to verify transmission and receipt of any type of communication or message. M.1.1.28 System will allow for notification if transmission of a queued message does not complete. M.1.1.29 System will allow for multiple persons to be assigned to a unit and provide a means to manage all messaging, etc. going to an individual assigned to a shared unit. M.1.1.30 System will allow for user defined Internet access by individual user or groups to include full access or limited access via proxy server. M.1.1.31 System must allow for bandwidth prioritization for emergency communications versus standard messaging. M.1.1.32 System must have an open architecture to allow future expansion using third party components. M.1.1.33 System must allow for user definable toolbars. M.1.1.34 System must provide an officer emergency key which can be activated in a surreptitious manner but cannot easily be activated in error. This emergency key will notify dispatchers and any other mobile units of Page | 115
    • officer/unit number and location at a minimum. M.1.1.35 System must work in conjunction with global positioning system (GPS) providing latitude, longitude, speed and direction of travel. M.1.1.36 System will also support automatic vehicle location (AVL) through the GPS facility to allow vehicle tracking. M.1.1.37 System will have a way to notify mobile user that additional information is available if it is not totally presentable on one mobile screen. M.2.0 Dispatch Receipt M.2.0.1 System will provide for mobile communications using any of several means of wireless topology. M.2.0.2 System will provide for display of all event information available at dispatch to the mobile unit in a GUI, user-friendly format. M.2.0.3 System will assure that all dispatches to a mobile unit are forced or overlaid to the mobile screen no matter what program is currently in use by the mobile unit. (See M.1.1.23 and .24 above) M.2.0.4 System will dynamically display all updates to an event modified in CAD without requiring mobile user intervention. (see M.1.1.23 and .24 above) M.2.0.5 System will provide updates to an event in such a manner that mobile user does not have to scroll, page up, page down or in any other manner intervene in order to recognize or receive the update. M.2.0.6 System will provide mobile user a method to perform simple functions, such as status change, acknowledgements, etc. with one keystroke, function key or programmed key. M.2.0.7 System will provide a means to automatically and dynamically provide the mobile unit with all histories, alerts, etc., that are provided to CAD at the time of location validation when the event is sent to the mobile unit. M.2.0.8 System will provide a means to run queries to interfaces via several methods including, but not limited to, card or magnetic swiping, manual entry, fingerprint, or other biometric method. M.2.0.9 System will automatically query all local databases (RMS master location, name, etc.) when information is entered by the mobile unit. Page | 116
    • M.2.0.10 System will provide a means to run multiple queries simultaneously via single entry of name and DOB, license plate or license number including, but not limited to: Plate: MN Vehicle Registration Plate: MN Vehicle Clear Check Plate: MN DL on Registered Owner & 2nd RO Plate: MN Clear Check on RO & 2nd RO Plate: NCIC Clear Check on RO & 2nd RO Name or DL: MN DL on RO & 2nd RO Name or DL: MN Clear Check on RO & 2nd RO Name or DL: NCIC Clear Check on RO & 2nd RO M.2.0.11 System must have the ability to view all units presently signed into the system to include CAD terminals. M.2.0.12 System must have the ability to view all events either active or pending. M.2.0.13 System must have the ability to view and transmit photo images. M.2.0.14 System must have the ability to close out and dispose of an event utilizing user defined drop down options (including EMS information such as hospital transport location) and narrative text. M.2.0.15 System will not allow clearance of an event without disposition by either a mobile unit or a dispatcher. M.2.0.16 System will automatically make a unit available upon final disposition of an event. M.2.0.17 System will allow for duplicate user defined receipt of all mobile communications to a supervisory mobile or terminal. M.2.0.18 System must display the following data fields to the mobile unit including, but not limited to: Event number Event Date and Time Event Primary Location Event Revised Location Caller Name Caller Address Caller Phone Received Date and Time Lat/Long Coordinates Event Type Event Priority Call Source Call Comments and Free Form Text Field Page | 117
    • Closest Intersection Event Disposition M.2.0.19 System must allow dispatcher ability to easily and directly transmit information directly from CAD to mobile unit without editing, cutting, pasting, etc. M.2.0.20 System must allow for mobile unit to self- initiate an event and assign a case or event number from the mobile unit that is within the sequential numbering used in CAD. M.2.0.21 System will provide location validation against the master file for mobile self- initiated events. M.2.0.22 System must allow mobile unit to override a validated location if desired. M.2.0.23 System must allow mobile unit to downgrade the priority of an event from the field. M.2.0.24 System will provide an audit trail of all changes made to an event from a mobile unit. M.3.0 Mobile Data Searches M.3.1 External - National/State/County M.3.1.1 System must provide the capability to search non-agency databases without leaving mobile application or initiating separate sessions, etc. M.3.1.2 System must also allow query returns to be viewed without leaving mobile application. M.3.1.3 System must have the ability to search State and National databases including, but not limited to: MNCIS State Database (CriMNet) NCIC DVS (Department of Vehicle Services) HennRap (Hennepin County Photos) MRAP (MN Repository of Arrest Photos) AFIS or Fingerprint Database Courts Federal, State or County Warrants M.3.1.4 System must have the ability to search State and National databases for information on persons, vehicles or articles. M.3.1.5 System must have the ability to receive at mobile level what are commonly called Administrative Messages sent by both State and NCIC without dispatcher intervention. M.3.1.6 System must have the ability to run multiple plates simultaneously and group the returns per individual plate. M.3.1.7 System must allow for easy viewing of multi- lined or paged returns to the mobile user. Page | 118
    • M.3.1.8 System will archive all query returns for a user defined time limit at the mobile level. M.3.1.9 System will have a means to notify user when archival or other files are reaching allocated maximum space requirements. M.3.1.10 System will allow both manual and scheduled deletion of such files. M.3.2 Internal - Agency RMS M.3.2.1 System will allow mobile search of all CAD and RMS events by multiple criteria to include, but not limited to: Name (Partial or Full) Address or other Location Address Range Event Number Date and/or Time of Event Event Type Plate Number Badge and/or Unit Number Disposition Code M.3.2.2 Query results presented to mobile user will be displayed chronologically beginning with the most recent. M.3.2.3 Queries and searches will access the entire RMS database to include, but not limited to, location master, name master, property module, citations, accidents, etc. M.3.2.4 System will allow access to other inter- department data to include, but not limited to (vendor to define): Agency Personnel Lists Mobile Phone or Pager Numbers City Codes and Ordinances Alarm Vendor Data State Contacts and Numbers Federal Contacts and Numbers Outside Police Agencies Mutual Aid Contacts and Numbers Call Out Rosters Roll Call Updates Emergency Response Teams Narcotics, Gang or Specialized Units M.3.2.5 All searches should be printable either in the car or to the station. Both locations are preferred. M.4.0 Field Reporting M.4.0.1 System must provide autofill of all data fields that have been previously supplied by CAD or the mobile user. M.4.0.2 System must provide logical flow and entry for any type of field report. User should not Page | 119
    • be required to navigate between many screens or open and close modules to complete a report. M.4.0.3 System must have user definable screens and data fields with option to disallow any fields the agency chooses not to use. M.4.0.4 System must allow user definable drop down tables for entry of data fields. M.4.0.5 System must allow for automatic, dynamic updates for any screens, forms, fields or tables when mobile user logs on next. System should be able to update from a central administrative location and not each mobile unit. M.4.0.6 Updates and upgrades should automatically download, should not warrant significant down time, and should not warrant extensive computer knowledge to apply. M.4.0.7 Field Reporting must be totally integrated to RMS and allow entry of reports including, but not limited to: Police, Fire or EMS Incident Report Arrest Report Property / Evidence Report Citation Field Interview or Contact Accident Reports or Info Exchange Tow Reports Residential or Business Alarms Standardized Department Templates and Forms Narrative Supplements M.4.0.8 System must download information captured in CAD or through a query or card swipe, etc. into appropriate fields in field report. M.4.0.9 System will allow user to override any captured information that has been autofilled into report fields. M.4.0.10 System will allow user to attach any type of industry standard digital, audio or multi- media files to a field report including, but not limited to, jpg, gif, wav, etc. M.4.0.11 System will allow use of a drawing program for such items as scene recreation, etc., that will attach to the field report. M.4.0.12 System will allow a report to be initiated at the field level and completed in house or initiated in house and completed in the field. M.4.0.13 System will allow flexibility in transfer of report between field mobile unit and agency headquarters for review and approval by Page | 120
    • supervisory personnel. M.4.0.14 System will allow the user to easily assign temporary review privileges to cover such events as vacations, shift changes, etc. M.4.0.15 System will automatically audit and track each report, update and transmission and provide logging. M.4.0.16 System will allow updating by supervisory personnel to include final review and addition of Minnesota Offense Code (MOC) or any other state or federally mandated coding. M.4.0.17 System will allow viewing of any report based on user privileges while in any stage of editing or review. M.4.0.18 When report has been approved after final supervisory review, system will assure that it is available for viewing, printing, updating or supplementing by any user. M.5.0 Mobile Mapping/AVL M.5.0.1 System must have the ability to interface agency ESRI or ArcView mapping into the mobile environment. M.5.0.2 System will assure that exact mapping used throughout all other modules will be available for exact use in the mobile environment. M.5.0.3 System will provide, at mobile receipt of event, a visual representation of that event on the mobile mapping product. M.5.0.4 Mapping will have several features to include ESRI shapefile overlays, zoom, expand, address lookup, premise/alias lookup, etc. M.5.0.5 System will provide various means to interact within the map to include, but not limited to, mouse, touch screen, keyboard and preprogrammed function keys. M.5.0.6 System will provide validation methods from the mobile environment equal to the CAD validation process. (See CAD Section C.3.4) These capabilities include, but are not limited to: number of personnel on duty, special events, priority of event, etc. M.5.0.7 System will validate location based on street number, street name, street directional, street type and suite or apartment number. M.5.0.8 All locations, whether in or out of city, must show the agency jurisdiction of each address being validated within the system at time of entry. M.5.0.9 System will provide, in the case of partial Page | 121
    • address entry, multiple selections based on Soundex or phonetics and displayed as a drop down option with the most likely validation being listed first. M.5.0.10 System will allow in cases of multiple pages / screens of returned addresses (i.e., multiple dwelling or apartment listings) a simple method to page up / page down to review selections. M.5.0.11 System will allow validation with as few as one character, alpha or numeric, input. M.5.0.12 System will present valid street ranges if a correct street but incorrect street number is entered by dispatcher. M.5.0.13 System will allow a simple one-keystroke method to select correct address from multiples without necessitating retyping of the location. M.5.0.14 System must allow override of any location whether in or out of jurisdiction. M.5.0.15 System will allow location validation for intersections without dependence on which might be entered in the first position. M.5.0.16 System will display, based on entry of one street, all valid intersecting streets if location type chosen is intersection. M.5.0.17 System will validate the address whether initially entered by dispatch or a mobile unit. M.5.0.18 System must allow validation to commonplace names that may / may not have an exact street address (i.e., parks, etc.) M.5.0.19 System will allow for multiple commonplace names to be used for any one location. M.5.0.20 When a commonplace name is entered for validation, system will select the validated address of that name as the correct location. M.5.0.21 System must audit and report all location entries that do not validate and allow update in location geofile with most current information at time of event entry without changing historical records. M.5.0.22 System will allow for a change of location of an event and dynamically update the location for all signed on users. M.5.0.23 System will provide complete AVL software solution that is integrated to CAD mapping. M.5.0.24 System must support differential. M.5.0.25 System should have the ability to display the GPS signal strength. M.5.0.26 System must allow for user defined refresh Page | 122
    • capability at the CAD level for all units using AVL. M.5.0.27 System should provide the ability to query the location of a unit(s) for a defined period of time. M.5.0.28 System should provide mobile unit direction of travel at the CAD level. M.5.0.29 System must provide a means to alert CAD if a mobile unit is at a location exceeding a user-defined time limitation. M.5.0.30 System must provide a means of tracking and archiving the speed of any mobile unit and have this information available to query. M.5.0.31 System must provide a means of assigning a mobile unit to a pre-defined default location (unless on a call) should the AVL malfunction. M.5.0.32 System must provide the capability to use AVL and GPS for the selection and recommendation of mobile units based on unit closest to event with the most expedient route. M.5.0.33 System must provide user definability of the available status of a unit for recommendation to an event. M.5.0.34 System should provide user definable control of the polling and transmission of unit location data by methods including, but not limited to: Set Time Intervals Distance of Travel Speed in Excess of Set Parameter Unit Transmission of Status Update Activation of Emergency Lighting Dispatcher Requested Update M.5.0.35 The ability to monitor units shall be from any desktop computer designated by administration. The number of monitoring locations should not be limited. M.6.0 Messaging M.6.0.1 System must provide a means to designate message type and message priority. M.6.0.2 System must allow user defined message priority but also base priority on type and bandwidth availability. M.6.0.3 System will provide a mechanism for mobile user and CAD to verify transmission and receipt of any message or communication. M.6.0.4 System must provide a way to store and forward messages for mobile user initial sign on. M.6.0.5 System will provide an audible and visual Page | 123
    • alert of incoming message transmission. M.6.0.6 System will provide the following information in each message to include, but not limited to: Message Text Message Sender Message Receiver Date and Time Stamp Mobile Unit Number M.6.0.7 System must allow for transmission of group messages. M.6.0.8 System will provide a means to not only receive transmissions sent from State and National interfaces to a particular unit, but also the capability to receive group or unsolicited messages. M.6.0.9 System must allow for archiving of messages and transmissions and for user definable deletion. M.6.0.10 System will assure that all transmissions may be archived and queried. M.6.0.11 System will, if storing messages locally on mobile unit, have the ability to alert user if storage of transmissions is reaching maximum capacity. M.6.0.12 System will give the mobile user the ability to review messages, transmissions, events, etc. sent / received from the mobile unit. M.6.0.13 System must have the ability to send or receive any industry standard files (i.e., jpg, gif, wav, etc.) attached to a communication. M.6.0.14 System will support messaging via multiple hardware topologies to include laptops, tablets, PDA's, etc. M.7.0 Mobile Reports / Notifications M.7.1 Citations M.7.1.1 System must allow for manual input, input from a bar code or magnetic stripe reader, and/or State interface return to auto- populate the appropriate fields of the citation form as obtained from the driver license. .7.1.2 System should allow for promptable drop down listings of State Statutes and City Code/Ordinances with literal descriptions. M.7.1.3 System should automatically transmit all information from the citation as created in the mobile unit into the RMS system. RMS module must have the ability to void the citation if necessary. M.7.1.4 System should automatically validate against the Master Name, Vehicle and Page | 124
    • Location files before creation of a new record. M.7.1.5 System should allow for printing of multiple copies of the citation at the mobile level. M.7.1.6 System should allow for differential of agency copy of citation versus defendant copy to redact officer notes, etc. M.7.1.7 System should allow mobile user the option to create an event number or to decline. M.7.1.8 System should allow for automatic electronic transmittal of the citation to the Hennepin County Court without further user intervention or entry procedures. M.7.1.9 System will have same information and collectible data fields in mobile application as in RMS. M.7.2 Accidents M.7.2.1 System must allow for manual input, input from a bar code or magnetic stripe reader, and/or State interface return to auto- populate the appropriate fields of the accident report as obtained from the driver license. M.7.2.2 System should allow for promptable drop down listings of all contributors or fields of the State accident report form. M.7.2.3 System should automatically transmit all information from the accident report as created in the mobile unit into the RMS system. M.7.2.4 System should automatically validate against the Master Name, Vehicle, and Location files before creation of a new record. M.7.2.5 System should allow for printing of multiple copies of the accident report at the mobile level. M.7.2.6 System should allow for differentiation of a State accident report and an accident exchange of information but should transmit information from both to RMS. M.7.2.7 System should allow for automatic electronic transmittal of the accident report to the Minnesota Department of Motor Vehicles (DVS) without further user intervention or entry procedures. M.7.2.8 System should allow for revisions / changes to an accident report to be updated to the original State and RMS record and also without creating a new event number. M.7.2.9 System will have same information and collectible data fields in mobile application Page | 125
    • as in RMS. M.7.3 Alarms M.7.3.1 System will allow for an alarm card to be completed at the mobile level and will automatically forward all data to RMS. M.7.3.2 System will allow for a validation against the Master Name and Location files and auto- populate information from those files to include alarm company. M.7.3.3 System will allow integration with a field printer so that alarm notifications can be printed and left at the scene. M.7.3.4 System will allow for mobile user to designate either as chargeable or non- chargeable alarm. M.7.4 Field Contacts / Warnings M.7.4.1 System will allow entry of names, validated against Master Name file, without assigning event number. M.7.4.2 System will allow for user definable contact types and reasons and will allow queries against the data. M.7.4.3 System will automatically attach contacts and warnings to the Master Name file. M.7.4.4 System will allow field contact information for both individuals and vehicles. M.7.4.5 System will allow use of a mag stripe or card reader and in squad printing capabilities. M.8.0 Equipment and Peripheral Integration M.8.0.1 System will integrate peripherals, including but not limited to thermal printers, optical and/or magnetic card swipes, digital media, fingerprint security sign-on, handheld units (citation writers, PDA units, etc.). (NOTE: Handheld and/or portable units are necessary for motorcycle, bicycle, parking enforcement and other non-squad activities.) M.8.1 Magnetic/Bar Code Reader M.8.1.1 System will, upon scanning a driver's license from any state, understand the information on the license and transfer it to the appropriate form. M.8.1.2 The system will support industry standard card readers. M.8.2 Digital Photo Integration M.8.2.1 The system will support the insertion of digital photos through a media card input port. M.8.3 Printer M.8.3.1 Two (2) printers will be needed for in-squad Page | 126
    • printing with one being a thermal printer. Page | 127
    • Interface Requirement Index Internal Interfaces I.1.0 CIS Interface I.1.1 Pagers I.1.2 Alarms I.1.3 Reverse 911 I.1.4 Fire RMS I.1.5 E-mail I.1.6 Master Clock Time Server I.1.7 E911 AND TDD Interface I.1.8 Winscribe Dictation/Transcription I.1.9 Internet Web Portal I.1.10 Motorola Toning/Alert System I.1.11 EP Warning/Citation Writer External Interfaces I.2.0 Hennepin County Warrants I.2.1 DVS/ CJIS / NCIC I.2.2 CJRS (MOC) / NIBRS (UCR) I.2.3 CriMNet CIBRS I.2.4 MN State Courts Message Switch I.2.5 Radio System (800 MHz) I.2.6 CAD-to-CAD (APCO Project 36 Interface) I.2.7 Dynamic Imaging (HENNRAP/MRAP) I.2.8 LiveScan Fingerprinting (BCA) I.2.9 Statewide Supervision System (MN DOC) I.2.10 NFIRS (State Fire Marshall) I.2.11 Aspen Commercial Vehicle Inspection I.2.12 Message Switch I.2.13 MN DVS Crash Reporting System I.2.14 National Grid System (FEMA) INTERFACES I.1.0 EP CIS Y/N/M/F Comment I.1.0.1 The CAD and RMS systems must allow for full integration with the Eden Prairie in- house CIS (Computer Information System), an ASP/SQL/HTML browser based reporting system. I.1.0.2 Vendor must provide username and password access to database backend for customized read only web based reporting I.1.0.3 Vendor must provide data dictionary and Page | 128
    • table relationships for CAD and RMS database(s). I.1.0.4 System shall be SQL or other ODBC compliant database I.1.1 PAGERS I.1.1.1 The interface shall allow CAD users to send short messages (less than 256 char- acters) to Fire, Police and EMS staff who have digital pagers. Vendor will discuss technical structure and standard ASCII, XML, etc. and how to integrate messages into other applications and architectures. I.1.1.2 The system will provide an option for group paging, allowing pre-selected groups or user selected groups to be chosen. I.1.1.3 The CAD system shall have the ability to send event notifications to selected pagers. I.1.1.4 The System Administrator shall have the ability to designate which event types or alarm level will trigger an event notification and to whom. I.1.2 ALARMS I.1.2.1 The System shall integrate with the Scada /Ultrac System. Locations for event notification and immediate data transfer of premise information I.1.2.2 The System will activate CAD incidents based on real-time parameters such as alarms and/or events, and also provide capability for automated printing, e-mailing, or paging to immediately inform technicians of alarm status and actions. I.1.2.3 System will allow trend analysis from work order history provides information to implement predictive maintenance strategies. I.1.2.4 System will allow re-transmission of alarm data to specified cell phones, pagers, e- mail accounts and fire stations. I.1.2.5 The CAD system will provide closed-loop feedback to alarm system to acknowledge receipt of alarm and event close out in a timely manner. I.1.3 REVERSE 911 I.1.3.1 System will allow interface to reverse 911 and provide use of both CAD map-based geographic and list calling functionality. I.1.3.2 System will be integrated to allow designated users the ability to change geographic call areas within reverse 911 on the fly and update lists dynamically to Page | 129
    • all user positions. I.1.3.3 System will be integrated to allow for message grouping including, but not limited to, law enforcement agencies, emergency management agencies, health care organizations, transportation, utility departments, etc. I.1.3.4 System will allow reverse 911 system to be integrated with the E911 phone database. I.1.3.5 System will allow both numeric and alpha paging at CAD position. I.1.3.6 System will allow integration for seizing non-dedicated phone lines during callout and not impede any functionality of the total system. I.1.3.7 System must allow for the CAD map-based geographic capability to be used at an off site facility. I.1.3.8 System must allow for a faxing notifications and also notifying by TTY/TDD. I.5.0 FIRE RMS I.5.0.1 The system will integrate to Firehouse RMS with the ability to transfer full incident information as required to create an event in Firehouse. I.5.0.2 The system will adhere to basic NFIRS reporting standards to maintain records and forward data to Firehouse RMS. I.5.0.3 I.1.5 E-MAIL I.1.5.1 For e-mail purposes, the system must interface to a Microsoft Exchange Server or shall be inclusive as part of the internal application. I.1.5.2 If e-mail system is internal, system must allow receipt acknowledgment of email message in same manner as text messages. I.1.5.3 When a message is received at the destination terminal, it must be signaled to the receiver by a counter display and tone. I.1.5.4 The system must allow users to forward, reply, save and delete received messages. I.1.5.5 The system must allow users to send Certified Mail. System sends an automatic message back to the sender when the mail is opened. I.1.5.6 The system must allow users to send Acknowledgement Required. Requires the recipient to reply to the E-mail before they can delete I.1.5.7 The system must allow users to send Page | 130
    • priority mail messages. I.1.5.8 The system must allow users to send mail to a specific person(s) by personnel name or badge number I.1.5.9 The system must allow users to send mail to all on-duty or off-duty personnel I.1.5.10 The system must allow users to send mail to a specific console(s) position(s) I.1.5.11 The system must allow users to send mail to mobile unit(s) I.1.5.12 Send mail to predefined groups (i.e. all dispatchers, all supervisors). These maybe any combination of user defined groups such as consoles, personnel, mobile units, external e-mail. I.1.5.13 The system shall support separate message counters to allow the users to see the number of messages to the position, user signed-on, and external messages received. I.1.5.14 The system will allow messages to be routed to any system printer. I.1.5.15 The system will differentiate between e- mail messages and messages returning from State/NCIC. I.1.5.16 The CAD system shall have the ability to send / receive E-mail messages to CAD system users, mobile system, and external SMTP-compliant E-mail systems. I.1.5.17 The CAD system shall have the ability to send notification and recurring messages. Messages maybe defined to be sent for a defined number of times by hour, days, weeks, and months. I.1.6 MASTER CLOCK I.1.6.1 All applications shall include an interface to a Spectracom Ethernet time server model 9288 NTP master time source I.1.6.2 The system shall automatically reset all application time clocks from the master time source at least once ever thirty minutes I.1.6.3 It is desired that the application use Uniform Continuous Time (UCT) at the system level with display in local time. The application must accommodate Daylight Savings time changes so that the City can accurately record time-stamped events in an intuitive manner, and to easily and accurately calculate response time statistics. For example, if a unit is dispatched before a DST change and Page | 131
    • arrives on scene after the DST change, the system must provide for a way to properly display or report time stamped events so that the person viewing the information knows that the events spanned the DST change I.1.6.4 All applications shall include an interface to a Spectracom Ethernet time server model 9288 NTP master time source. I.1.7 E911 AND TDD INTERFACE SYSTEMS I.1.7.1 The CAD system shall interface to the 911 controller so as to populate the CAD workstation event screen with ANI and ALI data. The Eden Prairie PSAP currently uses the Positron VIPER digital hardware and Positron Power 911 software system. I.1.7.2 CAD shall satisfy NENA standards for E-911 / CAD interface. I.1.7.3 The CAD system shall interface with the 911 system to allow TDD and TTY connections through CAD. I.1.7.4 Integrate TDD data capture from all CAD workstations. I.1.7.5 System shall support FCC-mandated Wireless 911 Call location receipt, per Phase I and II of FCC Docket 94-102. I.1.8 WINSCRIBE DICTATION I.1.8.1 The in-field reporting system shall allow for voice audio file capture and importation into the Winscribe Dictation/Transcription System. I.1.8.2 The system shall track the status of the audio file in a workflow system. I.1.8.3 The system will allow the option to remove or retain the audio file from system, depending on a preselected work type. I.1.8.4 System should allow for seamless integration of a DSS Player or directly support the DSS audio file type. I.1.9 Intranet Web Portal I.1.9.1 The system shall have the ability to interface to an Internet Web Portal for the purpose of providing police reports to the public. I.1.9.2 The system’s CAD shall provide a means to auto-populate a public version of an incident report, based on predefined settings. (E.g. Specific house numbers should default to the block, name fields redacted, certain event types not included, and the release can be time delayed via an Page | 132
    • administrative setting.) I.1.9.3 The Police RMS shall provide a user interface solution for manual audit and approval of a police report before it would be exported to the Web Portal for public accessibility. I.1.9.4 The system shall provide a solution for custom redaction and the preservation of the newly redacted report. I.1.9.5 The system shall keep a log of all reports disseminated to the Web Portal. The log should include date, time, purpose of release, and the user who authorized the release. I.1.10 Toning/Alert System I.1.10.1 System shall integrate with Motorola MCC 7500 paging alerts. I.1.11 EP Warning/Citation Writer I.1.11.1 The system’s mobile solution shall provide an interface that launches a web browser to a pre-determined web link. The link shall have the ability to pass a variable of a user selected incident number . I.1.11.2 The mobile client shall retain all previously run DVS/CJIS/NCIC query data on the local machine or server in an XML or compatible format. I.1.11.3 The link should be available for both active and closed events. I.2.0 Hennepin County Warrants I.2.0.1 Mobile connection to Hennepin County Warrants ODBC connection to query warrants via Full Name and DOB I.2.1 DVS / CJIS / NCIC I.2.1.1 The system will have the ability to initiate CJIS/NCIC queries on all valid CJIS/NCIC message types using pre-designed forms as part of the application. Responses to inquiries will be returned to the original terminal requesting the inquiry and will give a visual and audio indication that the message is waiting to be viewed. I.2.1.2 The system shall automatically format and send CJIS/NCIC inquiries upon the entry of traffic stop, which includes a license plate number, and (optionally) state of issue. I.2.1.3 The system shall automatically format and send CJIS/NCIC inquiries upon the entry of subject data to include name, DOB and/or race and sex. Page | 133
    • I.2.1.4 The system shall automatically format and send CJIS/ NCIC inquiries upon the entry of a towed/impounded vehicle, boat, trailer or other licensed object. I.2.1.5 The system shall automatically format and send CJIS/ NCIC inquiries upon the entry of a name into the Master Name Index MNI I.2.1.6 When a vehicle registration is run in the system and the response returned, the system shall read the name from the response and automatically form a CJIS/NCIC driver license query (QDP) to check for wanted hits on the person. I.2.1.7 The system should have the capability to automatically validate the entries made into CJIS/NCIC. Validation of active warrants should be able to be performed by the system itself with minimal user intervention. I.2.1.8 The system shall include a set of the most common message formats used for preparing CJIS/NCIC inquiries. I.2.1.9 The vendor will be responsible for updating the interface to the CJIS/NCIC system as the State changes its specifications. I.2.1.10 System must comply with CJIS/NCIC policies and procedure regarding security and encryption. I.2.1.11 The system will offer multiple levels of security for CJIS/ NCIC access to include, but not limited to: Inquiry only, Inquiry and criminal history access, entry capability, full access to all functions. I.2.1.13 The Criminal Justice Information System (CJIS) is the system provides “hot file” information and is accessed through CJDN (Criminal Justice Data Network). I.2.1.14 National Crime Information Center (NCIC). The Criminal Justice Data Network (CJDN) provides the network access or interface to NCIC. All of the CJIS files that meet the federal criteria pass on information and data to the NCIC system. I.2.1.15 Computerized Criminal History (CCH). The State Bureau of Criminal Apprehension maintains the CCH files. Computerized criminal histories are a compilation of reports from law enforcement, prosecution, courts, and correction agencies in Minnesota. The interface allows the criminal justice system to track an individual from his/her arrest Page | 134
    • through discharge and disposition of each offense. I.2.1.16 The Criminal Justice Data Communications Network (CJDN) is the overall system that provides criminal justice agencies computer access to data stored on the State and National systems. All systems must meet their requirements and policies at the time of implementation. I.2.1.17 All inquiries to the State of Minnesota must adhere to State Query formats. The vendor will be responsible for obtaining the latest policies for networking and the multiple formats required at the time of implementation. I.2.2 CJRS (MOC) / NIBRS (UCR) I.2.2.0 The Minnesota Criminal Justice Reporting System (CJRS) is a statewide centrally located computerized data collection repository of criminal information. The information is collected from participating law enforcement agencies statewide. The information collected is submitted into the CJRS for processing and dissemination and is used primarily for statistical purposes. I.2.1.1 System shall integrate and transmit files to State of Minnesota for reporting according to guidelines in “CJRS Manual” . I.2.1.2 Police RMS must seamlessly interface to this system for mandated reporting requirements. I.2.3 CriMNet CIBRS I.2.3.0 The State of Minnesota collects person/incident information from state law enforcement agencies through the CriMNet CIBRS System. The Police RMS system must support the creation of batch export files in compliance with CIBRS standards “CIBRS XML Upload File Format Spec.v01.00” http://www.crimnet.state.mn.us/Standards/ standards.htm I.2.5 RADIO SYSTEM (800 MHz) I.2.5.1 The City is currently a member of the statewide regional radio system utilizing a trunked Motorola 800 MHz radio system with smart zone controllers. I.2.5.2 The CAD system and radio system management terminal shall be interfaced Page | 135
    • to allow the dispatcher to dynamically regroup all unit assigned to an incident to another talk group. Proposals shall describe any experience interfacing with radio systems especially any offering dynamic regrouping or similar advanced features. I.2.6 CAD-TO-CAD (APCO Project 36 Data Interface) Vendor to discuss capabilities in this area, I.2.6 is not a mandatory requirement I.2.6.1 It is desired that the system be compatible with the APCO standard under development to import and export CAD data. I.2.6.2 The system shall be capable of exporting CAD incident data to other PSAP's via secure networks or internet. I.2.6.3 The system shall be capable of automatically importing CAD incident data from other PSAP's via secured networks of internet. I.2.7 Dynamic Imaging HENNRAP/MRAP (County/State Repository of Arrest Photos) I.2.7.1 The Police RMS Jail Management Module shall be able to interface with the State of Minnesota Dynamic Imagining software used to capture photos of arrested persons. I.2.7.2 The Jail Management Module shall manage booking intake information including, but not limited to, case number, date, time, location of arrest, arrested person’s full name, DOB, address, phone numbers, next of kin, arrest purpose, property inventory, cell placement and cell checks. I.2.7.3 The system shall assign a booking number to each arrest. I.2.7.4 The system shall be able to delineate between adults and juveniles. The system shall remove redundant data entry into the Dynamic Imaging system by seamlessly export the above information into Dynamic Imaging’s relationship table database. I.2.8 LiveScan Fingerprinting (BCA) I.2.8.1 The Police RMS Jail Management Module shall be able to interface the LiveScan Fingerprinting software used to capture fingerprints from arrested persons in the Page | 136
    • State of Minnesota. I.2.8.2 The Jail Management Module shall manage booking intake information including, but not limited to, case number, date, time, location of arrest, arrested person’s full name, DOB, address, country of birth, and one to many criminal counts for each arrested person. I.2.8.3 The system shall be able to delineate between adults and juveniles. I.2.9 Statewide Supervision System (MN DOC) I.2.9.1 The Police RMS Jail Management Module shall be able to interface the State of Minnesota Department of Corrections “Statewide Supervision System” for arrested persons. The system shall manage booking intake information including, but not limited to, case number, date, time, location of arrest, arrested person’s full name, DOB, adult/juvenile, address, race, citizenship, date/time of booking, release information, and one to many criminal counts for each arrested person. I.2.10 NFIRS (State Fire Marshal) National Fire Incident Reporting System (NFIRS) is a state/federal database that tracks fire incidents including, but not limited to, cause, quantity, types, and locations. See requirements at http://nfirs.fema.gov/ The Fire RMS shall be capable of exporting required information to NFIRS I.2.11 Aspen Commercial Vehicle Inspection The Aspen Commercial Vehicle application is a state/federal Department of Transportation database that manages enforcement action relating to commercial vehicles. I.2.12 MESSAGE SWITCH I.2.12.1 Ability to integrate previously entered information with current record and forward that record to next recipient, i.e. CAD to Field report Field report to records management, records management to State mobile updates from centralized server. I.2.12.2 System will include message switching functionality with will support automated Page | 137
    • messages and queries between a number of user applications. I.2.12.3 System will have one of the following compliances: JXML XML API (Application Programming Interface) Other I.2.12.4 System will facilitate bi-directional communications of integrated and non- integrated applications I.2.12.5 System will support communications between CAD, RMS, Mobile and also outside mandated systems including, but not limited to, NCIC, III, State, etc.) I.2.12.6 System will support both workstation and remote devices (i.e., mobiles) to log on to the host applications. I.2.12.7 System should run in a Windows environment. I.2.12.8 System should satisfy the open architecture standards and provide multi- protocol support. I.2.12.9 System should provide scalable expansion to prevent bottlenecks. I.2.12.10 System will provide all necessary middleware to interconnect all the applications to be run through the message switch. I.2.13 Minnesota DVS Crash Reporting System I.2.13.0 The Minnesota DVS Crash Reporting System is a web based data collection system that captures statistical information for crash incidents. I.13.1.1 System must allow for MN State accident reports to be written and drawn using the DVS web site electronic forms and automatically downloaded into the Police RMS. This information will include, but not limited to, date, time, location, and person/ vehicle information. FIRE RECORD MANAGEMENT F.1.0 FIRE - GENERAL Y/N/M/F Comment F.1.0.1 Pop-up messages upon log in which would include, but not be limited to: • Event Reminders • Certification Expirations • Equipment Maintenance Due Page | 138
    • The same incident report or occupancy record should have the ability to be opened/edited/saved in multiple locations without overwriting information. System should be capable of two-way sharing of information between CAD, Fire, and Police RMS and Mobile locations. Information sharing should be in real-time, without the necessity of downloads. The vendor should have their own Fire Solution, or must have the integration capabilities between other Fire RMS systems for two-way information sharing. The vendor will be required to demonstrate this integration upon the request of the City. Must have the ability to track public education events such as Station Tours, Block Parties, etc., while tracking the number of adults and children attending. The system must be capable of performing an internal scan against the CAD Master Address database and display all available data including owner/occupant information, address information, Hazardous Materials, hydrant information, utility disconnect information, optional photos or other pertinent current/historical data, etc. The system must maintain a detailed audit trail of all changes made within the RMS. The system should notify the Administrator when changes have been made to the Incident Report after it has been completed. While an incident is going on, the responding apparatus, their assignment, and their location must be available to the other Fire Department stations. The system must be able to run at the same time as other systems, such as CAD, on the same computer. F.2.0 FIRE – IN-FIELD REPORTS Y/N/M/F Comment F.2.0.1 Mandatory Fields are only required at time of submission. User must be able to maneuver between fields/pages as information becomes available. Report must be able to be closed/saved as each station/mobile unit (possibly simultaneously) completes their information – even if the entire report is not complete at their station. Completion will occur as all stations/mobile units complete their portion. Notices should be sent to the Administrator showing incomplete reports as of a specific time of day that has been pre-designated. Page | 139
    • Must have an Export File that complies with the State and National Fire Reporting requirements. The system must be capable of receiving, formatting, and storing all Fire Department CAD (E-911) dispatch tickets on a real-time basis. The following information (at a minimum) should be exported from CAD, to start a new Incident Report, without any manual input from the Fire Department. • Date • Time of Call • Clear Time • Incident Number • Station Paged • Units in Service, with en-route, arrival, and clear times. • Occupancy Information • Officer in Command The system must allow the Fire Stations to query the Fire Incident Report by providing keyword or partial keyword inquiry searches on all data fields within the incident report. Examples of such data fields include: Incident #, Alarm Date, Location Data. The system will import the CAD dispatch ticket to the Fire RMS system. The system must provide for over-ride capability for any CAD pre-filled data. The system must be able to capture all of the necessary information required to fully complete the NFIRS incident report as shown on Attachment The system must allow the specific Fire and Police Department personnel access to Fire Reports as required by their individual job responsibilities. The system must allow for drop downs in all necessary data fields to facilitate the use of multiple codes or other optional answers as required. The system must allow for the documentation of non-incident related staff and activities records through the use of a Staff activity form. Information in this form is to include:  Start Date  Activity code  Start time  End time  End date  Activity Description  Default Values  Station, Unit or Shift # Page | 140
    •  Hours Worked  Credit Points  Activity Type  Fire  Rescue  Medical  Other  Staff ID F.3.0 FIRE - MOBILE Y/N/M/F Comment F.3.0.1 Fire Mobile should be structured like the Police Mobile, except without NCIC Truck-to-truck and truck-to-police Instant Messaging Capabilities F.4.0 FIRE – PERSONNEL MANAGEMENT Y/N/M/F Comment F.4.0.1 Firefighters should be able to view their personal information, based on log in ID. The items they should be able to view, but not edit, should include but are not limited to: • Home Address • Contact Information • Spouse/Significant Other/Children Names • Training Attended • Calls Attended • Certifications • History The system must allow for the maintenance, tracking and scheduling of the Fire Department personnel availability schedules. The system must provide a Staff Availability report that will allow the officers in charge of personnel to inquire about an individual/squad/station’s availability schedule. The system must allow the Administrator to add new staffing records, modify existing staffing records, and delete records in addition to the ability to add, delete and edit individual staff personal data. The system must allow the appropriate Fire Department staff to inquire on a person, address, or incident # and display information specific to that item. The system must allow for tracking of vacation time accrued, available, and used for a specific time frame. The system should allow for attachment of photos to the personnel file. The system should allow for attachment of other documents to the personnel file. (Recognition letters, Award Nominations, etc.) The system must allow mass updates for items Page | 141
    • such as certifications, class attendance, etc. F.5.0 FIRE – INVENTORY Y/N/M/F Comment F.5.0.1 The system must provide the ability to document vendor information through the use of a vendor records form. Components of the vendor records must include: • Vendor Name • Vendor ID • Vendor State ID • Vendor Class • Address • City, State, Zip • Phone Numbers • Email Address • Internet Address • History The system must allow for the documentation of Inventory through the use of an Inventory form. Information in these forms include: • Inventory Description • Inventory ID • Station • Unit • Staff ID • Vendor ID • Inventory Location • Inventory Class • Purchasing Replacement Information • Purchase date • Original Cost • Date received • Repl. Date • Repl. Cost • Placed In Service • Manufacturer • Make • Model • Year • Serial # • Miscellaneous Information • Generic Equipment • Out of Service • Quantity of Units • Last Maintenance Test • Date • Mileage • Hours • Job Code The system must allow for mass updates of Page | 142
    • inventory items. The system should allow pre-determined min/max levels within an inventory category to be tracked. The system should send notifications to the administrator for those items which have reached their minimum inventory levels. The system should allow for a purchase order to be created for any item reaching its minimum stocking levels. The system should allow for receipt of inventory against the purchase order. The system should allow for tracking of vendor performance against key benchmarks such as, but not limited to, on time shipping, accuracy, back-orders, etc. F.6.0 FIRE – INSPECTIONS/INVESTIGATION/PRE- Y/N/M/F Comment PLANS F.6.0.1 All Pre-Plan and Inspection Data entered into the Fire RMS should be available through CAD and all Police and Fire mobile units. Police and/or Fire Hazards Key holder information Other Contact Information Previous Contacts – Police & Fire Photo Inventory Log The system must be capable of logging and storing evidence information including an inventory of all photographs taken at the investigation scene. Information included as part of the Photo Inventory Log must be:  FD NFIRS Incident #  Law Enforcement Incident #  Address  Date  Time  Roll # or total rolls taken (if 35mm)  Photos taken or identified by (name)  List of photos in numeric order The system must allow for supplemental reports to the Incident/Investigation Report. These would include, but are not limited to Fire Marshal’s Report and Police Reports. The system must have the ability to create, print, and track all permits, along with fees owed and collected. The system must allow for the creation of Inspection Reports, and have the ability to import all local, state, and federal codes directly into the document. System must be capable of tracking evidence, Page | 143
    • along with it’s locations, which might be other than the Police or Fire Evidence Rooms. The system should be capable of tracking false alarms based by specific queries, and print reports and invoices as needed. The system should be able to invoice and track all occupancies identified as rental housing. All permit data must be capable of electronic distribution to Finance and Building Inspections, including fees due, fees received, and any special comments. F.7.0 FIRE - TRAINING Y/N/M/F Comment F.7.0.1 The system must allow for the maintenance, tracking and scheduling of the Fire Department personnel training programs. The system must allow the training coordinator/assigned personnel to add new training programs, modify existing training programs, and delete a training program in addition to the ability to add, delete, and edit staff attendance. Should have the ability to enter training attendance as a group or by individual. The system must provide the ability to document and track training classes through the use of a training class basic form. Components of the Training Class Basic form would include: • Start Date • Category • Class Description • Location Agency • Hours • CEU (Continuing Education Unit) • Method of Instruction • Training Type • Staff ID The system must provide the ability to document and track training programs through the use of a training program form. Components of the training program would include: • Program description • Certification program code • Duration • Requirements Information • Training Type/Code • Description • Number of Hours • Staff ID • Training Class duration • Current Exam Score • Expiration Date Page | 144
    • • Requirement Summary o Type (training or activity) o Training Code o Hours Required o Current Hours o Balance • Details for training code (text entry) The system must provide the ability to document training vendor information through the use of a vendor records form. Components of the vendor records must include: • Vendor Name • Vendor ID • Vendor State ID • Vendor Class • Address • City, State, Zip • Phone Numbers • Email Address • Internet Address • History The system must provide keyword or partial keyword inquiry searches on an individual’s name or identification number. The system will display the personnel’s completed training, including: • Training class identification number • Training class name • Date(s) of training • Training class duration • Training class cost • Required indicator The system must provide keyword or partial keyword inquiry searches on training class identification numbers and/or training class name. The system will display the training class name, ID number, along with the personnel that have completed the training. The system must be capable of displaying and printing the training reports. F.8.0 FIRE – CAD Y/N/M/F Comment F.8.0.1 Should have the ability to instruct dispatcher the station and vehicle to be paged based on the type of call and location of call, per the EPFD Response Matrix. The system should allow access to CAD from Fire computers based on User ID and permissions. F.9.0 FIRE – EMS Y/N/M/F Comment F.9.0.1 In addition to the basic EMS Reporting Requirements, as shown on Attachment Page | 145
    • Page143, the system must have the capability to track patient information, including but not limited to personal information, vital statistics, treatments given, and transport. The system must have the capability to bill for EMS Services, or have an interface with a third- party for billing. F.10.0 FIRE - HYDRANTS Y/N/M/F Comment F.10.0.1 The system must allow for the documentation of Fire Hydrant Records through the use of a basic Hydrant information form. Information in this form is to include:  Basic Hydrant Section  Hydrant ID Number  Prefix  Address/Street/Highway type and suffix  Station ID  District #  Water Main ID  Hydrant Specifications  Make  Model  Year  Barrel Size / length  Main type / size  Valve location / size  Hydrant Recent Activities Section  Last Inspection  Last Flow Test  GPM  Flow @ 20 PSI  Flow @ 10 PSI  Flow @ 0 PSI (or inactive)  Serviced  Flushed  Painted  Defects  Defect Type  Description  Repair activity  Measurements  Static Pressure  Residual Pressure  Pitot pressure #1  Pitot Pressure #2  Discharge Coefficient  Outlet Diameter The system should be capable of accepting mapping overlays for hydrant data and/or water distribution systems. Page | 146
    • FIRE RFP - Attachment FIRE Incident Reports This system must be able to capture all of the necessary information required to fully complete the NFIRS incident report including: Basic Incident Information:  FD ID  Incident #  Exposure #  Date (Mo, Day, Year)  Day of the week  Alarm date  Arrival time  In service  Situation Type  Action Taken  Mutual Aid (Rec’d or Given)  Fixed Property Use  Ignition Factor  Address  County  Township  Zip code  Census Tract (pre-filled from GIS data)  Occupant Name/Address/Phone#  Owner Name/Address/Phone #  Method of Alarm  Type of alarm  District  Shift #  Station #  # Alarms  911 Used  Personnel Responded  Engines Responded  Aerial Apparatus - # of  Other Vehicles - # of Casualty Information:  Number of Injuries  Fire Service  Other  Number of fatalities  Fire Service  Other Fire Information:  Complex Type  Mobile property type  Area of fire origin  Equipment involved in ignition Page | 147
    •  Form of heat of ignition  Type of material ignited  Form of material ignited  Method of extinguishment  Level of fire origin  Estimated Loss  Total Value of Loss Structure Information:  Number of Stories  Construction Type  Extent of flame damage (user defined drop down selections)  Extent of smoke damage (user defined drop down selections)  Detector performance  Sprinkler performance  Smoke information  Type of material generating most smoke  Form of material generating most smoke Avenue of smoke travel Mobile Property / Mobile Equipment Information:  Mobile Property  Year  Make  Model  Serial #  License Number  Equipment involved in ignition  Year  Make  Model  Serial # Additional narrative section:  Ability to type in text as needed. Fire Department Personnel Information:  Name & Position of Officer in Charge  Date  Name/Position of personnel making the report  Date Structure Fire Report  Structure type  Building status  Stories at or above grade  Stories below grade  Main floor size  Total sq ft  Length in feet  Width in feet  Story of fire origin  Fire spread  Number of stories damaged by flame  Extent of damage  Flame spread (Y / N) Page | 148
    •  Detectors  Presence  Detector type  Power supply  Detector operation  Detector effectiveness  Detector failure reason  Automatic Extinguishing system  Presence  Extinguishing system type  Extinguishing system operation  Number of heads operating  Extinguishing system failure reason Civilian Fire Casualty Report  Name (last, first, mi, suffix)  Address  Gender  Age - Years and months  D.O.B.  Race  Ethnicity  Affiliation  Injury date (same as alarm date)  Injury time  Severity of injury  Cause of injury  Human factors contributing to injury  Factors contributing to injury  Injury code  Activity when injured  Location at time of incident  General location at time of injury  Story at start of incident  Primary area of body injury  Disposition Fire Service Casualty Report  SSN #  Name (last, first, mi, suffix)  Gender  Age - Years and months  Injury date (same as alarm date)  Injury time  Responses  Usual assignment  Physical condition  Severity  Taken to  Activity at time of injury  Specific location  Vehicle type  Protective equipment contributed to injury?  Fire service equipment failure?  Protective equipment item Page | 149
    •  Protective equipment problem  Manufacturer  Model  Serial number Hazardous Material Report  Hazardous Material ID  UN Number  DOT hazard code #  CAS registration #  Chemical Name  Container information  Type  Capacity  Capacity units  Release  Release Units  Physical state when released  Released into?  Released from?  Area and evacuation  Population density  Area effected  Area evacuated  People evacuated  Buildings evacuated  HazMat actions taken  Fire or explosion detail  Where occurred first  Cause of release  Factors contributing to release  Factors affecting mitigation  Equipment involved in release  Mobile property involved in release  Mobile property type  Mobile property make  HazMat civilian casualties  Deaths - # of  Injuries - # of  No Casualties  HazMat Disposition Dollar Loss and Value Report  Pre-incident value  Buildings  Vehicles  Contents  Estimated Loss  Buildings  Vehicles  Contents  Insured Amount  Buildings  Vehicles  Contents Page | 150
    •  Settlement Amount  Buildings  Vehicles  Contents  Insurance Information Arson / Investigation Report  Agency Referred  Case Status  Availability of material first ignited  Suspect motivational factors  Entry method  Extent of fire involvement on arrival  Other investigative information  Property ownership  Initial observations  Laboratory used  Investigative Leads / Involvement  Type of suspect or involvements last name  Subject D.O.B.  Age of subject  Evidence Collection Additional Narrative Report  FD ID #  Alarm Date  NFIRS Incident Number  Exposure #  Type  Scene Address  Narrative information Fire Information:  Complex Type  Mobile property type  Area of fire origin  Equipment involved in ignition  Form of heat of ignition  Type of material ignited  Form of material ignited  Method of extinguishment  Level of fire origin  Estimated loss and Value of loss Structure Information:  Number of Stories  Construction Type  Extent of flame damage  Extent of smoke damage  Detector performance  Sprinkler performance EMS Incident Reports Page | 151
    • This system must be able to capture all of the necessary information required to fully complete the NFIRS incident report including: Basic EMS Incident Information:  FD ID #  Service #  Alarm Date  Arrival Time  Incident #  Occupancy ID  Address Type  Number / Milepost  Street Prefix  Street / Highway  Street Type  Street Suffix  Apt/Suite/Suite#  Intersection Information  City Information  State Information  Zip code  Census Tract (Pre-fill from GIS Data)  Additional Supplemental Address info:  Zone (Pre-fill from GIS Data)  County  Township (Pre-fill from GIS Data)  Dispatch Information:  Dispatched For  Dispatch Notification Date and Time  Arrival date & time  Last Cleared Date  Last Cleared Time  Station Shift Information & Alarm  Station Number  Shift Number  Dist. #  Aid Given or Received  Mutual Aid Details  Department / Unit Code  Response dates / times  Resources used  Their Incident Number Patient / Victim Information Disposition and transport section Note: the disposition and transport section documents information relative to patient disposition and transportation of the patient including:  Patient Disposition  Disposition Type  Patient Status  Pulse on transfer  Transport  Mode of Transport  Initial Destination / Facility Code  Destination Determined by: Page | 152
    • SECTION 5 – ADDITIONAL VENDOR ATTACHMENTS ATTACHMENT J - DESCRIPTION OF SERVICES 1. Provide a statement of the project approach, any unique benefits, and other considerations. 2. Provide an estimate of the earliest start date following execution of a contract. 3. Submit a work plan with key dates and milestones. Response should include: 3a. Identification of tasks to be performed and/or goods to be provided by Vendor. 3b. Timeframes to complete performance of the identified tasks or expected timeframe in which the project would be completed. 3c. Implementation strategy including transition plan if necessary. 3d. Training of Administrators and Users 3e. Data Conversion and Implementation. 4. Describe the types of reports you will provide, if any. 4a. State the frequency of such reports. 4b. Provide samples of such reports. 4c. Describe the process for requesting reports. 4d. State any costs associated with reports. 4e. Describe method of report delivery (electronic, paper, e-mail, etc.) 5. Provide summary resumes for proposed project team members or assigned staff, including their specific experiences with similar projects, qualifications and special expertise, and number of years with your company. 6. What difficulties or challenges do you anticipate in providing services to the City of Eden Prairie and how do you plan to manage these? What assistance will you require from the City? 7. Provide details regarding any special services or product characteristics, or other benefits offered, or advantages to the City of Eden Prairie in selecting your company's product or service. Page | 153
    • ATTACHMENT K - PRICING Vendors Must use/submit the MS Excel version of this worksheet found on the Eden Prairie RFP website http://www.EdenPrairie.org/ . This Chart below is for reference only. EP VENDOR COST SHEET Cost Notes Eden Prairie Use Only Software/Training 1 CAD Software General 2 CAD Application Software 3 Software Support Define - see Attachment “L” 4 Training 5 6 GIS Mapping Software 7 Software Support Define - see Attachment “L” 8 Training 9 (AVL -See Mobile) 10 11 Other Application Software (specify) 12 Other Support (specify) Define - see Attachment “L” 13 Other Training (specify) 14 15 Other (specify) 16 Other (specify) 17 18 19 Mobile Application Software 20 CAD Client Application Software 21 Software Support Define - see Attachment “L” 22 Training 23 24 Field/Incident Reporting Software 25 Software Support Define - see Attachment “L” 26 Training 27 Other 28 Other 29 30 AVL Vehicle Location Software 31 Software Support Define - see Attachment “L” Page | 154
    • 32 Training 33 34 Ticketwriter Application Software 35 Software Support Define - see Attachment “L” 36 Training 37 38 Other Application Software (specify) 39 Other Support (specify) 40 Other Training (specify) 41 42 RMS Application Software 43 RMS Application Software 44 Software Support Define - see Attachment “L” 45 Training 46 Other 47 Other 48 49 Other Application Software (specify) 50 Other Support (specify) Define - see Attachment “L” 51 Other Training (specify) 52 53 Other Application Software 54 55 56 57 58 59 60 Sub Total 61 62 Vendor Services 63 Data Conversion 64 Police Record System 65 Police CAD 66 Fire Record System 67 Sub Total 68 69 Implementation Support 70 71 Interfaces 72 CIS 73 EMD ProQA 74 Pagers Page | 155
    • 75 Alarms 76 Reverse 911 77 Fire RMS 78 BCA / CJIS / NCIC 79 MOC / UCR / NIBRS 80 CIBRS 81 E-Mail 82 Master Clock 83 E911 AND TDD Interface 84 Message Switch 85 Radio System (800Mhz) 86 CAD-to-CAD(APCO 36) 87 Paging (Motorola MCC 7500) 88 Other 89 Other 90 91 92 Software Escrow Services 93 Service 2 94 95 Sub Total 96 97 Hardware/Database 98 99 Database 100 101 CAD Server 102 RMS Server 103 IIS Server 104 Server Support Define - see Attachment “L” 105 Server Upgrades 106 107 Network Server 108 Network Hardware 109 Network/Desktop Software 110 Network Support Define - see Attachment “L” 111 Desktop Hardware 112 113 Wireless Access Service 114 Wireless Server 115 Wireless Comm Hardware 116 Wireless Comm Software Page | 156
    • 117 Wireless Comm Define - see Attachment “L” Support 118 119 Laptop Hardware 120 Laptop Software 121 Laptop Support 122 Laptop Peripherals 123 TicketWriter /Printers 124 125 Total Signature Pad / Evidence Label Printer 126 127 Hardware Installation 128 Anti Virus 129 130 131 Sub Total 132 133 134 Total Page | 157
    • ATTACHMENT L - GENERAL SUPPORT GUIDELINES This is an aid to clarify the types of support levels for each of the areas, vendors are to determine and define level of support to be provided as part of proposal CAD, RMS, MOBILE SOFTWARE 1st Level – Internal IT determination and Vendor documentation / help files 2nd Level – Vendor phone support 3rd Level – Vendor on site support MOBILE HARDWARE 1st Level – Internal IT determination 2nd Level – Vendor support if purchased through initial contract 2nd Level – Manufacturer support if purchased outside initial contract COMMUNICATIONS SOFTWARE (i.e. Message Switch) 1ST Level – Internal IT determination and Vendor documentation / help files 2nd Level – Vendor phone support 3RD Level – Vendor, Internal IT and 3rd Party Conference (i.e., Wireless carrier) 4rd Level – Vendor on site support COMMUNICATIONS SOFTWARE (i.e., Wireless Card) 1st Level – Internal IT determination and Manufacturer documentation / help files 2nd Level – Manufacturer phone support 3rd Level – Manufacturer, Internal IT and Vendor Conference 4th Level – Manufacturer on site support INTERFACES 1st Level – Internal IT determination and Interface documentation / help files 2nd Level – Internal IT and Interface Phone Support (i.e., EPD and State, County, etc.) 3rd Level – Internal IT and Vendor interface team 4th Level – Internal IT, Vendor interface team and outside interface team conference For purposes of this RFP, any third-party software or hardware that is integral to the overall operation and functionality of Vendor’s software, and is presented in the RFP as such, will be considered as “Vendor” and not third-party software as it relates to support or intervention. Page | 158
    • ATTACHMENT M - GENERAL TRAINING GUIDELINES The Vendor shall provide for Administrative/Technical Support, Supervisor and End User training. Training is defined as those hours specifically set aside for the sole purpose of training and not time spent providing instructions to the City’s staff prior to final inspection and acceptance. The training should provide users with an understanding of how to best integrate and configure the system, assist them with development of skills necessary to take full advantage of the system’s functions and features, and provide them with a working knowledge of the system as it relates to their daily job functions and the procedures of the department. The agenda of training should include, but not be limited to, installation and upgrades, configuration, administration and maintenance of the system, system failure, backup and recovery procedures, data and program backup procedures, understanding the elements of each application and how it relates to the total system, integration between CAD, Records, and Mobiles, basic and advanced use of each application of the software, etc. Vendor will include in the proposal pricing all training that will be offered as part of the total bid inclusive of all travel and per diem expenses and/or fees. Vendor should include on-site instructors, instructional materials, guides, training aids or workbooks, sample techniques, etc. If Vendor proposes a “train the trainer” concept, please also provide cost options for complete on- site training if available. The City is requesting that the following parameters be kept in mind when proposing a training regiment: • Training should be job specific to the needs of each of the Department areas or divisions. Specific areas could be defined as: IT Technical Support, Dispatch, Officer Mobile and Field Reporting, Administration and Support Data Entry and Retrieval, Investigative, Data Analysis and Mapping, Statistical Analysis and Reporting and Data Retrieval, Analysis and Reporting • The preferred method of training in above areas would be hands-on • Documentation of processes to include examples would be preferred • The desire for multiple persons to attend any “train the trainer” sessions to expedite total overall Departmental training. • Specificity of cost, content, etc. of training sessions to allow Department flexibility in selecting training options Vendor will submit with this RFP a written detailed description that includes content and duration of each course and number of personnel allowed, suggested or mandated. In the written description, vendor should address both initial and on-going training, how frequently and where training is conducted and any various methods in which it is conducted. Vendor should also detail what training is required by Vendor for each application presented in RFP. Page | 159
    • ATTACHMENT N – VENDOR/SOLUTION PROVIDER CONTACT DATA This section is for Vendors to enter the information for the various partners and associated vendors they are recommending for the core products they are proposing for the EPD technology upgrade solution. This also includes the proposed peripheral hardware recommendations for the associated systems to support the applications proposed. While this may not be the final contractual list of providers, it must represent the Vendors best representation of the final architecture as understood currently. Prime Contractor / System Integrator Information: Information Comment Company Name: Address: Address: Contact Name: Contact Title: Office Phone: Mobile Phone: Fax: Email: Other: Computer Aided Dispatch (CAD) Vendor: Information Comment Company Name: Address: Address: Contact Name: Contact Title: Office Phone: Mobile Phone: Fax: Email: Other: Records Management System (RMS) Vendor: Information Comment Company Name: Address: Address: Office Phone: Mobile Phone: Fax: Email: Other: Page | 160
    • Mobile Applications Systems Vendor: Information Comment Company Name: Address: Address: Contact Name: Contact Title: Office Phone: Mobile Phone: Fax: Email: Other: Ticket Writer Printer Vendor: Information Comment Company Name: Address: Address: Contact Name: Contact Title: Office Phone: Mobile Phone: Fax: Email: Other: Page | 161
    • Other Vendor: Information Comment Company Name: Address: Address: Contact Name: Contact Title: Office Phone: Mobile Phone: Fax: Email: Other: Page | 162
    • ATTACHMENT O - VENDOR QUALIFICATIONS AND REFERENCES GENERAL VENDOR/PROPOSER INFORMATION Primary Contractor / System Integrator: Name:___________________________________________________________ Address:______________________City_____________State_____Zip_______ Telephone:_________________________Fax:___________________________ Contact Name:________________________E-Mail:_______________________ Years in Public Safety Business: CAD:________ RMS:________ Mobile:______ Total Number of Police Customers Installed:__________ Total Installations in Minnesota:____________ Number of Employees: National:___________ Minnesota:____________ Total Full Time:__________ Total Part Time / Contract:________ Revenue: Percentage of last year’s revenue from Public Safety software: _____________ Percentage of last year’s revenue from other sources:_____________________ List Principal other sources:__________________________________________ ________________________________________________________________ Financial Statements Enclosed: Yes:________ No:_________ Number of lawsuits filed against the firm in the past five (5) years:___________ Description / Status of Lawsuits:______________________________________ ________________________________________________________________ Have any of these lawsuits involved a municipal or country government: Yes:__________ No:__________ Please list these government entities:__________________________________ ________________________________________________________________ Page | 163
    • ________________________________________________________________ Secondary Contractor / System Integrator: Name:___________________________________________________________ Address:______________________City_____________State_____Zip_______ Telephone:_________________________Fax:___________________________ Contact Name:________________________E-Mail:_______________________ Years in Public Safety Business: CAD:________ RMS:________ Mobile:______ Total Number of Police Customers Installed:__________ Total Installations in Minnesota:____________ Number of Employees: National:___________ Minnesota:____________ Total Full Time:__________ Total Part Time / Contract:________ Revenue: Percentage of last year’s revenue from Public Safety software: _____________ Percentage of last year’s revenue from other sources:_____________________ List Principal other sources:__________________________________________ ________________________________________________________________ Financial Statements Enclosed: Yes:________ No:_________ Number of lawsuits filed against the firm in the past five (5) years:___________ Description / Status of Lawsuits:______________________________________ ________________________________________________________________ Have any of these lawsuits involved a municipal or country government: Yes:__________ No:__________ Please list these government entities:__________________________________ ________________________________________________________________ Page | 164
    • ________________________________________________________________ General Questions: 1. Will prices be held firm for 180 days from the date of submission: Yes_______ No_______ 2. Upon being selected as one of the finalists, will Vendor provide a Dunn & Bradstreet Report at its expense? Yes__________ No:__________ 3. What is the cost-free software warranty period? ____________________________________ 4. What is the date the original application software was released? CAD___________________ RMS___________________ Mobiles____________________ 5. When was the most current version released? CAD___________________ RMS___________________ Mobiles____________________ 6. Do you offer a non-chargeable “Help Line” for software problems and, if so, what hours? __________________________________________________________ 7. What is your average response time for a maintenance call for software? __________________________________________________________ 8. What language is your software written in and does it use a relational database? CAD___________________ RMS___________________ Mobiles____________________ 9. If software changes or revisions need to be made due to State or Federal mandates, are these included in your annual software maintenance costs? Yes__________ No___________ 10. Is your application software license considered to be a license in perpetuity? Yes______ No______ 11. Do annual software maintenance costs include CAD, RMS and Mobile application replacements if the applications are rewritten or replaced while covered under maintenance contract? Yes___ No___ 12. What are your charges for the following additional items if requested over and above the contract? Programming:________________________________________________ Training:____________________________________________________ Additional Data File Conversion:_________________________________ Page | 165
    • 13. What software applications or systems have you converted to date: ___________________________________________________________ ___________________________________________________________ Page | 166
    • DETAIL REFERENCES CAD REFERENCE (1): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:__________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ CAD REFERENCE (2): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ CAD REFERENCE (3): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Page | 167
    • Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:__________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ CAD REFERENCE (4): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ RMS REFERENCE (1): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ Page | 168
    • RMS REFERENCE (2): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ RMS REFERENCE (3): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ RMS REFERENCE (4): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Page | 169
    • Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ MOBILE REFERENCE (1): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ MOBILE REFERENCE (2): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ Page | 170
    • MOBILE REFERENCE (3): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ MOBILE REFERENCE (4): Customer Name:__________________________________________________ Address:_______________________City____________State_____Zip_______ Telephone:_______________________Fax:_____________________________ Contact Name:____________________E-Mail:___________________________ Public Safety Systems Installed: CAD:________ RMS:_______ Mobile:________ Project Description:_________________________________________________ ________________________________________________________________ ________________________________________________________________ Approximate Project Completion Date: _________No. of Years Installed:______ Page | 171
    • 1ADDENDUM A Municipal Contract Provisions Unless excluded by applicable law the following provisions shall apply to this Contract: 1. Definitions. The following definitions apply to this Appendix. 1.1 “City” means the City of Eden Prairie. 1.2 “Contracting Party” means the party or parties that are contracting with the City under the Contract. 1.3 “Contract” means the contract or agreement that this Addendum is attached. 2. Data Practices Act. The Contracting Party shall at all times abide by the Minnesota Government Data Practices Act, Minn. Stat. § 1301, et seq., to the extent that the Act is applicable to data and documents in the hands of the Contracting Party. 3. Audits. The books, records, documents, and accounting procedures and practices of the Contracting Party or other parties relevant to this agreement are subject to examination by the City and either Legislative Auditor or the State Auditor for a period of six years after the effective date of this Contract. 4. Income Tax Withholding. No final payment shall be made to the Contracting Party until the Contracting Party has provided satisfactory evidence to the City that the Contracting Party and each of its subcontracts has complied with the provisions of Minn. Stat. § 290.92 relating to withholding of income taxes upon wages. A certificate by the Commissioner of Revenue shall satisfy this requirement. 5. Worker’s Compensation. Contracting Party represents and warrants that it has and will maintain during the performance of this agreement worker’s compensation insurance coverage required pursuant to Minn. Stat. § 176.181, subd. 2 and that the certificate of insurance or the written order of the Commissioner of Commerce permitting self insurance of worker’s compensation insurance coverage provided to the City prior to execution of this agreement is current and in force and effect. 6. Discrimination. In performance of this contract, the Contracting Party shall not discriminate on the grounds of or because of race, color, creed, religion, national origin, sex, marital status, status with regards to public assistance, disability, Page | 172
    • sexual orientation, or age against any employee of the Contracting Party, any subcontractor of the Contracting Party, or any applicant for employment. The Contracting Party shall include a similar provision in all contracts with subcontractors to this contract. The Contracting Party further agrees to comply with all aspects of the Minnesota Human Rights Act, Minn. Stat. § 363.01, et seq., Title VI of the Civil Rights Act of 1964, and the Americans with Disabilities Act of 1990. 7. Conflicts. No salaried officer or employee of the City and no member of the Board of the City shall have a financial interest, direct or indirect, in this contract. The violation of this provision renders the Contract void. Any federal regulations and applicable state statutes shall not be violated. 8. Claims. To receive any payment on this Contract, the invoice or bill must include the following signed and dated statement: “I declare under penalty of perjury that this account, claim, or demand is just and correct and that no part of it has been paid.” 9. Prevailing Wage. If required by Minn. Stat. §§ 177.41 - 177.43, the Contracting Party shall pay all employees the prevailing wage for similar work in the area and shall pay at least time and a half for all overtime worked by its employees. The prevailing wage for similar work in the area is________________. The prevailing hours for similar work in the area are ______________________. The prevailing hourly basic rate of pay is __________________________. [This paragraph is applicable only if state funds are involved in the Contract.] 10. Contracting Party’s Prompt Payment of Subcontractors. The contracting Party shall pay to any subcontractor within ten (10) days of the Contracting Party’s receipt of payment from the City for undisputed services provided by the subcontractor. The Contracting Party shall pay interest of one and a half percent (1 ½%) per month or any part of a month to a subcontractor on any undisputed amount not paid on time to the subcontractor. The minimum monthly interest penalty payment for an unpaid balance of $100.00 or more is $10.00. For an unpaid balance of less than $100.00, the Contracting Party shall pay the actual amount due to the subcontractor. 11. Limitation of Remedies In the event of a breach of the Contract by City, the Contracting Party shall not be entitled to recover punitive, special or consequential damages or damages for loss of business. Page | 173
    • By signing this Addendum the parties acknowledge that the above provisions become part of the Contract unless excluded by applicable law. CONTRACTING PARTY City of Eden Prairie By_________________________ By___________________________ Its_________________________ Its Mayor By___________________________ Its City Manager Page | 174