Page 1 of 84

  

Bidders  

RETURN THE ENCLOSED PROPOSAL IN A SEALED  ENVELOPE TO: 

 Baldwin County Commission 

ATT: Wanda Gautney 312 Courthouse Square, Suite 15 Baldwin County Courthouse 

Bay Minette, AL 36507  

251.580.2520  

You Must Mark On The Envelope:  

REQUEST FOR PROPOSAL   

“Technology Enhancement for Sheriff’s Office”  

RETURN BY 4:00 P.M. CT ON March 14, 2008 

 For questions concerning this RFP 

Contact:  Wanda Gautney 

No faxed responses will be accepted 

Page 2 of 84

 

SECTION 1 – Introduction  REQUEST FOR PROPOSAL The intent of this Request for Proposal is to evaluate and select technology enhancements and replacements for the  Baldwin County Sheriff’s Office (BCSO) that is capable of satisfying the present and future needs of the BCSO. The proposal may include all of the following; Computer Aided Dispatch (CAD), Record Management System (RMS) and Jail Management System (JMS).  The enterprise solution must be robust, fully integrated and fully operational with a documented presence in the marketplace for a period of at least 3 years.    Responses must be returned no later than 4:00 P.M. central time (standard or daylight savings time, as applicable) on March 14, 2008.  Proposals submitted after this date and time will not be considered.   The County is not responsible for delays occasioned by the U.S. Postal Service, the internal mail delivery system of the County, or any other means of delivery employed by the bidder.  Similarly, the County is not responsible for, and will not  open,  any  bid/proposal  responses,  which  are  received  later  than  the  date  and  time,  indicated  above.    Late bids/proposals will be retained in the bid/proposal file, unopened.  Evaluation of proposals will begin immediately after proposal opening date.  Proposals submitted will not be publicly available until after evaluation process has been completed and approved by the County Commission.  

This RFP will provide interested parties with sufficient information to enable them to prepare and deliver proposals that will be reviewed and evaluated by a project team established by the BCSO.    This Request for Proposal presents the technical and functional requirements for an enterprise solution to be implemented by a company yet to be determined through a sealed bid process issued by the County. It also provides general direction to the company in submitting a response.  It is the responsibility of the Bidder to include in their proposal all software components/modules, along with supporting documentation, hardware requirements, needed to fulfill and faithfully perform all system requirements in accordance with the objectives of the Baldwin County Sheriff’s Office.  The system offered shall be complete in every respect inclusive of all software components and required maintenance or licensing.  Any Bidder responding to this RFP must be a Qualified Bidder that is authorized to conduct business in the State of Alabama and Baldwin County; must be able to provide and support all the products in this RFP; must offer quality products as requested in this RFP; must meet or exceed all the Selection Criteria in this RFP in order to be considered eligible. 

RFP Coordinator 

Wanda Gautney has been designated as the RFP Coordinator for this project.  The RFP Coordinator is the only point of contact in for this procurement action.   

Communications directed to parties other than the RFP Coordinator and/or the designated alternate(s) may result in disqualification of the proposal. 

Minimum Qualified Bidder 

Bidders submitting a response should, in addition to the specifications in Section 5, meet these requirements:  

• Have a documented ability to provide all the products as listed in and required by this RFP, Functional/Technical requirements, and other supporting documents 

Page 3 of 84

• Must have a history of providing Integrated Public Safety solutions similar to specifications herein for a minimum of three (3) years. 

• Is authorized to conduct business in the State of Alabama and Baldwin County or is eligible and willing to obtain required licenses. 

• Meets or exceeds all the Selection Criteria in the RFP in order to be considered eligible. • Have sufficient existing personnel qualified in training and service to satisfy any problems that may arise 

during the entire course of the engagement listed herein. • Must document a minimum of three (3) references to the size and scope of specifications listed herein.  See 

Client References in Section 3 for details. • Database requirement:  Microsoft SQL 2005 Server or greater (Windows) running on MS Windows server 2003 

or greater.  • Accommodate integration requirements with other regional, state and federal agencies • A user friendly system • Open systems architecture to maximize flexibility, interoperability, and portability of the system • Develop a strategy that clearly identifies technical and operational requirements to improve productivity and 

service delivery to the BCSO • Ensure that the components of the system are designed to operate as a single integrated system that reduces 

redundant data entry and improves information flow • Supports public safety and justice information sharing by using the Global Justice Data Model from the 

Department of Justice, www.it.ojp.gov/gixdm • Have the ability to provide ongoing maintenance/support of the product offered • The proven financial stability of the provider as documented by a certified financial statement.  

Language, Words User Interchangeably 

The word COUNTY refers to the BALDWIN COUNTY COMMISSION, SHERIFF and/or BALDWIN COUNTY, ALABAMA throughout this document.  Similarly, RESPONDENT, VENDOR, OFFEROR and BIDDER refer to the person or company submitting an offer to sell its goods or services to the COUNTY.  The words PROPOSAL, QUOTATION, and BID are all offers from a BIDDER.  The County has established for the purposes of this RFP that the words SHALL, MUST OR WILL are equivalent in this RFP and indicate a mandatory requirement or condition, the material deviation from which shall not be waived by the County.  A deviation is material if, at the sole discretion of the County, the deficient response is not in substantial accord with this RFP’s mandatory condition requirements.  The words SHOULD and MAY will be considered equivalent in this RFP and indicate very desirable conditions or requirements but are permissive in nature.  Deviation from, or omission of, such a desirable condition or requirement will not in and of itself cause automatic rejection of a proposal, but may result in being considered as not in the best interest of the County. 

Definition of Terms 

The functional requirements contain the terms listed below.  In reviewing the requirements, the definitions given below shall apply.  ACJIC – Alabama Criminal Justice Information Center  AOC – Alabama Administrative Office of Courts  ICE ‐ Immigration and Customs Enforcement    BCSO – Baldwin County Sheriff’s Office  CIS – Baldwin County Communications and Information Systems Department  JMS – Acronym for Jail Management System, the collection of functional applications that satisfy the bulk of the Sheriff’s Office jail reporting requirements.  

Page 4 of 84

RMS – Acronym for Record Management System, the collection of functional applications that satisfy the bulk of the Sheriff’s Office field reporting requirements.  CAD – Acronym for Computer Aided Dispatch, the collection of functional applications that satisfy the bulk of the Sheriff’s Office call dispatch requirements.  LETS – Alabama Law Enforcement Tactical System  NCIC – National Crime Information Center  NLETS – International Justice & Public Safety Information Sharing Network  XML – Extensible markup Language    

END OF SECTION 1  

READ, UNDERSTOOD WITHOUT EXCEPTIONS______YES ________NO*  *IF EXCEPTIONS ARE MADE, THEY MUST BE INCLUDED WITH PROPOSAL RESPONSE AND EXPLAINED FULLY.   

Page 5 of 84

 

SECTION 2 – General Information 

Introduction 

The Baldwin County Sheriff’s Office (BCSO) has identified the need to replace their legacy information systems.  These currently consist of HTE/SunGard (Chiefs and Jalan modules) plus custom in‐house developed Civil Papers, Jail Foodbill, and Pistol Permits.   The scope of this request includes, but is not limited to, supplying all necessary software, integration and installation services, conversion, training, project management, maintenance and support.    Experience The BCSO is seeking prospective vendors in regard to this project.  Specifically, the BCSO requests that responses to this document include a list of at least three similarly complex projects undertaken within the previous five years for agencies sized as BCSO or larger.  This list should include the location, nature of the project, the name of a contact person for which the work was performed, how many sworn officers, how many patrol cars, their internal technical contact, the starting and the completion dates for the project.  For each project, describe how the work performed relates to the project that is described in this document.  The description should include the agency, as well as the size and complexity of the project.  What is your total number of current accounts sold and implemented?  How many new accounts have you successfully installed in the last five years?   The BCSO is aware of current industry technologies and is seeking a balance between mainstream and state‐of‐the‐art technology.  The BCSO wants to employ solutions that will prolong the life of the new system and postpone the need for replacement.  With this in mind, the BCSO envisions a integrated system that will be based upon advanced, yet proven technology that is derived from current industry standards and best practices.  The BCSO requires an open architecture for both the hardware and software components. 

Project Objectives 

 • To eliminate redundant data entry and enhance current day‐to‐day operations by integrating the functions of 

most of the existing processes into a single comprehensive system • To utilize the Global Justice Date Model standards for interagency exchange of data • To accomplish  the objectives  in a cost effective manner using open system  technologies  to provide a more 

flexible and expandable solution this is web‐based 

Background‐Baldwin County Sheriff’s Office 

The Sheriff, as the chief  law enforcement officer  in the County,  is at the center of public safety and criminal  justice activities for Baldwin County.   The Sheriff  is the primary  law enforcement provider  in the unincorporated areas and selected incorporated areas of the County serving approximately 200,000 residents.  The Office provides the full array of  law  enforcement  services  in  addition  to managing  the  jails,  supporting  the  courts,  and  providing  emergency communications for the SO. 

 The Sheriff’s Office has five (5) locations throughout Baldwin County.  They are as follows:  

• Bay Minette • Robertsdale • Foley • Fairhope • Lillian 

 The Sheriff’s Office has 90 plus sworn positions.  Supporting civilian staff is 160 plus positions.  Major divisions include:  

Page 6 of 84

• Corrections Command • Uniform Services Command • Investigation Command 

o Crimes against person investigations o Drug Task Force o Sex Crimes task Force o Youth services investigations (juvenile records) 

• Civil Affairs Command o Sex offender tracking and notifications o Crimes against property o Communications  o Domestic violence unit o Victim assistance unit o Warrants o Reports o Court Services including warrant and civil service o Gun Permits 

Current Public Safety Solution 

The current system was selected in the 1990’s and has since been maintained by the vendor and the Baldwin County Department of Communications Information Systems (CIS).  The applications reside on a AS 400 using a DB2 data base platform..  The system has aged past its life cycle and needs to be replaced to allow for complete integration of all automated systems within the Sheriff’s Office on an open architecture platform.  Jail  The Sheriff’s Office has one jail location.  The jail has approximately 650 inmates housed at any given time    

END OF SECTION 2  

READ, UNDERSTOOD WITHOUT EXCEPTIONS______YES ________NO*  *IF EXCEPTIONS ARE MADE, THEY MUST BE INCLUDED WITH PROPOSAL RESPONSE AND EXPLAINED FULLY.   

Page 7 of 84

 

SECTION 3 – Preparation of Proposal 

General 

Before submitting a proposal, the Bidder shall thoroughly familiarize itself with all contract conditions referred to in this document and any addenda issued before the proposal submission date.  Such addenda shall form a part of the RFP response and all documents shall be made a part of the contract.  It shall be the Responder's responsibility to ascertain that the proposal includes all addenda issued prior to the proposal submission date.  The Bidder shall determine by personal examination, and by such other means as may be preferred, the actual conditions and requirements under which the Agreement must be performed.  If, upon inspection and examination by the Bidder, there are any existing conditions or requirements that are not completely understood, the Bidder shall contact the buyer in writing.   

Telephone Inquiries – NOT ACCEPTED 

Telephone inquiries with questions regarding clarification of any and all specifications of the proposal will not be accepted.  All questions must be e‐mailed to wgautney@co.baldwin.al.us  no later than 12:00 pm on February 20, 2008.  Communication (written or oral) with individuals other than those listed herein will not be allowed.  Only written replies issued by  Baldwin County will be deemed official responses.  No verbal responses will be honored with regard to this RFP.  Communications directed to any party other than those listed above may result in disqualification of the bidder. 

Interpretation and Addenda No  interpretation or modification made to any Bidder as to the meaning of the RFP shall be binding on the Baldwin County Commission unless repeated  in writing and distributed as an addendum by Baldwin County.     Interpretations and/or clarifications shall be requested by email to Wanda Gautney at wgautney@co.baldwin.al.us            Verbal information obtained otherwise will not be considered in awarding of contracts.  E‐mail shall be considered an acceptable method for the transfer of written documents for this purpose.  Pre‐RFP Meeting A mandatory Pre‐RFP Conference will be held  at  the Baldwin County  Purchasing Department  located  at  257 Hand Avenue, Bay Minette, AL., on February 28, 2008 at 2:00 P.M.  ALL INTERESTED VENDORS MUST ATTEND THE PRE‐RFP MEETING.   Vendors will not be allowed to submit a RFP for this project  if they or a representative of their company does not attend the Pre‐RFP Conference.  All questions relating to the RFP should be submitted in email form   no later than 12:00 P.M. on February 20, 2008 to wgautney@co.baldwin.al.us and will be discussed at the mandatory Pre‐RFP Meeting.     

Telegraphic/Electronic Proposals ‐‐ NOT ACCEPTED Proposals sent by electronic devices (i.e., facsimile machines and e‐mail) are not acceptable and will be rejected upon receipt.   Bidders will be  expected  to  allow  adequate  time  for  delivery of  their proposal  either by  airfreight, postal service, or by other means.  Proposals shall be prepared in accordance with and in the same order sequence as the Proposal Format outlined in this section.  Proposals not complying with this format may be considered non‐responsive and may be removed from consideration on this basis.   All costs  incurred by the Bidder  in preparing the proposal or costs  incurred  in any other manner by the Bidder with regard to this RFP will be wholly the responsibility of the bidder.  All proposals, materials,  

Page 8 of 84

supporting materials,  correspondence  and  documents  submitted  by  the  Bidder  become  the  property  of  Baldwin County and will not be returned.  Each Bidder must submit, in a SEALED package, one (1) ORIGINAL RFP plus  ten (10) copies.  Additionally, the Bidder must provide an electronic version of the above in WORD or PDF on CD.    Bidders may submit additional  information and brochures relative to the product(s) for which they are offering, but those submittals will only be considered in addition to, not in lieu of, any information submitted on the County’s form  The Bidder shall sign the proposal correctly using the Signature Page provided with each Group and the proposal cover sheet.  The proposal may be rejected if it shows any omissions, alterations of the form, additions not called for in this RFP, or any irregularities of any kind.  The responder shall make no other distribution of the proposal.  An authorized principal of the company, President or Vice President, shall sign all submitted proposals.   

Specification Deviations by Bidder 

Any deviation from the specifications in this RFP document must be noted in detail, and submitted in writing on the Proposal Signature Page.   Completed specifications should be attached for any substitutions offered, or when amplifications are desirable or necessary.  The absence of the specification deviation statement and accompanying specifications will hold the Bidder strictly accountable to the specifications as written herein.  Failure to submit this document of specification deviation, if applicable, shall be grounds for rejection of the item when offered for delivery.  If specifications or descriptive papers are submitted with the proposal, the Bidder’s name should be clearly shown on each document. 

General Instructions In order to facilitate the analysis of responses to this RFP, Bidders are required to prepare their proposals in accordance with the instructions outlined in this section.  Each Bidder is required to submit the proposal in a SEALED package marked “RFP  Functional/Technical Proposal” .  Bidders whose proposals deviate from these instructions may be considered non‐responsive and may be disqualified.  Proposals should be prepared as simply as possible and provide a straightforward, concise description of the Bidder’s capabilities to satisfy the requirements of the RFP.  Expensive bindings, color displays, promotional materials, etc., are not necessary or desired.  Emphasis should be concentrated on accuracy, completeness, and clarity of content.  All parts, pages, figures, and tables should be numbered and clearly labeled.  Proposal Format: All proposals must be prepared and submitted in the same sequence order as outlined below:  

• Cover Letter (if desired) • Table of Contents • Executive Summary • Bidder is to return the entire RFP and confirm that each Section/Statement/Paragraph has been read and fully 

understood (ie.,Section 1, Read and Understood) • Company background • Required Operating System Environment • Documentation • Optional Software • System Security • Responses to System Requirements • Training, support, maintenance and upgrade program • Client references • Required Forms 

Page 9 of 84

o Executed Signature Page o Executed Non‐Collusion Affidavit 

 Failure to comply with this request may result in a downgrade of the evaluation of the proposal. 

Submission of Proposal 

Final proposals (Functional/Technical)  must be marked accordingly and delivered in a SEALED PACKAGE and be received by 4:00 PM Central Time on March 14, 2008.  ONE HARDCOPY ORIGINAL  of the RFP plus ten (10) copies  plus one (1) CD copy.  Copies of the proposal must be delivered to the following address:   

Wanda Gautney Baldwin County Courthouse 

312 Courthouse Square, Suite 15 Baldwin County Courthouse 

Bay Minette, AL 36507 

 Each SEALED package containing the proposal must be clearly marked with the Bidder name.  No proposals may be withdrawn after the proposal opening.  Bidders are responsible for ensuring that proposals are received by the above office prior to the deadline.  The County is not responsible for and will not open any proposal responses received later than the date and time specified above.  Late proposals will be rejected and can be picked up by bidder.  However, Baldwin County reserves the right to extend the receipt deadline due to "force majeure" or other causes which might restrict the competitive nature of the proposal process. 

Bidder’s Costs 

Costs for developing proposals are entirely the responsibility of the Bidder and shall not be chargeable to Baldwin County.  

Clarifications/Discussions/Software Demonstrations: 

Baldwin County reserves the right to request proposal clarifications, conduct discussions or require software demonstrations of any or all Bidders prior to selection.  The County will not be liable for any costs incurred by the Bidder in connection with such clarifications, discussions or demonstrations (i.e., travel, accommodations, etc.) 

Rights to the Proposal Document 

All copies and contents of any proposal, attachment, and explanation submitted in response to this RFP, except copyrighted material, shall become the property of the Baldwin County  All copyrighted material must be clearly marked to reflect its copyrighted status.   

Selection of Software  

The selection of the enterprise solution will be made to the Responsible Bidder whose proposal/product best meets the needs of Baldwin County. Baldwin County reserves the right to reject any or all proposals or parts thereof.  The County further reserves the right to waive technicalities and formalities in the proposal where it is deemed advisable in protection of the best interest of the County.  Bidders should list options to the specification. If Bidder knows of an optional method not listed in the specification, please list the method to accomplish this option. The County reserves the right to interpret all proposals and waive any ambiguities therein to the best interests of the County.  Third Party Software If the product proposed generally covers the requested functions, but omits certain specialty functions, it is acceptable to propose a third party software package with which your product integrates.  Responses must clearly identify the 

Page 10 of 84

third party software vendor(s), product name(s) and version.  Customer references in which third party software has been implemented should be included in the item above.  Responses must indicate whether the third party software licenses required by your proposal are included with your solution.  Since the evaluation will be based on a complete solution, any additional costs must be included in the response.  

 Bidders deemed responsive and qualified to the RFP will be invited to participate in solution and technical demonstrations.  The length of time and days will be determined later. 

Executive summary 

The Executive Summary shall be limited to a brief narrative highlighting the Bidder’s proposal.  The summary should contain as little technical jargon as possible, and should be oriented toward non‐technical personnel.   Company Background  The Bidder should outline their company’s background, including:   

