Docstoc

A.1 INTRODUCTION - Douglas County

Document Sample
A.1 INTRODUCTION - Douglas County Powered By Docstoc
					                      DOUGLAS COUNTY
                          OREGON


                 LAW ENFORCEMENT
                   PUBLIC SAFETY


            REQUEST FOR PROPOSAL
                                 # 015




Release Date: November 7, 2011
                         i. TABLE OF CONTENTS
Section
  i Table of Contents   …………………………………………..             1

  A. Introduction
       1. Introduction      …………………………………………..          4
       2. Facility Review …………………………………………..            6
       3. Existing Hardware/Software………………………………       11
       4. System Selection …………………………………………..          12
       5. Peripheral Interface Selection.……………………………   13
       6. Requirement Responses.…………………………………          14

  B. Technical requirements…………………………………………..          15

  C. General Features/Requirements..………………………………       17

  D. Records
      1. Maps             …………………………………………..           20
      2. Master Indices …………………………………………..             21
      3. Objects          …………………………………………..           22
      4. Reports          …………………………………………..           23
      5. Searches         …………………………………………..           24
      6. Security         …………………………………………..           25
      7. User defined forms.………………………………………..          26
      8. Administration …………………………………………..             26
      9. Arrest           …………………………………………..           29
     10. Budget           …………………………………………..           30
     11. Case             …………………………………………..           31
     12. Case Management ………………………………………..             32
     13. Citations        …………………………………………..           33
     14. Civil Processing …………………………………………..           34
     15. DMV accident …………………………………………..               36
     16. Evidence         …………………………………………..           36
     17. Field Interviews …………………………………………..           37
     18. Case Handling …………………………………………..              38
     19. Gun Permits      …………………………………………..           39
     20. Help             …………………………………………..           39
     21. Imaging/Mugshots..………………………………………..           40
     22. Incidents        …………………………………………..           41
     23. NIBRS Reporting…………………………………………..             42
     24. Property         …………………………………………..           44
     25. Record View      …………………………………………..           44
     26. Vehicle          …………………………………………..           45
                                 -1-
      27.    Field Reporting …………………………………………..        45
      28.    Internal affairs ………….……………………………….       46
      29.    Juvenile Custody ………………………………………….        47
      30.    Logs             …………………………………………..       48
      31.    Parking Tickets …………………………………………..        48
      32.    Pawn             …………………………………………..       49
      33.    System Administration ..…………………………………..   49
      34.    Towed Vehicle …………………………………………..          50
      35.    Warrants         …………………………………………..       51

 E.   Computer Aided Dispatch
       1. Calls             …………………………………………..         52
       2. General Dispatching..……………………………………..        56
       3. Fire & EMS Dispatching…………………………………..        56
       4. Incident Tracking …………………………………………..         58
       5. Unit Tracking     …………………………………………..         59
       6. Incident Response & Tracking.…………………………..    59
       7. System Functions..………………………………………..          61
       8. CAD Reports       ………………………………………….          65
       9. Misc. CAD         ………………………………………….          66

F.    Jail
       1.    General            …………………………………………..     69
       2.    Support            …………………………………………..     70
       3.    Bar Coding         …………………………………………..     70
       4.     Inmate Tracking   …………………………………………..     70
       5.    Jail Booking       …………………………………………..     71
       6.    Jail Commissary    …………………………………………..     73
       7.    Jail Setup         …………………………………………..     74
       8.    Inmate Billing     …………………………………………..     76
       9.    Kitchen            …………………………………………..     76
      10.    Jail Misc.         …………………………………………..     76
      11.    Jail Interfaces    …………………………………………..     79

G.    District Attorney         …………………………………………..     80

H.    Contact Information       …………………………………………..     85

I.    Evaluation of Responses
       1. Evaluation Team …………………………………………..           87
       2. Evaluation Criteria.…………………………………………         87
       3. Evaluation Scoring…………………………………………           88


                                    -2-
J.   Vendor Response Information
      1. Cost of Proposed System.………………………………..   89
      2. Proposed Timeline.………………………………………..      90
      3. Response Issues Items.…………………………………..    91

K.   Proposal Validation   …………………………………………..     92

L.   Proposal Information
      1. General Information..………………………………………     93
      2. Addenda to the RFP.………………………………………       93
      3. Cancellation of RFP………………………………………..     93
      4. Cost of Proposal …………………………………………..      93
      5. Format of Proposal…………………………………………       93
      6. Content of Proposal..………………………………………     93
      7. Contract         …………………………………………..      96
      8. Submission of Proposals.…………………………………    97
      9. Withdrawal of Proposals..…………………………………   97
     10. Evaluation of Proposals……………………………………    97
     11. Award of Contract………………………………………….       99
     12. Protests         …………………………………………..      99
     13. Public Records …………………………………………..        99




                               -3-
                            SECTION A
                       A.1 INTRODUCTION
Douglas County, Oregon is issuing this Request for Proposal (RFP) for the
purpose of soliciting vendors for a comprehensive Law Enforcement data
processing system to serve the current and projected needs of the County. We
will select vendors by a weighted process using some or all of the following: site
visits to clients, vendor demonstrations, user‘s group information, etc. Proposals
will be evaluated in accordance with their adherence to project objectives as well
as accuracy and completeness in responding to the requirements of the invitation
for proposals.

The County desires to acquire a vendor solution for Records Management,
Computer Aided Dispatch, Corrections Facility (Jail), Civil Paper Processing,
Mobile Data Communication, Field Reporting, and District Attorney Case
Management. The preferred concept selected by the DCSO (Douglas County
Sheriff‘s Office) will be the one deemed most compatible with long-term needs of
Douglas County law enforcement. See general rule #1 below.

The following general rules and comments are provided for the use is responding
to the request for proposals;


  1.    IMPORTANT – This is a multi-faceted comprehensive Law Enforcement
        RFP. It is intended to reach ALL vendors having all OR individual
        components of the included systems. Each section of this RFP is
        optional for vendor response. Vendors having just a Jail system MAY
        respond to that area plus any General Requirements areas. Those with
        just RMS and/or CAD may respond to those areas, etc.. If a vendor has
        a solution for all areas please respond to the full RFP. At this time we
        are looking at both integrated systems and ‗Best of Breed‘. Make sure
        to check the appropriate boxes on the system selection page as to what
        sections you are responding to. We also would ‗highly prefer‘ a system
        that is Windows/SQL based.

  2.    Proposals will be evaluated on the response and the areas responded to
        and may be ranked without interviews; hence, firms are encouraged to
        submit their initial proposals as comprehensively as possible.

  3.    Firms may be invited to present their proposals in more detail and to
        answer any questions the evaluation panel might have. All provided

                                       -4-
      specification pages must be completed and returned with the bidder‘s
      proposal.

4.    Where confidential or proprietary information is required or should
      prospective developers deem it necessary to submit such matter, each
      page should be marked in bold type with words ―PROPRIETARY
      DATA‖.

5.    Any information that may have been released by the DCSO either
      verbally or in writing prior to the issuance of this request for proposal will
      be disregarded.

6.    Brochures may be included if incorporated logically into the substance
      and format.

7.    The evaluation panel reserves the right to reject any or all proposals
      should they be deemed unsatisfactory or to conclude that there are no
      satisfactory proposals and discontinue evaluations. The DCSO reserves
      the right to waive any formalities and determine the best proposal
      submitted in the interest of Douglas County.

8.    IMPORTANT – Include all hardware specifications necessary to
      implement and run the system in a production environment at optimum
      performance.

9.    It is very important for the proposal reviewers to be able to compare
      similar types of materials among proposals received. If the discussion of
      a particular subject cannot be found because it is placed elsewhere, the
      proposal may not receive the highest evaluation it might otherwise merit.

10.   Proposers may attach documents substantiating their proposal claims,
      such as an example system design document, example training plan,
      etc. These attached documents must be specifically referred to within
      the proposal as appropriate.

11.   Please submit three (3) copies of your proposal with the same amount of
      copies for any attached documents or supplemental data.

12.   Each proposer should include the brand name of components used in
      their hardware proposal and indicate whether this selection is optional or
      required.



                                      -5-
This RFP is issued pursuant to Douglas County Local Contract Review Board
Rules. This request was preceded by research, requests for information from
vendors, and information obtained from other Oregon counties. We used this
process to help set expectations as to the quantity and quality of existing
systems either in production in Oregon or elsewhere in the Country as well as a
basis for budgeting of the project.

Douglas County contract forms will be used and are available for review upon
request.

                       A.2 FACILITY REVIEW
               DCSO – DOUGLAS COUNTY SHERIFF’S OFFICE

The Sheriff is the County's chief law enforcement officer, and is a non-partisan
electee for a four-year term. The Sheriff's Office is the County's chief law
enforcement agency, but operates in concert with state and municipal agencies.
The Sheriff's Office is responsible for criminal investigations, county road patrol,
operation and maintenance of the 283-bed County Jail, and carrying out the civil
and criminal processes and orders of the State and County court systems.
Additionally, the Sheriff oversees the operations of the Search and Rescue,
Disaster Preparedness, and Neighborhood Watch programs. The Sheriff's Office
also provides contractual endorsement services to several Douglas County cities.

The Douglas County Sheriff‘s Office present staffing consists of;

In Administration (6):
            Sheriff John Hanlin
            Under-Sheriff Brian Sanders
            1 Emergency Management Coordinator
            4 Admin Clerks.

In Operations (57):
           1 Lieutenant
           5 Sergeants
           3 Corporals
           47 Patrol Deputies
           1 Property Manager.

In Records (10):
                                        -6-
           1 Records Supervisor
           9 Police Records Clerks.

In Detectives (7):
            1 Sergeant
            4 Detectives
            1 Medical Examiner
            1 Police Records Analyst.

In Corrections (46):
            1 Lieutenant
            4 Corrections Sergeants
            39 Corrections Deputies
            2 Clerks.

In DINT (Douglas Interagency Narcotics Team) (4):
           1 Lieutenant
           1 Sergeant
           2 Deputies.

There are approximately 30 Marked Patrol Cars in operation.

Douglas County extends from sea level at the Pacific Ocean to 9,182-foot Mt.
Thielsen in the Cascade Mountains and is 5,071 square miles in size. It has the
entire Umpqua River watershed within its boundaries, and contains nearly 2.8
million acres of commercial forestlands. Over 50% of the land area of the County
is owned by the Federal government. These lands are managed by the Forest
Service and the Bureau of Land Management.




                                        -7-
The 2010 County population was 107,667. There are 12 incorporated cities in the
County: Glendale, Riddle, Canyonville, Myrtle Creek, Winston, Sutherlin,
Oakland, Yoncalla, Drain, Elkton, Reedsport, and Roseburg. Douglas County is
divided into 80 voting precincts.

This is a very large area that the Sheriff's Office has to respond to emergencies,
accidents, traffic control, and the daily routine calls.

                    CAD – COMPUTER AIDED DISPATCH

The Communications 911 Division (Computer Aided Dispatch) was established in
1977 to provide communications for the Sheriff's Office 911 service to citizens of
Douglas County. It has grown at a steady rate and currently provides 911
services to all Douglas County citizens, communications service to 5 police
agencies, 28 fire departments, and 5 ambulance companies. Emergency calls for
Reedsport Police and Oregon State Police are relayed to their own dispatch
centers. The computer screens need to display units available, their status, their
location in the county, as well as many other items.

The Douglas County 911 Communications present staffing consists of;

In Dispatch (20):
           1 Communications Manager
           3 Supervisors
           16 Communications Personnel.
                                       -8-
                        CORRECTIONS FACILITY (JAIL) -

An important function of the Douglas County jail is to protect the public from
dangerous people and to keep the inmates safe. We provide rehabilitative
opportunities such as GED, RSAT, jobs and life skill education. By incarcerating
offenders, they serve consequences for their actions. Victims and the general
public are protected. We have 283 inmate beds and average 6,552 bookings per
year. For staffing – see Sheriffs Office above.
The Jail uses numerous modules and interfaces to resolve the complexities
encountered with their duties. They use Bar Coding of inmates as well as
Imaging and Mug-shots. The Commissary module is tied into the inmate banking
structure. The Jail Kitchen reports on expenses and numbers of meals provided
statistically. Property lockboxes allow tracking of personal inmate property. Also
they have integration or interface to various other law enforcement agencies and
functions such as access to and from Local Police Departments for housing and
billing of inmates, COPLINK, Police Records, Cash Receipting and a complete
Medical Facility.


                              DISTRICT ATTORNEY

The District Attorney is elected for a four-year term, and serves as the
prosecuting attorney for the State of Oregon in Douglas County. The District
Attorney's primary duties include: prosecuting crimes occurring in the County
which violate State statutes (excluding cases filed in municipal courts);
conducting grand jury sessions; and attending court sessions.

The programs administered by the District Attorney's Office are: The Victims
Assistance program and Criminal Prosecution. The Victims Assistance Program
is set up to assist victims and witnesses through the legal process and the
criminal justice system.

The present staffing in the District Attorney‘s Office consists of;

In Administration (13):
            1 District Attorney
            1 Office Manager
            10 Legal Assistants
            1 Victims Assistance coordinator.

In Criminal (9):
            8 Deputy D.A.‘s
            1 Deputy D.A. for Juvenile
                                         -9-
               A.3 Existing Hardware/Software
Presently we utilize Tiburon‘s version 7.4 for Records (RMS), Computer Aided
Dispatch (CAD), Corrections Management System (CMS), Field Reporting (ARS)
and version 1.0 for Tiburon‘s District Attorney (PIMS) system. Our goal is to
migrate the entire integrated system to a Microsoft Windows and SQL platform..
Present hardware configuration is as follows;

R/S 6000 model
     CAD911 (CAD Server) IBM 7028 6C3 P series ~30 GB Used Disk Space
     RMS911 (RMS Server) IBM 7028 6C3 P series ~75 GB Used Disk Space

Paging
     Zetron Paging Device

Remote Sites
    FortiWifi 50B (Remote VPN Sites)

Connectivity
    Fortinet Firewall
    Cisco 3750 1 Gbps Backbone Switch

VMware Cluster (4 x Dell PowerEdge R710)
    CADARS - Field Reporting, Client Updates
    CADWEB- Web Based Tiburon Client
    CADTIPS - Mugshots

MDC’s -
    Panasonic Toughbooks (103)

Workstations
    RMS installed on workstations -             202
    CAD installed on workstations -               8
    JAIL (CMS) installed on workstations -       19
    DA (PIMS) installed on workstations -        22




                                       - 10 -
              A.4 SYSTEM SELECTION
PLEASE CHECK ALL THAT APPLY FROM THE LIST BELOW OF SYSTEMS
AND/OR FUNCTIONAL AREA(S) THAT YOU ARE RESPONDING TO.

                                      INTERFACE
                           SYSTEM     AVAILABLE
                           (Y OR N)    (Y OR N)
      CAD

      RECORDS

      JAIL MANAGEMENT

      CIVIL PROCESSING

      FIELD REPORTING

      MDC, MDT‘S

      GUN PERMITTING

      FINGERPRINTING

      MUGSHOTS

      DISTRICT ATTORNEY




                            - 11 -
       A.5 PERIPHERAL INTERFACE SELECTION
PLEASE CHECK ALL THAT APPLY FROM THE LIST BELOW OF SYSTEM
FUNCTIONALITY THAT EXISTS WITHIN THE LAW ENFORCEMENT
ARCHITECTURE YOU PROVIDE.
                                               INTERFACE
                                      SYSTEM    AVAILABLE
                                      (Y OR N)   (Y OR N)
   NIBRS/UCR
   LEDS/NLETS/NCIC
   (State Message Switch Interface)
   VINES
   (Victim Identification Notification System)
   NDEx
   (National Data Exchange) * See Below
   COPLINK
   911 RECORDING
   E-911 ALI/ANI
   911 MAPPING
   COMMISSARY
   INMATE PHONE SYS.
   CASH RECEIPTING
   INMATE BANKING
   INMATE MEDICAL
   MULTIPLE AGENCIES

* Presently used by Oregon State Police
N-DEx brings together data from law enforcement agencies throughout the
United States, including incident and case reports, booking and incarceration
data, and parole/probation information. N-DEx detects relationships between
people, vehicles/property, location, and/or crime characteristics. It ―connects the
dots‖ between data that is not seemingly related. And it supports multi-
jurisdictional task forces—enhancing national information sharing, links between
regional and state systems, and virtual regional information sharing.



                                        - 12 -
         A.6 REQUIREMENT RESPONSES

Please respond to the requirements as follows –

   Y = Yes we perform the requirement as asked

   N = No this feature is not available

   C = Customization – quoted as a line item

   F = Future addition to our system

ALL vendors please answer sections B & C

Then answer those sections of requirements that
apply to your system(s).

Use Section J3 if necessary for issues that are not
covered by your software/hardware.

Fill in Proposal Validation in Section K.

  Submitted responses to be delivered to Douglas
     County, Oregon by the deadline stated.




                          - 13 -
                       SECTION B
              B.1 TECHNICAL REQUIREMENTS
                                                                     Response
1.    System highly preferred to be WindowsSQL based/server
based application with mirrored disk protection.
2. Provide for complete security and restrictions to access both
internally and remotely.
3. Provide log files of all access internally and remotely.
4. Vendor will supply all technical specifications for hardware
related to operating their software at an optimum level.
5. System should be able to handle multiple agencies (local
PD‘s).
6. System should interface with local first responders (Fire
Departments, ambulance services, etc..)
7. Incorporate application in conjunction with Microsoft SQL
database server.
8. Allow for the provision of remote diagnostics via web.
9. Allow open-file backup of data, so as not to interfere with
normal operation of law enforcement and DCSO.
10. Permit an interface with standard mapping applications such
as ARCView and MapInfo.
11. Support internet access by means of the TCP/IP information
transfer protocol.
12. Does the system support – running the primary servers in a
Virtual environment.
13. Does the system support – running in a 100% virtual
environment.
14. Is the system compatible with Windows Server 2008 R2.
15. Does the backend database system – support mirroring (or
similar technology) to provide a fault tolerant configuration
that continues to operate during a database server failure.
16. Will the system be able to provide a ‗Dashboard‘ that displays
an overview of overall health status of the system.
17. If the system needs to interact with any external equipment,
does it support interfacing via TCP/IP.
18. If web based components are used do they support multiple
web browser platforms.
19. Is the system capable of resource handling for 300+
concurrently connected devices/users.

                                       - 14 -
