Eden Prairie RFP Document by fjwuxn

VIEWS: 68 PAGES: 171

									                     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
       EDED PRAIRIE GENERAL INFORMATION .......................................................................... 4
       GENERAL REQUIREMENTS: ................................................................................................ 5
   II. EXECUTIVE SUMMARY .......................................................................................................... 7
       PROJECT SCOPE: ................................................................................................................. 7
       INTERFACES: ........................................................................................................................ 7
       PROJECT GOALS AND OBJECTIVES: ................................................................................. 9
       OPERATIONAL BUSINESS CASE: ....................................................................................... 9
       KEY ASSUMPTIONS AND DIFFERENCES: ....................................................................... 11
       ESTIMATED TIMEFRAME: .................................................................................................. 11
       POLICE AND FIRE FUTURE SYSTEM ............................................................................... 12
       PUBLIC SAFETY (POLICE AND FIRE) INTERFACE FLOWCHARTS: .............................. 12
       CURRENT PAPER WORKFLOW FOR POLICE DEPARTMENT ....................................... 13


SECTION 2 – GENERAL CONTRACTUAL AND LEGAL INFORMATION..................................14
   GENERAL INFORMATION ........................................................................................................14
   PRE-PROPOSAL MEETING AND/OR SITE EVALUATION VISIT ............................................14
   DEFINITIONS .............................................................................................................................15
   OVERVIEW OF PROCESS ........................................................................................................18
SECTION 3 – VENDOR AND INFORMATIONAL ATTACHMENTS ............................................30
   ATTACHMENT A – GENERAL CONTRACT CONDITIONS ......................................................31
   ATTACHMENT B - VENDOR OFFER SIGNATURE AND CERTIFICATION FORM ..................45
   ATTACHMENT C - VENDOR PROFILE AND EXECUTIVE SUMMARY ....................................47
   ATTACHMENT D – PERFORMANCE BOND ............................................................................49
   ATTACHMENT E – SAMPLE CONTRACT ................................................................................55
   ATTACHMENT F – IC-134 INSTRCUTIONS .............................................................................57
   ATTACHMENT H – INDEMNITY AGREEMENT ........................................................................59
SECTION 4 - FUNCTIONAL REQUIREMENTS ATTACHEMNTS ...............................................60
   ATTACHMENT I - FUNCTIONAL REQUREMENTS DESCRIPTION.........................................61
   COMPUTER AIDED DISPATCH (CAD) .....................................................................................62
   RECORDS MANAGEMENT SYSTEM .......................................................................................88
   MOBILES .................................................................................................................................109
   INTERFACES ...........................................................................................................................124
   FIRE RECORD MANAGEMENT ..............................................................................................135
    FIRE RFP - ATTACHMENT………………………………………………………………………...147
SECTION 5 – ADDITIONAL VENDOR ATTACHMENTS ...........................................................150
   ATTACHMENT J - DESCRIPTION OF SERVICES ..................................................................150
   ATTACHMENT K - PRICING ....................................................................................................151
   ATTACHMENT L - GENERAL SUPPORT GUIDELINES .........................................................155
   ATTACHMENT M - GENERAL TRAINING GUIDELINES ........................................................156
   ATTACHMENT N – VENDOR/SOLUTION PROVIDER CONTACT DATA ..............................157
   ATTACHMENT O - VENDOR QUALIFICATIONS AND REFERENCES .................................. 160
   ATTACHMENT P – MUNICIPAL CONTRACT PROVISIONS…….……………………………. 163

                                                                                                                                    Page | 2
                    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.
                                                  rd
     Vendor will highlight in their proposal any 3 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)
                 Internet Web Portal (edenprairie.org)
              External Interfaces
                 Hennepin County Warrants (Mobile)
                 MN DPS/DMV


                                                                              Page | 7
            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:

              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
Value                                          way, to provide community with best value for
                                               dollar
Enhanced Customer Service                     Provide maximum non-safety service output
                                               (quality) for requestors, in most time effective
                                               manner

OPERATIONAL BUSINESS CASE:
Estimated Impact of change – Metrics and Intangibles

     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

                                                                                           Page | 9
                            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

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 | 10
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 | 11
POLICE AND FIRE FUTURE SYSTEM