1. Specify the number of years the company has been in the public sector software business.  Provide a chronology of the company’s growth, heritage, staff size, and ownership structure.  Include names and titles associated with CEO’s and primary owners. 

2. Indicate whether the business is a parent or subsidiary in a group of companies. 3. Provide a brief statement of the company’s background demonstrating longevity and financial stability. 4. The most recent audited financial statement (e.g., annual sales profitability, etc.). 5. Number of customers currently using the proposed software in State and Local Government. 6. Geographic area covered. 7. Has the company had a workforce reduction during the past 5 years?  If so, provide details regarding 

workforce reductions, such as areas affected, the percentage of workforce in that area, senior management changes, etc? 

8. Location and description of the company office and the support centers designated to provide primary support for the proposed system. 

9. Describe the company’s commitment to research and development for the specific public safety application proposed; include development staff size and percentage of annual revenue invested in application development of solution proposed. 

10. Describe how your company measures customer satisfaction for software applications and customer service and support. 

Required Operating System Environment  

The Integrated Public Safety Solution must be an n‐tier open systems solution running in a Windows 2003 server environment.  The Bidder must list all the operating system software products required to support the proposed computing environment.  List any additional software products required to support the proposed application software.   

Proposed Application Software 

The Bidder must describe, in detail, features and capabilities of the proposed application software.   

Documentation  

The Bidder must provide an overview of the documentation provided with the software applications (by proposed application).  The overview must address requirements defined in the following paragraph.  All documentation must be provided in English.  Baldwin County requires documentation that describes the features, use, administration, and maintenance of all applications.  The documentation must be provided for both users and the technical personnel who will administer and maintain the system.  It is desirable that differing levels of documentation 

Page 11 of 84

(user documentation and technical documentation) exist.  This documentation shall be provided in written form for each application module, with a copy of each documentation type for each application module being provided with the application software.  Also describe what provisions are available to update documentation of applications as the applications are modified.  It is highly desirable to have documentation available on CD‐ROM in standard format, such as Microsoft Word.  

Optional Software 

The Bidder shall include a description of any enhancing facilities (or value‐added components) available for use with the proposed software that have not been specifically requested in the RFP.  Consideration will be given to such optional elements that can be demonstrated by the Bidder to be of significant value to Baldwin County.  Pricing for Optional Software must also be included in the SEALED package and clearing mark on the pricing sheet as optional software. 

System Security 

The system must provide data and application security controls to prevent unauthorized use of the database, restrict access to the database, maintain database process controls, and log all database transactions.  In addition, the system shall provide security to limit availability, to application software screens, data elements, and the contents of data elements where appropriate.  Standard Hardware and Software  All required standard computer hardware, communications hardware, telephony hardware, Microsoft Server Software, Microsoft Desktop Operating Systems, Microsoft Office Applications, Microsoft Server CALs, Computer Associates Antivirus, Computer Associates Backup Software, and ESRI Software will be provided by the County through other existing bids and will not be acquired through this RFP.  It is desired that there will be no proprietary hardware requirements, but in the case proprietary hardware is required for implementation then that should be identified and costs included with this RFP.  It is desired that there be limited third party software requirements (other than those listed as existing in the current County Environment), but in the case other third party software is required for implementation then that should be identified and costs included with this RFP.   County CIS Staff will be responsible for installation of desktop and server hardware along with standard Microsoft Software. The County intends to utilize its existing Microsoft SQL 2005 Server.  Bidder must provide with this response section detail specifications, configuration requirements, quantity requirements, and proposed network configuration diagram for all hardware and software for both server and desktops which is required for optimal performance of the proposed solution.  The Bidder must provide the hardware and software, with the exception of that listed in the above paragraph, required for the proposed application software to meet the described requirements of BCSO.  The description must identify each individual component the Bidder believes BCSO must have and the purpose of that component. 

Responses to System Requirements 

Bidder must provide a response to each item listed in the System Requirements (Section 5) listed in the RFP.   Products proposed should be the latest tested, proven and published version for the Windows 2003, n‐tier platform.  Bidders must describe the architecture of their system and give an estimate of the expected response time based of the statistics given in Table 2. 

Responses to Functional/Technical Requirements Bidder’s response shall be confined to only the software product version (or latest release) proposed unless otherwise mutually agreed upon and priced in a manner that is compliant with the State of Alabama Bid Law and deemed acceptable by the Baldwin County Purchasing Department.  The Bidder will be responsible for informing the County and subsequent implementer of the availability, requirements and installation procedures of any product fixes, patches, upgrades or enhancements published during the original warranty or extended warranty periods. 

Page 12 of 84

Data Conversion Requirements 

The current DB2 database on the AS400 has historical data back to the 1990’s.  The file conversion must be included as a separate line item in the pricing.  Please provide any information in regards to how you would handle data conversion or assist BCSO in providing the data conversion.   Final data conversion will be determined at time of conversion.  However, data to be converted will include:  

• Jail Records • Name Records • Call History Records • Geo Code Records • Charge and Incident Records • Warrants Records • Civil Paper Records • Pistol Permit Records 

 Training Describe the training program that is required to use the software.  The training program must include training for functional users and technical training for IT support personnel.  Describe any training issues that relate to maintenance of the software, i.e., must support personnel be certified by the software Bidder to install and maintain the software?  Describe your overall user training approach, and include a sample training manual.  Describe how you approach ongoing training, such as annual training classes, online training, etc. 

Support, Warranty, Maintenance, and Upgrade Programs 

Describe your company’s approach on service and support.  How is it carried out, how do you troubleshoot problems for your current clients, and how do you measure success with your clients.  Provide a through description of your help desk services including, dial‐in, web support and ongoing maintenance.  The following areas should be addressed:  

• Problem reporting and resolution procedures, include required reporting method • Response time  • Hours of operation, such as 7 x 24 • Hotline support, include toll‐free access; hours of operation  • VPN / CA Remote Control option • Frequency and delivery method of future upgrades and product enhancements • Documentation updates • Methodology for fixing application bugs • Describe the terms of the software license and the warranty period.  Is the license a one‐time fee or is there 

an ongoing fee? • Describe Normal Maintenance Agreement available to BCSO • Describe an optional three year warranty agreement • How the Bidder provides the software source code*, e.g., at no cost with system purchase, escrow 

arrangement, Purchase agreement, or other arrangements (specify).  * The successful Bidder shall provide a source code escrow agreement to be enforceable in events such as the Bidder’s going out of business or other unjustified disappearance; failure by the Bidder to repair or make required modifications to the software within a certain period of time after notice; the Bidder’s ceasing to further develop or support software in general; failing to enter into a maintenance agreement concerning the software; and similar contingencies. 

Project Team 

Provide resumes of proposed project team demonstrating recent project management engagements.    

Page 13 of 84

Client References 

Bidders must provide at least three client references that are similar in size and complexity of Baldwin County, ideally state or local governments that have licensed the proposed software within the past five (5) years.  Information should include name of organization, client contact persons (technical and user), address, telephone number, project completion date, software version implemented, proposed, software modules licensed, and operating system environment.    Contract History List all contracts lost, or not renewed (list contact person and telephone number), for a five‐year period.  Provide a narrative describing the reason the contracts that have not been renewed.  Bidder must specifically identify any contracts from which they have asked to be relieved or any contracts that have been cancelled prematurely.  Litigation History Provide a list of all litigation the Corporation has been or is currently involved during the last five years.  Include a narrative describing all cases that were settled and amounts of settlement.  Fines of Penalties List all contracts in which you experienced a loss of funds exceeding $50,000 due to delays damages, liquidated damages, and or forfeiture of performance bond in whole or in part.    

END OF SECTION 3  

READ, UNDERSTOOD WITHOUT EXCEPTIONS______YES ________NO*  *IF EXCEPTIONS ARE MADE, THEY MUST BE INCLUDED WITH PROPOSAL RESPONSE AND EXPLAINED FULLY.   

    

Page 14 of 84

 

SECTION 4 – General Terms and Conditions 

 GENERAL TERMS AND CONDITIONS 

 The  Bidder  is  to  state  any  exceptions  to  the  conditions  listed  in  Contract  Terms  and  Conditions  listed  in  the  RFP deemed  important  by  the  Bidder.    A  Non‐Collusion  Affidavit  and  the  executed  Signature  Page  shall  be  included.  Sample license and maintenance agreements shall also be provided in this part of the Bidder’s response.  This section is  intended to form the basis for the development of a contract to be awarded as a result of the RFP. Bidders must submit pro forma contracts for software, hardware, and/or services with their response. The pro forma contracts must contain the terms and conditions described within this document.    Terms and conditions differing from those in this RFP shall be cause for disqualification of the proposal   Pricing Pricing responses must be  itemized and  include all costs (e.g., business  license fees, source code, object code, travel and per diem, documentation, maintenance, hourly  rates, price breaks at various concurrent user  levels, additional software dependencies) for each  item  indicated and whether the cost  is one‐time, annual,  implementation or other (specify).  In the event the product or service (other than implementation) is provided at no additional cost, the item should  be  noted  as  “no  charge”  or words  to  that  effect.    Initial  cost  of  the  software  shall  include  the  first  year’s maintenance and shall entitle the purchaser to any upgrades released during the first year without additional cost.    Hold Harmless And Indemnification Contracting party agrees  to  indemnify, hold harmless and defend Baldwin County, Alabama,  its elected officers and employees(hereinafter  referred  to  in  this  paragraph  collectively  as  "County"),  from  and  against  any  and  all  loss expense or damage,  including  court  cost and attorney's  fees,  for  liability  claimed against or  imposed upon County because of bodily injury, death or property damage, real or personal, including loss of use thereof arising out of or as a consequence of the breach of any duty or obligations of the contracting party  included  in this agreement, negligent acts, errors or omissions, including engineering and/or professional error, fault, mistake or negligence of Integrator, its employees, agents, representatives, or subcontractors, their employees, agents or representatives in connections with or  incident  to  the performance of  this agreement, or arising out of Worker's Compensation claims, Unemployment Compensation  claims,  or  Unemployment  Disability  compensation  claims  of  employees  of  company  and/or  its subcontractors or claims under similar such laws or obligations Company obligation under this Section shall not extend to any  liability caused by  the  sole negligence of  the County, or  its employees.   Before beginning work,  contracting party shall  file with the County a certificate  from his  insurer showing the amounts of  insurance carried and the risk covered  thereby.   Liability  insurance coverage must be no  less  than $1,000,000.   During performance  the company must  effect  and maintain  insurance  from  a  company  licensed  to  do  business  in  the  State  of Alabama.    Coverage required  includes  1)  Comprehensive  General  Liability;  2)  Comprehensive  Automobile  Liability;  3)  Worker's Compensation and Employers' Liability.  Warranties: Vendor  warrants  that  all  materials  and  work  will  conform  with  applicable  specifications,  samples  and/or  other descriptions given to the County, and will be free from defects.  Without limitation of any rights that the County may have by reason of any breach of warranty, goods that are not as warranted may be returned at Vendor’s expense for either credit or replacement, as the County may direct.  Insurance: The successful bidder will maintain such  insurance as will protect him and the County from claim under Workmen's Compensation  Acts,  and  from  claims  for  damage  and/or  personal  injury,  including  death,  which may  arise  from operations under this contract. Insurance will be written by companies authorized to do business in Baldwin County, 

Page 15 of 84

Alabama and shall include Baldwin County, Alabama as Added Additional Insured including a thirty (30) day(s) written cancellation notice. Evidence of  insurance will be  furnished  to  the Purchasing agent not  later  than  seven  (7) day(s) after Purchase Order/contract date.  Insurance Minimum Coverage Contracting party shall file the following insurance coverage and limits of liability with the County's Risk Management Office and Purchasing Department before beginning work with the County.    General Liability   $1,000,000 ‐ Bodily injury and property damage combined occurrence   $1,000,000 ‐ Bodily injury and property damage combined aggregate   $1,000,000 ‐ Personal injury aggregate Comprehensive Form including           Premises/Operation, Products/Completed Operations, Contractual,            Independent contractors, Broad Form property damage and personal injury.  Automobile Liability   $1,000,000 ‐ Bodily injury and property damage combined coverage   Any automobile including hired and non‐owned vehicles  Workers Compensation and Employers Liability   $100,000 ‐ Limit each occurrence  Umbrella Coverage   $1,000,000 ‐ Each occurrence   $1,000,000 ‐ Aggregate  Award of Contract: Award  of  contract  for  this  project  will  be  recommended  to  the  County  following  the  evaluation  of  submitted responses. This  recommended award will be made  to  the Responsible Vendor whose bid  response best meets  the needs of Baldwin County.  Vendor must state that the response  is valid for a minimum of one hundred eighty (180) days after the Bid Opening Date.  Baldwin County reserves the right to reject any or all Bid Responses or parts thereof.  The County further reserves the right  to waive  technicalities and  formalities  in  the Bid Responses where  it  is deemed advisable  in protection of  the best  interest of  the County.   The County  reserves  the  right  to purchase optional  items  from  the successful Vendor. Vendors should  list options to the specification and pricing. If Vendor knows of an optional method not  listed  in the specification, please list the option and the price to accomplish this option. The County reserves the right to interpret all Bid Responses and waive any ambiguities therein to the best interests of the County.  Modification of Agreement/Contract Changes: All changes/modifications to the original scope of work must be submitted to the Purchasing Department for review. These submissions (and if applicable, the costs associated with the changes) will be reviewed with the County Project Manager. Changes  that are  reviewed by  the Purchasing Department and  the County PM and are determined  to be necessary  and  are  at  no  cost  to  Baldwin  County  may  be  approved  by  the  County  Project  Manager.  Any changes/modification  that  involves  ADDITIONAL  MONEY  shall  not  be  binding  unless  signed  by  an  authorized representative of Baldwin County.     

Page 16 of 84

Laws and Regulations: All applicable State of Alabama and federal laws, ordinances, licenses and regulations of a governmental body having jurisdiction shall apply to the award throughout as the case may be, and are incorporated here by reference.  Any contract executed based on award of this RFP must stipulate that governing law will be the State of Alabama.  Termination of Contract:   This contract may be terminated by the County with a thirty (30) day written notice to the other party regardless of reason.  Any violation of this agreement shall constitute a breach and default of this agreement.  Upon such breach, the  County  shall  have  the  right  to  immediately  terminate  the  contract  and  withhold  further  payments.    Such termination shall not relieve the contractor of any liability to the County for damages sustained by virtue of a breach by the contractor.  Termination of Contract For Cause: If, through any cause, the successful Vendor shall fail to fulfill in a timely and proper manner its obligations, or if the successful  Vendor  shall  violate  any  of  the  covenants,  agreements  or  stipulations  of  the  award,  the  County  shall thereupon have the right to terminate the award by giving written notice to the successful Vendor of such termination and  specifying  the  effective  date  of  termination.    In  that  event,  as  of  the  time  notice  is  given  by  the  County,  all products,  reports or other materials prepared by  the successful Vendor shall, at  the option of  the County, become Baldwin County’s property, and the successful Vendor shall be entitled to receive compensation for any satisfactory work completed, prepared documents or materials as furnished.   Notwithstanding the above, the successful Vendor shall not be relieved of liability to the County for damage sustained by the County by virtue of breach of the award by the successful Vendor for the purpose of set off until such time as the exact amount of damages due the County from the successful Vendor is determined.  Termination of Contract for Convenience: Baldwin  County may  terminate  the  award  at  any  time  by  giving written  notice  to  the  successful  Vendor  of  such termination and  specifying  the effective date  thereof, at  least  thirty  (30) working days before  the effective date of such  termination.    In  that event, all products,  reports, materials prepared or  furnished by  the successful Vendor or under the award shall, at the option of the County, become its property.  If the award is terminated due to the fault of the successful Vendor, termination of award for cause relative to termination shall apply.  If the award is terminated by the County as provided herein, the successful Vendor will be paid an amount as of the date notice is given by the County which bears the same ratio to the total compensation as the furnished bear to the total materials covered by the award, less payments of compensation previously made.  Assignment: No portion of the Bid Responses or resulting project may be assigned after award notification to a third party without the express written consent of both Baldwin County.  Prime Contractor Responsibilities Vendor will assume responsibility of delivery of services and application performance, regardless whether or not the Vendor  subcontractors  any  of  these  items  and  services.    The  Vendor will  be  the  sole  point  of  contact  regarding contractual matters,  including  performance  of  services  and  the  payment  of  any  charges  resulting  from  contract obligations.  Vendor will be totally responsible for all obligations outlined under this RFP.  Subcontracting: The intention to subcontract any portion of the project to a named entity must be part of the vendor’s Bid Responses.  No portion of  the Bid Responses or  resulting project  after  award notification may  subsequently  be  subcontracted without the prior written approval of both the Baldwin County.  Installation: Work must be performed on weekend or after normal business hours. Normal business hours are M‐F, 8:00 A.M. to 5:00 P.M. All installation must be coordinated through the County PM and CIS. 

Page 17 of 84

 Protection Damage: Awarded vendor will be responsible for any damage to property of the County or others caused by him, his employees or subcontractors, and will replace and make good such damage.   Freight: Freight charges are to be included in the quoted price, rather than as a separate item. Shipping  shall  be  quoted  as  FOB Destination  and  the  shipper maintains  ownership  until  the  County  has  received, inspected and accepted the goods.  Taxes: Baldwin County  is exempt  from all  tax. Provided however, bidder shall be responsible  for payment of all sales, use, lease, ad valorem and any other tax that may be levied or assessed by reason of this transaction. 

 Performance Bond:   A Performance Bond in one‐hundred percent (100%) of the total amount of the project will be provided prior to any work beginning.  Proof of bonding ability for this project must be submitted with the RFP.  Bidders are required to write in the cost of the performance bond that will be paid by the County on the blank space provided on the bid pricing sheet.   Bond will be furnished not later than 14 days after requested.  Bidders are required to furnish a sample copy of your company’s performance bond with the RFP response.  Evaluation Criteria: The following criteria will be used to evaluate bids:  

• The quality of the overall solution proposed • The conformity to the specifications (Ability of the products to meet or exceed the listed functional and 

technical requirements) • The  outline of acceptable support services (Ability of vendor to support the RFP system requirements) • The proven financial stability of the provider as documented by a certified financial statement • Cost (Cost will not be the sole determining factor for award) 

 Vendor’s Costs: Costs for developing responses are entirely the responsibility of the Vendor and shall not be chargeable to Baldwin County. Responses should be prepared as simply as possible and provide a straightforward, concise description of the Bidder’s capabilities to satisfy the requirements of the Bid.  Expensive bindings, color displays, promotional materials, etc., are not necessary or desired.  Emphasis should be concentrated on accuracy, completeness, and clarity of content.  All parts, pages, figures, and tables should be numbered and clearly labeled.  Termination for Non‐Appropriations: Funds for the Contract are payable from the County appropriations.  In the event no funds or insufficient funds are appropriated and budgeted in any fiscal year for payments due under the Contract, the County shall immediately notify Contractor or its assignee(s) of such occurrence, and the Contract shall create no further obligation of the County as to such current or subsequent fiscal years, and shall be null and void, except for the portions of payments herein agreed upon.  In such event, the Contract shall terminate on the last day of the fiscal year for which appropriations were received, without penalty or other expense to the county of any kind.  After such termination of the Contract, the County shall have no continuing obligation to make purchases under the Contract.  No right of action or damages shall accrue to the benefit of the Contractor or is assignee(s) as to the portion of the Contract, which may so terminate.   