20. Does the system provide a minimum of 1 year‘s log activity in
a searchable format without having to load archives.
21. Is the system ‗bandwidth efficient‘ so that it does not saturate
low bandwidth connection to remote/mobile users.
22. Do you have multiple interface capabilities to multiple types of
E-911 hardware.
23. Does the system support storing the primary data on iSCSI
volume(s).
24. Does system support running in a Microsoft Terminal Services
environment where multiple user sessions originate from the
same server/ip address.
25. Can upgrades be performed without impact to the users.
26. Do you allow for the use of Notebook/tablet technology.
27. Do you allow for the use of phone technology with any
applications.

Please answer the following:
28. What are the system storage requirements.




29. What are the workstation requirements.




30. Please describe in detail how the system ensures very high reliability.




31. Do you provide complete database schema specs for your database - listing
tables, fields and relationships – please discuss ----




                                        - 15 -
                   SECTION C
      C.1 GENERAL FEATURES/REQUIREMENTS

                                                                         Response
1. Provide audit trail of on-line file maintenance to critical fields
with Operator ID, Terminal ID, date/time, and old/new data.
2. Allow for all data to be entered on a preliminary basis subject
to review and validation for posting.
3. Allow for data base inquiry by any and all fields entered
and/or displayed.
4.    Provide a complete set of easy to read and understand
user/system documentation either in hard copy or on-line.
5. Provide ability for secured remote access for inquiry only by
outside agencies and news media personnel.
6. Incorporate spell check, copy and paste from other
applications, and the ability to compose narratives using
another word-processing program when working with the
narrative function.
7. Provide field-to-field data entry with each field identified on the
screen.
8. Support the use of touch screen monitors and make extensive
use of color-coding for easily identifiable text and fields.
9. Provide a way for the user to view when a record was entered
and from where on the network it was entered (date entered and
last activity date).
10.Allow simultaneous access to the records database by a
virtually unlimited number of users, to the extent provided by the
DCSO hardware.
11.Provide ‗permission based‘ use of system, allowing the
designation of definable user groups.
12.Support one-stop printing/faxing and allow exporting reports to
Excel/Word or other spreadsheet/report writing methodology.
13.Allow print jobs to be directed to various network or local
printers.
14.System should be easy to operate with the emphasis not on
computer skills.
15.System MUST provide any/all state required reports.
16.Allow for conversion of all historical data from existing files.
17.Vendor MUST be able to include all requirements of these
systems that are dictated by Oregon law (statutes).

                                          - 16 -
18.Vendor MUST be able to comply with all future Oregon laws
and provide them as a non-billable maintenance feature of the
software as well as FREE upgrades to each system responded
to.
19.Provide ability to image documents.
20.Provide ability to index all imaged documents to all associated
data.
21.Have capability for web enablement though browser
functionality.
22.Allow the user to add, edit or delete unlimited narratives in any
part of a case or record.
23.Allow different users access to information based on their
security configuration.
24.Enable the user to title narratives and display them in a
browse list.
25.Cross reference pertinent databases for outstanding warrants.
26.Allow anyone who has access to a record the ability to view
narrative.
27.Provide a system accessible glossary containing some of the
basic terms used in the records system.
28.Produce code tables containing the summary information
presented in selection menus throughout the system.
29.Permit access to officer identification information from
appropriate screens by use of a keyboard stroke or mouse.
30.Provide a calendar function, which allows the user to
add/verify dates.
31.Integrate data from arrests, jails and courts from the agencies
under the scope of jurisdiction.
32.Allow the storage of records tracked by RMS to the full extent
permitted by the size of the storage device.
33.Record and permanently store all data entered into RMS.
34.Provide the exact emulation of many official state incident,
arrest, and DMV/Accident report forms.
35.System to support the record-keeping requirements of multiple
police, fire/EMS, jail, and court agencies.
36.Ability to interface with a sketching program in order to provide
on-line drawings.
37.Provide ability to show statistical reports in graph/chart format
(bar, pie, gantt, etc.).
38.Provide option allowing the user to spell check a word against
words that sound similar (sound-ex).

                                        - 17 -
39.System should have the capability for interface with scene
drawing tools if not incorporated in base system.
40.Provide a complete and accurate NCIC interface.
41.Provide a LEDS (Law Enforcement Data Switch) interface.
42.Support implementation or interface to AFIS fingerprint
imaging systems.
43.Permits the display of general directory permission, as well as
file access permission within the directory.
44.Provide an automatic link to all the different records within
each of the many folders.




                                      - 18 -
                 SECTION D
      RECORDS MANAGEMENT REQUIREMENTS
D.1 MAPS
                                                                     Response
1.1 Ability to display historical calls in a graphical report
instead of a printed text format by using MapLink.
1.2 Boundaries can be modified and updated when districts
grow or change to encompass new territory.
1.3 Ability to see RMS and map simultaneously by adjusting the
display or toggling between the two programs.
1.4 Add and desired labels to street labels table.
1.5 Mapping should be menu driven in order to require
minimum training for proficiency in the available functions.
1.6 Allow two maps to be displayed at the same time (i.e. close
up of an area and the entire area).
1.7 Allow maps to be drawn internally, digitized from external
sources, and imported from other mapping programs such as
ArcView or MapInfo.
1.8 Allow the user to define how the map is displayed including
the size of the area and the appearance of the map.
1.9 Provide the ability to interface with most DCSO-specific
mapping programs by utilizing connecting software.
1.10 Provide the ability to work in conjunction with mapping
software such as MapLink, MapInfo, or ArcView to provide the
capability to pinpoint addresses on a geographic map.
1.11 Permit the sharing of maps within e-mail and Microsoft
Windows documents by means of DDE and OLE capabilities.
1.12 Allow the user to display, upon command, points of interest
such as cross streets, hydrants, or hazards.
1.13 Allow the display of nearby landmark structures (e.g. water
sources, utilities, and businesses).
1.14 Provide the display of various perspectives (e.g. close-ups
of individual neighborhoods, entire county).
1.15 Provide the ability to set and visually identify emergency
evacuation areas and routes.
1.16 Provide the ability to produce maps illustrating the location
of various incidents through the use of system records.



                                      - 19 -
D.2 MASTER INDICES
                                                                        Response
2.1 Provide the ability to define Master Location records
through a coded table.
2.2 Allow the user to query and interface with the master name
index, the master address index, the master property index, and
the master vehicle index – subject to system rights granted by the
administrator.
2.3 Maintains lists of all names, property, addresses, and
vehicles entered into the DCSO‘s records from any module.
Searches the database(s) for matches automatically whenever a
new record is added. Alerts the user whenever a match is found
in any Master Index module.
2.4 All text entry fields should be searchable, allowing for
searches on single or multiple fields.
2.5 If a match is found when entering any master index
information, allow the user to select the matching record and fill in
corresponding text entry fields automatically with same
information.
2.6 Allow the user to add information to the master indices
directly, independent of other records.
2.7 System should provide use of a master alias database that
contains a separate record for every name (and every version of
that name) that has ever been added to the system.
2.8 System should keep track of both individual names and
business names and distinguish between the two types in record
searches.
2.9 System should allow the linking of one master name record
to numerous master alias records, such that whenever a name
search is performed it must actually search the master alias
database first.
2.10 Allow the viewing of an image attached to any of the various
name modules by associating the image with the appropriate
master name record.
2.11 Provide the ability to display a list of aliases for any master
Name.
2.12 System must alert the user automatically if a master name
entry is the subject of an outstanding civil paper or unserved
warrant in any jurisdiction.
2.13 Link alias records that belong to the same master name
record automatically.
2.14 Allow the user to manually link names having different
master name records.
                                        - 20 -
2.15 Allow the disassociation of manually linked alias records.
2.16 Allow a user with the appropriate user rights to remove
internal links of alias records to master name records if they were
established by the system.
2.17 Provide the ability to merge two master name records into a
Single record.
2.18 Allow the user to view a synopsis of an individual‘s history
throughout the records management system.
2.19 Allow the user to add gang affiliations records to individuals
in the master name database.
2.20 Provide the ability to associate ‗Alerts‘ with name records,
such that a user is alerted when he/she accesses that record.
2.21 Allow the user to add ‗Known Associates‘ records to
individuals in the master name database.
2.22 Provide the ability to indicate scars, marks, tattoos, and
other body identifiers through use of a front and back body chart.
Link body identifiers to master name records upon entering,
updating, or querying any associated name module.
2.23 Allow the user to add Modus Operandi (MO) records
associated with individuals in the master name file.
2.24 Provide the ability to attach audio-visual information on
buildings, landmarks, and structures – including floor plans,
photographs, audio clips, video clips, and other multi-media
information.

D.3 OBJECTS
                                                                      Response
3.1 Allow the user to attach an OLE file (Object Linking and
Embedding) to any record.
3.2 Provide the ability to automatically convert changes made in
an original object to the current file when object saved as linked.
3.3 Provide the ability to freeze live video pictures and attach
them to existing files.
3.4 Allow the display of an object as an icon, indicating the file
Name.
3.5 Allow the user to update an object and its description, after
an object is attached to an RMS record.




                                       - 21 -
D.4 REPORTS
                                                                          Response
4.1 Provide the ability for the user to simply produce multiple
reports in these categories. Arrest, Officers, Citations, Civil,
Juvenile, DMV, evidence, Gun Permits, Incidents, Crime
Analysis, Logs, Pawn and Warrants.
4.2 Provide the ability to preview, print and export any report or
graph.
4.3 Provide an ‗export‘ option on the report menu allowing the
user to export field values to mail merge documents in Microsoft
Word.
4.4 Allow faxing of all reports.
4.5 Allow the user to send a report to a file so that the data can
be imported to a text based or word processing application.
4.6 Allow the creation of synopsis reports which provide
statistics on the total number of closed incidents and average
number of days to clear cases.
4.7 Validate all NIBRS cases for the selected jurisdiction and
month, and notifies the user of any validation errors in conjunction
with IBASE reporting.
4.8 Provide a report preview window that displays what a
printed report will look like including scrolling, printing, exporting,
and zooming options.
4.9 Allow reports to be exported to HTML, a Microsoft
Exchange folder, a Lotus Notes database, and e-mail.
4.10 Allow the user to send a report to a file so that the data can
be imported into other programs like Microsoft Word or Microsoft
Excel.
4.11 Provide ad hoc reporting functions allowing the user to
create and customize reports using information from the
database.
4.12 Prompt the user to name and save ad hoc reports so that
they may be accessible for future retrieval via a ‗browse‘ list.
4.13 Allow the user to add a table, link tables, select fields, edit
field properties, format the report, preview the report, save, and
print the report when creating ad hoc reports.
4.14 Provide a reporting feature that enables the personnel to
track maintenance histories.
4.15 Provide the ability for the user to create reports from ALL
DCSO data files.



                                         - 22 -
D.5 SEARCHES
                                                                        Response
5.1 Provide the ability to search any data field or any
combination of data fields from any database, table, or index.
5.2 Provide for approximation when conducting text searches.
5.3 Provide the ability for searches or queries to be conducted
for exact matches of specific data, or data meeting a range of
parameters including grater than, less than, between, sounds like,
and contains.
5.4 Allow the user to search text, date and numeric fields using
the search descriptors and Boolean operators =, >, <, >=, <=, ?,
#, and/or, *.
5.5 System should provide for a ‗find‘ option allowing the user
to search for record(s) based on the information in one field.
5.6 Allow the user to configure a key word list record to search
user defined key fields or key words.
5.7 Display a browse list of all records meeting the users
search criteria.
5.8 Offer a ‗seek‘ option allowing the user to filter the records
displayed in a browse list.
5.9 Provide a ‗seek‘ function which features a pull down
selection menu of search methods, including all those listed in 5.4
above.
5.10 Enable the user to identify any ‗match‘ found in a search by
file number and access a browse screen for a complete synopsis
of the record.
5.11 Provide a ‗view manager‘ function allowing the user to
choose fields, define their sort order, and apply filters for records
displayed in a browse list.
5.12 Provide the ability to query the state criminal database.
5.13 Enable the user to conduct NCIC queries.
5.14 Provide the ability to display data entered about specific
vehicles.
5.15 Provide the ability to inquire and display detailed
information about personnel, including any sick or vacation time.
5.16 Provide several ways to search for help, including search
for specific words, help topics, and the contents of the Help file
itself.




                                        - 23 -
D.6 SECURITY
                                                                     Response
6.1 Ensure content integrity by providing a ‗central
configuration‘ module which enables owning jurisdictions to
restrict file/information usage.
6.2 Allow security at table level through SQL server insuring
that no unauthorized person can view the data, even when using
third party software.
6.3 Enable the DCSO to use case type security to control
access to incident and arrest records involving juveniles and rape
victims.
6.4 Enable the system administrator to set up security based on
jurisdiction.
6.5 Allow the system administrator to set up security based on
user ID, case type, and such that each user can only view, edit,
add, print, and/or delete the types of records for which he/she is
authorized.
6.6 Provide password security which allows four unique levels
of protection in all areas of the program.
6.7 Provide a high level of operating system security including
passwords that will permit designation of access by user level or
group.
6.8 Allow the user only two attempts at entering the correct
password after which the account is locked out.
6.9 System should log data, time & device for each account that
is locked out.
6.10 All successful and failed logins need to be logged.
6.11 The system must prevent the user from re-using the last ten
passwords.
6.12 Password expiration intervals must be able to be set.
6.13 The system must force the use of complex passwords
(letters, numbers, symbols) and prevent the use of dictionary
words for passwords.




                                      - 24 -
D.7 USER DEFINED FORMS
                                                                     Response
7.1 Provide an equivalent ‗user defined‘ tab for every form,
such that the user-defined field(s) may be defined by the user.
7.2 Provide a ‗properties‘ button allowing the user to adjust the
size, move, or change field labels.
7.3 Allow the user to import DCSO information or other user
specific forms into a user-defined page.
7.4 Provide the user with the option of hiding a user-defined
field and recalling it at a later date.
7.5 Allow the DCSO to disable the ability to let every user
create user-defined fields.


D.8 ADMINISTRATION
                                                                     Response
8.1 Provide a personnel administration module/file/screen.
8.2 Classifications option should allow the user to manage the
DCSO‘s equipment and training needs by setting up
classifications based on the different job descriptions within the
DCSO. Once they are set up these may be selected when
adding personnel, equipment items, and training courses. Each
person has one classification, but equipment items and training
courses can have multiple classifications such that the user may
assign them to more than one type of employee.
8.3 Courses option should allow the user to maintain
information about the various training courses available to your
agency‘s employees.
8.4 The time codes option would allow the user to better keep
track of day that employees take off by establishing codes for
different reasons they might miss work.
8.5 The equipment option would allow the user to add inventory
records of the different kinds of equipment used at the DCSO.
8.6 The serial numbers for equipment option would allow the
user to enter a list of serial number records using the serial
number forms.
8.7 The shift option would allow the user to set up complex
work schedules for employees encompassing multiple shifts as
well as define a different shift for each time period that people
work.
8.8 The shift mix function would allow the user to set up how
many employees should be assigned to each day of the week.
                                       - 25 -
8.9 Schedule shifts option would allow the user to schedule
shifts using the shift and shift mix information previously set up.
8.10 The personnel option should allow the user to maintain
personnel records for each employee including personal
information, equipment, hours and training needs.
8.11 Equipment tracking functions should allow the user to easily
assign a specific equipment item to a specific employee.
8.12 Employee training function should allow the user to track all
courses completed by each employee.
8.13 Days off function should allow the user to keep track of the
days employees request off and the reason for each day off.
8.14 Administration module should allow the user to update
classification and course record pull down lists on personnel,
equipment, and course forms.
8.15 Administration module should provide the ability to generate
reports detailing training activity by officers including total
accumulated hours.
8.16 Administration module should allow the user to flag training
files to identify personnel in need of training.
8.17 Administration module should provide the ability to query
the system for personnel having specific skills.
8.18 Administration module should allow authorized users to
view an individuals previous reviews, time taken off, number of
years with the department, training completed, and overtime
worked.
8.19 Administration module should track vacation and sick time
taken and remaining.
8.20 Provide the ability to alert the system administrator when an
employee exceeds the allotted time off.
8.21 Provide a user defined option linking the administrative
‗hours worked‘ tables to CAD and Log so that the beginning and
ending tours of duty calculate the hours worked per day for each
unit.
8.22 Provide a shift scheduler that allows the user to establish
work schedules up to a year in advance.
8.23 Provide a shift scheduler flexible enough to allow the
change of specific personnel and/or specific hours worked within
a given period.
8.24 Allow the user to generate reports specific to the
administration module as well as ad hoc reports on any field or
combination of fields within the system.
8.25 Allow unlimited personnel files to be entered from single or
multiple departments.
                                       - 26 -
8.26 Allow classification of personnel by department, section,
rank, and training/equipment requirements.
8.27 Provide specially formatted screens for personnel data,
hours worked, equipment issued, department inventory, and
training records.
8.28 Provide the ability to track course information.
8.29 Allow the administrator to code training courses to indicate
whether it is required for a specific classification of personnel.
8.30 Ability to produce training schedules by requirement code
and frequency required.
8.31 Provide ability to track courses completed by employees
including course, date of completion, and score in the employee‘s
personal file.
8.32 Allow the user to retrieve course, date of completion, and
score by multiple criteria.
8.33 Provide the ability to generate training completion reports
for employees based on time frame and type of course.
8.34 Allow training schedules to be produced by any date range
and sort function.
8.35 Provide the ability to generate employee rosters showing
those employees meeting selected criteria.               List may be
generated by name, rank, time in service, identification number,
skill set, or other user defined criteria.
8.36 Provide the ability to display all personnel due by a specific
date for training or activities such as certification for first aid and
medical exams.
8.37 Provide a file for maintenance of personnel information.
8.38 Allow the user to easily assign a specific equipment item to
a specific employee.
8.39 Provide the ability for the administration module to record
each piece of equipment issued to an employee and subtract that
number from the proper inventory.




                                         - 27 -