PUBLIC SAFETY (POLICE AND FIRE) INTERFACE FLOWCHARTS




                                                       Page | 12
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 | 13
       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 | 14
         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 | 15
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 | 16
Will ................................ the same as a “must” or “mandatory” requirement




                                                                                        Page | 17
                              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 | 18
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 | 19
      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 | 20
        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 | 21
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 | 22
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
       shall notify Vendor of such request but under no circumstances shall the City be required

                                                                                        Page | 23
       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
       procedures relative to the system components and certify that Vendor is satisfied that the
       System is functional and operational per Vendor specifications.

                                                                                         Page | 24
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)
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

                                                                                      Page | 25
       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%
       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


                                                                                           Page | 26
          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 complete copy of the source code and executable code (in machine readable form) of
              the licensed software provided by the Contractor;
          A complete copy of any existing design documentation and use documentation; and/or
          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.
          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

                                                                                              Page | 27
      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
      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;


                                                                                             Page | 28
      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 | 29
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 | 30
           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 | 31
      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 | 32
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 | 33
                               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 | 34
       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 | 35
       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 | 36
       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 | 37
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 | 38
       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 | 39
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 | 40
       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 | 41
       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 | 42
       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 | 43
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 | 44
   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 | 45
         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 | 46
     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 | 47
   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 | 48
                          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 | 49
                   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 | 50
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 | 51
                                           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 | 52
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

                                                                                         Page | 53
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 | 54
                            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 | 55
                     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 | 56
                    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 | 57
       ATTACHMENT G – CERTIFICATE OF INSURANCE




VENDORS - Please include Certificate of Insurance
           Here In Your Response




                                                 Page | 58
                    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 | 59
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 | 60
  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 | 61
                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 | 62
           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 | 63
           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 | 64
           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 | 65
           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 | 66
           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 | 67
           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
           without regard to unit status.

                                                              Page | 68
           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
           event.

                                                            Page | 69
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
           include Mobile Data Computer (fixed),


                                                            Page | 70
           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
           assignment, mobile number, etc.

                                                               Page | 71
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
           multiple units simultaneously and also


                                                             Page | 72
           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.
C.3.0.28   The duplicate detection process must be


                                                            Page | 73
           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
           Elite tone/alert systems. (Reference:

                                                           Page | 74
           “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
           address being validated within the system at

                                                            Page | 75
           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.
C.3.3.19   System will allow for a change of location of

                                                                Page | 76
           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.
C.4.0.5    System will allow messaging to units by

                                                            Page | 77
           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
C.7.0.1    Application will provide capability to create

                                                            Page | 78
           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.
C.7.0.14   Application must allow a location breakdown

                                                              Page | 79
           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
           single location.

                                                            Page | 80
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.
C.8.1.3    The configuration tool shall manage access

                                                              Page | 81
           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.
C.8.2.4    The map viewer shall generate diagnostic

                                                             Page | 82
           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
           from the object list.


                                                           Page | 83
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…
C.8.6.5    The map viewer must be 911 wireless

                                                            Page | 84
           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
           information shall be available for all

                                                            Page | 85
          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
          summary reports.


                                                            Page | 86
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 | 87
            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 | 88
           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 | 89
           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 | 90
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 | 91
          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 | 92
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 | 93
           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 | 94
           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 | 95
          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 | 96
          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 | 97
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 | 98
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 | 99
          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 | 100
           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 | 101
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 | 102
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 | 103
           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 | 104
           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
           Notify Based on Sealed Record

                                                           Page | 105
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
            traffic management purposes including


                                                           Page | 106
            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.
R.12.3.12   System will provide the ability to enter,

                                                             Page | 107
            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 | 108
                                     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 | 109
           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 | 110
           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 | 111
           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 | 112
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
                                                      nd
           Plate: MN DL on Registered Owner & 2
           RO
                                                nd
           Plate: MN Clear Check on RO & 2 RO
                                                   nd
           Plate: NCIC Clear Check on RO & 2 RO
                                             nd
           Name or DL: MN DL on RO & 2 RO
                                                         nd
           Name or DL: MN Clear Check on RO & 2
           RO
           Name or DL: NCIC Clear Check on RO &
             nd
           2 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 | 113
           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 | 114
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 | 115
           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 | 116
           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 | 117
           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 | 118
           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 | 119
           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 | 120
          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 | 121
          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 | 122
printing with one being a thermal printer.




                                             Page | 123
                        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


                                                                            Page | 124
          password access to database backend for
          customized read only web based reporting
I.1.0.3   Vendor must provide data dictionary and
          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

                                                           Page | 125
           designated users the ability to change
           geographic call areas within reverse 911
           on the fly and update lists dynamically to
           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

                                                            Page | 126
           recipient to reply to the E-mail before they
           can delete
I.1.5.7    The system must allow users to send
           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


                                                            Page | 127
           accurately calculate response time
           statistics. For example, if a unit is
           dispatched before a DST change and
           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

                                                            Page | 128
           should default to the block, name fields
           redacted, certain event types not included,
           and the release can be time delayed via an
           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


                                                            Page | 129
           send CJIS/NCIC inquiries upon the entry of
           subject data to include name, DOB and/or
           race and sex.
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


                                                             Page | 130
           correction agencies in Minnesota. The
           interface allows the criminal justice system
           to track an individual from his/her arrest
           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


                                                          Page | 131
          with smart zone controllers.
I.2.5.2   The CAD system and radio system
          management terminal shall be interfaced
          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


                                                         Page | 132
          shall be able to interface the LiveScan
          Fingerprinting software used to capture
          fingerprints from arrested persons in the
          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




                                                         Page | 133
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
            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.

                                                           Page | 134
                            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
          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.


                                                                                   Page | 135
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.
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.

                                                      Page | 136
          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 #
                        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.

                                                                                   Page | 137
          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
          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


                                                                                 Page | 138
                 Out of Service
                 Quantity of Units
                 Last Maintenance Test
                 Date
                 Mileage
                 Hours
                 Job Code

          The system must allow for mass updates of
          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

                                                                                  Page | 139
          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,
          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


                                                                                       Page | 140
                  Duration
                  Requirements Information
                  Training Type/Code
                  Description
                  Number of Hours
                  Staff ID
                  Training Class duration
                  Current Exam Score
                  Expiration Date
                  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

                                                                                   Page | 141
           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
           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


                                                                                       Page | 142
                         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.



                                     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


                                                                                        Page | 143
           Other
       Number of fatalities
           Fire Service
           Other
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
     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


                                                                   Page | 144
       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)
     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

                                                     Page | 145
       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
             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

                                                      Page | 146
             Contents
       Estimated Loss
             Buildings
             Vehicles
             Contents
    Insured Amount
             Buildings
             Vehicles
             Contents
    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

                                                          Page | 147
       Construction Type
       Extent of flame damage
       Extent of smoke damage
       Detector performance
       Sprinkler performance