Page 18 of 84

Patent Guarantees: Bidder shall, with respect to any device or composition of Bidder’s design or Bidder’s standard manufacture, indemnify and hold harmless the County, its employees, and agents, from costs and damage as finally determined by any court of competent jurisdiction for infringement of any United States Letters Patent, by reason of the sale of normal use of such device or composition, provided that Bidder is promptly notified of all such actual or potential infringement suits, and is given an opportunity to participate in the defense thereof by the County.  Non‐Collusion Affidavit: Each Bidder submitting a proposal shall complete the Non‐Collusion Affidavit and include it with its response. 

Guarantee: Bidder certifies  that he is fully aware of the conditions of service and purpose for which items (s) included in this RFP are to be purchased, and that his offering will meet the requirements of service and purpose to the satisfaction of the Baldwin County Commission and its Agent.  All copies and contents thereof of any proposal, attachment, and explanation thereto submitted in response to this RFP, except copyrighted material, shall become the property of the Baldwin County.  All copyrighted material must be clearly marked in indication of its copyrighted status.  The County shall be held harmless from any claims arising from the release of proprietary information not clearly designated as such by the proposing firm.  Software Selection Notification: The software solution as recommended by the evaluation committee and approved by the Sheriff will be announced at a date to be determined.  The chosen software will become the basis for the implementation/software procurement RFP package.    Omissions: A good faith effort has been made by the County to list all functions or end result services they believe will be required for the fulfillment of the contract as specified.  This in no way relieves the successful bidder from its obligation to furnish all products, support personnel, maintenance/support services required to meet the needs of the County  for a fully functional ERP system.  Thus, any products/modules not specifically requested or proposed by the successful bidder, but are required for proper utilization of the software system as the County intends, will be furnished at no charge to the implementer/County.  General: Baldwin County expressly reserves the right to reject any and all proposals, or parts of proposals, and to make the pre‐selection determination of the software as the best interest of the Baldwin County Commission appears.  Permits, Codes & Regulations:   All equipment, construction, and installation will comply with City, County, State and Federal codes and Regulations. Successful bidder will obtain and pay for all permits necessary, notify proper authorities for inspections and furnish any certificates required for the work.  Public Disclosure Subject  to  applicable  law  or  regulations,  the  content  of  each  Bidder’s  Proposal  shall  become  public information upon the effective date of any resulting contract.  Negotiations: Baldwin County reserves the right to enter into contract negotiations with the selected bidder. If the County and the selected bidder cannot negotiate a successful contract, the County may terminate negotiations and begin  negotiating  with  the  next  selected  bidder.    This  process  will  continue  until  a  contract  has  been 

Page 19 of 84

executed or all proposals have been  rejected.   No bidder  shall have any  rights against  the County arising from such negotiations.  Bidder Qualifications All Bidders shall be in compliance with all applicable federal, Alabama State, County and municipal laws, regulations, resolutions and ordinances, including, without limitation, all certifications, licenses, and permits, per Alabama Code (1975), as amended, Sections 10‐2B‐15.01, et seq. (concerning out‐of‐state corporations doing business within Alabama), Sections 34‐8‐1, et seq. (concerning general contractor licensing for businesses which construct or superintend the construction of any building, highway, sewer, grading or any improvement of structure costing $50,000.00 or more), Sections 40‐12‐1, et. Seq. (concerning licenses), Sections 40‐14A‐1, et seq. (concerning taxation of corporations conducting business in this state), and Sections 40‐23‐1, et seq. (addressing sales and use tax); provided, the bidder is not exempted from the above mentioned Code Sections elsewhere in the Code.  All Bidders shall timely submit evidence or documentation establishing that they are presently licensed and permitted under the applicable above mentioned Code Sections, suitable to, and upon request by, the Baldwin County Commission.  Such evidence or documentation may be submitted with the bid.  All out‐of‐state bidders must provide proof of certification of authority, and any required registration, to transact business in this State, obtained from the Secretary of State, all as provided for in Sections 10‐2B‐15.01 et seq. and 10‐8A‐101, et seq., Code of Alabama 1975, as amended, in order to perform work for the Baldwin County Commission.  Bidder’s Registration Number shall be provided on the Bid Response Form.  The phone number for the Secretary of State is (334) 242‐5324, Corporate Division.   

END OF SECTION 4  

READ, UNDERSTOOD WITHOUT EXCEPTIONS______YES ________NO*  *IF EXCEPTIONS ARE MADE, THEY MUST BE INCLUDED WITH PROPOSAL RESPONSE AND EXPLAINED FULLY.   

Page 20 of 84

SECTION 5 – Functional and Technical Requirements  

             Priority Legend:         M = Mandatory requirement         H = Highly desired but not mandatory                

Acceptable Responses      A ‐ Exceeds requirement  0      B ‐ Meets requirement  0      C ‐ Meets with modification  0      D ‐ Does not meet requirement  0     

1.1  System Design   Priority  Response    The system must operate on the following infrastructure. 

Please indicate all hardware requirements (minimum and recommended) along with configuration specifications for this solution.  

     

1.1.1  Central Server(s) ‐ Microsoft Windows 2003 (Standard or Enterprise) utilizing Microsoft SQL Server 2005  

M     

1.1.2  Client workstations ‐ Pentium 4, 512 Mb ram, 40 GB hard drive, 100 Mb Ethernet, Windows XP SP2 or better. Microsoft Office 2003 Professional or better, Microsoft Internet Explorer 6.0 or better,  

M     

1.1.3  The offeror must include a system that is designed for 24/7/365 operation with 99.9% availability.  

M     

1.1.4  The offeror must include a system with a maximum acceptable response time to any CAD activity at peak periods (query, backup, etc.) of one (1) second (based on Ethernet 100/1000 network).  Please provide minimum hardware/software specifications (client and server) required to meet/maintain this response time criteria.  

M     

1.1.5  The offeror must include a system with a maximum response time of two (2) seconds for search/display of master name records. Please provide minimum hardware/software specifications (client and server) required to meet/maintain this response time criteria.  

M     

1.1.6  The system must utilize the latest technology to provide a state‐of‐heart environment that will serve the Sheriff’s Office’s needs for the present and the future that allows for easy expansion, upgrade, integration and maintenance.  

M     

1.1.7  All of the modules in the system should be of a uniform design. All menus, forms, data entry screens, should be designed using consistent principles. 

M     

Page 21 of 84

           

1.2  System Security   Priority  Response 1.2.1  Permissions shall be role‐based in the system with the 

ability for system administrators to create/modify these roles along with assigning users to these roles. This includes user, supervisor, manager, officer, call‐taker, command and administrator.  The system should include single sign‐on capability.    

H     

1.2.2  The system should allow for tiered access to information based on passwords and other authentications. The system should include the capability of utilizing other identification technologies, such as biometrics, ID card, security token, etc.  The system should include the capability to apply appropriate edits to all entered data to ensure data integrity and maintain activity logs and audit trails.  The system should include the capability for the agency to define and maintain codes and associated literals (i.e. plain English translation) for as many data elements as possible.  

H     

1.2.3  The system must include the capability to display and print an activity log including successful and unsuccessful log‐on attempts.  This log should be searchable by date or date range.  Information reported should include date, user ID, and success or no‐success attempt indicator, time of attempt and system module access requested.  

H     

1.2.4  The system should include the capability to restrict users to a single log‐on, based on user rights. (Prevent multiple log‐on on multiple machines)  

H     

1.2.5   The system should include the capability of suspending a log‐on account after a user‐defined number of unsuccessful attempts. The system should also include the capability of alerting administrative personnel when an account has been suspended.  

H     

1.2.6  The system must include the capability for defining user password expiration.  

M     

1.2.7  The system must include the capability of encrypting user passwords stored on or the server or when transmitted from the workstation to the server.  

M     

           

1.3  Systems Capabilities   Priority  Response 

Page 22 of 84

1.3.1  Offeror Should include:  • All solutions provided must be operational when installed. • The offeror must provide information sharing via Global Justice XML Data Model (GJXDM) interface. • The offeror must provide a system that eliminates redundant data entry, and allows for sharing of common files • The offeror must provide a user‐friendly, windows‐type interface that utilizes mouse click, command line, and function key interaction. • The offeror should include a system that operates in a Windows XP SP2 or higher client/server environment. • All solutions/equipment in this specification must be delivered, installed and operational within 180 days of the award date.  

M     

           

1.4  System Requirements   Priority  Response 1.4.1  The offeror should provide site‐licensing for all core 

modules when available and/or more cost effective.  H     

1.4.2  The offeror must include all "client‐related" software.   M     1.4.3  The offeror must include "client/server and/or database 

related" hardware specifications for all devices.  M     

1.4.4  The offeror must include an application that is compatible with Microsoft Windows XP SP2 and Microsoft Office 2003 or higher.  

M     

1.4.5  The offeror must include support with installations of software during implementation.  

M     

1.4.6  The offeror must include all "server‐related" software.    M     1.4.7  Source Code (to include interfaces) that must be 

maintained by offeror due to trade secrets or maintenance shall be held in escrow.  

M     

1.4.8  The offeror must include software that utilizes mouse click, function key, and command line functionality.  

M     

1.4.9  The offeror must include multi‐screen capability.   M     1.4.10   All client applications shall be true windows‐based 

software on any "thick" client.  M     

1.4.11  The offeror must include an application that does not require significant "pushing out" or uploading of application information to each client.  The Pushing out of application changes should be very simple and straight forward.  

M     

1.4.12  The system must have spell check and inteli‐sense or automatic field filling capability.  

M     

1.4.13  The offeror must include the capability to store data in a relational database with table‐driven design. The offeror will provide to the agency database administrators, any/all administrative passwords needed to access the database.  

M     

Page 23 of 84

1.4.14  The offeror must include the capability to perform system backups without system degradation or interruption.  

M     

1.4.15  The offeror must include the capability to roll‐back to data of the last backup in case of system failure.  

M     

1.4.16  The system must include the capability to archive data that is not current, but search the archive data for reporting functions.  

H     

1.4.17  The offeror must include the capability to limit record modifications by users or groups.  

M     

1.4.18  The offeror must include the capability to maintain a history of all modifications made to any record.  

M     

1.4.19  The offeror must include the capability to view the following information for any modifications to a record: name of modifier, date and time of modification and what was modified.  

H     

1.4.20  The offeror should include the capability to perform ad‐hoc queries and reports on the audit history of any record(s).  

H     

1.4.21  The offeror must include the capability of Report number assignment. CAD will maintain this function since most formal report numbers are assigned during handling of the dispatch event.  All other modules will have access to the report number.  

H     

1.4.22  The offeror must provide the capability for selected workstations connected to the system to have the ability to query and/or enter records into State/NCIC. 

M     

1.4.23  The offeror must provide a system in which all sub‐systems accept information from each other in a completely seamless manner.  

M     

1.4.24  The offeror must provide a system that captures all required UCR data (such as sex, race, age, etc.) from incident and/or arrest reports. In addition, this function must be able to provide reports and data exchanges as required by the Alabama Criminal Justice Information Center. 

M     

1.4.26  The offeror should include the capability to utilize electronic signature equipment (signature pad) to the maximum extent possible through‐out the system when applicable to minimize requirements for printed forms/documents, such as receipts and release documentation. The system should include the capability to recall or view existing signatures as a redundant matching technique.  

H     

Page 24 of 84

1.4.27  The offeror must provide, as part of the maintenance agreement, software changes as required when new state or federal laws are enacted and impact such things as; data entry, reporting, security and other related areas.  

M     

1.4.28   The offeror must provide a system that uses to the maximum extent possible; the process of single point of entry concept, where data entered into any of the modules is immediately available to all other modules if that data is needed.  

M     

1.5  Training, Support and Documentation   Priority  Response 1.5.1  The offeror must provide on‐site training for key 

personnel and must utilize the Train‐the‐Trainer method for all training except for CAD which will be conducted directly with each user.  The offeror will be required to provide adequate training manuals for each student and class.  The offeror will provide electronic copies of all training manuals that can be re‐printed for future training classes as needed by the agency.  

M     

1.5.2  The offeror will include as part of this proposal user acceptance testing (prior to system go‐live). During acceptance testing, defects identified or classified as critical must be corrected prior to completion of testing. Discrepancies that prevent normal acceptance testing from completing must be corrected as soon as possible before testing is to be restarted.  Acceptance testing will be accomplished with real data from the agency.  

M     

1.5.3  The offeror must include implementation and continuous support plans for all users of the system.  This support shall include twenty‐four hour per day help desk support via a toll‐free number.  

M     

1.5.4  The offeror should include on‐site support personnel capabilities for problem resolution beyond phone/VPN.  

H     

1.5.5  The offeror should include a projected schedule of periodic updates to system software.  

H     

1.5.6  The offeror must provide warranty information with their response. The offeror should provide the cost of annual support required for three years.  Each year should be listed separately.  

M     

1.5.7  The offeror should include detailed technical system documentation that describes the system as‐built architecture and data structure.  

M    

1.5.8  The offeror must include all data dictionary's to include at least the following: field name, field definition, field length, field type, field rules/integrity checks, originating source, general edits and table name(s).  

M     

Page 25 of 84

1.5.9   The offeror should include the capability to create accurate, up‐to‐date hard copy versions of any on‐line documentation.  The agency must be able to reproduce any of these manuals to meet internal needs.  

H     

1.5.10  The offeror should provide electronic updates to documentation manuals periodically as system capabilities change.  

H     

1.5.11  The offeror must include complete system administrator documentation.  

M     

1.5.12  The offeror should include the capability for system administrator(s) to edit/add to the on‐line help text.  

H     

1.6  System Expandability and Future Options  Priority  Response 1.6.1  The  design  of  the  system  must  be  compatible  with 

current and  future  incentives, such as Mobile Data, AVL (Automatic  Vehicle  Location),  ME‐911,  ANI/ALI,  CTI (Computer  Telephony  Interfaces),  NCIC  2000,  and  IP Telephony. 

M     

1.7  Printing   Priority  Response 1.7.1  The offeror must include the capability to print to any 

local or network‐attached printer  M     

1.7.2  The offeror must include the capability to control printing of non‐public data.  

M     

1.7.3  The offeror should include the capability for exporting reports into ASCII/CSV/XLS/XML formats.  

M    

1.7.4  The offeror should include the capability to restrict printing of a data entry screen that contains sensitive data (i.e. NCIC data and non‐FOIA).  

H     

1.8  Performance and Availability   Priority  Response    The following performance and availability requirements 

shall apply to all components of the system.       

1.8.1  The offeror should include the capability for the system to be configured in a manner that ensures a high level of availability and redundancy.  

H     

1.8.2  The offeror must include the capability to ensure an uptime of at least 99.9%.  

M     

1.8.3  The offeror must include the capability for the system to be configured in a manner such that the failure of any single component shall not cause a system failure.  

M     

1.8.4  The offeror must include a robust reporting tool that can generate ad‐hoc reports as an internal function or with other third‐party tools such as Crystal Reports, MS Reporting Services  or similar.  

H     

1.8.5  The offeror should include the capability to distribute reports via E‐mail, fax or hard copy.  

H     

Page 26 of 84

1.8.6  The offeror must include the capability to view reports on‐line.  

M    

1.9  Data conversion/Migration   Priority  Response 1.9.1  The offeror will be required to convert the data identified 

in this proposal. If additional data requiring conversion is identified by the vendor or this agency that significantly impacts system integrity or performance will be handled on a one‐on‐one basis prior to final payment.    

M     

1.9.2  The offeror will perform all data extraction during migration. The agency will provide necessary personnel to assist in data cross‐walking during the conversion process as needed. Include any additional requirements/resources that may be needed during this phase that may not have been expressed within this proposal.  

M     

1.9.3  The offeror will understand that data cleansing will be performed as data is converted into the new system.  The agency will work with the offeror in defining the requirements of this process.  

M    

1.9.4  The offeror’s data conversion should include the capability of re‐identifying  old report numbers (incident, case, offence, etc.) to standard numbers utilized by your system.  This is intended to simplify querying and/or reporting on a single numbering system.  

M    

1.9.5  The offeror will be required to convert some of the data elements into a standardized format (address, phone numbers, names, etc.) as needed or determined by the offeror or agency to maximize system performance or provide for system usability.  

M     

1.9.6  The agency’s criteria for successful conversion will be the following:  ‐ (to be completed by agency personnel)   ‐ Randomly selecting 50 records from each of the converted databases   ‐ Performing a spot check between the old system and the new system to verify data is in appropriate data elements and that appropriate links have been established between tables.  ‐ 100% accuracy on all data elements and links must be verified prior to acceptance of conversion.  

M     

           

2  Computer Aided Dispatch (CAD)        

2.1  General Requirements   Priority  Response 

Page 27 of 84

2.1.1   The system must provide dispatch functions from call takers, dispatchers and supervisors. It must be user friendly and customizable based on unique requirements of the agency.  The system must communicate with other entities, such as NCIC.  The system must be capable of the following additional features:  agency‐to‐state data communications not encompassed in NCIC, an open architecture and application programmer interface that may connect to other systems. The system shall operate on agency hardware and network infrastructure. The software must be expandable to encompass multi‐jurisdictional solutions. 

M     

2.1.2  All aspects of the CAD system must be optimized for rapid response time and system reliability.  Since time is of the essence, the CAD system must accurately provide a date and time stamp for every activity.  

M     

2.1.3  The CAD system also supports other activities that assist in the effective use of public safety resources, including shift change roll call, "Be on the lookout" (BOLO) files, and the ability to schedule a call in the future.  

M     

2.1.4  The offeror must provide E911 Automatic Number Identification (ANI)/Automatic Location Identification (ALI) system capability.  

M     

2.1.5  The offeror should include the capability for Computer Telephony Interface (CTI) options.  

H     

           

2.2  GIS Graphical Information System   Priority  Response 2.2.1   The offeror must include that all GIS system data shall be 

compatible with ESRI software.  M     

2.2.2  The offeror must include the capability for GIS to attempt to match addresses entered into the CAD system.   Matches should provide patrol zone, wrecker area assignment, city, county, zip code information to the incident location. 

M     