D.9 ARREST
                                                                     Response
9.1 Provide the ability for the user to record arrest information
on pre-formatted, state-specific templates such as charge, drug,
property, name and vehicle.
9.2 Provide a main arrest form.
9.3   Provide a name form.
9.4   Provide a charge form.
9.5   Provide a drug form.
9.6   Provide a property form.
9.7   Provide a vehicle detail form.
9.8   Provide a vehicle owner form.
9.9 Allow for automatic form level validation for all arrest
   records.
9.10 Allow for standardization of incident based reports with
Uniform Crime Codes and validates to ensure correct codes are
used.
9.11 Provide the ability to automatically link to related incident
reports.
9.12 System should automatically alert user to outstanding
warrants.
9.13 Provide ability to associate files with an unlimited number
of people, crimes, vehicles, stolen/seized/other property, and
narratives.
9.14 Provide the ability to produce arrest forms on laser
printers emulating official state forms.
9.15 Provide ability to match state arrest and booking reports.
9.16 Allow user to validate an entire record including arrest,
charge, drug, property, and/or vehicle with one button.
9.17 Index master name, property, vehicle, location, and alias
databases during data entry to facilitate quick keyword searches.
9.18 Allow queries and interfaces with master name and alias
databases during data entry to facilitate quick keyword searches.




                                       - 28 -
D.10 BUDGETS
                                                                       Response
10.1 Provide the ability for the user to add, edit, delete, and view
cost centers.
10.2 Capture detail information regarding cost centers.
10.3 Allow ample space on the cost centers form for user defined
fields in the event the user desires to capture additional
information.
10.4 Provide a browse list from which the user may select the
‗cost center form‘ of interest, and immediately view its detailed
information.
10.5 maintain records of monthly cost center budgets (Jan.
budget) and actual expenditures (Jan. actual) for the current and
next year.
10.6 Allow the user to divide the agency into cost centers to
better track expenditures. For example, he/she might want to
make Administration one cost center and Security another. We
may decide to divide into as few or many cost centers as
necessary.
10.7 Allow the user to freeze a cost center budget from
unauthorized changes after it has already been created.
10.8 Allow the user to design and track monthly budgets
separately for each cost center within the DCSO and provide a
diagram of the budget items for each along with current budget
totals.
10.9 Provide the ability to represent all budgeting accounts in a
graphic overview or ‗Budget Tree‘ which plainly displays budget
details including parent and child accounts.
10.10 Provide the user color codes indicating fundamental
information regarding budgets such that a green folder in the
budget tree indicates that a folder has a positive amount. A red
folder indicates that an account has a negative balance. A yellow
folder indicates that a folder has a zero balance.
10.11 Allow the user to enter parent line items by choosing the
parent account that he/she wants to add a line item type to from a
drop down list.
10.12 Allow the user to enter item types, or descriptions of each
of the items that money will be disbursed to such that any
expense incurred or type of expense incurred would be listed.
10.13 Allow the user to add, edit, delete, and view information
about the various vendors that the DCSO buys or leases from.
10.14 Allow the user to generate ad hoc reports on any field or
                                        - 29 -
combination of fields captured by the system.
10.15 Provide a browse list from which the user may select the
‗vendor form‘ of interest, and immediately view its detailed
information.
10.16 Allow the user to add, edit, delete, and view expense and
distribution information.
10.17 Provide error checking and validation routines to allow for
balancing of accounts.
10.18 Allow the user to record expenses.
10.19 Allow the user to distribute expenses.
10.20 Ability to download selected financial information from
external source (ex. Oracle).
10.21 Ability to download selected billing expense information
into a billing form (specifically for grant billing). Since grants vary
greatly – need ability to pick and choose those specific items.
10.22 Provide user defined fields for items not in system – and
flexibility to manipulate them.
10.23 Provide the ability to limit access to various expenses (ex.
various expenses regarding overtime, specific medical duties,
some kitchen duties, etc.).



D.11 CASE RECORDS
                                                                          Response
11.1 Case records are the basis for all other incident type
records including arrest, juvenile, custody, incident.
11.2 Provide ability to track incidents related to a case, arrests
related to a case, and narratives added to a case report.
11.3 Provide access to pertinent case elements by means of a
case number reference on all associated records.
11.4 Ability to store and retrieve interviews, find case records, or
generate reports from records.
11.5 Automatically change all associated records when any
changes are made to a case record.
11.6 View the case number, case description, folder number and
jurisdiction in the browse window at the top of the form.
11.7 Ability to add a case by completing and saving the ‗main
case form‘ before adding additional information to a case, such as
arrests, juvenile custody records, or an incident.
11.8 Provide ability to record description of incident as user
defined or by UCR code titles.
                                         - 30 -
11.9 Jurisdiction associated with call number should be
automatically filled in the main case form if a call was generated
using the CAD program.
11.10 Select case type as reportable or non-reportable.
11.11 Provide the ability to either assign the case number
manually OR automatically assign if not present.
11.12 Provide the ability to attach objects and images within each
incident with imaging capabilities.
11.13 Allow users to change folder from the case records form
when necessary.
11.14 Specify the type of case, such as NIBRS or miscellaneous,
and what jurisdiction the case falls in.
11.15 System should assist and aid the user in NIBRS reporting
by requiring the elements mandated by the NIBRS system.
11.16 Include the ability to modify records when validating a
case. All missing or incomplete information to appear on the
display screen. Automatic field/form error validating.
11.17 Allow user to validate cases from the case records form.
11.18 Allow user to validate that a case is ready for submission to
the state by validation processing and a ‗no errors‘ message
display.
11.19 Provide for all reporting necessities (see reports section).



D.12 CASE MANAGEMENT
                                                                      Response
12.1 Provide ability to display detail from with one keystroke from
any incident form.
12.2 Allow supervisors to assign investigative status and monitor
case progress.
12.3 Allow supervisors to track and maintain officer availability,
task assignments, and solvability ratios as defined by the user.
12.4 Allow supervisors to update investigative status, case
dispositions, and view cases in any order by using a ‗view
manager‘.
12.5 Allow officers to update their status on case and incident
assignments.
12.6 Provide ability for user to access records defining which
officers are assigned to which parts of a case.
12.7 Automatically link the various parts of a case as they are
entered.
                                       - 31 -
12.8 Automatically link incident reports to arrest records, warrant
records, evidence records, and citation records.
12.9 Provide ability to move quickly/freely through all parts of a
Cases records.
12.10 Allow investigator or approved personnel to close an
incident if no investigation is to occur.
12.11 Include audit trail function to display the specifics of each
change made to a record including the date and time of the
change, who made the change, and the before and after value of
the field.
12.12 Ability to generate and print pre-defined reports and any ad
hoc reports (see report section).
12.13 Allow cross-referencing a solvability code file in order to
Weigh the probability factors in solving a given crime.
12.14 Allow supervisors to view and update which officers are
available for task assignment related to a case and the date
officer is assigned within the officer availability form.
12.15 Provides a task assignment form allowing supervisors to
assign individual tasks to each officer and monitor officer‘s
progress or completion of assignments.
12.16 Include seek function for quick retrieval of necessary
information.
12.17 Include synopsis function enabling user to review a list of
all parts of a record and sub-records simultaneously.
12.18 Include narrative function allowing user to attach a note,
memo, etc. to a form which contains vital supplementary
information.
12.19 Allow user to specify the type of reporting criteria to be
used (e.g. NIBRS).
12.20 Provide pre-defined and ad hoc reporting processes (see
Report section).


D.13 CITATIONS
                                                                        Response
13.1 Maintain information about every aspect of a citation
Including charge, fee, name, payment, and vehicle.
13.2 Provide the ability to alert the user if citation subject has
outstanding warrants.
13.3 Allows complete user-defined ad hoc reporting as well as
pre-defined reports for citation by category and citation by citation
number.

                                        - 32 -
13.4 Allows user to associate a citation record (including all sub
-records) to already existing folders and cases with one button on
main citation form.
13.5 Standardizes data entry by providing pull down menus
whenever possible.
13.6 Index master name, vehicle, location and alias databases
During data entry to facilitate quick keyword searches.
13.7 Allow user to query and interface with master name and
alias databases during data entry to facilitate quick keyword
searches.


D.14 CIVIL PROCESSING
                                                                         Response
14.1 Provide a Civil Master File.
14.2 Provide a Civil History file for auditing.
14.3 Has modules available for maintaining information about
every aspect of a civil paper including personal information about
the subject and complaint of the civil paper, information about the
officer/s assigned to the case, and information about the efforts to
serve the paper.
14.4 Provide the ability to track all civil papers by various criteria
(e.g. officer, case number, expiration date, etc.)
14.5 Grid number should be automatically generated by
geographic area, based upon patrol grid map.
14.6 System needs to produce reports on all outstanding civil
papers.
14.7 Civil screens should be specially formatted to follow layouts
of common civil papers.
14.8 Provide automatic checking for warrants when entering any
civil paper name.
14.9 Accommodates unlimited plaintiffs and defendants.
14.10 Index names of all civil plaintiffs and defendants during
data entry to facilitate fast searches.
14.11 System must be able to query all fields associated with the
civil process.
14.12 Allow user defined reporting.
14.13 Allow user to create/modify forms and control number of
copies to be printed by type of paper served (proof of service
form).
14.14 Allow multiple screens for multiple people involved.
                                         - 33 -
14.15 System must be able to produce routing slips (for serving
papers) for all involved parties.
14.16 Include radio number, date, time, and address on all
routing slips. Also must have an area to check if served
personally, sub-served, or posted (for Feds).
14.17 System must allow entry of routing slip data in order for
automatic generation of proof of service forms.
14.18 Allow user to control the number of forms printed (1,2,3). It
varies by type of paper served.
14.19 User maintained code tables for type, status, officers, etc…
must be available.
14.20 Ability to produce billing statements either by cycle or
individually.
14.21 System should have the ability to handle subpoenas.
14.22 Need the ability to track attempted but unsuccessful
service of papers.
14.23 System should be able to track restraining order
processing.
14.24 Need a special instructions field available both on-line and
on reports for any caution indicators.
14.25 Provide for on-line help for each field.
14.26 Provide auto fill as needed for as many fields as possible.
14.27 Must provide automatic fill of state and zip fields when local
city entered (city code table).
14.28 If subpoena is served at residence listed on the service
Jacket – auto fill address.
 Provide the ability to produce forms required by Douglas County
AND the state of Oregon Courts
14.29 Track abandoned vehicles.
14.30 Be able to backtrack any multiple screen processing.
14.31 Auto fill date fields where applicable.
14.32 Have the ability to flag a name if they have a concealed
handgun license when entering restraining orders or stalking
orders.
14.33 System needs to produce letter to petitioner requesting
additional info/address on outstanding restraining orders.
14.34 All information entered into Civil must be linked to
RMS/CAD/JAIL/DA so as to eliminate duplicate data entry.
14.35 Information entered into Civil must be accessible to all
modules in the system.
                                        - 34 -
14.36 Alerts the user to any unserved civil papers and cross
-references them to jail confinement records or arrest records
stored in the system.
14.37 Allow the user the option to either view or ignore the
audible or visual warning regarding unserved papers.


D.15 DMV ACCIDENT
                                                                      Response
15.1 Maintain accident and incident reports involving vehicles
and/or pedestrians.
15.2 Ability to query the DMV database.
15.3 Integrates with sketching software for quick generation of
detailed accident diagrams.
15.4 Allows the user to add, edit, view, and delete the DCSO‘s
DMV records.
15.5 Complies with state specific DMV forms.
15.6 Standardizes data entry by providing user with a list of valid
DMV codes.
15.7 Provides unlimited narratives.
15.8 Allows complete user-defined ad hoc reporting and pre-
formatted DMV reports by file number.
15.9 Queries and interfaces with Master Name and Alias,
Location, Vehicle, and Property databases.
15.10 Indexes Mast Name, Property, Vehicle, Location, and Alias
databases during data entry to facilitate quick keyword searches.


D.16 EVIDENCE
                                                                      Response
16.1 Maintain information about every piece of evidence related
to a case.
16.2 Allow accessibility of evidence information through a search
engine.
16.3 Allow reports to be sorted by type of evidence and officer
the evidence was assigned.
16.4 Allow user defined ad-hoc reporting.
16.5 Track every piece of evidence providing a place to record
all points of the chain of custody.
16.6 Allow the ability for user to designate evidence tag number
field as a barcode/non-barcode field.
                                       - 35 -
16.7 Allow for automatic search of the stolen property database
AND issue warning if a match is found as the user enters
information about a piece of evidence.
16.8 Allow search capability on all entered fields including
unlimited narrative (comments).
16.9 Provide the ability to include any and all fields on printed
reports.
16.10 Provide ability to associate evidence and evidence custody
record to a specific case AND/OR multiple cases.
16.11 Allow objects to be imported from other applications.
16.12 Provide ability to interface with master name and property
databases.
16.13 Provide specially formatted screens for easy data entry.
16.14 Allow for inventory reporting (audit).
16.15 Provide ability to report on evidence no longer needed –
including integration with District Attorney proceedings for
dismissals and six-month expiration dates for misdemeanors.
16.16 Allow for multiple locations of evidence within a case –
intake/storage/out taking
16.17 Provide ability to produce OSP activity report in State of
Oregon format.
16.18 Produce evidence reports as required by Douglas County
evidence personnel.


D.17 FIELD INTERVIEWS
                                                                    Response
17.1 System must make it possible to associate a field interview
record (including all the sub-records such as name or vehicle) to
already existing folders and cases.
17.2 Allow the assignment of a user-defined number to field
interviews after being saved by the user.
17.3 Provide the ability to query and interface with databases
from the field interview module including master name and alias,
master location, and master vehicle.
17.4 Provide the ability to cross reference field interview name
entered with warrants database and issues a warning if the
person has any outstanding warrants or civil papers to be served.
17.5 Maintain a Field Interview master file



                                        - 36 -
D.18 CASE HANDLING
                                                                       Response
18.1 Provide a single point of reference for all information
associated with both present and historical law enforcement
activity.
18.2 Allow the creation of folders for use in managing individual
cases, all cases assigned to individual officers, all cases
belonging to a given department, and any use defined by an
individual or organization.
18.3 Allow law enforcement supervisors convenient means for
monitoring the assignments of officers under their jurisdiction.
18.4 Provides complete visibility to associated details of a case,
including incidents, arrests, and custody by means of synopsis.
18.5 Allow the user to organize investigations that are related,
accidents and citations attributed to a given officer, accidents and
citations associated with a given shift, warrants by type, and
warrants by any user defined category.
18.6 Provide the ability to share information with all master
indices modules (address, name, property, vehicle), and use
capabilities and information of the accessories (images, objects,
reports).
18.7 Maintain groups of folders by jurisdiction number,
jurisdiction/agency name, folder description, confidentiality flag,
and folder number.
18.8 Allow sub-module records to be organized with the
appropriate folder.
18.9 Allow the movement of records to other folders within the
same jurisdiction.
18.10 Includes the jurisdiction number and name in an easy drop
down box. Also includes the folder description, confidentiality
check-box and folder number which automatically populates once
the record is saved.
18.11 Provide multiple ‗canned‘ reports for day to day operations.
18.12 Need to track citations issued and by whom.
18.13 Provide ability to pull up number of citation/case/civil paper
served/other crime analysis information by key word or words.
18.14 Permit the entry and verification of jurisdiction information
whenever a new folder record is entered. These fields may not
be subsequently modified.




                                        - 37 -
D.19 GUN PERMITS
                                                                      Response
19.1 Ability to generate and print reports on standardized forms.
19.2 Provide the ability to generate reports based on user input.
19.3 Provide an approval option that automatically assigns a
permit number.
19.4 Provide the ability to generate and print pre-defined reports.
19.5 Provide the ability to maintain information of people
providing a reference for the person asking for the gun permit.
19.6 Maintain information about permit type and reasons to
approve or deny the permit.
19.7 Maintain information about the person and firearm for which
the permit is being applied.
19.8 Provide the ability to include references, types of permits
issued, and reasons for approvals or denials.
19.9 Allow the user to add, edit, and view the agency‘s gun
permit records.
19.10 Provide the ability to query and interface with master name,
alias, and master location databases.
19.11 Provide the ability for tracking gun permit records through
all aspects of the RMS system.


D.20 HELP
                                                                      Response
20.1 Accessed by means of pointing and clicking with the
mouse, or by a simple keystroke combination ( ALT+H for
example).
20.2 Features on-line help documentation on how to use the
Records Management System.
20.3 Includes a built-in glossary, accessible through the on-line
help feature.
20.4 Features examples and demonstrations, reference
information about using RMS commands, and links to other
related help topics.
20.5 Includes a ‗Contents‘ category (to display ‗how to‘ and
reference information, specifically general RMS features, before
you begin instructions, basics and essentials, overview of
systems     administration,    personnel,    budget,    equipment
maintenance, ad hoc report wizard, and reference manual), an
index category (containing a comprehensive on-line help index),
                                       - 38 -
and a ‗find‘ category (that will allow the user to search for
particular words and phrases in help topics instead of searching
for information by category).
20.6 Allow the first-time user to build a ‗search database‘ without
technical assistance, thus allowing more flexibility in defining
search capabilities.
20.7 Permit refinement of the search database, allowing the
inclusion or exclusion of help files, complete phrase searches,
unlimited topic searches, similarity searches, and use of matching
phrases as user types an entry.
20.8 Enable the user to mark a topic for later reference, and then
search the ‗find database‘ for information on that topic.
20.9 Permit a user to make comments, notes or suggestions
regarding a help tip or help procedure through the adding of an
annotation.


D.21 IMAGING/MUGSHOTS
                                                                      Response