EMS Incident Reports

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


                                                                                        Page | 148
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 | 149
      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 | 150
                                 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


                                                                               Page | 151
31         Software Support     Define - see Attachment “L”
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


                                                              Page | 152
73            EMD ProQA
74                  Pagers
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

                                                            Page | 153
                  Hardware
116         Wireless Comm
                   Software
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 | 154
              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
 st
1 Level – Internal IT determination and Vendor documentation / help files
 nd
2 Level – Vendor phone support
 rd
3 Level – Vendor on site support

MOBILE HARDWARE
 st
1 Level – Internal IT determination
 nd
2 Level – Vendor support if purchased through initial contract
 nd
2 Level – Manufacturer support if purchased outside initial contract

COMMUNICATIONS SOFTWARE (i.e. Message Switch)
 ST
1 Level – Internal IT determination and Vendor documentation / help files
 nd
2 Level – Vendor phone support
 RD                                 rd
3 Level – Vendor, Internal IT and 3 Party Conference (i.e., Wireless carrier)
 rd
4 Level – Vendor on site support


COMMUNICATIONS SOFTWARE (i.e., Wireless Card)
 st
1 Level – Internal IT determination and Manufacturer documentation / help files
 nd
2 Level – Manufacturer phone support
 rd
3 Level – Manufacturer, Internal IT and Vendor Conference
 th
4 Level – Manufacturer on site support

INTERFACES
 st
1 Level – Internal IT determination and Interface documentation / help files
 nd
2 Level – Internal IT and Interface Phone Support (i.e., EPD and State, County, etc.)
 rd
3 Level – Internal IT and Vendor interface team
 th
4 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 | 155
               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 | 156
    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 | 157
                 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 | 158
                 Other Vendor:
                   Information   Comment
Company Name:
Address:
Address:
Contact Name:
Contact Title:
Office Phone:
Mobile Phone:
Fax:
Email:
Other:




                                     Page | 159
      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 | 160
________________________________________________________________


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 | 161
________________________________________________________________


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


                                                                                          Page | 162
      Additional Data File Conversion:_________________________________

13.   What software applications or systems have you converted to date:
      ___________________________________________________________

      ___________________________________________________________




                                                                          Page | 163
                                  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 | 164
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 | 165
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 | 166
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 | 167
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 | 168
                                  ADDENDUM 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

                                                                                 Page | 169
      origin, sex, marital status, status with regards to public assistance, disability,
      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 | 170
      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 | 171

								
To top