2.2.3  The offeror must include the capability for the GIS system to provide unit and call mapping.  

M     

2.2.4  The offeror must include the capability of showing calls and units on a map based on priority or emergency status.  

M     

2.2.5  The offeror should include the capability for the GIS system to provide unit recommendation for closest unit that can respond to the incident 

H     

2.2.6  The offeror should include the capability for the GIS system to be customizable for display of specific geographic regions, including statewide, dispatch area district, county, zone or special event area.  

H     

Page 28 of 84

2.2.7  The offeror must include the capability to view the CAD mapping as an option.  

M     

2.2.8  The offeror must include the capability for the GIS location verification to be required prior to call entry completion.  

M     

2.2.9  The offeror must include the capability for the GIS system to temporarily mark a street segment as closed.  Closing the street segment would prevent the street from being used to calculate routes and closest unit recommendations. 

M     

2.2.9  The offeror must include the capability for the GIS system to provide route information to the user for providing turn by turn directions from unit's location to the incident location.  This should include travel time and travel distance measurements. 

M     

           

2.3  Call Taking   Priority  Response    Calls for service (CFS) initiate the CAD process. Callers are 

citizens or other agencies requesting services from the agency or giving notification of events or activities of concern.  A CFS may come from many different points of origin, such as alarm systems, E 911 systems, direct calls (7‐ or 10 digit numbers), walk‐ins, CAD‐to‐CAD interfaces, or Web‐based systems.  

     

2.3.1  Calls for service must capture(at a minimum) the following times upon entry: time call is received, time officer is dispatched, time officer is notified, time officer is in route, time officer arrived, and time officer completed assignment.  

M     

2.3.2  Calls for service must capture, at a minimum, the following data elements during entry; phone number call is coming from, complainants name as well as their address, location of occurrence, notes pertaining to incident, nature of call, priority, disposition, system generated incident number and case number assigned (if applicable).  

M     

2.3.3  The offeror must include at a minimum, the following statuses, captured during a call: notified, en route, on‐scene, subject in custody, transporting subject to jail, transporting or in route to a secondary location, at jail for breath test, at hospital, female/juvenile in custody, assignment complete (on‐scene), call disposition, directing traffic, assisting other agency.  

M     

2.3.4  The offeror must include a report that produces all transactions for a specific unit, a specific CAD user, and a specific Communications Center.  

M     

Page 29 of 84

2.3.5  The offeror should include the capability to perform a quick data entry method in case of system unavailability and calls must be keyed in batches.  

M     

2.3.6  The offeror must include the capability for all transactions to be recorded in a history table.  

M     

2.3.7  The offeror must include the capability to access the main CAD screen by one keystroke or mouse click.  

M     

2.3.8  The offeror should include the capability for alpha‐numeric call numbers.  

M    

2.3.9  The system must include the capability to link duplicate CFS, one call is disposed with a cross‐reference to the original CFS.  

M    

2.3.10  The offeror must include the capability of utilizing multiple types of locations of calls, including street crossings, interstate mile marker, US and Primary Highway cross reference, and county/secondary road criteria.  

M    

2.3.11  The system must include the capability to capture CFS location information when different than caller's location.  

M     

2.3.12  The offeror must include the capability for the CAD to denote primary and secondary pursuit officers and the assigned supervisor during any pursuit.  

M    

2.3.13  The system must include the capability to assign complaint/nature codes, which may include general classification and subtypes of the call based upon agency policy.  

M    

2.3.14  The system must include the capability to automatically evaluate the CFS location (and potentially other site parameters) to determine whether a call is a duplicate.  The call taker must be given final decision regarding duplicate calls after evaluating the information presented.  

M    

2.3.15   The CAD must include the capability to initiate a CFS with the type of call (nature of the complaint), the priority and the location of the CFS.  

M     

2.3.16  The system must include the capability to verify caller location against current address listing or geofile. The location information can be a street address, intersection or common place name.  Location information for a common place name, such as City Hall has a street address listing cross‐reference that will provide the legal street address. The geo‐file must include latitude and longitude information  

M    

Page 30 of 84

2.3.17  The location geofile must: • Validate that the street name is an actual street in the service area • Resolve ambiguities while accounting for spelling variations and duplications • Validates intersections • Validates address range • Relates common place names to actual addresses • Relates X/Y coordinates to an actual address • Transforms latitude and longitude to map coordinates for display • Translates call location to agency reporting area • Translate alias names to actual street names  

M     

2.3.18  The system must include the capability to dispatch a call after the base information has been captured (nature, priority, location, etc.). Once additional information is added to the call, the system will update the new information and make it available to all call takers/dispatchers real‐time.  

M    

2.3.19  The system should include the capability to automatically query person’s information after entry into the system.  Person’s information includes protection orders, warrants, mental or health issues, gang information, sex offender registry information, etc. This query should inquire local/State/NCIC databases as needed.  

M    

2.3.20  The system should include the capability to automatically query vehicle information after entry into the system.  This query should inquire local/State/NCIC databases as needed.  

M    

2.3.21  The system must include the capability to retrieve relevant historical and tactical information cross‐referenced to the CFS location.  This information may include previous calls for service, whether the premise has records of registered firearms, hazardous material stored at the location (usually business sites), serious medical information concerning individuals residing at the premise, and other relevant information.  

M    

2.3.22  The system must include the capability to generate a unique call number for each new call for service.  

M     

2.3.23  The system must include the capability to identify the patrol area assignment against the location information obtained from the caller.  

M     

2.3.24   The system should include the capability of recommending resources for the selected CFS, based upon preset criteria for the type and priority of CFS.  

M    

2.3.25  The system must include the capability to permit call takers to override the systems recommended resources as needed based on additional information or requests by officers on the scene.  

M     

2.3.26  The system may include the capability of assigning an incident number without intervention as a system option. 

M    

Page 31 of 84

2.3.27  The system must include the capability to display available resources, based on unit status, which could include unassigned as well as assigned with a lower priority status of call to which a unit is assigned.  

M     

2.3.28  The system must include the capability to dispatch units from outside of the CFS location area into the area when resources are not available within the selected area.  

M     

2.3.29  The system should include the capability to create and maintain BOLO (Be on the lookout). BOLOs may also be created using a mobile data terminal interface if installed.  

M     

2.3.30  The system should include the capability to attach expiration date to BOLOs.  

M    

2.3.31  The system should include the capability to capture the following BOLO elements: nature of BOLO, priority, date, range of effectiveness, subject person and subject vehicle information, and contact information.  

M    

2.3.32  The offeror should include the capability for data entry and maintenance of BOLOs on persons and vehicles.  

M    

2.3.33  The offeror should include the capability of logging when a BOLO is broadcast to include date/time stamp and dispatcher.  

M    

2.3.34  The offeror should include the capability to show all current BOLOs in one specific location.  

M    

2.3.35  The offeror should include the capability of flagging BOLOs as closed due to apprehension, finding a vehicle or administrative.  

M    

2.3.36  The offeror should include the capability of entering BOLOs from other police agencies.  

M    

2.3.37  The offeror should include the capability to search on prior BOLOs.  

M    

2.3.38  The offeror must include the capability of removing a unit from a call, then assigning a unit to another call, and suspending or placing on hold the first call. If the unit was the only unit assigned to the suspended call, the call shall automatically be put into a pending queue.  

M     

2.3.39  The offeror must include the capability of placing calls on hold to allow calls with a higher priority to be entered.  

M     

2.3.40  The offeror must include the capability for pending calls to be displayed on the main CAD screen.  

M     

2.3.41  The offeror must include the capability to scan new calls to determine if a closed call should be reopened.  

M    

2.3.42  The offeror must include the capability to sort calls based on call priority.  

M     

Page 32 of 84

2.3.43  The offeror must include the capability for Unit/Call status changes to be recorded and retrievable including all related unit, call, and CAD operator initiated fields  

M     

2.3.44  The offeror must include the capability to display available unit statuses with unit call number, unit area assignment, unit status, and type of unit (enforcement, supervisor, etc.)  

M     

2.3.45  The offeror must include the capability to display all open calls, unit statuses, and weather advisors on the main CAD screen.  

M    

2.3.46  The offeror must include the capability sorting all open calls by call type, priority, or location.  

M    

2.3.47  The offeror should include the capability to assign timers to units on calls with audible and/or visual alarms.  The timer parameters shall be maintained by call type and length.  

M    

2.3.48   The offeror must provide the capability for a specific unit sign on and sign off screen. The sign on screen shall utilize a shift roster that includes shift, area working, and/or special assignments.  

M    

2.3.49  The offeror should include the capability to accommodate a status change for more than one unit at a time.  Multiple units may be signed on or signed in at one time.  

M    

2.3.50  The offeror must provide the capability of assigning temporary units.  

M     

2.3.51  The offeror must include the capability to classify units by different divisions in a unit/personnel file.  

M    

2.3.52  The offeror must include the capability to assign multiple units to calls.  

M     

2.3.53  The offeror must include the capability to assign roles to units on calls, such as primary unit, supervisor on scene, backup support, traffic direction or crowd control.  

M     

2.3.54  The system must include the capability to maintain the elapsed time between status changes/checks and alert the dispatcher when agency‐defined thresholds are met.  

M     

2.3.55  The system must include the capability to capture multiple arrival times; an example would be the arrival at the location and another arrival at the scene.  

M     

2.3.56  The system must include the capability to capture any change in unit location along with time stamps, including changes of location associated with the same CFS.  

M     

2.3.57  The offeror should include the capability for command line transactions to automatically change unit statuses.  

M    

2.3.58   The offeror should include the capability for command line transactions to initiate call entry screens based on call type.  

M    

Page 33 of 84

2.3.59  The offeror should include the capability to format certain calls types, such as pursuit calls, for faster data entry.  

M    

2.3.60  The offeror should include the capability to define views of open calls and available units for each CAD user.  This assignment shall be based on geographic region or specific units.  

M    

2.3.61  The offeror should include the capability to transfer calls for service from a CAD user to other CAD users, or other CAD stations at any location in the system.  

M    

2.3.62  The offeror must include a CAD system that can support non‐emergency calls, emergency calls, administrative messages, and field initiated calls.  

M     

2.3.63  The offeror should include the capability to enter broadcasts, such as weather advisories, road closures, and general administrative broadcasts. These broadcasts shall be viewable and routable to any CAD position, or any CAD user.  

M    

2.3.64  The offeror should include the capability to place expiration date and times on weather advisories, road closures and administrative messages. These records shall be removed from the main CAD screen upon expiration.  

M    

2.3.65   The offeror should include the capability for officer transmissions, such as breaks, court, and special assignments, shall be recorded in calls for service.  

M    

2.3.66  The offeror should include the capability for identifying events, calls, and units upon status changes by color change or flashing text.  

M    

2.3.67   The offeror must include the capability to search for warning, caution information, prior tow records, or prior calls during CAD call entry.  

M     

2.3.68  The offeror should include the capability of performing immediate NCIC checks on traffic stops.  

M    

2.3.69  The offeror should include the administrator with the capability to customize data entry fields for traffic stops.  

M    

2.3.70  The offeror should include the capability to enter multiple vehicles during a single traffic stop.  

M    

2.3.71  The offeror should include the capability to require specific and mandatory fields for fatality dispositions.  

M    

2.3.72   The offeror must include the capability to assign a unique case number that is auto‐generated when required.  

M     

2.3.73  The offeror should include the capability for agency to configure new case numbers at the beginning of each year. 

M    

Page 34 of 84

2.3.74  The system should include the capability to generate multiple case numbers for a single incident.  

M    

2.3.75  The system must include the capability of providing basic incident data to the records management systems (RMS) upon completion of the CFS.  

M     

2.3.76  The offeror should include the capability to customize call types, disposition types, and status changes by a system administrator.  

M    

2.3.78  The offeror must include the capability to reopen closed calls.  

M     

2.3.79  The offeror must include the capability to keep an existing incident number issued to a closed call after the call is reopened.  

M     

2.3.80  Call Scheduling ‐ The system must include the capability to create a CFS, and schedule it for a future date and time to become active.  

M    

2.3.81  The offeror must include the capability for a tow‐type database to include specific classifications of wreckers or road service.  

M    

2.3.82  The offeror must include the capability for a tow rotation database. This database should include the capability to record information regarding the attempt to contact the company or the company’s reasons for declining service.  

M    

2.3.83  The offeror must include the capability to allow for a wrecker to be put back on rotation at a pre‐selected position with a log entry stating the reason for putting the wrecker back on rotation.  

M    

2.3.84  The offeror should include an owner/operator special request code/database. Please provide information on this procedure.  

M    

2.3.85  The offeror should include the capability of entering towing companies that are not in the database or the current system.  The entry shall be made from the tow request screen or a tow maintenance screen.  

M    

2.3.86  The offeror should include the capability to maintain a separate log for towing records.  

M    

2.3.87  The system must include the capability to close a CFS after appropriate disposition information has been captured.  When the call is closed, information collected during the CFS should be automatically transferred from the CAD system to the records management system (RMS). Any updates made by the CAD operators on reopened calls will be automatically transferred to the RMS.  

M     

2.3.88  The system should include the capability to schedule appointments for transport. 

M     

Page 35 of 84

2.3.89  The system should include the capability to schedule multiple appointments for transport. 

M     

2.3.90  The system should include the capability to schedule recurring appointments for transport. 

M     

2.3.91  The system should include the capability to schedule return trip appointments for transport. 

M     

         

2.4  Call Management and Management Reporting  

Priority  Response 

2.4.1  The CAD system should provide the capability to monitor the activity on any dispatcher workstation.  If necessary, a supervisor needs to have the ability to take direct control over a dispatch position without leaving the supervisor console.  

M    

2.4.2  The system must include the capability for standard reporting using flexible parameters.  Reports should be defined either through the CAD system or a third‐party reporting tool and then be stored as a standard report available through the CAD system.  

M    

2.4.3  The system should include the capability to report on any data element by any other data element in the system.  

M    

2.4.4  The system should include reports that can be run by any user‐defined data and time range:  For example: • Daily log showing calls received for the prior 24 hours from time of printing • Activity be specified geographical area and by time period • CFS summary by specified geographical area and by time period • Activity by day of the week •  Response time by specified geographical area and by time period 

M     

2.4.5  The system should include the capability to report on major incidents for reporting to Emergency Management. 

M    

2.5   Interfaces   Priority  Response    These CAD interfaces are considered to be essential for 

conducting primary law enforcement business functions.  The five primary CAD interfaces are 1) the messaging system 2) the local RMS 3) Regional/State/NCIC warehouses, 4) E‐911 and 5) Warrants  

     

2.5.1  The system must include the capability to import subscriber information (ANI and ALI) including phase 2 wireless caller location information for each E911 caller, as provided by the telephone company, into CAD‐compliant entry process, eliminating the need for redundant data entry either automatically or via hot‐key. The E‐911 data shall be simultaneously imported into the mapping system for immediate centering and display.  

H     

Page 36 of 84

2.5.2  The system must include the capability to query state, local and national databases. These queries will occur automatically from selected CAD commands using the messaging system interface.  In addition, the operator will have the ability to use stand‐alone query screens, eliminating redundant data entry.  Responses to such queries should be stored with the call record.  

H     

2.5.3  The system should include the capability to interface with other CAD systems in a multi‐CAD environment if the agency's elect to participate in a co‐operative effort.  

H     

2.5.4  The system should include the capability to communicate with a mobile data terminal system, either a system provided by this vendor or any other vendor's system.  

M     

2.5.5  The system should include the capability for the CAD to accept input from an Automatic Vehicle Location (AVL) system.  The CAD should convert vehicle location to a street address and record the vehicle location in the unit history.  

M     

2.5.6  The system should include the capability to interface with the county's GIS to support maintenance of the CAD map layers, such as reporting districts/areas, and the creation of the CAD geofile.  

H     

2.5.7  The system may include the capability to import and display the radio ID (and optionally the officer ID) information to the dispatcher by those keying mobile radios.  

L     

2.5.8  The system should include the capability to synchronize the CAD server and all workstations with a master time clock.  

M     

2.5.9  The system should include the capability to automatically perform an alphanumeric page for selected CAD calls and dispatches.  A dispatcher may initiate an alphanumeric page for any paging group.  

H     

2.5.10  The system should include the capability to automatically format and send an e‐mail for selected CAD calls and dispatches.  The information sent in an e‐mail should be configurable by the agency but generally will contain the call information or a list of open calls meeting certain search criteria.  

H     

2.5.11  The system should include the capability to broadcast, publish, and send messages to individuals or agencies that need to be aware of critical events. Examples include Amber Alert, critical incident occurrences, transportation, hospitals, or the public at large via the internet.  

H     

2.5.12   The system should include the capability to communicate with one or more subsystems (i.e., EMS Dispatch, Fire Dispatch, etc.)  

H     

           

Page 37 of 84

2.6  CAD system Administration   Priority  Response 2.6.1  The CAD system must provide the capability to configure 

the system as needed to meet agency requirements.  Administrative functions include: • CAD table maintenance • Security and data management • Geofile maintenance • Error logging • Customization  

M     

2.6.2  The system should utilize authoritative code tables referenced in the NIEM data model and NCIC.  

H     

2.6.3  The system must include the capability to log all actions.  These logs should be viewable and searchable by the system administrator(s).  

M     

2.6.4  The system should include the capability to configure, on a per user basis, screen parameters, color choices, font size, screen layout, and other user preferences.  

H     

           

3  JMS (Jail Management System)        

3.1  General Requirements   Priority  Response    The Jail Management System must be designed to 

efficiently manage all aspects of Jail operations to include inmate and facilities maintenance and/or tracking. The application must maintain records on all persons who are arrested/booked, including medical, personal property, inmate funds and commissary.  The system must be able to track any and all transactions pertaining to an inmate’s incarceration in the facility, to include (but not limited to) the following: monies added/subtracted, property, cell assignments and moves, visitors, medical, disciplinary actions, charges, record accesses and/or changes.  All events will be tracked by date/time, user id, what was changed and original values.  

     

3.1.2  The system must include the capability of providing pick lists for frequently used fields including offense or statute codes, race, sex, property types, and physical characteristics that comply with UCR coding standards.  

M    

3.1.3  The system should include the capability to utilize a “Soundex” function when searching the master name.  

M    

3.1.4  The system must include the capability for providing an audit trail record for every record entered, edited, or deleted.  The audit trail must include the original value of the record or field, the new value, identity of who entered or changed the data, and the date and time of the entry or change.  

M    

3.1.5  The system should include the capability to include a thumbnail photograph with selected inmate queries/reports.  

M    

Page 38 of 84

3.1.6  In the event that a new ID number is issued for an arrestee and it is determined later through fingerprint identification or some other means that the arrestee already had an ID number the system should: • Allow the new information to be added to the original record as a new arrest • Delete the ID number that was issued in error, but maintaining an audit of it • Accommodate inmate name changes for repeat arrestee  