21.1 Provide the ability to attach mug shots, accident scenes,
and sketches to all records.
21.2 Provide the ability to capture and view high quality color
photographs or digital images.
21.3 Attach images of a person to specific records.
21.4 Provide the ability to present a secure line-up by limiting
access to the suspect‘s information; user must enter a sequence
of keys to access the master name files.
21.5 Provide the ability to compare mug shot images produced in
a search using user provided details (e.g. comparing location
and/or design of a tattoo, mark or scar).
21.6 Alert the user when a suspect appears in the database
several times, allowing the user to choose the most appropriate
picture.
21.7 Perform a search for images by name.
21.8 Search and print computerized images from records
Screens.
21.9 Use images individually for mug shots, crime scenes, or
collectively (e.g. line-up).
21.10 Attach images to a record.
21.11 Perform a search for images of people who match the
known physical description of a suspect.

                                       - 39 -
21.12 Produce a line-up from the images in the system using any
combination of specified criteria.
21.13 Use secondary search fields for user discretion in defining
suspect search criteria (for example search for brown and blue
eyes).
21.14 View all images within the Records Management System
on a single screen; select browse all from the images button
located on a master menu.
21.15 Interface imaging module with Snappy or another industry
approved capturing device.
21.16 Interface software with a LaserJet printer (high
Speed/quality).
21.17 Allow the application of additional software applications to
provide imaging with the capabilities of capturing, storing and
retrieving 24-bit digital color images for purposes such as mug
shots, alert bulletins, line-ups, and ID cards.
21.18 Allow the user to select an image of a suspect then retrieve
his/her name and pertinent information by a single keystroke.
21.19 Allow witnesses to view images in multiple order for
positive identification.
21.20 Provide a ‗browse all‘ feature to include user defined detail
date pertaining to the suspect (for example; folder number, case
number, description, name, etc.).
21.21 Ability to edit images.



D.22 INCIDENTS
                                                                       Response
22.1 Provide a method to add supplemental information to an
approved incident while maintaining the security of the original
form.
22.2 Allow the user to enter an unlimited number of crimes,
Vehicles, property, reportees and witnesses.
22.3 Provide the ability to index incident statistics to produce a
monthly summary report, trend analysis report, UCR reports,
stolen property reports and numerous user-defined reports.
22.4 Validate all NIBRS cases for selected jurisdiction and
Month.
22.5 Provide the ability to notify the user of any validation errors
for all NIBRS cases.
22.6 Incident forms must emulate state forms when produced on
a laser printer.
                                        - 40 -
22.7 Names, property, vehicles, locations and aliases must be
indexed for fast keyword searches.
22.8 Provide a complete audit trail to indicate any changes made
to data.
22.9 Provide the ability to search by user defined criteria.
22.10 Ability to produce synopsis reports to provide statistics on
total numbers of closed incidents and the average number of
days to clear cases.
22.11 System must have the capability of form level validation for
incident, incident offense, victim, suspect, drug, property,
business and vehicle forms upon saving.
22.12 Include an approval button that allows an officer with
Approval rights to approve the incident.
22.13 Provide the ability to change an approved incident through
use of a supplemental form.
22.14 Provide the ability to display original, approved values – but
will alert the user that a supplemental exists.
22.15 Supplemental form should include fields that changes have
been made to, along with the before and after values, and the
name of the person who made each change.


D.23 NIBRS REPORTING
                                                                       Response
23.1 Provide the capability to enter incident information through
the official NIBRS incident report or through the record view
depending on system defaults.
23.2 Display the official NIBRS incident report when first adding
an incident from a case record.
23.3 Ability to view changes to incident report at any time by
selecting an ‗audit trail‘ function from the menu.
23.4 Page 1 (first screen) should contain general information,
offense information and victim information.
23.5 Ability to enter more than three offenses through the record
view.
23.6 Ability to select up to three criminal activity types to
describe the type of criminal activity from a pull-down selection
menu.
23.7 Ability to select up to three codes to describe the type of
weapon from a pull-down selection menu.
23.8 Ability to select whether or not a weapon is an automatic
from a pull-down selection menu.
                                        - 41 -
23.9 Provide the ability to search the master name/alias database
after entering victim name. Selecting closest match and populate
all information or add the new name to the database.
23.10 Ability to select victim‘s address from master address
database or geo-validate a new address.
23.11 Age field should calculate automatically from entered date
of birth.
23.12 Ability to select up to five injury types.
23.13 Allow user to select up to ten offenses per incident.
23.14 Page two (second screen) of the official NIBRS report
should contain property, offender, arrestee, and witness
information about the incident.
23.15 Provide the ability to enter more than one piece of property
with a different type of property loss and to hit on master property
information using the record view.
23.16 Provide the ability to search the mast name/alias database
after entering offender name. Select closest match and populate
all information or add new name to the database.
23.17 Ability to select offender‘s address from the master address
database or geo-validate a new address.
23.18 Ability to select appropriate weapon code from a pull-down
selection and indicate whether the weapon was automatic.
23.19 Provide the ability to automatically generate arrest number
according to the number mask set in system administration.
23.20 Provide the ability to select the correct UCR code for the
arrest charge from a pull-down selection menu and add more
than one arrest charge record for each offense through the record
view.
23.21 Provide the ability to attach narratives to witness
information.
23.22 Search the mast name/alias database after entering
witness name. Select closest match and populate all information
or add new name to the database.
23.23 Provide the ability to select witnesses‘ address from the
mast address database or geo-validate a new address.




                                        - 42 -
D.24 PROPERTY
                                                                          Response
24.1 Provide an option of displaying a previous property record if
an exact match is made on make, model, and serial number.
24.2 Provide a Property Records master file.
24.3 Provide the ability to search master property database after
entering serial number. If a match is made and the item is listed
stolen, jurisdiction and case number should be listed for the
stolen property.


D.25 RECORD VIEW
                                                                          Response
25.1 Provide the ability to allow the user to add or modify
information, including drug records, interview records, incident
information, additional offenses, and information about people or
businesses involved with the incident, property records, or
validate an incident.
25.2 Ability to select the order in which record types are entered.
25.3 Ability to enter information involving drugs in an incident.
25.4 Ability for the supplemental area to be automatically
checked if the incident is approved and changes have been
made.
25.5 Modified fields should be displayed as a different color.
25.6 Ability to search master name/alias database after entering
interviewee name.          Select closest match and populate all
information or add new name to database.
25.7 Provide the ability for the incident number to be
automatically generated based on a number mask in system
administration.
25.8 Changes made after approval must be considered
supplements.
25.9 Date of incident, day of week, and date incident end should
automatically fill in if using the date reported field as a substitute.
25.10 Allow for fast path addition of witnesses, complaints,
victims, and suspects through use of a pull-down menu or button
driven function.
25.11 Person number should be a generated number that
increments with each added person or business.
25.12 Ability to search master name/alias database after entering
suspect name. Select closest match and populate all information
                                         - 43 -
or add the new name to the database.
25.13 Ability to check suspect address against master address
database or geo-validate a new address.
25.14 Allow the victim to be a person or business type record.
25.15 Provide the ability to search the master name/alias
database after entering business name. Select closest match
and populate all information or add new name to the database.
25.16 Provide ability to check business address against master
address database or geo-validate a new address.
25.17 Allow other involvement types such as complainant,
guardian, other, parent, reportee, or witness to be associated with
incident records.


D.26 VEHICLE
                                                                      Response
26.1 Provide the ability to search a master vehicle database after
entering the vehicle identification number. If a match is found
vehicle record will automatically be populated.
26.2 Provide the ability to search the master name/alias
database after entering vehicle owner. If a match is made owner
record will automatically be populated.
26.3 Provide the ability to customize any produced forms –
abandoned vehicle, impound, etc.


D.27 FIELD REPORTING
27.1 Provide the ability to support over 100 MDC‘s in the field
27.2 Does your system allow for the following process:
      Initiation of report in the field
      Pull relevant data from Computer Aided Dispatch System
      Pull relevant data from Jail Management System
      Allow Officer to input narrative and associated data
      Officer completes/approves validity of report
      Supervisor reviews report
      Officer makes corrections/then Supervisor approves
      Records reviews
      Officer makes corrections/then report transferred to RMS
      Report is locked for update.
27.3 NIBRS information needs to have a look up process for
automated entry – saving time for and authentication for Officer.
                                       - 44 -
27.4 Provide ‗automated mark-ups‘ so when report is being
reviewed – it can be done electronically both for the Supervisor
and the Records Clerks.
27.5 Allow Supervisors (through security) to make minor
changes to the Officer‘s report involving spelling or grammar.
This would entail a sophisticated level of security.
27.6 Does your system provide for electronic distribution of
reports – by e-mail, fax, etc…
27.7 The need in a report writing system is for an excellent word
processing tool. Does your system include this and when writing
the report – is the narrative going directly into the database.
27.8 Does the system provide for code tables when inputting
report data – for example if inputting ‗firearms‘ you should be able
to type a name and then choose from a list of possible correct
choices.
27.9 Provide the ability to attach the CAD history of a call to a
report.
27.10 Do you provide enough space in the property and evidence
fields to adequately describe the item.
27.11 Allow an override in the event of property/evidence tags
needing to be corrected (with proper security).
27.12 Produce Douglas County defined property/evidence slips.
27.13 Property/Evidence reporting needs to be tailored to the
specifications of the Douglas County Sheriff‘s Office.
27.14 Allow for auto-population of fields wherever possible.
27.15 Provide bar coding for property and evidence.
27.16 Provide the ability to attach digital evidence to report.
27.17 Provide the ability to generate a PC (Probable Cause)
Affidavit.
27.18 Can system be interfaced with an on-line citizen reporting
system.
27.19 Provide the ability to electronically fill out a traffic accident
report.
27.20 Need to produce reports from CAD entries.
27.21 Provide reporting for warrants, runaways, MIP‘s and other
criteria as needed.
27.22 Provide law enforcement patrol logs from CAD entries.
27.23 Print media logs for internal and external use.
27.24 Receive calls from dispatch – add alarm notification.
27.25 Allow comment/narrative to include update status reports.

                                          - 45 -
27.26 Provide the ability to query other law enforcement and/or
State agency databases such as LEDS, NCIC, DMV records
27.27 Allow messaging from car to car, car to dispatch, AND car
to workstation.
27.28 Provide mobile mapping of car locations, call locations and
routing for incidents.
27.29 Provide a user customizable interface for mapping.
27.30 Ability to scan in/out and print bar codes to evidence while
integrating with the Records Management System.
27.31 Need a SIMPLE report writer to get statistical and ad-hoc
reports.
27.32 Provide a ‗staff notification‘ function that would alert
selected staff to certain types of events that were occurring.



D.28 INTERNAL AFFAIRS
                                                                     Response
28.1 Provide administrative functionality pertaining to officer
data, code tables, and number masks.
28.2 Maintain case information relating to Douglas County‘s
internal affairs investigations of officers.
28.3 Maintain data on the case, person(s), and exhibit(s) within
the case record.
28.4 Maintain information on the subject, complainant, and
witness within the person information area.
28.5 Tracks date received, received by, and exhibit within the
exhibit information area.
28.6 Allow the user to sort records in the way they wish to be
viewed (ordered).
28.7 Allow the user to add, edit, and delete officer information.
28.8 Allow user to add officers as needed or add entire division
at once.
28.9 Allow user to add, edit, and delete category/code/and
description for code.
28.10 Allow user to set up the number mask, which generates a
unique number for each case.
28.11 Allow user to add narratives associated with a record.




                                       - 46 -
D.29 JUVENILE CUSTODY
                                                                      Response
29.1 Provide security measures which enable users to access
records based on case types, jurisdictions, and juvenile rights all
definable in System Administration.
29.2 Store all juvenile data in separate secure tables including
images and narratives.
29.3 Maximum age limit for juvenile records should be definable
in System Administration.
29.4 Enable the user to record arrest information on pre
-formatted, state specific templates such as custody, charge,
drug, property, name, and vehicle forms.
29.5 Allow complete user-defined ad hoc reporting and several
pre-formatted reports including juvenile custody with case
disposition, juvenile custody with offender address, and juvenile
custody with offender detail.
29.6 Allow for automatic form-level validation for all arrest
records.
29.7 Provide standardized incident based reports with UCR and
validate entries to ensure correct codes are used.
29.8 Provide automatic link to related incident reports.
29.9 Provide automatic alert to any outstanding warrants.
29.10 Provide ability to access associated files with an unlimited
number of people, crimes, vehicles, stolen/seized/other property,
and narratives.
29.11 Provide the ability to produce custody forms on laser
printers emulating official state forms.
29.12 Provide ability to match state arrest and booking reports.
29.13 Allow the user to validate an entire record including arrest,
charge, drug, property, and/or vehicle with one ‗button‘.
29.14 Provide the ability to index master name, property, vehicle,
location, and alias databases.
29.15 Provide the ability to query and interface with all the above
databases.
29.16 The records area needs to be able to coordinate with the
Jail area for any customization involved with juvenile custody
records.
29.17 Docket connection – generate custody documents for court
appearances.
29.18 Provide a common visitor index for tracking.


                                       - 47 -
D.30 LOGS
                                                                      Response
30.1 Provide the user with the options to change folders, add a
name to a log, or create a case from a log at any time.
30.2 Allow the user to transfer log calls into case records to
Increase the efficiency of data entry.
30.3 Allow the user to query and interface with the master name
and alias and location databases.
30.4 Allow the user to add names pertaining to log records only if
the main record has been completed.
30.5 Provide the ability to generate detailed reports from the
Systems log records.
30.6 Automatically assign log numbers based upon the number
mask set up by the System Administrator.
30.7 Cases generated by log entries should be flagged (linked)
back to the log number.
30.8 Provide the ability to browse and select a log item and view
its detail information.


D.31 PARKING TICKETS
                                                                      Response
31.1 Maintain information about parking violations.
31.2 Provide the ability for user to establish codes from a
number of code classes including violation, permit class, permit
type, and ticket disposition.
31.3 Provide a parking ticket code form which includes category,
code, code description, and category description.
31.4 Provide the ability to print official notices of delinquent
parking citations.
31.5 Standardize data entry by offering pull-down menus
whenever possible.
31.6 Provide the ability to work with objects, images, and reports.
31.7 Provide the ability for user to view, add and edit the master
address, name and vehicle databases.
31.8 Provide the ability to query and interface with all law
enforcement databases.
31.9 Provide the ability to index during data entry to facilitate
quick keyword searches.



                                       - 48 -
D.32 PAWN
                                                                    Response
32.1 Provide the ability to track all pawn transactions within
Douglas County.
32.2 Provide the ability for automatic alerts if the individual
attempting to pawn item(s) has an outstanding warrant or civil
paper.
32.3 Provide the ability to capture information on person(s)
pawning items.
32.4 Provide the ability to check each pawned item to ensure it
has not been reported stolen.
32.5 Provide the ability to present information about items that
are reported stolen including location and folder number in which
the record is located.
32.6 Provide for unlimited pawnshops and items.
32.7 Allow for definition of pawnbrokers from the main menu.
32.8 Provide the ability to report on pawned items based on
property type, brand, model, individual who pawned the property,
and pawnshop.
32.9 Allow complete user-defined ad hoc reporting and pre-
formatted pawn data reports by ticket number.
32.10 Allow the user to add, edit, and view pawn ticket records.
32.11 Provide the ability to query and interface with all law
enforcement databases.


D.33 SYSTEM ADMINISTRATION
                                                                    Response
33.1 Provide the ability to accomplish the following on-line;
     33.1.1      central configuration which allows for defining
access rights for possible multiple jurisdictions
     33.1.2       number controls allowing for creation of masks
     for generating case numbers and record numbers
     33.1.3       officer information tables allowing for officer
     name to be accessed through officer ID‘s
     33.1.4       name pull-down menus
      33.1.5      code tables throughout the system
      33.1.6      user-defined system defaults
      33.1.7      synopsis setup for record displays

                                         - 49 -
      33.1.8      user rights and security
      33.1.9      user-defined keyword list setup
33.2 Allow the system administrator to assign rights to other
jurisdictions for purposes of sharing information using a central
configuration scheme.
33.3 Central configuration scheme should include the following;
       33.3.1      name of authorized jurisdiction
      33.3.2      modules authorized to share/view
      33.3.3      access permissions allowed
      33.3.4      names of all authorized access
33.4 Provide the ability to setup user‘s rights and privileges,
defaults, keywords, passwords, pawnbrokers, code tables,
number masks, form input orders, solvability codes and synopsis
criteria.
33.5 Provide the ability for the system administrator to add, edit,
and modify all system defaults.
33.6 Allow System Administrator to control table level access on
the SQL server.
33.7 Provide the ability to enable or disable at the field level.
33.8 Provide the capability to set up all code tables.
33.9 Provide the ability create keyword lists.
33.10 Provide the ability to maintain UCR code tables.
33.11 Provide ability to setup display characteristics of all
screens.
33.12 Allow System Administrator to setup field defaults and
overrides.
33.13 Provide ability to modify browse orders, sort orders, screen
orders.



D.34 TOWED VEHICLE
                                                                       Response
34.1 Provide the ability to have multiple categories of towed
vehicles for assisting and recording information.
34.2 Provide the ability to link with all other databases in the law
enforcement system.
34.3 Provide a Towed vehicle file.

                                        - 50 -
34.4 Provide the user the ability to select information from drop
down menus or check boxes.
34.5 Ability to capture towing company information.
34.6 Provide the ability for user to create several form letters for
instant notification of a vehicle being towed based on valuation of
vehicle.
34.7 Allow the user to create form letters and automatically insert
Owner/Vehicle information
34.8 Provide the ability for user to create ad hoc reports.



D.35 WARRANTS
                                                                       Response
35.1 Provide the ability for the user to keep track of warrant
subjects, issue warnings whenever the subjects name and/or
address is accessed regarding any activity in the system.
35.2 Provide the ability to associate warrant records to existing
cases, including all the sub records such as citation name,
vehicle, charge, fee, and payment records.
35.3 Allow for the association of names and address information
within the warrant database with the associated master indexes.
35.4 Provide the ability for the warrant records to track unlimited
Types of papers.
35.5 Include synopsis reporting providing warrant statistics by
officer, case, offense, jurisdiction, and type of paper.
35.6 Provide the ability to search on all information fields, based
on exact matches, words that sound alike, words contained
within, as well as dates/times/offenses/locations.
35.7 Allow for unlimited subjects, complainants, and narratives to
be added to a warrant record.
35.8 Warrant information must be compatible with state warrant
report layouts.
35.9 Names entered into the warrant records area must be
automatically indexed to facilitate quick keyword searches.
35.10 Allow user to create a user-defined warrant tracking form.




                                        - 51 -
                SECTION E
   COMPUTER AIDED DISPATCH REQUIREMENTS