M    

3.1.7  The system must include the capability of listing all inmates currently incarcerated alphabetically. At a minimum, the data displayed should include; • Inmates name • ID number • Cell assignment  

M     

3.1.8  The system must include the capability of selecting a name from the incarceration listing and performing additional actions (insert charges, edit inmate account, etc.) against that record.  

M     

3.1.9  The system must include the capability of providing multiple ways to search for inmate records.  At a minimum, the system should allow users to search by full or partial name, alias, Social Security number, Inmate ID number or other identifying numbers, and address  

M    

3.1.10  The system must include the capability of displaying an inmate summary screen with at a minimum the following data; • Inmate name • SSN • DOB, Race, Sex • Cell location •  Photograph • Booking date and time • Number of times arrested • Warnings/Cautions • Holds • Inmate Charge Status (Felony/Misdemeanor) • Sentence start date, # days, # days credited, expected release date and time  

M    

3.1.11   The system should include the capability for unit officers to limit the display/interaction of the inmate population to the inmates in his/her unit only. The system should include the ability for any unit officer to change the view criteria to search for any inmate in the facility.  

M    

3.1.12  The system must include the capability for authorized users to add/modify/delete local ordinances from multiple agencies into the statute data table.  

M     

3.1.13  The system must include the capability of determining the last known location of a given inmate.  

M    

3.1.14  The system must include the capability to automatically export a pre‐determined range of data  elements on ALL inmates on a predetermined schedule (hourly, bi‐hourly, etc) to an FTP site.  

M   

3.2   Booking   Priority  Response 

Page 39 of 84

3.2.1  The system must include the capability to provide a list of any inmate records that match either the name/alias or social security number provided by the arrestee. If a match occurs, the system should alert the booking officer of any known associates already incarcerated in the facility.  

M    

3.2.2  The system must include the capability to support a connection between the RMS and the JMS to share inmate number, booking number  

M    

3.2.3  The system must include the capability to retrieve all pertinent data for an individual upon selection of a previously issued ID number and enter it into the applicable data fields which will be used during the recording of a new booking.  

M    

3.2.4  The system must include the capability to edit any field that has been pre‐filled by the retrieval of a previously issued ID number.  

M    

3.2.5  The system must include the capability to capture, store and display historical mug‐shots at time of booking.  

M    

3.2.6  The system must include the capability to assign the next sequential number in the ID number queue if the arrestee has not been previously assigned an ID number and proceed to the next booking process.  

M     

3.2.7  The system should include the capability to redact certain booking information for release to the public.  

M     

3.2.8  The JMS must include the capability to capture the following information from persons arrested or placed into protective custody: • Date and day of week • Time • Name (First, last, and suffix) • Photograph • Fields for multiple; Alias Names, DOB, Moniker, AKA, Maiden Name, SSN, DOB, DL#, Inmates City and State of Birth, Occupation and Employer, Attorney, Marital Status, Addresses (including house or building number, apartment number, street name, city state, and zip or postal code) • Multiple telephone numbers and phone number designation fields, e.g. home, business, etc. • Physical Description fields including; sex, race, height, weight, eye and hair color, complexion, build, facial hair, age (calculated based on DOB). • Multiple fields for identifying marks (scars, marks, tattoos) • Emergency contact • Inmates FBI, State, Agency number and booking number • Flags for Juveniles and Gang associations • Father's name • Next of kin • Charge(s) • Bond Amount • Arresting officer(s) • Court • Booking officer  

M     

Page 40 of 84

3.2.9  The system must include the capability of searching the master name index file for previous entries of persons being booked into the facility. This search should be as timely as possible (within two (2) seconds at peak activity) to prevent duplicate name entries.  If a match or possible match is found, the system must allow for verification of personal information and allow changes as required.  

M    

3.2.10  The system must have the capability during the booking process, to automatically query local warrant databases.  

M    

3.2.11  The system must include the capability to support the following booking functions: Initial, Supplemental, and Weekender.  

M    

3.2.12  The system must include the capability, during the booking process of entering  the following abilities: • Entry of court dispositions  • Entry of sentencing information including time to serve, fine amounts, commitment dates and credit for time served  • Entry of release information, such as bail amount  • Ability to suspend a booking at any point in the process and resume at a later time to the point it was suspended, without losing any data entered prior to the suspension • Entry of medical screening information with automatic notifications to medical staff that the inmate has medical problems  • Entry of personal property • Entry of arrest information, including charges, date and time of arrest, place of address and arresting agency • Display of historical booking charges  • Ability to track individuals sentenced to community service in lieu of incarceration • Generation of printed inventory and receipt for inmate personal property. • Open an individual trust account • Photograph • a single digit fingerprint 

M    

3.2.13   The system must include the capability to run a suicide evaluation checklist as part of the booking process.  

M    

3.2.14  The system must include the capability for the completion of medical screening forms/questions that are user definable.  

M    

3.2.15  The system must include the capability to notify the booking officer of any outstanding cases against the defendant so that any question of bail can be resolved.  

M    

3.2.16  The system must include the capability to enter additional charges that are added subsequent to initial booking.  

M    

Page 41 of 84

3.2.17  The system must include the capability to include data from the Judge/Magistrate’s Commitment Order ad includes the following fields; • Social Security Number • Arrest Type • Charge • Statute and Counts • Bond Type and Amount • Agency • Date • Court • Hearing Date • Court Case Number • Hearing Time • Charges and Verdicts (unlimited) • Felony/Misdemeanor at booking, and as adjudicated  

M    

3.2.18  The system must include the capability to prepare wrist band labels with bar codes, name, Inmate ID number, DOB, and color photograph.  

M    

3.2.19  The system must include the capability to prepare laminated identification (ID) cards with, bar codes, name, Inmate ID number, DOB, and color photograph.  

M   

           

3.3  Inmate Identification and Record Keeping   Priority  Response 3.3.1  The system must include the capability to store an 

unlimited number of scars, marks, and tattoos for a person.  

M    

3.3.2  The system should include the capability to store the relatives for a person, including relationship, name address and phone number.  

H     

3.3.3  The system should include the capability to store current and previous spouses for a person, including name, address and phone number.  

H     

3.3.4  The system must include the capability to store a true name for a person without regard to the name entered at time of booking.  

H     

3.3.5  The system must include the capability to store an unlimited number of mug shot photographs and a single digit fingerprint.  

M   

           

3.4  Inmate Money Accounting (Trust Fund)   Priority  Response 3.4.1  The system must include the capability of creating and 

maintaining an individual cash account for each inmate.  M    

3.4.2  The system must include the capability to attach the booking number to the account.  

M    

3.4.3  The system must include the capability to allow additional funds to be added to the inmates account (i.e. inmate payroll, etc.).  

M    

3.4.4   The system must include the capability of drawing funds out of the account in the form of a check to an individual or third party.  

M    

Page 42 of 84

3.4.5  The system must include the capability of recording incurred debits and credits for commissary purchases.  This information may be provided through the commissary interface as described in the interfaces portion of this document.  

M    

3.4.6  The system must include the capability to support automatic subsistence fee (Pay for Stay) charge deduction.  

M    

3.4.7  The system must include the capability for users with appropriate permissions the ability to “reverse” or correct any transaction.  

M    

3.4.8  The system must include the capability to print one or more receipts for each transaction.  

M    

3.4.9  The system must include the capability of maintaining a current account balance at all times, recording any and all credits and debits regardless of the means by which they are entered.  

M    

3.4.10  The system must include the capability of interfacing with the existing commissary system to record debits to the inmates trust fund balance. (see Commissary interface requirements section for additional information)  

M     

3.4.11   The system must include the capability to check the inmates trust fund balance (funds availability verification) each time a commissary order form is saved to ensure that the inmate has sufficient funds to pay for the requested items. (see Commissary interface requirements section for additional information)  

M    

3.4.12  The system must include the capability to provide a means of crediting cash received from outside sources to inmate accounts.  At a minimum it should record the amount received, date and time, and the inmate account to be credited  

M    

3.4.13  The system should include the capability of documenting the name of the person making a deposit into an inmate’s account.   

M     

3.4.14  The system must include the capability of placing a lien against an inmate’s account.  This lien shall prevent the inmate from making any expenditure for discretionary items such as canteen. The lien record should indicate the person or court ordering the lien, the amount and the person to which funds will be sent, and a comment field.  

M    

3.4.15  The system must include the capability to record an audit trail with a reference number for all transactions, along with identification of the person making the changes to the account.  

M    

Page 43 of 84

3.4.16  The system must include the capability for generating cash receipts and expenditure journals, and a balance ledger for all accounts  

M    

3.4.17  The system must include the capability to close an account and provide a detailed statement as of that date. 

M    

3.4.18  The system must include the capability to charge inmates for miscellaneous items.  

M    

           

3.5  Inmate Property (personal and non‐personal)  

Priority  Response 

3.5.1  The system must include the capability to enter a record of the inmate’s clothes and personal property at the time of entry into the facility and maintain a history of such clothing/personal property. 

M     

3.5.2  The system must include the capability to print receipts for inmate clothing items.  

M     

3.5.3  The system must include the capability for the accountability and inventory of all personal property under Jail control. 

M    

3.5.4  The system must include the capability for the accountability and inventory of all clothing and personal property at time of inmate release.  

H     

3.5.5  The system must include the capability to record locker number, safe utilized, box, and hanger.  

H     

3.5.6  The system must include the capability of utilizing a pick from list of available lockers, box, or hanger.  

H     

3.5.7  The system must include the capability to print/record a property receipt for signature.  If electronic signature capture is in place and capturing signatures, then printing should be an option.  

M    

3.5.8  The system must include the capability to add or move property to a locker in a piece by piece or group function. 

H     

3.5.9  The system must include the capability to print/record an outside party property release (some or all).  

H     

3.5.10   The system must include the capability to query inmate property records.  

H     

3.5.11  The system must include the capability to support inmate trust fund accounting and check printing.  

M    

3.5.12   The system must include the capability to record initial deposit upon arrest and a receipt must be printable.  

M    

3.5.13  The system must include the capability of detailed recording of all deposits and all disbursements.  

M    

3.6  Classification   Priority  Response 

Page 44 of 84

3.6.1  The system must include the capability for automatically determining the classification of an inmate based on severity of charge(s), court disposition(s), agency questioners and medical information.  The system must allow classification personnel the ability to manually override the computer‐generated classification.  The system must be recognized by the National Institute of Corrections (NIC) as a standardized classification technique/process.  

M     

3.6.2  The system must include the capability to generate a list of inmates due for classification or review.  

H     

3.6.3  The system should include the capability to designate any gang affiliation and status of the gang.  

H     

3.6.4  The system must include the capability of utilizing a list of 'Keep‐separates' for each inmate and use this list during inmate classification.  

H     

3.6.5  The system must include the capability of displaying a history of classification changes and reviews.  

H     

3.6.6  The system must include the capability to track the following kinds of classification data; • Sentence/Charges • Hold Status • Escape Status • Observations • Attitude toward staff • Attitude toward other inmates • Other attitude observations (Calm, Nervous, etc.)  • Keep separates  • Keep in separate cell  • Track for transportation  • Remarks  • Drug/Alcohol usage (frequency, type, programs)  • Mental Health  • Psychological problems  • Treatments  • Medications  • Suicide attempts  • Educational history  • Military history  • Special management concerns  

M     

3.6.7  The system must include the capability during the cell assignments process of displaying a list of available cells.   

M    

           

3.7  Alerts (Special Flags)   Priority  Response 3.7.1  The system must include the capability to identify special 

conditions (diabetic, violent tendencies, keep separate, etc.) to the user that if not identified, could result in potential problems if not dealt with.  These alerts should be of such that it is immediately apparent that the alert exists.  

M    

3.8  Visitor Control   Priority  Response 

Page 45 of 84

3.8.1  The system must include the capability to record/maintain a list of authorized visitors for each inmate.  

M    

3.8.2  The system must include the capability of scheduling visitors to the facility on a housing unit by housing unit basis by the housing unit officers, including the following data captured: inmate to be visited, booth assigned, date and time of visit, and visitor’s name.  The system must include the capability to delete scheduled visits by authorized users.  

H     

3.8.3  The system should include the capability of automatically checking a “Banning list” for those people/inmates not permitted to visit the jail.  

H     

3.8.4  The system should include the capability of automatically including inmates that are being released into the “Banning list” for a user definable period (i.e. 90 days, 120 days, etc.).  

H     

3.8.5  The system should include the capability of utilizing swipe card readers for drivers license /and/or ID cards for quick input of visitor information into the facility.  

H     

3.8.6   The system must include the capability to check local databases for wants/warrants/holds on any visitor (after proper verification of identity), and display results to jail personnel and to check NCIC records upon request 

M     

3.8.7  The system must include the capability of maintaining a master visitor log for all visitors to the jail which is separate from the MNI  

M     

3.8.8  The system must include the capability to display/print all current visitors in the facility.  

H     

3.8.9  The system must include the capability to allow housing officers to restrict certain individuals from visiting an inmate. (i.e. banned for a period of time for improper conduct during a recent visit)  

H     

           

3.9  Inmate Movement and Transfer   Priority  Response 3.9.1  The system must include the capability of automatically 

updating the inmate custody location and jail head count based upon the movement/transfer of an inmate.  

M    

3.9.2  The system must include the capability of displaying all inmates out on detainer.  

M    

3.9.3  The system must include the capability to print a list of all in‐custody inmates, including housing assignment and current location.  

M    

3.9.4  The system must include the capability to display/print inmate count reports by area, including number of inmates assigned, number currently out of area.  

M     

Page 46 of 84

3.9.5  The system must include the capability to display/print a listing of all movements that have occurred for an inmate.  

M    

3.9.6  The system must include the capability to display/print any 'alerts' which could indicate certain precautions are required during movement/transfer.  

M    

3.9.7  The system shall have the capability for scanning and processing wrist‐bands and/or ID cards with bar‐coding for use with inmate accountability and movement tracking.  

H     

3.9.8  The system should include the capability to provide daily summary of key inmate information including; • Cell assignment • Program participation • Daily movements  

H     

3.9.9  The system must include the capability to monitor and review segregated inmates, including the evaluation of continued segregation. At a minimum the data collected should be; • Inmates name and ID • Date of review • A field for reviewer’s decision to continue segregation or return the inmate to the general population • A comments field • Name and ID of the reviewing employee  

M    

3.9.10  The system must include the capability to track associations between inmates; • Keep separates • Gangs • Co‐defendant  

M     

3.9.11  The system should include the capability to track all inmate movement for a given day, including the name and department with custody.  

H     

3.9.12  The system must include the capability to track the assignment of inmates to cells and to any other locations including, but not limited to, out of facility (in custody) movements including, but not limited to trips to and from court, medical facilities, other detention facilities, etc.  

M    

3.9.13  The system should include the capability to support the use of bar code scanning, for inmate location and movement tracking in real time, and with complete record/audit trails, with the use of a pocket PC wireless device. 

H     

3.9.14  The system must include the capability to support display of inmate information and color photograph on the Corrections Officers workstation and handheld/portable barcode.  

H     

3.9.15  The system should include the capability to schedule important events concerning inmates, such as, inmates next scheduled court date, medical appointments, or transfer.  

M    

Page 47 of 84

3.9.16  The system should include the capability to display/print all planned activities/times for the day, by floor or by unit; • Programs (GED, Religious group gatherings, etc.) • Court appearances • Religious Services • Attorney visits • Medical/Dental • Suicide watch • Special alerts  

H     

3.9.17  The system must include the capability to enter/modify an on‐line duty post log (Officers log).  

H     

3.9.18  The system must include the capability of recording rounds and security checks.  

H     

3.9.19  The system must include the capability of recording all unusual activities and/or disturbances in a log.  

H     

3.9.20  The system must include the capability of recording the segregation of an inmate to include reason.  

M    

3.9.21  The system should include the capability to post shift briefing for the next shift.  

M    

3.9.22  The system should include the capability to allow an authorized user to enter the inmate’s location without releasing the inmate from jail or releasing the inmate’s assigned cell for reassignment when the inmate is away from the facility overnight.  

M    

3.9.23  The systems should include the capability to track the transport of inmates outside the facility. At a minimum the transportation form system should include the inmate’s name or ID number, the originating location, the destination, and a comment field.  

M    

3.9.24  The system should include the capability to track court dates for inmates.  This information should be easily retrievable by authorized officers.  

M    

3.9.25   The system must include the capability to display/print a list of all inmates due to court for a given day.  

M    

3.9.26   The system must include the capability to track hazards/alerts, specified medical needs, and keep‐separates.  

M    

3.9.27  The system should include the capability to report on various inmate‐related events.  

M    

           

3.10  Facility Management   Priority  Response 3.10.1  The JMS must include the capability to maintain a record 

of each housing location in the system.  These locations are defined at the facility, floor, cell/room and bed levels. 

M    

3.10.2  The system must include the capability to produce lists of the population (head counts) for each facility, floor, unit and cell.  

M    

3.10.3  The system must include the accountability of items issued to inmates (i.e. sheets, blankets, pillows, mattresses, etc.)  

M    

Page 48 of 84

3.10.4  The system must include the capability for users with appropriate security privileges to configure the identification (naming) of units, cells and/or beds.  

M     

           

3.11  Court Tracking   Priority  Response 3.11.1  The system must include the capability of entering court 

date information into the booking record to provide court listings for the day, and movement/event tracking sheets.  

M    

3.11.2   The system should include the capability of displaying/printing all court events on an inmate by inmate basis.  

M    

3.11.3  The system should include the capability of interfacing with the local court system via an internet call of another application.  Offeror will be provided with necessary url and security protocols to effect the call.  

M   

3.12  Release   Priority  Response 3.12.1  The system must include the capability to display or print 

a listing of inmates due for release for a given day.  To release an inmate, all charges must have a disposition.  When a release transaction is entered, the system will automatically check all charges for dispositions and check for any other in‐custody records for the inmate. If all charges are satisfied and no other in‐custody records are found, the inmate will be released and the jail count adjusted. The system must also check to verify that any 'HOLD' records for other agencies have been disposed of satisfactory.  

M    

3.12.2  The system must include the capability to automatically check local databases for any detainers, new or open charges, or warrants prior to authorization of release.  

M    

3.12.3  The system must include the capability of checking with the inmate phone interface to determine if a balance is due back to inmate and make appropriate modifications to the inmate trust account.  

H     

3.12.4  The system must include the capability to support single‐print fingerprint ID prior to release.  

M    

3.12.5  The system must include the capability to document the reason for release in a separate field for tracking the name and court of jurisdiction issuing the release order.  

M     

3.12.6  The system must include the capability for printing a receipt listing all property and medication returned to the inmate at release with a signature block for the inmate and the processing officer.  If the system has incorporated signature pad technology, this process should capture the signatures electronically and then print a receipt with signatures included.  