E.1 Calls
                                                                        Response
1.1 Call entry is typically performed at a dispatcher position;
however, call taker and supervisory positions must also be
capable of call entry.
1.2 The call entry screen must be consistent for all user types
(call-taker, law enforcement dispatcher, fire/EMS dispatch, etc.).
This includes the operation of function key and menus.
1.3 The call-taker/dispatcher shall be able to enter an incident for
both the police and the fire and EMS dispatchers without having
to enter the incident information twice. The incident location may
be different from the caller‘s location.
1.4 The layout call entry screen shall be user definable. The
system manager shall be able to locate any entry fields on the
screen.
1.5 Any call entry screen must have capability of processing at
least five (5) multiple incidents at the same time.
1.6 If a call is in progress when another call is received, the call-
taker must be able to retrieve a new call entry screen for the
second call without losing the information already entered for the
first call.
1.7 Upon answering a call on 9-1-1, the complete ALI record shall
be displayed on the call entry screen.
1.8 If the call-taker has not already entered other information, the
call-taker can accept the 9-1-1 information as follows: the ALI
location as the incident location, the ANI telephone number as the
caller‘s telephone number, and the ALI location as the caller‘s
address. If the call-taker has entered data into any of these fields
prior to accepting the 9-1-1 information, the data shall be left as
entered by the call-taker.
1.9 All of the ALI information shall be saved into a database
(retrievable by the call-taker/dispatcher) and cross-referenced to
any incident created.
1.10 The time the 9-1-1 call was answered shall be made part of
the incident record if an incident is created. This time shall be
captured by the CAD system clock source based on when the 9-
1-1 controller received the ALI record.
1.11 The call-taker/dispatcher shall be able to verify a location
entered into location field of the data entry screen. The location
                                        - 52 -
shall be able to be entered as a street address, an intersection, or
a commonplace name.
1.12 Vendors shall indicate at what point in the call entry process
the location verification can or does occur. A call-taker shall be
able to verify a location without being required to enter an
incident.
1.13 The verification process shall take no more than three (3)
seconds to return a location.
1.14 The system shall have the capability of searching for a full or
partial street address.
1.15 The system shall have the capability of searching for an
intersection of two streets with either street listed first. The
complete name of each street of the intersection may consist of a
numeric, a directional prefix (i.e. E, W, N, S), the street name, the
street type, and a directional suffix. The system shall allow the
entry of multiple intersections of the same two streets. The call-
taker shall be able to enter the intersection with less than the
complete street name, preferably after the entry of three
characters or less.
1.16 The system shall have the capability of searching for a
commonplace name.
1.17 The system shall have the capability of searching for
mileposts or markers on roads or highways.
1.18 The system shall have the capability to search for locations
on the interstate highways.
1.19 The system shall have the capability to search for locations
on ponds, creeks and other waterways. These locations shall
include bridges, overpasses, causeways and commonplace
names.
1.20 The system shall have the capability to search for locations
on railroads. These locations shall include mile or kilometer
markers, crossings, and commonplace names.
1.21 Location entry shall also be possible by use of an alias street
name.
1.22 The system shall have the capacity to search for
subdivisions, business centers, trailer parks, and parks.
1.23 Each position shall have an integrated mapping screen. This
screen may appear as a window on the same monitor as the call
entry screen.
1.24 If the location entered by the call-taker cannot be verified
(i.e. location is in another jurisdiction), the call-taker shall have the
capability to override the verification process.
1.25 Some locations in other jurisdictions shall be verifiable in the
                                           - 53 -
system. If a call-taker attempts to enter a call in one of these
other jurisdictions, a visible warning shall be displayed alerting the
call-taker to this.
1.26 The system shall have the capability to override street and
address recommendations from the geobase and add out of
jurisdiction addresses. Any and all address overrides done will be
stored in a geofile exception file for easy retrieval and access by
the system administrator.
1.27 The call type code entered by the call-taker shall be
validated against a user definable list of call type codes (retaining
current codes).
1.28 The call taker/dispatcher shall have the capability of
displaying a pick list of call types and selecting a valid call type
from the list. By default, each call type, set by user definition, shall
determine the priority of the call; however, the call-
taker/dispatcher shall be able to increase or decrease that
priority, as necessary, without having to change the call type.
1.29 The system shall provide EMD pre-arrival instructions. When
a call-taker/dispatcher enters a particular call type, the pre-
defined questions and expected responses shall be displayed on
the call entry screen.
1.30 The system shall allow the entry of hazard information
regarding a location from a call-taker, supervisor, or dispatcher
screen without having to exit the screen.
1.31 Upon Geobase validation of an entered address an easily
discernible flag will be presented on the call entry screen showing
that a hazard exists. Clicking the flag or using a function key will
cause all details that have been entered regarding the hazard to
be presented to the call-taker/dispatcher in a separate window.
1.32 The system shall allow the entry of premise information
regarding location from a call-taker, supervisor, or dispatcher
screen without having to exit the screen.
1.33 The system shall allow the entry of burning, blasting, or other
similar permits information for any location within the county.
When a location is entered, the call-taker shall be alerted to any
burning, blasting or similar permits within a user-defined radius of
the location.
1.34 The system shall allow the unlimited entry of fire protection
systems that are out of service and all hydrants.
1.35 The system should allow for commonplace names and
permit the dispatcher the option to choose a name based on input
of three characters.
1.36 When a location is entered, the call-taker shall be able to
                                          - 54 -
display a listing of incidents of certain types occurring at that
location during a user defined period of time. The list shall include
both police and fire incidents and be sorted by chronology,
priority, or call type.
1.37 The system shall prompt the dispatcher that the incident
being entered is a possible duplicate if another incident is
occurring in its immediate area and is of a similar call type.
1.38 Once the complete or partial call information is entered, the
routing of that incident to the appropriate dispatcher shall be
automatic; however, a call taker may override that routing to send
the incident to any dispatcher.
1.39 A unique event/incident number shall be assigned to every
call entered into the system.
1.40 A dispatcher must be able to assign a case number to police
incidents as well as fire/EMS and alarms as needed. The case
numbers assignment must be settable by flag, to permit the
system to generate sequential case numbers or if inactive to
permit the dispatcher to enter a case number manually.
1.41 Some calls entered in the system will not require any
response and are entered solely for administrative purposes. A
dispatcher shall be able to ―file‖ these calls, such as misdials to 9-
1-1 or citizen complaints, without having to assign a field unit to
take the call.
1.42 The dispatcher shall be able to enter additional remarks to
any open or closed incident.
1.43 Each call taking and/or dispatcher position shall have the
ability to view the current status of incidents and units for either
law enforcement or fire and EMS.
1.44 All positions shall be able to enter information regarding
vehicles towed at the law enforcement agency‘s request and
privately towed vehicles. All positions shall be able to retrieve
information regarding all tows by entry or one position shall be
able to retrieve information regarding all tows by entry or one
among tow companies, permitting override when a tow company
is unable or refuses to accept a tow.




                                         - 55 -
E.2 General Dispatching
                                                                        Response
2.1 It is required that the dispatch screen on police, fire or EMS
have command line capability for dispatch of units on calls-for-
service as well as any point and click or mouse controlled
dispatch functions.
2.2 There must be multi-screen command lines or the equivalent
that permits a dispatcher to interrupt entry of one dispatch or unit
request to answer and enter information from another, returning
to the first or subsequent unit(s) without losing any information or
functionality. For example: a unit without mobile data calls in with
a request to do an inquiry on a VIN and license number. While
entering the information unit calls in on a traffic stop with the
location and license number. The dispatcher must be able to stop
entry and subsequent inquiry from the first unit to enter the traffic
stop along with the automated LEDS/NCIC and DMV request that
is generated and return to the first inquiry where the process was
interrupted as though no interruption occurred.




E.3 Fire & EMS Dispatching
                                                                        Response
3.1 Stacked calls shall be listed in the pending queue by priority
of the call. The colors for each priority shall be user-definable.
3.2 The dispatcher shall be given an audible and visible alert that
an incident has been added to the pending queue.
3.3 Fire and EMS response recommendations must be user
definable based on the type of situation reported (call type),
entered by the call-taker, and the occupancy type for the structure
or area type.
3.4 The system shall identify areas with no or inadequate water
supply for fire suppression operations.
3.5 The system shall identify structures with no or out-of-service
fire protection systems to the extent provided or entered by the
county Fire Department.
3.6 In addition to the occupancy types listed above, the following
area types may also drive the fire and EMS response
recommendations: a. Interstate Highways, b. Railroad Tracks
3.7 The system shall be able to recommend task forces. A task
force is a user definable group of two or more units that are
considered as a single entity.
                                        - 56 -
3.8 Each unit shall be assigned a unit number and unit type. The
unit type shall indicate the type of vehicle and its capabilities.
3.9 The dispatcher shall be able to recommend units based on
the unit or crew‘s special capabilities. These special capabilities
shall be in addition to the unit type.
3.10 The dispatcher shall be able to recommend a unit as two
different types of units.
3.11 The dispatcher shall be able to recommend one of several
different types of units.
3.12 The dispatcher shall have the ability to provide an alternate
to the unit due when the normal first unit due is unavailable. The
system must recommend the subsequent unit.
3.13 Retrieval of an incident from the pending queue shall be
possible with a single keystroke. Though the next highest priority
call shall be retrieved by default, the dispatcher shall be able to
retrieve any incident from the pending queue.
3.14 The dispatcher shall be able to exchange or replace units.
3.15 The dispatcher shall be able to substitute units when
exchanging
3.16 The dispatcher shall have the ability to change unit coverage
and move ups.
3.17 The system should have the ability to make units 2nd or 3rd
due to any incident.
3.18 The system must manage equipment move-ups
automatically. The dispatcher may override or substitute available
resource recommendations.
3.19 When a move-up is made the system should automatically
recalculate available resources for all involved stations.
3.20 Equipment move-ups should be able to be set up and
managed by the administrator according to multi-agency
requirements for replenishing other agencies.
3.21 The system should have the ability to display and
recommend units due from the established run cards.
3.22 A dispatcher should be able to busy out a station and have
software automatically move up and display all stations and
affected resources accordingly.
3.23 The dispatcher or fire station personnel at each fire station
shall be able to view the current status of pending incidents,
dispatched incidents, and units on a status screen.




                                       - 57 -
E.4 Incident Tracking
                                                                        Response
4.1 Based on the call type, the system shall establish timers that,
upon expiration, shall alert the dispatcher.
4.2 Certain incident milestones shall be tracked by the system. A
command executed by the dispatcher shall mark the occurrence
and the time of the milestone on the incident record.
4.3 The system should provide the ability to capture all police, fire
or EMS unit activity in a unit history database, with the ability to
extract, report, archive, and have unlimited size.
4.4 The incident tracking functions should be user definable and
able to be turned on or off as needed.


E.5 Unit Tracking
                                                                        Response
5.1 All status changes to a unit while assigned to an incident shall
be referenced to that incident. Status commands shall be
representative of the status change such as ―A‖ for arrived on the
scene or ―C‖ for cleared the scene and shall be user definable.
5.2 The following are examples of status changes within the
system: These status changes shall be user definable;
Dispatched, En-route, Arrived on the Scene, Transporting to the
Hospital, At the Hospital, Establishing Command, Out of Service
(including an explanation code i.e. mechanical, equipment , or
personnel), Available on the Radio, Available in Quarters,
Stopped by Train, Clear of Train.
5.3 The dispatcher shall be able to relocate units to another
station and the system shall recommend that unit on calls in the
new area. Transfers that are conducted as a result of an incident
shall be referenced to that incident and appear differently on the
status monitor than non-incident relocations.
5.4 The dispatcher shall be able to exchange units on an incident.
5.5 The current user definable status of units shall be tracked
even when the unit is not assigned to an incident.
5.6 The system should have the ability to recommend auto aid
and change of quarters units in a consistent manner with the
established run cards.
5.7 By system administrator flag setting an audible and/or visible
alert shall be provided to the dispatcher anytime a unit exceeds a
user definable time limit for any status change.
5.8 The dispatcher shall be able to upgrade the response to an
                                        - 58 -
incident using a single command. Units shall be recommended to
upgraded alarms in the same manner as the initial alarm.
5.9 The dispatcher shall be able to request the system to
recommend any number of additional units. Units shall be
recommended as additional units in the same way as an initial
dispatch.
5.10 The dispatcher shall be able to add units to an incident that
have decided to respond to the incident on their own. The status
change shall be tracked different from an ordinary dispatch to
recognize that the unit was not requested and was self
dispatched.
5.11 Units may report their own incidents to the dispatcher. All
self-initiated codes shall be user-definable. The dispatcher shall
be able to enter these self initiated incidents either by a command
or the format call entry screen. Units may also self-initiate
themselves from their MDC, which will change their status on the
status screen.
5.12 Incidents forwarded for dispatch shall be listed in the
pending queue by priority of the call. The colors for each priority
shall be user-definable.
5.13 The dispatcher shall be given an audible and visible alert
that an incident has been added to the pending queue.


E.6 Incident Response & Tracking
                                                                       Response
6.1 Police response recommendations must be user definable
based on the type of situation reported (call type) entered by the
dispatcher, the location of the incident and the units assigned to
the police beat/sector where the incident is occurring.
6.2 The unit being recommended by the system should be
available; however, if no units are available, it must be within the
beat area or en-route to another incident, but not on the scene of
incident.
6.3 The dispatcher shall be able to recommend the closest unit of
any particular type regardless of their location within the district
for emergency incidents (defined by priority).
6.4 Upon retrieval of an incident from the pending queue, the
dispatcher shall be provided a recommendation of units to
respond to the incident. The dispatcher shall be able to modify
this recommendation, as necessary.
6.5 The system shall accept an unlimited number of beats for a
given area.
                                        - 59 -
6.6 The dispatcher shall be able to view the current status of
pending incidents, dispatched incidents, and units on a status
screen.
6.7 The current status screen shall be capable of being split into
multiple areas on the status screen, including available units and
busy units. The status screen setup shall be user definable.
6.8 Units on traffic and subject stops should ―stand out‖ from the
other displayed statuses or be displayed in a separate window or
area from other assigned units.
6.9 A visible alert shall be given to the dispatcher anytime an
incident remains in the pending queue for longer than a
predefined length of time. This length of time shall be user
definable based on the priority of the incident. It shall be capable
of being turned on or off.
6.10 Certain incident milestones shall be tracked by the system. A
command executed by the dispatcher shall mark the occurrence
and the time of the milestone on the incident record. Unit based
milestones, such as first unit arrival, shall be automatically
captured when the unit status command is executed. This
tracking must also include any backup units assigned. The
milestones shall be user definable.
6.11 All status changes to a unit while assigned to an incident
shall be referenced to that incident.
6.12 User definable status changes shall be available within the
system.
6.13 The current status of units shall be tracked even when the
unit is not assigned to an incident.
6.14 A visible alert shall be provided to the dispatcher anytime a
unit exceeds a user definable time limit for any status change.
6.15 The dispatcher shall be able to pre-assign incidents to units.
The pre-assigned units will be ―stacked‖ under the unit in priority
order. The dispatcher must be able to remove any of the incidents
that have been pre-assigned without having to clear all of the pre-
assigned incidents. The dispatcher must also be able to assign
the unit to any of the pre-assigned incidents regardless of priority.
6.16 Units patrolling the county may report their own incidents to
the dispatcher such as vehicle stops, subject stops, suspicious
vehicles, parking enforcement, etc. All self-initiated codes shall be
user-definable. The dispatcher shall be able to enter these self
initiated incidents either by a command or the format call entry
screen. Units may also self-initiate themselves from their MDC,
which will change their status on the status screen.
6.17 The dispatcher shall be able to forward an incident that they
                                        - 60 -
are handling to a fire and EMS dispatcher without having to re-
enter the incident. The dispatcher shall be able to reclassify the
call type and add remarks before sending the call to the other
dispatcher.
6.18 All dispatchers may access any current call from police, fire
or EMS while remaining in fire or police dispatch mode.
6.19 Upon clearing the prime unit or incident, the dispatcher shall
be required to enter a disposition of the incident and/or situation
found at the scene. The disposition and/or situation found shall be
from a user-defined table. The dispatcher and/or MDC user shall
be able to add comments upon clearing the incident or to a closed
incident. The dispatcher and/or MDC user shall also be able to
assign a user-definable clearance code to identify those incidents
of special interest to the sheriff‘s and police departments, such as
juvenile related, report taken, gang related, etc. A case or report
number will also be generated based on the disposition code if
the system administrator turns on this function.
6.20 The system shall provide an expeditious means for the
dispatcher to add an off duty unit to an incident. The off duty unit
may act as the primary unit, a backup unit or be self initiated on
an incident.


E.7 SYSTEM FUNCTIONS
                                                                       Response
7.1 All operators of the system must be required to log in and out
with unique user definable passwords. These passwords must
support access control to the operator position, type, and
commands with an audit trail.
7.2 The system shall allow one dispatcher to handle police, fire,
and EMS incidents at the same time from the same screen if
desired.
7.3 Authorized users of the system shall be able to search CAD
system incident and unit data.
7.4 All time entries shall be captured in hours, minutes, and
seconds format. Rounding time entries to the half or whole minute
is not acceptable.
7.5 The system shall interface with the LEDS State records
system, NLETS and the National Crime Information Center.
7.6 The system shall have the ability to import and export data via
ODBC from/to an external system.
7.7 The system shall provide a mapping display to all positions.
This display may be a window appearing on the call entry screen
                                        - 61 -
or dispatcher screen so long as it does not prohibit other
operations. The system shall also interface with a separate
mapping monitor.
7.8 The operator shall be able to print any map image displayed
on their screen.
7.9 The system shall provide an interface to an alphanumeric
personnel paging system and to fire station Zetron 6-26 station
alerting systems (where equipped) to generate tones appropriate
to the fire/EMS incident dispatch process.
7.10 The system shall provide a telephone directory for personnel
and agencies the county must contact. Information stored in this
directory shall include the name, agency/company, telephone and
type of Telephone number (home, work, pager, cellular, etc.). The
system operator shall be able to retrieve the telephone
information by complete or partial name or agency/company.
7.11 The system must interface with the County‘s radio console
system for set radio tone pages for the fire/EMS service.
7.12 The system shall have the capability to send alphanumeric
pages through The county‘s radio system. The pages shall be
sent automatically based on the incident or upon command
executed for a unit by an operator. The dispatcher will retain the
ability to manually page through the Dispatch Center‘s Zetron
Integrator RD dispatch console system.
7.13 The system shall have the capability to provide incident
related information to fire/EMS stations with ―rip and run‖ printers
or from any fire station equipped with workstations from a screen
print function of the incident.
7.14 The system must allow for documentation to be viewed by
the county via the computer. This documentation may include
policy and procedures manuals, notification lists, or user manuals
for other systems.
7.15 Each of the police, fire/EMS, and Dispatch Center
administrative offices shall be provided access capability to the
system with expandability.
7.16 Any workstations and/or status monitors in any remote
location so equipped shall function as any other workstation on
the system.
7.17 The log-on information for the personnel assigned to the
remote location must limit access to the system to only those
functions that have been authorized.
7.18 Access to or viewing of LEDS and/or NCIC material must
meet current and future security requirements.
7.20 In addition the system will search name and geobase files as
                                        - 62 -
part of the screen entry process. The workstation must contain
multiple call entry screen forms to allow for entering more than
one call at a time, permitting the operator to interrupt a call for
service to handle a more urgent call (save screen). The system
shall resume processing the interrupted call for service after
completion of the override.
7.21 The CAD system requires the following abilities:
    7.21.1 Police dispatching
    7.21.2 Fire dispatching
    7.21.3 EMS dispatching
    7.21.4 Unit assignments and history
    7.21.5 Incident status information
    7.21.6 Message taking
    7.21.7 Automatic incident number assignment with ability to
group individual incidents into one master user assigned number
    7.21.8 Recording of call-taker and dispatcher I.D. on all
entries and dispatches
    7.21.9 Dispatcher help functions
    7.21.10 Initial Unit and backup unit recommendation
    7.21.11 Daily dispatch log by patrol station with complete
information or dispatch activity for every unit and shift of the
working day
    7.21.12 Automatic time stamping
    7.21.13 Officer initiated complaint screen.
    7.21.14 System management functions including:
       7.21.14.1 Response time of mobile units
       7.21.14.2 Calls by geographic region – time of day – type of
call
       7.21.14.3 External interfaces:
          7.21.14.3.1 Spectracom NetClock/GPS
          7.21.14.3.2 TDD Interface
          7.21.14.3.3 Mobile Data Computers
          7.21.14.3.4 E-911 interface
          7.21.14.3.5 Zetron 6-26 station alerting system
          7.21.14.3.6 Alphanumeric Paging
          7.21.14.3.7 Radio Unit Identification – Activated on
Push to Talk (PTT)
          7.21.14.3.8 Portable radio emergency signaling
          7.21.14.3.9 LEDS/NCIC
          7.21.14.3.10 Computerized Mapping
          7.21.14.3.11 EMD support
          7.21.14.3.12 RMS access
          7.21.14.3.13 GPS/AVL
                                       - 63 -
7.22 Priority coding of calls must allow for both manual and
automatic priority assignment. This must be accomplished as part
of the manual call taking activity or by the CAD system, using the
call code to locate a priority code or response level from the pre-
stored code tables. Priority levels and call-received times will be
used to rank calls for service. Dispatch of calls by operator-
selected criteria, overriding automatic ranking must be possible
(manual). The system must support a minimum of five priority
levels.
7.23 The system shall have either a geographic file interface or
geofile included. This geobase file or interface will contain or
possess the ability to reference a call by intersection, address,
landmark, highway, commonplace and street and commonplace
alias. The operator must be able to enter the information as a
commonplace name, which will result in a hit or list of alternatives
if no direct match is found. All data contained in the current
geofile will be required in any new file. Any conversion necessary
to move the current geofile information into any new geofile will
be the responsibility of the vendor.
7.24 The system must provide for duplicate call identification,
which will check all incoming incidents against those that are
active to determine if the call is a duplicate or repeat call.
7.25 The CAD system must have and maintain complete current
unit status information. This information must reflect the current
status of all units on duty. The unit status must be displayed via a
separate monitor. Unit status must be accessible for update
manually or, in Phase II, through the use of mobile digital
computers. The system must automatically display changes
caused by unit assignment, shift changes, or unit-supplied
updates. Controlled and uncontrolled units must be displayed.
7.26 The monitor must also capture, by unit, the call type being
worked and a history of the status changes that have occurred.
7.27 The system will permit call pending queue for each unit. The
pending queue will be visible on the status monitor screen.
7.28 The status conditions will be user-definable and the CAD
system will permit the user to decide which incidents and status
indicators will be used.
7.29 In the event that an ―officer needs help‖ or emergency
situation arises in the field, the system must allow a dispatcher to
initiate an emergency notification by entering a simple command.
This procedure will sound an audible alarm and an emergency
message displayed on the dispatcher and supervisor terminals.
The message must display the unit‘s last known location. If the
                                        - 64 -
unit is equipped with an MDC, pressing a single key on the MDC
will perform this function which routes the same alarm message
to the dispatcher. Users of mobile radios with an emergency
button must also be able to activate this alerting function. This
notification will occur with radio unit identification and the Push-to-
talk (PTT) interface.
7.30 The basic CAD software must fully integrate with any future
upgrade(s) to the CAD software without any manual file
manipulation or rewriting required by County personnel. Any
changes that would require such file manipulation or rewriting
shall be done by the vendor and included as part of the annual
maintenance agreement.


E.8 CAD Reports
                                                                          Response
8.1 Officer activity –
   8.1.1 Daily Log
   8.1.2 Month End Report
   8.1.3 CAD Service Demand (SD) by address with detail
   8.1.4 CAD Service Demand (SD) by grid with detail
   8.1.5 Call activity summary PD, FD and walk-ins.
   8.1.6 Officer activity detail report by 31-day cycle.
8.2 Activity by dispatcher –
   8.2.1 Service Demand and Self-Initiated summary by call or
activity type.
   8.2.2 Service Demand and Self-Initiated by call or activity
type and personnel type.
   8.2.3     CAD tow report with detail including tow company
response times.
   8.2.4     Service Demand by caller name and location with
detail.
8.3 Master street listing.
8.4 Master intersection listing.
8.5   Ability to print invalid address entered by dispatchers
(geobase override file)
8.6 Shift sign-on report.
8.7 MDT-MDC reports.
8.8 CAD detail by narrative search.
8.9 CAD detail by vehicle search.

                                         - 65 -
8.10 CAD summary reports for Freedom of Information requests
(by grid, location, apartment complex, etc.)
8.11 Call activity by hour of day, day of week, day and hour.
8.12 Hazard, premise, directions, temporary file by address.
8.13 File information by address/business name, common
name/business name, all detail for Dispatch Center.
8.14 Call log by unit number.
8.15 Call log by badge number.
8.16 Call summary report.
8.17 Call response time analysis report.
8.18 Ability to do ad hoc searches and reports.



E.9 Miscellaneous CAD
                                                                       Response
9.1 The proposed system must create an ―incident by location‖
database. Whenever an address or location is entered on the
incident screen that information will be stored for automatic
retrieval by the system whenever a future call is received
regarding that location or address. A large database containing at
least the last 24 months of data with access from un-archived files
is required.
9.2 In the event that the CAD system should be temporarily
unavailable or in other circumstances dictating a need for calls
being written down rather than immediately entered into the CAD
system, a method must be available for later entry and update of
these calls.
9.3 The CAD hardware system must not only exchange
information within the Dispatch Center and to MDC equipped
vehicles but must network with select fire stations, the Sheriff‘s
Office, Roseburg Police Department and other offices to share
and query information.
9.4 Network security is required due to LEDS and NCIC
information being passed over it.
9.5 In order for this system to be effective for the uses of Douglas
County, high reliability is an important factor that will be
considered when this system is purchased. The ability to make
minor repairs, routine maintenance, system checks, backups, and
archives should be accomplished without necessitating taking the
system down. The ability for CAD to remain live and on-line
                                        - 66 -
during non-CAD program changes is of high importance.
9.6 Have a visual or audible alert on an address flagged with a
hazard, especially when it is a self initiated call.
9.7 Have the ability to set a timer function on any incident for fire,
medical, or law.
9.8 Have a Tow Rotation file to allow selection of the next up tow
for a specific zone. Needs to be able to accommodate multiple
zones or areas.
9.9 Be able to flag a name or place a hazard on a subject.
9.10 Be able to click on and open files.
9.11 Have the ability to track by unit number, such as police
vehicle ID‘s, along with the Officer‘s ID.
9.12 Ability to show ID unit when radio is keyed OR dropped.
9.13 Be able to minimize an event entry screen.
9.14 Allow for a visual alert if there are saved calls.
9.15 Allow for a visual alert if an address is associated with an
apartment complex or mobile home park AND prompt for an Apt
number or space number.
9.16 Be able to search the Business or Hazard files for length of
time since entry or type of business.
9.17 Be able to search a name, phone number, or vehicle license
within the body of a call.
9.18 IMPORTANT – Receive prompt assistance from our CAD
vendor – priority system must be adhered to for call backs.
9.19 When searching for a name -have a similar or sounds like
feature available.
9.20 Provide the ability to e-mail incidents from the console.
9.21 In files – be able to sort numerical or alphabetical.
9.22 Provide color coding for an Officer initiated call – for the
location and/or the Officer ID.
9.23 Have a single step process to duplicate a Law call from fire
OR a fire call from Law.
9.24 Allow a 1 or 2 step process to make an additional comment
into a Law call from a Fire call OR a Fire call from Law without
switching screens.
9.25 Provide the ability to have numerous event entry windows.
A new blank ―event entry‖ screen each time a 911 line is
answered.
9.26 Provide color coding and avl mapping for Law and Fire units.

                                           - 67 -
9.27 Does your CAD system allow for 3 console monitors – one
dedicated to GEO-mapping.
9.28 When a Law unit logs on with an MDC and Dispatch has not
initiated that unit – is there some sort of notification or color
coding of that unit to alert Dispatch.
9.29 Allow wrap around typing in fields.
9.30 Provide for multiple command lines with police and fire
separate.
9.31 Have the ability to associate prior addresses with a location
change for details.
9.32 Have the ability to log on fire units multiple times for unique
incidents.
9.33 Notifier for police/fire – for example when police say it is a
code 4 for fire – a code to okay police & notify fire.




                                        - 68 -
                          SECTION F
                 JAIL SYSTEM REQUIREMENTS
F.1 GENERAL
                                                                     Response
1.1 Provide ability to use jail records management system
independently or in conjunction with the main Case RMS.
1.2 Contain a master ‗tabular‘ jail menu.
1.3 Allow the user to select charges when using Jail in
conjunction with a Case RMS if an inmate has a prior record in
the Case RMS arrest module.          Charges will automatically
populate the charge records on inmates charges screen. Auto fill
should be available throughout the system.
1.4 Allow the user to view an entire synopsis on an inmate with
one keystroke selection.
1.5 Allow key work searches.
1.6   Allow input of NCIC inquiry results.
1.7   Track liability account payments.
1.8   Billing program for cities (add/change agency data)
1.9   Tracking of special programs (GED,Church,etc..)
1.10 Fields for inmate vehicle towing information.
1.11 Fields for inmate BAC level.
1.12 Bail payment capabilities.
1.13 Mug shots with line-up abilities
1.14 Multiple flags for inmate definition (user defined).
1.15 Provide a daily courts listing (interface from the courts
system) of all inmates in custody.
1.16 Provide for automatic sending of the 0600 documents to
their destinations – News Review (local newspaper), etc..
1.17 Provide security for Department, Division, Staff and external
agency use of all modules in the system, allowing different levels
of access for viewing and modifying specific information.
1.18 Allow LEDS/NCIC inquiry for warrant check & criminal
history from main inmate information screen.
1.19 Does the system allow for electronic tracking of medical
records.

                                          - 69 -
F.2 SUPPORT
                                                                    Response
2.1   Allows for WEB vendor support OR VPN connectivity.
2.2 Available on-site service for critical system components
including file server/workstations,etc.
2.3 Trained technicians on staff with up-to-date certifications.
2.4   Available training to accommodate all users of the system
2.5 Updates and enhancements provided at no additional
charge for the duration of the maintenance agreement.


F.3 BAR CODING
                                                                    Response
3.1 Selection of bar code application from the menu for printing
an inmates associated wristband.
3.2 Provide bar coding for tracking of inmates property.
3.3 Allow user to track items for commissary through
attachment of bar code.
3.4 Track inmate activities, billing, commissary, security checks
and inmate movement.


F.4 INMATE TRACKING
                                                                    Response
4.1 Provide the ability for the tracking of cell checks, time and
location where jail officers are working, incidents which occur
within the jail, and employee/inmate movement within the jail.
4.2 Include sub categories of movement and cell check to view
and manage inmates.
4.3 Within movement, allow for the selection of correctional
facility and floor to view. Display screen should show cells and
their associated inmate(s). allow selection of the appropriate
inmate to move.
4.4 Select cell check to upload bar code information, print bar
code timesheet, print cell check scan sheet, and print officer ID
bar code sheet.
4.5 Cell check scan sheet should allow user to sort by annex,
cell block, floor, cell number, or all.
4.6 Provide a ‗weekender form‘.

                                      - 70 -
4.7 Flag inmates for behavior problems, health problems, or
other miscellaneous.
4.8 Ability to have automatic 20‘s ran in LEDS at time of
bookings and releases.
4.9 Ability to have CCH‘s ran automatically on every booking.
4.10 Track cell movement of inmates electronically and with wrist
band application.
4.11 Track inmate property through property locker application.
4.12 Track a list of available lockers for selection of an open
locker when inmate is being booked.
4.13 Provide entry and editing for inmate property.
4.14 Record entry deputy, search deputy, release deputy, dates
and times related to property movement in/out.


F.5 JAIL BOOKING
                                                                     Response
5.1 Include at least three master options – admit, medical,
release
5.2 Admit option should include sub-options – add, edit, view,
confinement, release, location
5.3 Provide the ability to view inmate records, confinement
records, approving visitor records, cash deposit records, charges,
medical records, property records, screening forms, weekender
records, or add, edit and delete inmate related records in the
‗admit inmate‘ master area.
5.4 Provide a Confinement file for booking information.
5.5 Allow user to be prompted when admitting an inmate, to
select the desired display view.
5.6 Automatically assign each inmate a JCA number or tracking
number when first processed.
5.7 Allow additions to an inmates approved visitors list.
5.8   Allow additions to an inmates criminal charges.
5.9   Allow additions to an inmates property records.
5.10 Provide the ability to create a charge form allowing the user
to enter offenses for which an inmate has been charged.
5.11 Provide the ability to record information regarding custody
assessment and primary security level assignment for an inmate.
5.12 Provide the ability to add, edit, delete custody assessment
information.
                                       - 71 -
5.13 Provide the ability for custody assessment.
5.14 Provide the ability to add, edit or view information regarding
the primary security level assessment.
5.15 Provide information regarding the vocational skills of an
inmate and program recommendations. Allow selection from the
tool bar.
5.16 Override pull down or check boxes where possible.
5.17 Provide the ability to add, edit or view information regarding
the location of an inmate.
5.18 Provide the ability to capture medical information.
5.19 Provide information regarding doctor visits.
5.20 Provide information regarding prescriptions.
5.21 Provide information regarding medicine that has been
administered.
5.22 Provide information regarding pharmacy prescriptions.
5.23 Allow selection of inmate release from display selection
screen.
5.24 Provide audit trail of all functions associated with inmate
release (check list).
5.25 MUST check for any holds on inmate before release can be
officially authorized.
       5.25.1 Run NCIC/LEDS on bookings/releases automatically
      5.25.2 Automatically register sex offender information in
LEDS if address is different
5.26 System must perform checks in addition before an inmate is
released:
      5.26.1     calculate final check amount
     5.26.2      check for any property to be released to inmate
     5.26.3      update the inmate charges
     5.26.4      update the inmates confinement status
     5.26.5      generate the final check to the inmate
     5.26.6      calculate liability accounts
5.27 Provide the ability to generate multiple user defined reports.
5.28 Do you have a process for booking of juveniles in this
system and do you employ security/confidentiality business rules
that your system adheres to.
5.29 Provide the ability to make consular notification
automatically when the inmate is determined to be a foreign
                                        - 72 -
national. At this time a fax is required to be sent – see procedure
#685 ‗Consular Notification and Access‘ in the Douglas County
Sheriff‘s Office.
5.30 Provide the ability to follow standard procedures for
releasing inmates – see procedure #582 ‗Early Release Criteria‘
in the Douglas County Sheriff‘s Office.
5.31 When booking inmates, provide the ability to capture ALL
Distinguishing features.
5.32 Provide a an on-line single screen page summary that
includes Inmate, Arrest, Charges and Property information as well
as the ability to print each section individually.
5.33 Provide access to a list of open cells for cell selection (new
bookings or moves).
5.34 Prevent the housing of ‗Keep Separate‘ inmates together.
System should flag operator when trying to move an inmate into a
housing unit with one of the inmate‘s keep Separates.
5.35 Provide limited housing options for Juvenile inmates.
5.36 Does the system provide user defined fields for information
not presently captured by your system regarding Inmate,
Educational, Employment, Family, Charge, Release and Arrest
details.
5.37 Provide the ability to ‗re-book‘ an inmate released in error.
5.38 Is there a remarks/comment area available throughout the
system.
5.39 Provide an area for Pre-Classification Information from
Arresting Officer and Booking Deputy: PC, Escape History, Past
Behavior Problems, Psych or Medical Problems, etc.
5.40 Does system provide a method to track the need for inmate
reclassification.
5.41 Does system provide a method to track work and program
eligibility for an inmate.