M    

Page 49 of 84

3.12.7  The system must include the capability of printing incarceration papers.  

H     

3.12.8  The system should include the capability of tracking the officer and department of the agency taking custody of the inmate (if applicable). 

M    

3.12.9  The system must include the capability to automatically notify via email those persons or entities that have previously requested such notification.  These may include one or more Judges, Law Enforcement Officers, Prosecutors, Probations Officers or Community Corrections Officers  

 M 

 

           

3.13  Sentence Tracking   Priority  Response 3.13.1  The system must include the capability of calculating 

outdates based upon separate sentences for each charge and court. The system must be able to calculate good time and work credit into the calculation.  

M    

3.13.2  The system must include the capability of updating inmate records to reflect the court disposition of charges, modified bond amounts, amended charges, and sentences.  

M    

           

3.14  Inmate Incident Reporting   Priority  Response 3.14.1  The system must include the capability for recording 

inmate disciplinary problems and in‐custody incident reports against inmates. These reports will be linked to the current booking record.  

M    

3.14.2  The system must include the capability to capture the following data for inmate incident reporting: • Incident date/time, type, location, description, officers and inmates involved, and incident disposition • Entry of disciplinary action(s) taken, including loss of good and work time for each inmate • Supervisor review and comments • Automatic recalculation of release data if required  • Note administrative segregation, medical lockdown or lockdown • Use of Force (If use of force is indicated, automatic and mandatory entry of a use of force form) • Display/print of disciplinary action records  

M    

3.14.3  The system should include the capability to retrieve and print all prior reports involving an inmate.  

M    

3.14.4  The system should include the capability to prompt users in the visitation module of any restrictions imposed by an incident.  

M    

           

3.15  Weekender Program Management  Priority  Response 

Page 50 of 84

3.15.1  The system must include the capability to produce lists of persons expected to check in and out while serving a sentence on a weekend basis.  The system should simplify the check in and checkout of persons serving weekend sentences. If the weekender is not incarcerated, they must not be counted in the head count or ADP. 

 H    

3.16  Medical Information   Priority  Response 3.16.1  The JMS must include the capability to document/track 

all medical complaints/sick call and treatment information including medications, including interim and final disposition.  

M    

3.16.2  The system should include the capability to accommodate medical records maintained by a medical contractor.  

M    

3.16.3  The system must include the capability to display/print sick call information by housing unit or inmate.  

M    

3.16.4  The system must include the capability to charge inmates for medical services.  

M     

           

3.17  Inmate Billing   Priority  Response 3.17.1  The system must include the capability to track inmates 

boarded for or at other jurisdictions. Inmates boarded for another agency should appear on a receivable printout as monies due, while local inmates boarded at other jurisdictions should be listed on a payable report.  

M     

3.17.2  The system must include the capability of preparing invoices for state, federal, and out‐of‐county inmates.  

M    

3.17.3  The system must include the option to bill or not bill for the first/last day.  

M    

3.17.4  The system must include the capability of generating a billing journal for all agency/inmate invoices.  

M    

           

3.18  Reports   Priority  Response 3.18.1  The JMS must include a wide variety of reports and 