F.6 JAIL COMMISSARY
                                                                      Response
6.1 Allow user to maintain information about the following
categories:
     3.1.1 Inventory
     3.1.2 purchase orders
     3.1.3 vendors

                                       - 73 -
      3.1.4 sell items
      6.1.5 return items
6.2 Provide the ability to record information about each item in
stock.
6.3 Provide the ability to track inmate‘s accounts through the
use of a chart of accounts and check book recording.
6.4 Allow the user to enter deposit and withdrawal information.
6.5 Provide the ability for audit trails to track the inmates cash
deposits, cash withdrawals, commissary purchases, daily
balances.
6.6 Allow the user to define commissary items as being
available to only male or female.
6.7 Provide secure cash handling policies for commissary.
6.8 Allow returned items with or without a receipt by computer
tracking of items purchased.
6.9 Provide the ability to capture vendor information.
6.10 Provide the ability to track inventory item information.
6.11 Provide the ability to capture retail information.
6.12 Provide the ability to restrict commissary if liability account
exists.
6.13 Provide the ability to restrict commissary for disciplinary
reasons.
6.14 If system does not handle Commissary - Allow interface with
current Commissary program. Transfer Inmate balance amounts
to Keefe. Deduct order amounts from Inmate funds. Allow refund
of portion of commissary order due to shipping shortages.
Provide total amount of commissary order by dates.



F.7 JAIL SETUP
                                                                       Response
7.1   Provide for the following:
      7.1.1 jail locations
      7.1.2 medical screening
      7.1.3 storage areas
      7.1.4 reimbursement
      7.1.5 other screening

                                        - 74 -
      7.1.6 statutes
      7.1.7 input order of procedures
7.2 Provide the ability to color code areas for display on the
computer screen.
7.3 Provide the ability for user to layout the screen display.
7.4   Allow the user to specify the following:
      7.4.1 cell ID
      7.4.2 block
      7.4.3 number of beds
      7.4.4 capacity
      7.4.5 sex of inmate
      7.4.6 security level
      7.4.7 inmate ages
7.5 Allow the user to distinguish empty cell blocks by displaying
a blank cell on the screen.
7.6 Allow the user to setup procedures in any order desired.
7.7   Allow jail administrator to setup screening forms as desired.
7.8   Provide separate screens for male/female inmates.
7.9   Allow user to define layout of screens.
7.10 Allow user to setup jail reimbursement form.
7.11 Allow user to setup storage locations and types.
7.12 Allow jail administrator to define statutes to include:
      7.12.1        offense code
      7.12.2        offense description
      7.12.3        general statute citation
      7.12.4        type situation
      7.12.5        level degree
      7.12.6        UCR code
      7.12.7        NCIC code




                                          - 75 -
F.8 INMATE BILLING
                                                                       Response
8.1 Type 1 billing – We currently have and will need the
continued support of a system that has the ability to bill each of
the cities in Douglas County and the INS for their inmates. This
program must be able to read when an inmate is done with non-
billable charges and then start charging appropriately. Also it
must be able to split billing if there is more than one billable
agency holding an inmate. We currently bill an agency if their
inmate is here for one or more meal times in a day. Monthly
billing reports will need to be generated from this program.
8.2 Type 2 billing – We currently have and will need the
continued ability to provide inmate billing. We need to track
inmate billings, produce various small claims forms using the
inmate booking information, track delinquent payments and
generate statistical reports.


F.9 KITCHEN
9.1 Please provide all information pertaining to your handling of kitchen functions
including support, functionality, reporting, and processes.
Some items to consider –

We need a method of reporting allergies and special dietary needs to kitchen
staff, with Medical and/or Administration authorization.

We need to provide roster for separate areas of jail, indicating the number of
meals and special meals in each area.

(Separate attachment is desirable)

F.10 JAIL MISCELLANEOUS
                                                                       Response
10.1 Provide A pre-defined list of medical screening questions
that is editable by Medical personnel. handling of kitchen
functions including support, functionality, reporting, and
processes.
10.2 Provide an Insurance information screen with drill down of
available insurance information.
10.3 Provide ability to capture inmate personal information such
as Education, Employment, Family details.
                                       - 76 -
10.4 Provide LEDS/NCIC inquiry for warrants check and Criminal
History.
10.5 Provide a list of pre-defined reports and have the ability to
create user defined reports ad-hoc.
10.6 Provide a description of the various ways the public is
allowed to access inmate information, billing accounts, etc. if
available.
10.7 IMPORTANT – Calculate release date when provided with
start date, sentence length, prior credit and worker status.
10.8 Display time given for prior credit, work time, calculated
release date and actual release date when sentence ends on a
weekend.
10.9 Provide method of calculating hourly release date/time for
inmate sentenced to 2 day DUII (must serve 48 hours).
10.10 Do you provide a screen or function/process to capture pre-
classification information. For example – PC, Escape History,
Past Behavior Problems, Psych or Medical Problems, etc..
10.11 Need the ability to view classification detail and
assessment from a dedicated screen.
10.12 Method to track Reclassification and reasons.
10.13 Need ability to track work and program eligibility for
inmates.
10.14 Need ability to track information from ALL previous
bookings.
10.15 Need ability to split billing of inmate charges between
agencies and inmate based on release dates for specific charges.
We currently bill an agency if their inmate is here for one or more
meal times in a day. Monthly billing reports will need to be
generated from this program.
10.16 Allow for faxing and e-mailing of reports.
10.17 Provide the ability for audit trails to track the inmates cash
deposits, cash withdrawals, commissary purchases, daily
balances, inmate debt balances (medical, all other).
10.18 Provide Drop down menus listing each type of fee. Fee
type would be linked to a set amount that would pre-fill the
amount when selected.
10.19 Track daily revenue from Home Monitoring Fees, Jail and
Medical Debt, Clogs, Writing Kits, Hygiene Kits, Misc Fees.
10.20 Does system allow for maintaining separate accounts for
Cash, Checking, Commissary, Medical Debt, Jail Debt,
                                        - 77 -
Unclaimed Trust, Bail.
10.21 Provide End of Shift Reconciliation of all account balances.
We need a program that provides a means of detecting entry
errors.
10.22 Calculate release date when provided with start date,
sentence length, prior credit and worker status. Display time
given for prior credit, good time, work time, calculated release
date and actual release date when sentence ends on a weekend.
10.23 Provide method of calculating hourly release date/time for
inmate sentenced to 2 day DUII (must serve 48 hours).
10.24 Good Time and Work Credit are computed, based on good
behavior as follows:

Sentence length         Good Time Credit              Work Credit
is computed as
10 to 30 days            1 day for each 10            2 days off of
sentence for
31 to 90 days            3 days for each 30           every 7 days
worked. If
91 to 180 days           4 days for each 30           sentence is
under 30 days it
181 to 270 days          5 days for each 30           is calculated
1 day for 10.
270 or more days         6 days for each 30
Parole sentences do not receive good time credit.
Does your system have the ability to compute sentences
similar to our needs.
10.25 Need the ability to track Physician, Dental, Nurse visits,
and treatments.
10.26 Need the ability to bill medical items through the Jail
Banking module of function.
10.27 Need to be able to enter multiple service codes and
amounts in single billing.
10.28 Need the ability to indicate to Deputies that inmate has
medications when being released.            This flag would be
automatically activated by entry of medication billing.
10.29 Provide an area in the Medical section that indicates the
existence and location of a previous medical record.
10.30 Regarding Cell Movement – Provide the ability to add,
edit or view information regarding the location of an inmate. File
should include at least the following: location name, type, floor
and cell number, date of move, moving deputy, reason for move.

                                       - 78 -
10.31 Provide list of visitors, list to be carried over from previous
bookings.
10.32 Ability to     change visitor status from approved to
unapproved. All visitors will be marked as unapproved when
inmate is booked out.
10.33 Ability to check for warrants on visitors (push button
procedure).
10.34 Ability to schedule and record personal visits.
10.35 Ability to notify Command Center when Inmate is needed
for the visit.
10.36 List of approved professional visitors, and ability to select
from list of inmates to notify Command Center of sequential list of
inmates needed for professional visit.
10.37 Keep record of professional visits.
10.38 Typical necessary Jail reports:
       Court Arraignment List
        Release List
        Roster – List of inmates in custody by housing location
        Custody Report – Alpha report of inmates in Custody
        Keep Separate Report
        Fugitives
        Approved Workers
        List of Unclassified Inmates
        Recreation List
        Social Security Report


F.11 JAIL INTERFACES
                                                                        Response
11.1 Provide an interface with an outside billing company for
Inmate Billing.
11.2 Provide ability to interface with Keefe for commissary
program. Transfer inmate balance amounts to Keefe. Deduct
order amounts from inmate funds. Also refund of portion of
commissary order due to shipping shortages. Provide total
amount of Commissary order by dates.
11.3 Provide an interface with the District Attorney System.
Information to be transferred relates to inmate personal
information, arrest record, charges record, fingerprint ID number,
etc..
11.4 Interface with fingerprinting system (currently Cogent). Need
to transfer personal information, arrest record info and charges
                                        - 79 -
info.

11.5 Interface with Camera/mug-shot system. Transfer booking
information to mug-shot system including but not limited to ID
number, Name, date of birth, date of arrest, etc..
11.6 Mug-shot system MUST produce wrist bands and bar codes.
11.7 System must have the ability to produce mug-shot photo
line-ups.
11.8 System must interface with Patrol Report Writing System.
Need to transfer booking information to Report Writing System as
well as personal information, arrest info and charges info.




                                     - 80 -
                    SECTION G
      G.1 DISTRICT ATTORNEY REQUIREMENTS
                                                                        Response
1.1 Ability to have system password security, setup and
maintained by system administrator.
1.2 Ability to backup software and data files to secure media in
a timely manner.
1.3 Provide capability to archive data files and selectively
retrieve archived information for a specific case/defendant.
1.4 Provide menu driven functionality to get to different areas
allowing ‗hotkey‘ processing.
1.5 System should flow with functional progression of data entry
screens following case management processes.
1.6 Provide the ability for the software to integrate criminal case
tracking/ management with legal document production/ word
processing.
1.7 Provide the user with the capability to create their own
document formats on demand.
1.8 Ability to capture if ‗DIVR‘, ‗DC‘, ….. eligible and have that
carry over to the Charging Document.
1.9 Ability to capture if a joint defendant and have Charging
Document build a joint document OR separate and distinct
document.
1.10 Allow security for limiting staff capabilities of building
templates.
1.11 System must allow imaging of documents and include the
ability to attach those documents to case files.
1.12 The data information MUST be collected for witness, victim,
suspect and defendant.
1.13 Need to be able to search by sounds-like functionality
(soundex).
1.14 Provide a common pool of person information and allow
one person to be viewed as being involved in multiple cases as
same or different type of person.
1.15 Provide the ability to search on multiple fields (or any part of
that field) for report log and filed cases.
1.16 Ability to interface with LEDS and NCIC.
1.17 Provide the ability to ‗share‘ user defined (secured) data
with other agencies (secured by Douglas County District Attorney
staff).

                                        - 81 -
1.18 Provide the ability for e-mail accounts both inter-
departmental and inter-agency.
1.19 Provide the ability to automatically produce case status
notification letters and to determine/log all steps necessary for the
notification process. (See Vines interface)
1.20 Ability to capture, display, and print all fines and restitution
processed for victims.
1.21 Provide a ‗tickler‘ file for all needed actions/upcoming
events for report logs and filed cases.
1.22 Ability to specify witness type by case (multiples).
1.23 Provide the ability to indicate a defendant‘s felony case
procedure level.
1.24 Provide the ability to flag cases when processed.
1.25 Provide incident tracking for report logs, cases filed, and ‗no
action‘ events.
1.26 Ability to track log information.
1.27 Provide notification for release of resources when case
closes.
1.28 Provide the ability to reopen cases.
1.29 Allow for validation of trial dates.
1.30 Provide the ability to display a location of physical files from
the defendant info screen.
1.31 Provide the ability for definition of complexity and type of
case that is determined by District Attorney Office.
1.32 Ability to determine prior DA involvement with
defendant/witness
1.33 MUST Allow on-line access to DA for statistical queries on
ALL cases.
1.34 Provide a method of determining and reporting on an equal
distribution of workload among attorneys for assignment
decisions.
1.35 Ability to report case assignments by attorney.
1.36 Ability to report case scheduling and assigning by user
defined criteria.
1.37 Provide the ability to track warrants.
1.38 Allow calendaring functions for/by events and event types to
be shared by authorized District Attorney staff.
1.39 MUST include methodology/processes and automatic
reporting for setting up Grand Jury as well as export capability to
Word/Excel.
                                            - 82 -
1.40 Provide the ability to separate grand jury cases by selective
criteria.
1.41 Provide processes/functions to produce/tag evidence
related to grand jury proceedings.
1.42 Provide flags for grand jury tagged evidence when awaiting
resources as specified in 1.41 above.
1.43 Ability to track pre-sentence orders.
1.44 Allow for automatic notification from the DA to Parole &
Probation Department of pre-sentencing orders.
1.45 Allow for automatic notification from Parole & Probation to
the DA when pre-sentencing investigation is complete.
1.46 Provide the ability for all victim notification processes to be
automatic or flagged for attention (10 points of reference).
1.47 Provide the ability to track disposition of cases by defendant
and/or charges.
1.48 Allow for tracking of probation violations.
1.49 Allow for tracking of cases under appeal.
1.50 Provide enhanced facility for document preparation.
1.51 Ability to produce the ODAA Uniform Indictment Information
for legal document production.
1.52 Produce charging documents, general documents through
word processing functions.
1.53 Ability to retrieve and update variables for co-defendants
(ex. type of property, etc…).
1.54 Need to be able to have data from a main case for
witnesses, Officers, etc.. to be copied to each c-defendant file –
we could have 5 or more co-defendants and DO NOT want to
enter the information 5 separate times.
1.55 System MUST provide for security levels of access.
Security must be on each individual staff level.
1.56 MUST Provide the ability to automatically generate
subpoenas (3 weeks before trial).
1.57 Provide the ability to automatically generate trial notices to
officers.
1.58 Ability to store information relative to the following;
     1.58.1    courts and addresses
     1.58.2    judges
     1.59.3    deputy DA‘s
     1.58.4    law enforcement agencies and their addresses
                                        - 83 -
       1.58.5   contact personnel in other agencies
       1.58.6   defense attorneys and their addresses
1.59 System should provide the ability for user friendly ad-hoc
queries/reports for statistics given user defined parameters.
1.60 System should have regular/standard reports available from
menu options throughout the system including requested
statistical reports.
1.61 Need to be able to keep track of Officer requested subpoena
information (detailed when creating subpoena processing part of
system).
1.62 The following statistical reports are required;
       1.62.1 Report by specific charge and/or theme of case.
       1.62.2 Report by Deputy DA (either trial attorney or intake
DDA.
       1.62.3 Report by Court of Record.
      1.62.4 Report of all status of Hearings – for example – if
the hearing is Grand Jury and it says ‗continued‘ we don‘t want to
miss getting the hearing reset.
      1.62.5 Report by disposition of charges.




                                       - 84 -
                         SECTION H
                    CONTACT INFORMATION
For Project Management contact:
               Tom Fallon PMP, Project Manager
               1036 S.E. Douglas
               Room 123 Douglas County, Courthouse
               Roseburg, Oregon 97470
               541-440-4288
               541-440-6129 (fax)
               tmfallon@co.douglas.or.us

For Technical Data Processing contact:
               Kevin Potter, Information Technology Director
               1036 S.E. Douglas
               Room 123 Douglas County Courthouse
               Roseburg, Oregon 97470
               541-440-4330
               541-440-6129 (fax)
               krpotter@co.douglas.or.us

For Records Management Systems contact:
              Kathy Cross, Records Supervisor
              Roseburg, Oregon 97470
              541-440-4449
              kacross@co.douglas.or.us

For Computer Aided Dispatch contact:
              Katy Stall, 911 Supervisor
              Roseburg, Oregon 97470
              541-440-6111
              kzstall@co.douglas.or.us

For Jail Management Systems contact:
               Lt. Mike Root, Jail Supervisor
               Roseburg, Oregon 97470
               541-440-4504
               mlroot@co.douglas.or.us




                                     - 85 -
For District Attorney contact:
                 Lisa Thompson, Office Manager
                 Roseburg, Oregon 97470
                 541-440-4388
                 541-440-4403 (fax)
                llthomps@co.douglas.or.us


For Field Reporting contact:
                Dwes Hutson, Public Information Officer
                Roseburg, Oregon 97470
                541-440-4464
                dchutson@co.douglas.or.us




                                      - 86 -
                        SECTION I
                 EVALUATION OF RESPONSES
I.1 EVALUATION TEAM
Proposals will be evaluated by the Project Evaluation Team, which consists of
the following members:
      Tom Fallon                   Project Manager
      Kevin Potter                 Information Technology Director
      Dwes Hutson                  PIO/Field Patrol Supervisor
      Clayton Ruble                Deputy
      Kimm Barnes                  Crime Analyst
      Katy Stall                   Dispatch Communications Supervisor
      Ronna Salerno                CAD Supervisor
      Tom Cross                    CAD Dispatch
      Brenda Boak                  Jail
      Keri Aldous                  Jail
      Brent Case                   Jail
      Lisa Thompson                DA Office Manager
      Kathy Cross                  Records Supervisor
      Beth Bauder                  Records

I.2 EVALUATION CRITERIA
The following will be used for the basis of evaluation:
       Features, functionality and usability of the software

      Screen layout/appearance and flow of the applications

      Review of existing vendor client base

      Cost of software

      Capability and cost to perform any necessary/requested customization

      Hardware costs to comply with optimum software performance

      Quality of application manuals, user guides, or other
       documentation/training aids

      Software maintenance/support costs


                                       - 87 -
      Vendors ability to support the solution, including installation, conversion,
       software, training, and hardware/software maintenance and support

      Ability to fully train user personnel

      Review of any demonstrations given by vendors

      Ability to meet the scheduled time-line

      Ability to interface with peripheral software as required

      Vendor credentials and qualifications

      Amount of Douglas County technical support required by system

      Reports available/reporting capability

      Ability for potential growth of the system

      Availability of enhancements and new releases

      Vendor expertise in the applied area

      Vendor company credentials and time in business

I.3 EVALUATION SCORING
     Vendors will receive points only for the areas they respond to (D, E, F, G).
     They will only be compared to other vendors who have responded to the
     same area(s). Areas denoted with (**) will be scored for ALL vendors.

       Responses will receive points as follows:
       (**) General response format to RFP          25 points
       (**) References                              50 points
       (**) Proposed (Cost Section J1.)            400 points
       (**) Demos (If Selected)                    400 points
       (**) Team Additional (I.2 Criteria)          50 points
       (**) Section B                               31 points
       (**) Section C                               44 points
             Section D (Records)                   526 points
             Section E (CAD)                       187 points
             Section F (Jail)                      158 points
             Section G (District Attorney)          62 points
(**) = Total of 1,000 points Sections D,E,F,G each rated separately.
                                        - 88 -
SECTION J
      VENDOR RESPONSE INFORMATION
J.1 Cost of the Proposed System
Regardless of whether an offeror proposes to provide hardware and system
software, the proposal shall include complete information on overall cost,
including but not limited to the following: equipment cost, maintenance cost,
maintenance availability, system software cost, system software maintenance,
system software upgrade charges, system software maintenance availability and
overall hardware vendor support cooperation. Costs for these items are to be
provided in order for the County to project capital outlay of the proposed system
over a three-year period. The County reserves the right to purchase hardware
and system software from any source the County determines to be the most
advantageous to its needs and resources. Proposals shall provide prices for the
proposed systems with hardware where appropriate.

     The proposal shall state the total cost of the following:

      1.1     Designing, supplying, installing and testing the proposed system
      1.2     Software maintenance and support during the first three years of
              operation
      1.3     All modules that the vendor has available pertaining to Law
              Enforcement and Public Safety and D.A. Case Management
              whether or not queried for requirements.
      1.4     Documentation
      1.5     Training and materials (during and after implementation)
      1.6     Any miscellaneous definable costs
      1.7     Third party software needed
      1.8     Conversion costs (relate to specific areas)




                                        - 89 -
J.2 Proposed Timeline
     The following time considerations would best fit the needs of Douglas
     County. If not acceptable please comment.

     2.1   RFP responses to be received no later than Monday December 12th,
           2011 BY 5:00 p.m.
     2.2   RFP evaluation to be concluded by January, 2012
     2.3   Site visits and demos concluded by March, 2012
     2.4   Award of contract March, 2012
     2.5   System to be in production by September, 2012
     2.6   System signoff and maintenance by December, 2012

3 Respond as to the future direction of software-based functionality

4 If you cannot comply with any detail items – note the section, item
  number and explain on next page

5 Please provide client base information pertaining to public sector




                                    - 90 -
J.3 RESPONSE ISSUE ITEMS

   Please list any detail items that either do not apply to your product or
   that cannot be accommodated. In your comment please note if this is
   an issue that will be available in the future. Attach extra pages if
   needed.


   Section Item#                           COMMENT
   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________

   ____ ___    _________________________________________________


                                  - 91 -
                        SECTION K
                   PROPOSAL VALIDATION

MAIL ALL PROPOSALS TO:

    Tom Fallon, PMP
    Project Manager
    1036 S.E. Douglas, Room 123
    Roseburg, Oregon 97470


                   Vendor Contact/Response Information

Company:_______________________________________________________


    1. Primary Contact Representative:



         Name:            ________________________________________

         Title:     ________________________________________

         Telephone: ________________________________________

         Fax:       ________________________________________

         E-mail:    ________________________________________



    2. Proposal submitted by:


         Name:            ________________________________________

         Signature: ________________________________________

         Date:      ________________________________________


                                   - 92 -
                           SECTION L
                    PROPOSAL INFORMATION
L.1 GENERAL INFORMATION:
     1.1 The Contract Administrator will be the County 's primary
representative Kevin Potter, Information technology Director for this selection
process.

      1.2 Requests for extension of the selection schedule, requests for
information, and/or comments on the RFP must be submitted in writing to the
Contract Administrator before December 2, 2011. Offerors may telephone or e-
mail for preliminary information, but the provisions of this RFP cannot be
modified by oral interpretations or statements.

L.2 ADDENDA TO THE REQUEST FOR PROPOSALS: If inquiries or
comments by Offerors raise issues that require clarification by the County, or if
the County decides to extend the selection schedule or revise any part of this
RFP, addenda will be provided to all persons who receive the RFP. Receipt of
an addendum must be acknowledged by signing it and returning it with the
Proposal.

L.3 CANCELLATION OF RFP: The County may cancel this RFP and
terminate the selection process at any time if the County determines that
cancellation would be in the public interest.

L.4 COST OF PROPOSAL: The County will not reimburse Offerors for costs
incurred in preparation and presentation of their Proposals.

L.5 FORMAT OF PROPOSAL:
        5.1 Proposals must be typed. Erasures or other changes must be
initialed by the person signing the Proposal.

      5.2 The Proposals must be signed in ink by a person who is authorized to
represent the Offeror. A Proposal from a partnership must be signed by at least
one partner. A Proposal from a corporation must be signed by the president, the
chief executive officer, or other person authorized to act on behalf of the
corporation and must include evidence of the corporate officer's authority to sign.

L.6 CONTENT OF PROPOSALS:
      6.1 The Proposal should provide a clear, concise description of the
Offeror's ability to perform the Services. The Proposal must contain sufficient
                                        - 93 -
information to enable the County to consider it, in relation to other Proposals
received, and determine which Offeror is best suited to furnish the Services
needed by the County.
      6.2 The original content of the RFP should not be manipulated or
changed in any fashion to misconstrue meaning or provide incorrect information.
      6.3 In addition to the other requirements of this request, the Proposal
must include the following basic information:
         6.3.1    The Offeror's name, address, and telephone number.
         6.3.2    The state of incorporation if the Offeror is a corporation.
         6.3.3    The names of any affiliates of the Offeror or any assumed
                  business names under which the Offeror does business.
         6.3.4    The number of years the Offeror has been in business.
         6.3.5    The names of the Offeror's key personnel who will constitute
                  the Project team assigned to provide Services.
         6.3.6    The experience and other qualifications of the Offeror's
                  personnel for performing the type of Services required for the
                  Project.
         6.3.7    The name, address and telephone number of a representative
                  of every client for whom the Offeror has provided services of
                  the type required by the County within the last two years.
         6.3.8    Please provide client base information pertaining to public
                  sector.

      6.4 The Proposal must identify and provide the address of all clients of
the Offeror who have made claims against the Offeror within the last five years
alleging a breach of contract or negligence in performance of services. Include
information on claims made by a contractor against any client that were based on
the acts or omissions of the Offeror, including claims based on breach of an
implied warranty of plans and specifications. Describe the nature and current
status of the claims. Claims should be disclosed regardless of whether they
involved litigation, arbitration, or other formal dispute resolution process. The
disclosures required under this provision also apply to any the principals and key
employees of the Offeror and affiliates of the Offeror who will be assigned to
provide Services to the County.

      6.5 Regardless of whether an offeror proposes to provide hardware and
system software, the proposal shall include complete information on overall cost,
including but not limited to, equipment cost, maintenance cost, maintenance
availability, system software cost, system software maintenance, probable
system software upgrade charges, system software maintenance availability.
Costs should be provided in order for the County to project the costs of the
proposed system over a three-year time period. The County reserves the right to
purchase hardware and system software from any source the County determines

                                       - 94 -
to be most advantageous to the County, so proposals shall provide prices for the
proposed systems with and without the hardware.

      6.6      The proposal shall state the total cost of the following:
            6.6.1   Designing, supplying, installing and testing the proposed
                     system.
            6.6.2   Software maintenance and support during the first three
                    years of operation.
            6.6.3   All modules available Offeror has pertaining to District
                    Attorney Case Management.
            6.6.4   Documentation.
            6.6.5   Training and materials (during and after implementation).
            6.6.6   Any miscellaneous definable costs.
            6.6.7   Third party software needed.
            6.6.8   Conversion of ALL data
            6.6.9   A statement as to availability now or in the future of newer
                    versions of proposed software.

      6.7 The Proposal must describe any time constraints on providing the
Services and must include a proposed schedule for the Services.

      6.8 The Proposal must describe all Services that the Offeror anticipates
providing for the Project. The Proposal must describe the Offeror's proposed plan
for providing the Services. IMPORTANT           The Proposal must include all
hardware specifications necessary to implement and run the system in a
production environment at optimum performance. Each proposer should include
the brand name of components used in their hardware proposal and indicate
whether this selection is optional or required.

      6.9 The Proposal must state whether the Offeror is capable of performing
all Services needed for the Project or if the Offeror intends to subcontract any of
the Services, and to whom. All provided specification pages must be completed
and returned with the bidder's proposal. Brochures may be included if
incorporated logically into the substance and format.

       6.10 The Proposal may include substantive information concerning the
Offeror, the Services, or the Project that is not specifically requested by this RFP
if the Offeror believes that such information would be useful for evaluating the
Offeror's Proposal.

      6.11 The Proposal must identify any confidential information that the
Offeror contends is exempt from disclosure and state the basis for confidentiality
under the criteria established by ORS 192.501 and 192.502. Where confidential
or proprietary information is required or should prospective developers deem it
                                          - 95 -
necessary to submit such matter, each page should be marked in bold type with
words "PROPRIETARY DATA". However, County maintains the right to
determine the validity and scope of any claimed confidentiality.

      6.12 If the Proposal does not address any of the detail items outlined,
supra, in Section 2 and 3, a notation of the line number and an explanation for
the failure to address the detail must be included.

L.7 CONTRACT:
      7.1 The offeror selected by the County will be requested to enter into a
written contract using Douglas County‘s standard contract form.

       7.2 The Offeror may identify any special constraints or concerns raised
by the County's indemnification or insurance provisions, including any additional
costs that will result from compliance with such provisions. The Proposal should
identify all insurance which the Offeror will carry on the Project, including limits,
amount of deductibles, and whether coverage is "claims made" or "occurrence".
The selected Offeror shall provide copies of all applicable policies to the County
within ten days of selection and before the Contract is executed by the parties.

      7.3 If inclusion of any of the County 's proposed Contract provisions will
result in higher costs for the Services, such costs must be specifically identified in
the Proposal.

     7.4 Sample Contract is downloadable along with this RFP on Douglas
County‘s web site under bid documents. Titled: RFP# 15 Sample Contract.wpd
or RFP# 15 Sample Contract.pdf

      7.5 Pursuant to ORS 279A.120(2)(a), the County will give preference to
goods and services that have been manufactured or produced in Oregon if price,
availability, fitness, and quality are otherwise equal. In scoring the pricing portion
of Proposals, the County will add a percent increase to the Offeror‘s estimated
cost equal to the percent, if any of the preference given to the Offeror in the state
in which the Offeror resides, pursuant to ORS 279A.120(2)(b). In addition,
pursuant to the same statute, the Offeror should state in its response to the RFP
whether it is a ―resident bidder‖ as defined by ORS 279A.120.

      7.6 Any prospective Offeror who believes that the provisions of this RFP
or any aspect of the procurement process will encourage favoritism in the award
of a contract or substantially diminish competition must file a written protest to the
RFP prior to the date set for opening Proposals. Failure to file a protest will be
deemed a waiver of any claim by an Offeror that the procurement process
violates any provision of ORS Chapter 279 or the County‘s Local Contract
                                         - 96 -
Review Board rules. If protests are filed, the County may elect to postpone
opening Proposals without invalidating this RFP or any Proposal.

L.8 SUBMISSION OF PROPOSALS:
     8.1 Three (3) copies of the Proposal with the same number of copies of
any attached documents or supplemental data should be sealed and clearly
marked ―REQUEST FOR PROPOSAL – LAW ENFORCEMENT PUBLIC
SAFETY SYSTEM‖, and must be delivered no later than 5:00 PM on Monday
December 12TH, 2011 to:
     Tom Fallon PMP
     Project Manager
     1036 S.E. Douglas
     Room 123
     Roseburg, Oregon 97470

Offerors who mail Proposals should allow extra mail delivery time to ensure
timely receipt of their Proposals. Proposals received after the specified time and
date will be rejected and sent back to sender unopened.
      8.2 Proposals must be delivered or mailed. Proposals submitted by
facsimile or by e-mail will be rejected.
      8.3 By submitting a Proposal, an Offeror acknowledges that:
            8.3.1 The Offeror has read and understands this RFP, and
            8.3.2 The Offeror is familiar with the conditions that will affect the
Offeror's performance, if the County selects the Offeror as Contractor.
      8.4 A public opening of the Law Enforcement Public Safety RFP
responses will be held on December 14, 2011 (Wednesday) at 1:30 p.m. in
Room 123 of the Douglas County Courthouse, 1036 SE Douglas Ave,
Roseburg, OR. A list of those responding will be created and sent to all
participants. The list will also be available on request. Any interested
parties may attend.

L.9 WITHDRAWAL OF PROPOSALS: Any Proposal may be withdrawn by
delivering a written request to the Contract Administrator; however, any request
for withdrawal must be delivered to the Contract Administrator on or before the
above-referenced Proposal opening date and time. A request for withdrawal
must be executed by a duly authorized representative of the Offeror. All
Proposals not withdrawn prior to opening shall remain in effect for a period not to
exceed 90 days.

L.10 EVALUATION OF PROPOSALS:
     10.1 Proposals will be evaluated by the Project team in accordance with
the County's Local Contract Review Board Rules and ORS Chapter 279. The
County may debar an Offeror in accordance with ORS 279B.130.
                                       - 97 -
     10.2 The Project team shall consist of staff selected from each division of
the Sheriff‘s Department, District Attorney‘s Office, and Information Technology.

      10.3 It is very important for the proposal reviewers to be able to compare
similar types of materials among proposals received. If the discussion of a
particular subject cannot be found because it is placed elsewhere, the proposal
may not receive the highest evaluation it might otherwise merit. Proposers may
attach documents substantiating their proposal claims, such as an example
system design document, example training plan, etc. These attached documents
must be specifically referred to within the proposal as appropriate. Proposals
that do not contain all information required by this RFP or are otherwise non-
responsive may be rejected or given a diminished consideration in the evaluation
process. The Project team reserves the right to waive defects in a Proposal if the
County determines that it is in the public interest to do so.

       10.4 The County may require an Offeror to submit any information which
lawfully may be requested that the County deems necessary to determine the
Offeror‘s qualifications to provide the services. The Project team may interview
selected Offerors, but the Project team is not required to interview any Offeror or
all Offerors. If an Offeror fails to provide supplemental information or attend an
interview after receiving a written request from the Project team, the Project team
may cease further consideration of the Offeror's Proposal.

       10.5 The County reserves the right to reject any Proposal or all Proposals
if the County determines that rejection is in public interest.

      10.6 The Project team will evaluate requirements based on response. The
Project team may consider any information relating to the Services or the
Offeror's qualifications and experience as well as integration functionality.

      10.7 Fees will not be an overriding factor in the selection process, but a
Proposal may not be considered if an Offeror's fees are inordinate in comparison
to the fees of similarly qualified competitors.

       10.8 Proposals may be ranked without interviews; hence, firms are
encouraged to submit their initial proposals as comprehensively as possible. The
Project team retains exclusive discretion to determine:
            10.8.1 Whether a Proposal is responsive and conforms to provisions
of this RFP;
            10.8.2 Whether an Offeror should be allowed to submit supplemental
information;
            10.8.3 Whether an Offeror will be interviewed;
            10.8.4 Whether irregularities or deficiencies in a Proposal should
                                       - 98 -
be waived.

       10.9 If Offeror intends to subcontract any Services, Offeror shall submit to
County a written description, which must:
             10.9.1 State the name and business address of each
sub-contractor.
             10.9.2 Describe the Services that each subcontractor will
provide, and the dollar value of each sub-contract.
             10.9.3 State whether Offeror‘s subcontractors will be covered by
Offeror‘s liability insurance or provide their own insurance coverage of the types
and coverage amounts specified by the Contract.
             10.9.4 Provide a clear, concise description of each subcontractor‘s
ability to perform the Services, including the number of years that the
subcontractor has been in business, the names of the subcontractor‘s key
personnel who will be assigned to perform Services, and the experience and
other qualifications of the subcontractor‘s personnel for performing the type of
Services required for the Project, and confirmation that the subcontractor
possesses all licenses, certifications, or permits needed to competently and
lawfully provide the Services;
             10.9.5 Identify any time constraints on Offeror‘s subcontractors that
would affect their performance of the Services.

L.11 AWARD OF CONTRACT: IF the County selects a respondents bid, the
Contract/Contracts will be awarded tentatively by letter to the Offeror/Offerors
who is/are best suited to provide the Services. Final award will be subject to
negotiation and execution of the Contract/Contracts on terms and provisions
acceptable to the parties. If the County and the Offeror/Offerors initially selected
are unable to successfully negotiate a contract, an offer will be made to the
Project team's second choice in that category. The process described in this
subsection will be repeated until all pertinent Contracts are executed. ORS
279B.135 states that a contracting agency is to provide notice to each proposer
of intent to award a contract at least seven days prior to award (unless the
contract value is $150,000 or less).

L.12 PROTESTS: Any Offeror who disagrees with or questions the decision
on award of the Contract must submit a protest or request for information in
writing to the Contract Administrator within 10 days after the selection has been
made. Timely written responses will be issued for any questions or concerns that
are expressed by Offerors.

L.13 PUBLIC RECORDS: Proposals submitted to the County are public
records, and are subject to examination under ORS Chapter 192, except for
documents that the County determines to be exempt from disclosure under ORS
                                        - 99 -
192.501 or 192.502. The County will endeavor to honor valid requests by
Offerors for exemptions from disclosure, but the County reserves exclusive
discretion to determine whether a document qualifies for a statutory exemption.




                                     - 100 -

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:12/11/2011
language:Latin
pages:101