outputs, some of these are: • Jail release list • Jail court list • Arrest/Booking report • Jail roster and "Head Count" (this report must be automatically produced as defined by current directives and any discrepancy between the "Head Count" and the Jail Roster • Inmate billing list • Inmate history record • Monthly/Daily/Weekly Population reports • Daily report on available bed space by locations • Printing of on‐line booking statistics by facility, sex, booking type, agency, charge and arresting officer. • Daily, weekly Monthly ADP reports. 

M    

Page 51 of 84

3.18.2  The system must include the capability of reporting the average population by category by varying date range(s).  

M     

3.18.3  The system must include the capability of reporting on the total number of employees in the facility.  

H     

3.18.4  The system must include the capability of displaying/reporting a roster of employees in the facility showing the employee’s name, rank, assignment and location.  

H     

3.18.5  The system should include the capability of displaying a summary of the previous day’s activities including; • Incident reports • Bookings and releases  

M    

3.18.6  The system should include the capability of categorizing inmates by such traits as: alcoholics, drug abusers, and mentally ill/developmentally disabled persons.  

M    

3.18.7  The system should include the capability of identifying/reporting local incarcerations for felons or other state inmates.  

M    

3.18.9  The system must include the capability of retrieving key information from any workstation; e.g. release date, fund account balance, etc.  

M    

3.18.10  The system must include the capability of providing a booking report on any/all persons booked for a date or date range.   Report must include Name, DOB, SSN and all Alias Names.  

M    

3.18.11   The system must include the capability of a detailed duty post log that captures activities on each shift, for each duty post.  

M    

3.18.12  The system must include the capability to display/print a visitation log for an individual inmate and a jail‐wide report of all visitors in the facility.  

M     

3.18.13  The system must include the capability of printing an inventory of all inmate property at any time.  

M    

3.18.14   The system must include the capability of reporting for a user‐defined date range a listing of all inmates whose release date fell within the user‐defined date range.  

M     

3.18.15  The system must include the capability of displaying/printing an inmate fund account detail report showing all transactions to an inmate’s account during a user‐defined date range.  At a minimum, the report should include the date, amount, and type of each transaction.  

M    

           

3.19  Court Bond Function   Priority  Response 

Page 52 of 84

3.19.1  The system must include the capability of accepting/tracking monies, on a per charge basis, for an inmate’s charges and printing of a receipt which can be given back to the customer documenting the following at a minimum: 

H     

   • Inmate Name          • Charge/Charge Description          • Warrant/Ticket number           • Type of ID           • ID Number           • Court           • Court Date           • Agency           • Arresting Officer           • Bond amount for that charge           • Payment method           • Receipt number           • Officer taking in monies           • Date and time of transaction           • Received from name, address, state, and zip code                   

3.20  Commissary   Priority  Response 3.20.1   The system must track the purchases of individual items 

by each inmate.  M    

3.20.2  The system must interface with the Detention Center’s third‐party vendor (Keefe) for its commissary distribution.   

M    

           

3.21  Work Release and Trustees   Priority  Response 3.21.1  The system must include the capability to track inmates 

participating in Work Release programs.  M    

3.21.2  The system must include the capability to track inmates participating in Community Service programs. These inmates must not be included in the jail population.  

M    

3.21.3  The system must include the capability of determining inmate charges for their stay.  

M    

3.21.4  The system should include the capability of recording key supervisor and employer information including address, phone number, department, start date, cancelled date and by whom, for inmates with regular jobs.  

M    

3.21.5  The system must include the capability of maintaining logs for all inmate check ins/outs.  

M     

3.21.6  The system must include the capability of recording/maintaining trustee work schedules and locations.  

M    

Page 53 of 84

3.21.7   The system must include the capability of tracking related categories (moves, etc.) and activity logging for trustee and work release assignments.  

M    

3.21.8  The system must track employers’ information (name, address, phone, etc.). 

M    

           

3.22  Digital Image Capture, Storage and Retrieval  Priority  Response 

3.22.1  The JMS must include the capability to capture inmate photographs during the booking process that comply with NIST standards with respect to size, position, brightness and contrast. Photos can be taken from either a mounted camera station or a hand‐held model.  The system must have the ability to capture images from any part of the body for inclusion into the database for later retrieval.  Images should be stored in standard formats (i.e. JPG, GIF, TIFF, etc.)  

M    

3.22.2  The system must include the capability of attaching mug shots to a specific arrestee or inmate record.  

M     

3.22.3  The system must include the capability to allow for multiple mug shots to be tied to a single record.  

M     

3.22.4  The system must include the capability to work as a stand‐alone imaging station when network connectivity is lost between the server and the workstation. The system must have a mechanism to send the locally captured images to the server.  

H     

3.22.5  The system must include the capability to prevent unauthorized users from adding/changing/deleting images from the system.  

M     

3.22.6  The system should include the capability to print selected inmate images to agency specified documents, such as wanted posters or news agency photo sheets.  

M    

3.22.7  The system must include the capability to view any/all of the previously captured images for an inmate, to include frontal, side, SMT, property, and any other images taken.  

M     

3.22.8  The system must include the capability to perform line‐ups with images within the imaging database.  Line‐ups will utilize a minimum of 6 images (one of person of interest and 5 or more of look‐alikes).  Line‐ups should be configurable by the agency for matching specifications or range criteria. (The lineup system should search the MNI database and present a list of inmates with demographic data that falls within the range criteria and allow the users to select the images they want as the displayed photos)  

M     

           

3.24  JMS interfaces   Priority  Response 

Page 54 of 84

3.24.1  The JMS system must include the capability of data import and export to a variety of sources; i.e. other databases, text files, images, etc.  

M    

3.24.2  The system must include the capability to interface with AFIS Fingerprint Machines such as Identix and Motorola Printtrack. 

M    

3.24.3  The system must include the capability to interface with the Appriss Victim’s notification system (VINE) to notify crime victims of the incarceration, pre‐release, and release of inmates incarcerated in the facility.  

M    

3.24.4  The system must include the capability to interface with the mobile data and records management systems.  

M    

3.24.5  The system must include the capability of interfacing with the existing commissary system (Keefe) to update an inmate’s trust fund balance and commissary item purchase listing.  

M    

3.24.6  The system must include the capability of sharing MNI information with CAD and RMS.  

M     

3.24.7   The system must include the capability to interface with the existing Inmate Phone system and exchange pertinent information such as phone balance, cell assignment, phone system PIN, and other important information. 

M    

3.24.8  The system must include the capability to interface with the Social Security Administration for the passing of inmate social security numbers.  

M    

3.24.9  The system must include a public facing internet portal to provide limited (agent defined) information regarding jail inmates.  

M   

           

3.25  JMS System Administration   Priority  Response 3.25.1  The JMS must provide the capability to configure the 

system as needed to meet agency requirements.  Administrative functions include: • JMS table maintenance • JMS configurations (e.g., parameters, defaults, etc.) • Security (e.g., user roles, jurisdiction, etc.) • Data management (e.g., data dictionary, archive and purge)  

M     

3.25.2  The system must allow for tiered access to information based on passwords and other authentications.  

M     

3.25.3  The system must utilize role‐based authentication.   M     3.25.4  The system should include the capability of utilizing other 

identification technologies, such as biometrics, ID card, security token, etc.  

H    

3.25.5  The system should include the capability to apply appropriate edits to all entered data to ensure data integrity and maintain activity logs and audit trails.  

H     

Page 55 of 84

3.25.6  The system must include the capability to log all actions, including security violations and attempted breeches, errors, changes, and updates.  These logs should be viewable and searchable by the system administrator(s).  

M     

3.25.7  The system should include the capability for the agency to define and maintain codes and associated literals (i.e. plain English translation) for as many data elements as possible.  

H    

3.25.8  The system should utilize authoritative code tables referenced in the Global Justice XML Document Model (GJXDM) and NCIC.  

H     

3.25.9  The system must include the capability to support expungement, sealing, and purging of whole records and partial records.  

M     

3.25.10  The system must include the capability to indicate why a record or data element has been restricted.  

H     

3.25.11  The system must include the capability of redacting sensitive or confidential information prior to release to the public or for use outside the agency.  

M     

3.25.12  The system must include the capability for a multi‐jurisdictional system, to change parameters for each participating agency.  

M     

3.25.13  The system must include the capability to provide alerts or flagging for any configuration changes that could affect system integrity to prevent inadvertent damage to the system.  

M     

3.26  Inmate Phone System   Priority  Response 3.26.1  The offeror must provide an interface with the existing 

inmate phone system. This interface must provide a mechanism for retrieving the inmates PIN number from within the Inmate Phone System.  The interface must be capable of tracking funds deposited from a kiosk and or web interface that is to be provided by the phone system vendor.   

M    

3.26.2  The interface must include the capability of transferring an inmate’s phone account balance to the inmate trust account upon inmate release so that they can issue a check for all monies owed. The interface must include the capability of closing the inmate’s phone account during the release process.  

H    

3.26.3  The interface must be real‐time as to show accurate and timely information.  

M    

3.26.4  The interface must include the capability of performing an emergency bypass of the phone interface in the event of connectivity loss between the two systems.  Upon restoration of the connection, the interface must include the capability of synchronizing the two systems.  

H    

Page 56 of 84

              Law Records Management System (RMS)        

4.1  General Requirements   Priority  Response 4.1.1  The following are general requirements of the RMS that 

should be available: • Single point of entry wherever possible • Maximum use of code tables • Ability to enter/query narrative(s)/text fields • Spell check and formatting capability on narrative/text fields • Validation upon data entry (i.e. logical edits, edit checks for all fields) • Entry into RMS should automatically submit data to external sources as defined by agency.  

M    

4.1.2  The system should receive, at a minimum, the following data elements from CAD upon closure of a CFS; location, incident number, case number (if assigned), disposition, priority of call, date and times applicable and units assigned to call.  

M    

4.1.3  The system should provide the capability to reuse and/or import data returned from external sources in order to eliminate redundant data entry where useful.  

H     

4.1.4  The system must include the capability to attach photographs, videos, audio recordings, documents and other files types to case reports.  

M     

           

4.2  Master Indices   Priority  Response 4.2.1  The RMS must have basic master indices that correlate 

and aggregate information in the following areas: 1) Persons 2) Locations 3) Property 4) Conveyances (vehicles) and 5) Organizations (including businesses and gangs  

M     

4.2.2  The system must give the user the option of determining whether there is a match based on existing data.  

M    

4.2.3  The system should support the validation and linking of addresses, commonplace names, and intersections.  

M    

4.2.4  The system must support query and retrieval by name, vehicle, location, organization and/or property to produce a comprehensive response displaying all related records in the system.  

M     

4.2.5  The system must have the ability to look up and import names and demographic data from external sources such as ACJIC’s LETS, the AOC’s NameMaster Index or DPS’s Driver’s License file.   

M   

           

4.3  Master Name Index   Priority  Response 

Page 57 of 84

4.3.1  The RMS must utilize a Master Name Index (MNI) function to link individual master name records to every event (e.g. Incident Report, Arrest Report, Field Interview, Accident Report, license and Permits, etc.) in which the individual was involved or associated.  Every person identified within these events is given a Master Name record.  In querying an individual MNI record, the user would also be able to view all associated records as well as the associates of that individual.  

M    

4.3.2  The system must have the capability to view possible matches for the name so that the user can make the matching decision.  

M    

4.3.3  The system should have the capability to search the name file by a variety of criteria such as Soundex searching, phonetic replacement, diminutive first names (e.g. James/Jim/Jimmy; Elizabeth/Beth/Betty; Jack/John) and other static demographic information such as age, sex and race.  

M    

4.3.4  The MNI must, at a minimum, in addition to names, capture and maintain the following information: • Physical Characteristics (e.g. current and past descriptors) • Race and Ethnicity • Location history (e.g. current and past) • Employer Information (e.g. current and past, to include occupation) • Telephone Numbers (e.g. current and past) • Known Associates • Multiple Alias Names/Monikers • Available Mug Shot(s) and photographs • Multiple Identification (e.g. current and past, to include: Social Security, Drivers Licenses, Local and County ID) • NCIC Fingerprint Classification • Modus Operandi (MO) • Single digit fingerprint 

M    

4.3.5  The system must provide the capability to permit a record or report to be unlinked from a MNI and re‐linked to another MNI record.  

M     

4.3.6  The system must provide the capability to allow two or more MNI records to be merged into one record.  Additionally, the system must provide the ability to “unmerge” names previously merged.  

M    

4.3.7   The system should also allow the user to inquire by agency identifier, SSN, address, height, weight, FBI number, State ID number, SMT, phone number, sex and race with the ability to use any number of the above elements in combination.  

M    

4.3.8  The system should provide the capability of searching descriptive data via range sets where height, weight, DOB and address fields are to be included in the search.  

M    

4.3.9  The system must provide the capability to inquire on addresses or names of individuals when only a portion of the name or address is known.  

M    

Page 58 of 84

4.3.10  The system must provide the capability to output the final results of a search to a file or printer.  

M    

           

4.4  Master Vehicle Index   Priority  Response 4.4.1  The RMS must utilize a master vehicle function to link 

vehicle data to an incident and/or master name.  This system should provide the agency with detailed, searchable information.  

M    

4.4.2  The RMS must provide the capability search on VIN, License Plate number, License Plate state, License Plate year, registered owner, Description (e.g. make, model, year, color, style, attributes).  The system should provide the capability to search on partial’s when available.  

M    

           

4.5  Master Property Index   Priority  Response 4.5.1  The RMS must utilize a master property function to link 

all property data entered into the system.  Each record should be catalogued by using unique property characteristics such as make, model, brand, description, distinguishing characteristics, serial number, etc. The system should utilize coding standards such as NCIC property codes during the entry of property records.  

M    

           

4.6  Initial Incident Report   Priority  Response 4.6.1  The RMS must include the capability to establish a 

primary officer with overall responsibility for completion of the report.  

M    

4.6.2  The system must provide the capability to allow for the primary officer to be transferred to other officers during the life of the report.  

M    

4.6.3  The RMS system incident report must contain sufficient information to comply with all ACJIC and national reporting requirements to include required fields for state approved incident forms.  

M     

4.6.4  The RMS system incident report must allow for an unlimited amount of free‐text fields of narrative information.  Free text narrative must be supported with spell‐check capability and HTML formatting 

M     

4.6.5  The RMS system must provide the capability to search narrative information for specific word(s) or phrase(s).  

M    

4.6.6  The Incident Report function should include the capability to perform entry/query capabilities into the NCIC system, ACJIC‘s LETS and Officer’s Desktop via the interface using current record information.  

H     

4.6.7  The system must have the ability to print an ACJIC approved Incident Report as well as electronically transfer data to ACJIC in their approved format. 

M   

Page 59 of 84

4.6.8  The system must have the ability to export an Incident Report to local data system such as the DA’s case Management System including all files attached to said report 

M   

           

4.7  Supplemental Report   Priority  Response 4.7.1  The RMS system must have the capability to query and 

retrieve the initial Incident Report and use it as a baseline document for the Supplemental Report.  

M    

4.7.2  The system must have the capability to submit/re‐submit the Supplemental Report (report with changes) to a supervisor electronically for review.  

M    

4.7.3  The system must have the capability for multiple officers to simultaneously create/add supplemental reports regarding the same event.  

M    

4.7.4  The system must have the capability to link all supplemental reports to the original report.  

M    

4.7.5  The system must include the capability to link all associated reports with a common report number, this may be the original report number or possibly the original report number with a suffix indicating supplement number.  

M    

4.7.6  The Supplemental Report function should include the capability to perform entry/query capabilities into the NCIC, ACJIC‘s LETS and Officer’s Desktop system via the interface using current record information.  

H    

           

4.8  Report Review   Priority  Response 4.8.1  The RMS must include the capability to lock incident 

reports from further edits at a point determined by the agency.  This does not preclude the viewing of the document by those with access permissions, but the ability to block access should be a capability.  

M     

4.8.2  The system must provide the capability for supervisors to receive, review and approve Incident Reports online, and to electronically respond to submitting officers and investigators regarding report quality and accuracy issues.  

M    

           

4.9  Investigative Case Management   Priority  Response 4.9.1   The RMS must include a Case Management function for 

incidents that require further investigation or follow‐up may be referred to an investigator before they are closed or submitted to the prosecutor for a charging decision. The assignment may be made to a patrol officer, or the department’s investigative unit.  The system should be able to assign case responsibility and task responsibility.  

M    

Page 60 of 84

4.9.2  The Case Management function should include the following functions, but not limited to, capturing and storing investigation data, requesting a warrant, conducting interviews and photo lineups, and producing supplemental reports. Investigators may also initiate criminal charges and obtain and execute both search and arrest warrants. The agency should also have the capability to define specific activities, including time allocation for each activity, so the system can generate alerts to both the assigned investigator and the supervisor.  

M    

4.9.3  The system must include the capability to allow supervisors to access and review unassigned cases.  

M    

4.9.4  The system must provide the capability for assignment of case responsibility to a primary investigator based on factors in include: nature of activity, type of follow‐up required, workload of available investigators and cases already assigned.  

M    

4.9.5  The system must include the capability of providing a solvability factor for each case.  

M    

4.9.6  The system must provide the capability to monitor cases to ensure that progress is being made.  Information used for monitoring includes, but not limited to: case status and activities, both pending and overdue, case workload, deadlines and requests for new investigations.  

M    

4.9.7  The system must include the capability to alert personnel/investigators electronically to the maximum extent possible when deadlines or alerts are triggered.  

M    

4.9.8  The system must provide the capability to view existing assignments, shift resources, and notify investigators of changes as required.  

M    

4.9.9  The system must provide the capability of reviewing case activity and automatically update case status of the investigation.  

M     

4.9.10  The system must include the capability to track additional assignments to other investigators made by the primary investigator.  

M    

4.9.11  The system must include the capability to integrate all pertinent modules into Case Management as needed to include creation of supplemental reports as defined in Incident Reporting, Warrant requests as defined in Warrants module, Evidence collection/documentation as defined in the Property and Evidence module, and Arrest processes as detailed in the Arrest module.  

M    

Page 61 of 84

4.9.12  The system should include the capability to support the development of charging recommendations and their electronic approval prior to submission to the prosecutor.  The system should provide the capability of capturing the charging decisions.  

M    

4.9.13  The system must provide the capability to capture case dispositions as a separate data element from case status.  

M    

4.9.14  The system must include the capability, based on disposition, to determine if any property/evidence may be eligible for release to the owner as defined in the Property and Evidence module.  

M    

4.9.15  The system should include the capability of capturing court dispositions (i.e. per person arrested and per charge) as the court case is completed.  

M    

4.9.16  The system should include the capability to reopen a case if necessary based on new evidence.  

M    

4.9.17   The Case Management function should include the capability to perform entry/query capabilities into the NCIC,  ACJIC‘s LETS and Officer’s Desktop  systems via the interface using current record information.  

H    

4.9.18  The Case Management function should include the following outputs/reports:  ‐ Cases not assigned for investigation or follow‐up    ‐ Case Summary    ‐ Case aging report (list of cases by age range, days, weeks, month, etc.)    ‐ Assigned cases (open cases by investigator and current status)    ‐ Cases pending assignment       • Activity follow‐up     • Alerts (e.g. overdue, case assignment, and task assignment)     • Pending activity (e.g. by investigator, case, and division)     • Case disposition (both law enforcement dispositions and court dispositions)  

H     

4.10  Property and Evidence Management   Priority  Response    Property refers to any tangible item that can be owned, 

consumed, or otherwise used (e.g., stolen or recovered items, currency, narcotics, vehicles, animals, and evidence of any form) that is to be tracked be the agency.  Law enforcement agencies can take custody of property during the investigation of cases and preserve it for possible use at trial.  

     

   A property custodian is responsible for receiving property for the agency. Information about the property, including its source, is collected and recorded in RMS.  

M     

Page 62 of 84

4.10.1  The RMS must include the capability of managing all property and property reports handled by the agency.  Property data must be readily available to users department‐wide.  

M    

4.10.2  The system must include the capability to accurately track and verify all property items and that evidentiary chain‐of‐command requirements are met.  

M    

4.10.3  The system must include the capability of tracking property that is impounded or stored in remote facilities.  

M    

4.10.4  The system must include the capability to link property and evidence to either a case file or report that describes the properties involvement.  

M    

4.10.5  The system must include the capability of recording, at a minimum, the location, value, case number, deputies ID number(s), chain of custody, description(s), quantity, and disposal date of items found, evidence, and property that is being safeguarded for an arrestee.  

M    

4.10.6  The system must include the capability of printing barcode labels to affix to the property as well as the barcode labels for each storage location 

M    

4.10.7  The system must include the capability to conduct an inventory of all property being tracked by the module.  

M    

4.10.8  The system must include the capability to search for partials (tags, owner, deputy, location, etc.).  

M    

4.10.9  The system must include the capability of documenting recovery information on stolen and found property as required by NCIC.  

M    

4.10.10  The system should have the capability to manage the disposition of property, with timed events to notify property custodians when property items can be released, destroyed, or sold.  Disposition history must be maintained for a specified period of time as specified by the agency.  

M    

4.10.11  The system must include the capability of producing an inventory list of any or all items in storage.  

M    

4.10.12  The system must include the capability of collecting data pertaining to the collection of property/evidence to include: date and time received, contributing and receiving officers, and location.  These data elements will be recorded for both inventory control and chain‐of‐custody purposes.  

M    

4.10.13  The system must provide the capability to check property against the MPI local database for matches against previously entered records.  

M    

Page 63 of 84

4.10.14  The system must include the capability to link property/evidence information with the case and all reports.  

M    

4.10.15  The system must include the capability to record/track all movement of property and evidence, regardless of how minor, to ensure an accurate log of activities is captured, and to ensure all policies and chain‐of‐custody rules are followed.  

M    

4.10.16  The system should include the capability of creating bar‐code labels for property/evidence.  The system should include the capability of using the bar‐coding system during inventory, check‐in, out and movement of the property.  

M     

4.10.17  The system must utilize timed events to notify the property custodian when property can be lawfully disposed of, using system messages or by providing lists of eligible property items.  

M    

4.10.18  The system must include the capability of collecting disposition information from courts/prosecutor and a means of review and grant or deny approval or disposition requests.  

M    

4.10.19  The system should include the capability to query individuals coming in to claim property (by name, OLN, etc.) in local/State/NCIC databases for wants/warrants, or to verify that they are authorized to possess a weapon. 

M    

4.10.20   The system must include the capability of performing a local/State/NCIC database query to determine if the property has been reported stolen prior to release of the property.  

M    

4.10.21  The system must include the capability to attach images to the property record.  

M    

4.10.22  The Property and Evidence function should include the following outputs/reports: • Chain of custody • Property summary report • Property item detail • Released property report • Property inventory report • Property disposition reports • Form letter to inform the property owner of the pending disposition of property with instructions for filing a claim • Case closed evidence report • Evidence location summary report • Audit report 

M    

           

4.11  Sex Offender Registry (SOR)   Priority  Response 

Page 64 of 84

4.11.1  The system must include the capability of tracking persons identified as sex offenders by capturing the following data elements at a minimum: • SOR # (locally generated) • Registration date • Demographics data: Name, Address, Aka’s, Nicknames  •  Race, Sex, DOB, POB  •  Height, Weight, Eye Color, Hair Color  •  Scars/Marks. Tattoo’s • Drivers License number and State of issuance • State ID # • FBI # • Phone Numbers (Home, Work, Cell) • Next of Kin Data: • Name, Relationship, Phone #, Address, etc. • Charge/Offense Data: • Charge/Statute #, Charge Description, Date of conviction  •  Age of victim, race of victim, Relationship to victim • Employer Data: • Business name, address, phone #, etc. • Vehicle Data: •  License Plate #, License State, License Year  •  Vehicle Identification Number (VIN) • Vehicle Year, make model, style, color  

M     

4.11.2  The system must include the capability of capturing photographs during the registration process and including them into the record/database.  

M    

4.11.3  The system must include the capability to display photographs associated to the SOR record.  

M    

4.11.4  The system must include the capability of generating notification letters for those individuals required to register.  

M    

  The system must include the capability of electronically submitting SOR data to the state’s repository 

M   

           

4.13  Warrants   Priority  Response    The Warrant module is designed to track warrants that 

the law enforcement agency may serve .  It also tracks and records any warrant‐related activity or status changes. The documentation of each activity includes the type of activity, contact with the subject (if any), the date of the activity, and the results of the activity.  

     

4.13.2  The system must include the capability of collecting and/or electronically receiving from the courts warrant data pertaining to persons charged with a crime, a person convicted of a crime but failed to appear for sentencing, a person owing a fine, or a person that the judge has ruled in contempt of court.  

M    

4.13.3  The warrant module must interact with the master name index, where if the individual has an active warrant, the necessary information will appear during a name search.  

M    

4.13.4  The Warrants module must include the capability of data entry, inquiry, printing and deletion (with appropriate user permissions) from the system.  

M    

Page 65 of 84

4.13.5  The system must include the capability to track the status of all warrants, and the activities associated with those warrants. The documentation of each activity includes: type of activity, contacts, date and time, and overall result of activity.  

M    

4.13.6  The system should include the capability to track the physical location of the warrant.  

M    

4.13.7  The system should include the capability to automatically update State/NCIC databases upon entry of a new warrant.  

M    

4.13.8  The system must include the capability to cancel a warrant and to record this into the system.  The system should have the capability to automatically update State/NCIC databases upon cancellation of a warrant.  

M    

4.13.9  The Warrant function should include the capability to perform entry/query capabilities into the NCIC system via the interface using current record information.  

M    

4.13.10  The Warrant function should include the following outputs/reports:  

 M    

   • Warrants issued (by type, etc.)           • Warrants served or cancelled (by type, deputy, etc.)           • Warrant summary based on varying search criteria          • Attempts to serve by date or date range           • Warrant aging report                   

4.14  Arrest   Priority  Response 4.14.1  The RMS must include the capability to document arrest 

information to include name, charge(s), or other probable cause rules or definitions.  

M    

4.14.2  The system must include the capability of using arrest data with other modules (i.e. Booking or Jail Management System)  

M    

4.14.3  The system must include the capability of printing and/or transmitting the arrest report per ACJIC standards after all to the data has been entered.  

M    

4.14.4  The system must include the capability to capture the method of identification that was used to confirm the person’s identity prior to being taken into custody.  

M     

4.14.5  The system must include the capability to capture the completion of other steps such as the issuing of the Miranda warning.  

H     

4.14.6  The system must include the capability to add multiple charges to an arrest without sending duplicate UCR information to ACJIC.  

M     

Page 66 of 84

4.14.7  The Arrest function should include the capability to perform entry/query capabilities into the NCIC, ACJIC‘s LETS and Officer’s Desktop systems via the interface using current record information.  

M    

4.14.8  The Arrest function should include the following outputs/reports: • Daily arrests, by date and time, and date range • Arrest report and/or affidavit • Arrests by location • Arrest log  

M    

           

4.16  Citation (Ticket Control)   Priority  Response 4.16.1  The RMS should include the capability to collect citation 

data, such as charge(s), violation(s), location, date and time, court date and officer(s) involved, court data and court disposition.  

M    

4.16.2  The system should utilize the master name index for all persons involved and link them to citations.  

M    

4.16.3  The system should include the capability of creating and printing a uniform citation form as provided by the Alabama Administrative Office of Courts in the field from a Mobile Data Terminal.  

M    

4.16.4  The system should include reporting capabilities on pending court dates, officer, location, vehicle, or person(s).  

M    

4.16.5  The system should include the capability of accepting ticket book number set ranges from the Alabama Administrative Office of Courts and assigning those numbers to an officer for use in the system.  

M    

4.16.6  The system should include the capability to enter/query warning citations.  

H     

4.16.7  The system should include the capability of querying local/State/NCIC databases for previous citations/warnings as well as outstanding warrants or alerts.  

M    

4.16.8  The system should include the capability to allow the officer to collect demographics information on persons involved in order to collect statistics for reporting on bias‐based policing evaluations.  

H     

4.16.9  The Citation function should include the following outputs/reports: • Citation and warning summary based on varying search criteria • Citation by location • Citations and warnings by demographic data • Citation audit (e.g., missing/voided numbers)  

M    

4.16.10  The system should include the capability to submit citation data to the Alabama Administrative Office of Courts in the form and means as required by that agency. 

M   

           

Page 67 of 84

4.17  Field Interview (Contact)   Priority  Response    A field interview record is created by a law enforcement 

officer based on the department's SOP.  Typically, this process is triggered by unusual or suspicious circumstances or any activity that is considered by the officer to be of interest but would not otherwise be documented in RMS.  The data in the Field interview module is available for analytical support. It also can be searched by investigators to develop leads.  

     

4.17.1  The RMS must include the capability to enter/track field interview information.  All names in this module must be entered via the master name index and linked to the appropriate record.  This module must include the capability of conducting searches by: location, officer, name, vehicle, or other associated information.  

M    

4.17.2  The system must include the capability to collect, at a minimum: location and time, event circumstances, name and descriptors of persons, identifying information on vehicles or other property.  

M    

4.17.3  The Field Interview function should include the following outputs/reports: • Field contact summary, based on varying search criteria  

M    

           

4.18  Pawn   Priority  Response 4.18.1  The RMS must include the capability to track items 

received by pawnshops to help identify and/or recover personal property that has been reported stolen. The system must include the capability to compare pawn data with lost or stolen property records.  

M    

4.18.2  The system must include the capability to automatically search the pawn database upon entry of new stolen records for possible matches.  

 M    

           

4.19  Civil Process   Priority  Response    Civil process describes the law enforcement agency 

responsibility to serve legal papers and execute legal processes as required to facilitate due process through the judicial system.  RMS modules should allow the data entry of papers to be served, as well as the capability to track the service of civil papers. These documents may include writs, summons, subpoenas, warrants, judgment orders, and civil protection orders. RMS will provide the ability to record the disposition of all actions required by the order, including court‐ordered eviction, the seizure of property, and collection of court‐ordered fees.  

     

Page 68 of 84

4.19.1  The RMS must include the capability to record/track all transactions affecting civil process. These transactions include at a minimum: date and time, user making changes, field(s) changed, and original values.  

M    

4.19.2  The system must include the capability for entry/tracking of service attempts and circumstance information (narrative).  

M     

4.19.3  The system must include the capability of entering civil paper types via codes identified by the users.   

M    

4.19.4   The system must include the capability of generating a certificate of service for submission to the court upon successful service or expiration of the order.  

H     

4.19.6  The system should include a scheduling capability for trial dates and other events which require the officer’s presence.  

M    

4.19.7  The system should include the capability of maintaining a complete chronological history of all legal documents handled.  

M    

4.19.8  The system should include the capability to support the following outputs: • Active civil papers (e.g. by age, jurisdiction, server, etc.) • Served/Returned civil papers • Civil Papers/Civil Paper Jacket • Expired papers • Notice generation • Letter generation • Civil Summary (e.g. paper summary, assignments, attempts to serve, etc.) • certificates of service  

M    

4.19.9  The system should have the ability to accept electronic data from the local court systems in regards to civil papers to be served including case number, person to be served, type of paper, and type of service.  

M   

           

4.20  Permits and Licenses   Priority  Response 4.20.1  The Permits and License module records and tracks the 

issuance of licenses by the agency.  Examples of devices and activities that require a license include, but are not limited to, electronic alarms and firearm ownership  

 M    

4.20.2  The system should include the capability to track statuses of licenses by application granting, denial, revocation, and expiration.  The change of status or an upcoming expiration date should generate appropriate alerts and notifications.  

M    

4.20.3  The system should include the capability of checking applicant names against the master name index.  

M    

4.20.4  The system should include the capability to track fees associated to permits and licensing.  

M    

4.20.5  The system should include the capability to document background investigation information developed to determine eligibility for license or permits.  

M    

Page 69 of 84

4.20.6  The system should include the capability to support the following outputs: • Permits and license applications granted based on varying search criteria • Permits and license applications denied with reason • False alarm responses, for billing purposes • Expiration notice  

M    

4.20.7  The system must be able to generate a ID card for pistol permit to include demographic data, photograph and other desired data.  

M   

4.20.8  The system must have the ability to override the fee associate with a permit and issue same without charge.  

M   

           

4.21  Equipment and Asset Management      Priority 4.21.1  The RMS must include the capability to 

enter/track/report on equipment issued or used by agency personnel.  The system must include the capability of recording the receipt of equipment, the source of the equipment, the issue of equipment to an individual or organizational element. 

M    

4.21.2  The system should provide the capability to track the equipment by use of bar‐coding, RFID or other means to expedite inventory control.  

M    

4.21.3  The system should include the capability to store photographs of the equipment.  

M    

4.21.4  The system must include the capability of generating reports to support physical inventory and audit, equipment in repair or disposal status, and location of all assets.  

M    

4.21.5  The system must include the capability of entering detailed descriptive characteristics data, associated identifiers, and any agency‐specific unique identifier(s), such as inventory control number.  

M    

4.21.6  The system must include the capability of generating reports for overdue, lost, stolen or destroyed equipment. 

M    

4.21.7  The system should include the capability to record information about equipment condition and maintenance.  Information collected includes: reason for repair, costs, date of repair, maintenance location, date expected back in service, date returned to service, and date of next scheduled maintenance.  

M    

4.21.8  The system should include the capability to support the following outputs: • Physical inventory report, based on varying search criteria (e.g., category, age, and location) • Physical inventory exception report • Check‐in/check‐out log • Equipment history  

M    

Page 70 of 84

  The offeror must have the capability of providing stock room support to inventory and control certain items; allow requisition of these items on‐line; record filling of requisitions; establish reorder points for certain items; alert supply manager of reorder needs; provide reports on items consumed, in stock and in transit.  

M   

           

4.22  Fleet Management   Priority  Response 4.22.1  The RMS must include the capability to capture the 

following: • Descriptive characteristics of the vehicle (e.g., color, make, model, etc.) • Date vehicle was deployed • Starting mileage • Identifiers (e.g., VIN, license number) • Any agency‐specific unique identifiers  

M    

4.22.2  The system should include the capability to document/track established service schedules, such as tune‐ups and oil changes.  

M    

4.22.3  The system should include the capability to enter/track historical issuance or assignment related events  

M    

4.22.4  The system should include the capability to record, the date, price, mileage, and amount of fuel for each fill‐up.  

M     

4.22.5  The RMS should include the capability to capture the following: • Fleet inventory • Maintenance schedule • Fleet repair log • Fluid consumption/cost • Vehicle repair cost • Fleet equipment list  

M    

           

4.23  Personnel   Priority  Response 4.23.1  The RMS must include the capability to collect basic 

information pertaining to all personnel working for the department. Information may include names, addresses, physical characteristics, assigned equipment, emergency contact information, education, special skills, classifications (e.g., sworn/non‐sworn) and rank histories. 

M     

4.23.2  The system should include the capability to create and maintain schedules for personnel (e.g., days on, days off, hours, etc.)  

M    

4.23.3  The system must include the capability to document officer assignment, shift and location. All changes to officer assignments must be tracked.  

M    

4.23.4  The system must include the capability of generating duty rosters for a particular time period (e.g., past, present, future) defined by the supervisor.  

M    

4.23.5  The system should include the capability to track training history and the classification process (this may be accomplished in another module, if so, annotate with appropriate information).  

M    

Page 71 of 84

4.23.6  The RMS should include the capability to capture the following: • Personnel summary, based on varying search criteria • Personnel detail •  Training and certification scheduling • Pending certification and skill expiration • Issued equipment based on varying search criteria • Health maintenance requirements for duty status  

M    

           

4.24  Crime Analysis   Priority  Response 4.24.1  The RMS must include the capability to collect, report, 

collate, analyze, and disseminate accurate and useful information that describes patterns, trends, problems, and potential suspects.  

M    

4.24.2  The system must include the capability to perform GIS based crime analysis 

M    

4.24.3  The system should include a variety of reporting functions allowing presentation of information in a variety of formats, such as bar graphs, pie charts, and line graphs.  

M    

4.24.4  The system must include the capability to aggregate data on the various indicators, such as: • Current period vs. previous period • Current period vs. historical average • Percentage of total crimes for period by: • a. Reporting districts • b. Areas/beats/zones • c. Teams/shifts • Percentage change from prior periods (i.e. trends)  

M    

4.24.5  The system must include the capability to conduct crime distribution analysis based on a number of criteria, including: • By area/beat, by reporting district (i.e. zip code) • By time, date and day of week • Frequency of occurrence • Citation • Crime/Incident Report number • Field Interview data • Search Warrant data • Vehicle Information • Type (e.g. residential, auto, business, etc.)  

M    

4.24.6  The system should include standardized reports, such as general offense activity, offense activity by day of week, offense activity by beat, etc.  

M    

4.24.7  The system should include a quality control process on incoming reports to ensure that data is correctly and completely entered.  

M    

4.24.8  The system should include the capability to support crime/suspect correlations to show relationship between a suspect and an offense.  The correlations may be made using any number of selected criteria in which unique and distinguishing characteristics, physical identifiers, modus operandi, and various other common traits of offenders are known.  

H     

4.24.9  The system must also support user defined reporting parameters in addition to all standardized reports.   

   

           

Page 72 of 84

4.25  RMS Reports   Priority  Response 4.25.1  The RMS must include the capability to generate 

standardized and user defined reports, aggregate reports, as well as the ability to produce ad‐hoc reports from RMS queries. These reports include, but not limited to: • Incident Reports • Accident/crash reports • Property/evidence reports • Citation reports • Field Interview reports • UCR/NIBRS/SCRIBRS reports • Case reports outstanding or overdue report • Case Management reports • Summary reports for warrants, citations, calls for service, accidents, employees  

M    

4.25.2  The system must include the capability of aggregating data from multiple modules, tables or fields as needed for reporting purposes.  

M    

4.25.3  The system must provide a tool that can be used to produce any number of ad‐hoc reports. Ad‐hoc reporting tools may be provided using a third‐party solution.  

M    

           

4.26  RMS System Administration   Priority  Response 4.26.1  The RMS system must provide the capability to configure 

the system as needed to meet agency requirements.  Administrative functions include: • RMS table maintenance • RMS configurations (e.g., parameters, defaults) • Security (e.g., user role, jurisdiction) • Data Management (e.g., data dictionary, archive and purge)  

M     

4.26.2  The system must include the capability to support expungement, sealing, and purging of whole records and partial records.  

M     

4.26.3  The system must include the capability of redacting sensitive or confidential information prior to release to the public or for use outside of the agency.  

M     

4.26.4  The system must include the capability to allow supervisor(s) the ability to configure or modify system variables, such as agency name, ORI, address, phone number, Sheriff's name, etc.  The administrator(s) should also include the capability to change parameters, such as juvenile default age, X/Y or state plane geographical coordinates, name match rules, etc.  

M     

4.26.5  The system must include the capability to allow administrators to define conditions under which an alert or notification is issued.  

M     

           

5.1  Mobile Data   Priority  Response 5.1.1  The offeror must have a feature‐rich Mobile Data module 

that includes, but is not limited to, some of the following features:  

     

5.1.1.1  Silent dispatching of calls from CAD  M     5.1.1.2  CAR to CAR and CAR to CAD communications  M     

Page 73 of 84

5.1.1.3  Must communicate via secure IP connection (ex: VPN) with secure approved encryption (128 bit) for CIC/NCIC messages.   

M     

  NCIC use and communications must conform to requirements and certification of ACJIC 

M   

5.1.1.4  Integrated Dispatching ‐ must have the capability to self‐dispatch and query an incident on the status screen for detailed incident information, including prior incidents for the location. 

M     

5.1.1.5  BOLO’s from Dispatch  M     5.1.1.6  Integrated AVL (ability to read NMEA GPS receiver and 

report position to map (1 second intervals) and position to CAD in configurable intervals (ex: 15 seconds). Additionally, individual unit must report position to CAD each time the unit has a status change. 

M     

5.1.1.7  Integrated Mapping ‐ must plot dispatch incidents (calls) and units (AVL) on the map in real‐time (unit positions at least every 1 minute with instant position changes reported on unit status changes) 

M     

5.1.1.8  Individual Position Tracking (GPS/AVL)  M     5.1.1.9  Query Persons: Each single officer query must spawn 

several predefined queries for data so the officer does not have to query each one. The system should also have the capability to pull back images of persons if they are available. 

M     

5.1.1.12  Integrated video with motion detect for officers to see out the front of the vehicle while looking at the computer screen. 

M     

5.1.1.13  Integrated mobile reporting  M     5.1.1.14  Configurable colors, including Night Color mode.  M     5.1.2  The Mobile Data system must be capable of performing 

on 19.2/96 kbs data transfer rate. Other communications networks such as CDMA or Broadband are other technologies that could be used for this system and would need to be compatible with the Offeror’s system.  

M     

5.1.3  Mobile Reporting must be integrated to the mobile software and includes, but is not limited to, the following features: 

     

5.1.3.2  Data population from mobile software query responses, driver license scans, and other forms in Mobile Reporting.

M     

5.1.3.2.1  Ability to access ACJIC’s LETS system from roadside  M   

5.1.3.3  Multiple user profiles on the same mobile computer with data kept separate. 

M     

5.1.3.4  Traffic Citations and Warnings data and from which must be compatible and approved by the Alabama Administrative Office of Courts or use of the approved Alabama eCitation process currently in place. 

M     

Page 74 of 84

5.1.3.5  Ability to receive (unique citation numbers) and transfer (Traffic Citation data) to AOC server conforming to their requirements.  

M   

5.1.3.12  Quick Violation Configuration that enables an officer to select from a list of common or frequently used violations thus reducing data entry time. 

M     

5.1.3.13  The mobile system must include the capability to allow administrators the ability to configure or modify system variables, such as printouts, edit rules, and data element sizes without code changes.  

M     

5.2  Automatic Vehicle Locator (AVL)  Priority  Response 5.2.1  The offeror must have the capability of providing AVL 

support; either directly or through an interfacing system. Please provide system requirements (hardware and software) that we will need in order to perform this function. 

M    

       

Third Party Software 

 Please describe all third party software required or recommended for the proposed solution, including database, operating systems, and report writers such as Crystal Reports or MS Reporting Services or any development software tools that will be needed in reporting, managing, and enhancing this solution.    

END OF SECTION 5  

READ, UNDERSTOOD WITHOUT EXCEPTIONS______YES ________NO*  *IF EXCEPTIONS ARE MADE, THEY MUST BE INCLUDED WITH PROPOSAL RESPONSE AND EXPLAINED FULLY.    

Page 75 of 84

 

SECTION 6 – Information Technology Environment  

Acceptable Hardware/Software Requirements: • Microsoft SQL Server 2005 or greater • Windows Server 2003 or greater • Crystal Reports or MS Reporting Services 

 

System Interfaces: Any proposed records management system should be able to fully  integrate with all existing and proposed technologies including, but not limited to:  

• ACJIC/NCIC/LETS • County of Mobile Jail Management System (MJMS) • County of Baldwin SO Portal for Public Information • Administrative Office of Courts • Social Security Administration • VINE • Pegasus • Sex offender tracking system • Keefe Commissary Services 

  Baldwin County Existing Technical Environment These are the major components of the existing Baldwin County technical environment to which the new solution will be required to integrate to and be compatible with: 

• Existing Microsoft Environment o Microsoft Windows Server 2003 o Microsoft IIS 6.0 o Microsoft SQL Server 2005 o Microsoft Sharepoint Server 2007 o Microsoft Exchange Server 2007 o Microsoft Windows XP Professional and Vista Business Edition o Microsoft I.E 6.0 and later o Microsoft Office 2003 and 2007 (including Word, Excel, Outlook, Powerpoint) 

• Existing IBM iseries which houses the current legacy applications and which will be replaced by the new solution: 

o  IBM iseries V4.5 with DB2/400 • Existing GIS environment 

o ESRI ArcGIS 9.2 Workstation o ESRI ArcGIS Server 9.2 with SDE databases in MS SQL 2005 

• Existing Network Environment o Cisco 4500 & 3750 Switches. 

Page 76 of 84

o Backbone at minimum Ethernet 1000. o Desktops are switched Ethernet 100/1000. o All major facilities interconnected by County owned dark fiber o  Two Internet Providers MetroE at 6mb each. 

•  Existing Cellular Carriers being utilized by Baldwin County (Voice and Data) o AT&T Wireless (GSM/GPRS/EDGE) o SouthernLINC Wireless(iDEN) 

    

END OF SECTION 6  

READ, UNDERSTOOD WITHOUT EXCEPTIONS______YES ________NO*  *IF EXCEPTIONS ARE MADE, THEY MUST BE INCLUDED WITH PROPOSAL RESPONSE AND EXPLAINED FULLY.   

Page 77 of 84

Non‐Collusion Affidavit  This must be completed and submitted with the Respondent’s proposal.   STATE OF ________________________ COUNTY OF ______________________    I, ________________________________________, representing_________________, upon oath depose and state that neither I, nor anyone in my organization, have employed any person outside of my organization to solicit or procure this contract.   

I  further depose and state  that neither  I, nor my organization, will make any payment or agreement of any compensation in connection with the procurement of this contract.    I further depose and state that there is no contract, agreement or arrangement, either oral or written, express or  implied,  contemplating  any division of  compensation  for  services  rendered under  this  contract, or participation therein, directly or indirectly, by any other person, firm, or corporation, except as defined in the proposal.    I  further  depose  and  state  that  neither  I,  nor  anyone  in my  organization,  has  either  directly  or  indirectly entered  into  any  agreement,  participated  in  any  collusion  or  otherwise  taken  any  action  in  restraint  of  free competitive bidding in connection with this contract.          Signed: ______________________________________          Title:    ______________________________________   Subscribed and sworn before me this _____day of _____________________, 2008           Notary:   ______________________________________ 

       

Page 78 of 84

 

Signature Page  

Baldwin County, or its Agent, shall have the right to waive any informality or irregularity. Under certain limited conditions, the Purchasing Department may apply a local preference option in determining the low bid for purchases of personal property. 

 All provisions of this Invitation are accepted by bidder as part of any contract or purchase resulting therefrom. 

 Please specify terms of payment below; otherwise, the terms will be 2% 10th Prox.  Date: _____Company Name: ___________________Web address: ______________  Terms: _____Address:____________________________City:_________________  County: _______________State:_____Zip:____________Phone :(___) __________  

If Baldwin County Business Licenses were issued to your company for the past twelve (12) months, please list numbers: _____________________________________________. 

 Vendor's Federal I.D. Number: ____________________________  I certify that ___________________________ has ___ has not ___ been in operation for one year at      (Company Name)                 (Check one) location(s) zoned for the type of business conducted by my company at the address stated above.  

______________________________ (Authorized Signature) 

 ______________________________ 

(Print Name)  

______________________________ (E‐Mail Address) 

  

 Toll Free Phone: __________________ Fax Number: ______________________  Return original bid in sealed envelope. Authorized signature of bidder must be in ink.  RFPs received in our office after the specified date and hour will not be considered.  INDICATE THE FOLLOWING ADDRESSES IF DIFFERENT FROM ABOVE:  1.  RFP AWARD NOTICE ADDRESS 

Page 79 of 84

 2.  PURCHASE ORDER ADDRESS  3. REMITTANCE ADDRESS (AND NAME IF DIFFERENT THAN ABOVE) 

Page 80 of 84

  

RFP Pricing Sheet (Bidder must use this form) 

Fill in all spaces     Software:   Computer Aided Dispatch: 

 Server Licensing            $_______________ 

  Client Licensing            $_______________  Record Management System: 

 Server Licensing            $_______________ 

  Client Licensing            $_______________  Jail Management System: 

 Server Licensing            $_______________ 

  Client Licensing            $_______________    Interfaces:   Inmate Phone System           $_______________   Inmate Commissary            $_______________   Alabama Bureau of Identification (ABI)      $_______________   Mobile Jail Management System         $_______________   Other__________________________      $_______________  Miscellaneous Items:    Data Conversion            $_______________   Reporting Tools            $_______________   Other (Please explain)           $_______________  Third Party Software:      (Descriptions__________)          $_______________   (Descriptions__________)          $_______________   (Descriptions__________)          $_______________      

Page 81 of 84

Services:  

Project Management            $_______________   Software Installation            $_______________   System Testing            $_______________   Training              $_______________   Other Services (please explain)        $_______________  System Maintenance, Warranty and Support:      Annual Software Maintenance        $_______________       Optional (3 year) warranty          $_______________         Performance Bond:  

Performance Bond            $_______________  

Optional Items:      (Descriptions__________)          $_______________             Total:                  $_______________ 

Page 82 of 84

 

Test Requirements   

At least sixty (60) days prior to commencement of the functional systems testing, the vendor shall submit for approval a detailed functional systems test plan based on general procedures described herein and that shall certify that the desired functionality has been delivered and meets all performance and load benchmarks.  The test plan shall document how each functional specification is to be tested, the method of testing and the anticipated results.  This documentation shall describe each scenario to be used for each functional specification.  The functional systems test shall be conducted jointly by BCSO designees and the vendor.  The functional systems test will:  

• Demonstrate every functional attribute of the software, including system software, operating system, utilities, interfaces, system administration procedures, all ancillary application program modules and all management information requirements. 

• Verify that all transactions with external systems are performing as specified. • Test and verify that real‐time recovery and switching to the backup system(s) operates as specified 

by the vendor. • Conduct full‐scale load benchmarks based on scenarios jointly developed with the vendor and BCSO. 

 The test results shall be included in the test report and BCSO shall have the option of conducting an independent test of all or any of the functional requirements, as specified in the response document.  Within fourteen (14) days after completion of functional systems testing, the vendor shall provide a written report to document completion of the test, and to indicate test results, problems, solutions and a schedule to implement such solutions.  When the operating system, software and interfaces have been delivered, installed and fully tested, including the functional systems test, and the system is ready for reliability testing, the vendor shall provide written certification to the BCSO that the installation phase of the contract has been fully completed and all requirements have been met.  The reliability test shall run for a period of thirty (30) days, twenty‐four (24) hours a day for a total of seven hundred (720) consecutive hours after the system is implemented in production mode.  This period shall be known as the performance period.  During the performance period, the agency shall have the option to run in parallel mode all subsystems that will be replaced by the system until the system if fully accepted.  The performance period shall begin on the date the vendor notifies BCSO that the system is ready for reliability testing.  If there is a system failure, as defined below, deficits shall be corrected and the reliability test and the performance period shall start over.  The following criteria constitute the standard of performance:  The system shall operate in conformance with the vendor’s technical specifications and functional descriptions, which shall satisfy the requirements of this proposal at a 100% accuracy level:  

• As quoted in the vendor’s proposal • As amended in the contract negotiations • As amended throughout the design and development stages • As formally documented 

 

Page 83 of 84

Operation use time and downtime shall be measured in hours and whole minutes.  System failure downtime is that period of time during which the scheduled productive workload, or simulated workload, being used reliability testing cannot be continued on the system due to failure of a software system component.  If simulated workload is being used for reliability testing, it shall be consistent with the data processing requirements set forth elsewhere in this contract.  Operational use time for performance testing for a system is the accumulated time during which the system is in actual operation and can be used by BCSO.  Downtime for each incident shall start from the time BCSO contacts the vendor’s designated representative at the prearranged contact point until the system(s) is back in proper operating condition.  The vendor shall provide continuous telephone coverage to permit BCSO to make such contact.  Any single failure or any series of failures of the system software that results in any of the following conditions shall be considered a system failure:  

• Complete shutdown of the system.  This includes failures that cause human intervention to maintain critical operations or to restart the operating system or server applications software to restore the system function. 

• If three (3) seconds is the specified response time, then an increase to nine (9) second or longer in five (5) transactions is a system failure. 

• An increase in any single transaction response time of four (4) times the response time proposed in the RFP, or longer.  For example, if three (3) seconds is the specified response time, then an increase to twelve (12) seconds in one (1) transaction is a system failure. 

 Loss of any of the basic system functions, such as the inability to transfer event messages between workstations, loss of the use of all communication functions, or the inability of the system to maintain folder status or event status on a current basis.  

• Repeated failure of the same function of equipment component is unacceptable even if it does not cause the conditions listed above for a system failure. 

• More than two incidents of downtime per week for the same problem. • Any critical entry or information control capability is not available at all active workstations positions. • The loss of the ability of the system to communicate (in either direction) with agency systems, 

interfaces, data sources.  During the reliability test period the system shall be fully available, in excess of seven hundred sixteen (716) hours, i.e., a total of four (4) hours or more of downtime (unavailable time) shall be considered system failure.  BCSO shall maintain appropriate daily records to satisfy the above requirements and shall notify the vendor in writing of the date of the first day after successful performance period.  The date of acceptance shall be the first day after the successful performance period.  If the system fails to meet the standard of performance after ninety (90) calendar days from the installation date or start of the performance period, whichever is later, BCSO may at its option request a rescission of the contract and request the immediate removal of the system.  The impact on prior payments of such a rescission shall be determined in contract negotiations. 

Page 84 of 84

               

End