rfcsp dpd alpr system ver1.0

THE CITY OF DALLAS, TEXAS

SPECIFICATIONS

REQUEST FOR COMPETITIVE SEALED PROPOSAL

BHZ1217

DPD MOBILE AND FIXED AUTOMATIC LICENSE PLATE RECOGNITION (ALPR) SYSTEM

RFCSP DPD ALPR System of 106

TABLE OF CONTENTSINTRODUCTION........................................................................................................3

2.0 BACKGROUND....................................................................................................3

3.0 SCOPE OF SERVICES........................................................................................3

4.0 PROPOSAL PROCESS.......................................................................................3

5.0 Proposer Qualifications.....................................................................................3

6.0 Statement of Work..............................................................................................3

7.0 Functional and Technical Requirements..........................................................3

8.0 Contract Terms and Conditions........................................................................3

9.0 Proposal Pricing.................................................................................................3

10.0 Required City Schedules and Forms..............................................................3

11.0 Proposer’s Hardware and Software Configuration........................................3

Appendix A – System Diagram................................................................................3

Appendix B – Proposal Pricing...............................................................................3

Appendix C – Reports..............................................................................................3

Appendix D – CIS IT Standards...............................................................................3

Appendix E - Product Vendor Questionnaire.........................................................3

Appendix F - Sensitive, Personal,Commercial Information and Legal Considerations

....................................................................................................................................3

Appendix G - Features Response Form..................................................................3


INTRODUCTIONThe purpose of this Request for Competitive Sealed Proposal (RFCSP) is to acquire a turnkey Automatic License Plate Recognition (ALPR) System for the City of Dallas which meets or exceeds all requirements of this document.

On November 2007, the Dallas Police Department (DPD) began using the “Platescan” Automated License Plate Reader (ALPR) equipped with a four camera system. The system was permanently installed in a marked 2006 Chevrolet Impala and deployed an average of 35 hours per week. The Unit was deployed by the Auto Theft Deployment Squad and was operated primarily in areas of high vehicle thefts and recoveries. The ALPR system has scanned approximately 97,000 license plates, detected approximately 200 stolen vehicles, located a vehicle with a “Felony” warrant, has been manually loaded with AMBER Alert information and has been used in attempting to locate a “Person in Danger.”

An ALPR system has proven to be a valuable crime detection and investigative tool for the Dallas Police Department.

The primary purposes of the ALPR system is for the identification of vehicles flagged as stolen vehicles, amber alerts vehicles, be on the lookout (BOLO) vehicles, wanted persons, missing persons, and sex offender persons.

The secondary and long term focus of the ALPR vehicles is to act as a random information gatherer which can populate the system with as many plates as possible to use in conjunction with (additional) back office software for analysis and intelligence efforts

The Dallas Police Department is seeking a new and improved mobile and fixed license plate recognition system to actively scan vehicle plates from all angles of a moving squad car or from fixed locations, and provide real time alerts to the officer operating the vehicle of suspicious plates that are scanned. There will be an initial implementation as described below. Further, the City wishes to establish a 5 year price agreement for the purchase of additional systems and services as needed and as funding allows.

The selected vendor must provide all equipment, materials, installation, software, setup, and training to provide a complete system.

Acquisition of cameras, software, professional services and installation/moving services will be via competitive bid.

The goals of the project are: • Improve DPD’s crime detection efforts by implementing a state of the art mobile and

fixed wireless technology ALPR system.• Installation of ALPR cameras that are to be deployed to both marked and unmarked

police vehicles. o Total of 18 “Vehicle” systems (breakdown below)

2 per substation = 14 vehicle systems 2 for Auto Theft unit: 1 vehicle system and 1 portable vehicle system ICAC Unit: 1 portable vehicle system


Gang Unit: 1 portable vehicle system• Installation of ALPR cameras that are to be deployed to FIXED locations

o Approximately 30-50 systemso Locations of Cameras are to be determined

• Exponentially improve DPD’s ability to recover stolen vehicles and identify amber alert vehicles, BOLO vehicles, missing persons, and sex offenders.

• Improve DPD’s intelligence gathering activities by providing back office software that allows for administration, data mining, reporting, data sharing, and intelligence gathering activities.

• Improve on the lessons learned from prior ALPR system, and to ensure new solution has the ability for database refreshes via wireless technology.

• Improve system performance by selecting a vendor to provide ongoing support and maintenance.

• Streamlined process for relocation of the fixed ALPR systems, as dictated by DPD’s surveillance needs.

The new ALPR System should meet at a minimum, all of the required specifications outlined in this document. The successful should provide added value and/or functionality above and beyond the minimum requirements.

The scope of this project includes the following:

1. The provision of a industry proven ALPR System that provides DPD’s the best tools for crime detection.

2. The selection, installation, configuration and testing of ALPR Software and Hardware that meets or exceeds the City of Dallas’ minimal requirements, interface, and reporting needs

3. The establishment of a production environment with backup/recovery capability, required to maintain and run the system.

4. Ordering, installation, configuration and testing of hardware that meets the City of Dallas standards, and is capable of supporting the proposed system and projected number of users.

5. The development and delivery of user, administrator and support personnel training and documentation

6. System Administration tools and report capabilities7. Identification of Proposer’s roles and responsibilities for project implementation and

post-implementation8. Identification of City roles and responsibilities for project implementation and post-

implementation

9. The Proposer will be responsible for delivery of onsite training to ensure that all necessary users are trained and certified in the use of this system.

The Provider will also be requested to provide the following warranty periods:A. 5 year on all system hardwareB. 5 year on system maintenance and supportC. 5 year on fixed/mobile installations

Lease vs. Purchase: RFCSP DPD ALPR System of 106

The City of Dallas will consider either a Lease or Purchase solution for the new ALPR System. The Vendor is encouraged to propose pricing for both leased or purchased solutions. All warranty periods noted above will be applicable for either a lease or purchase program.

The Successful Proposer should demonstrate the ability to provide, deliver, install, configure, and make operational the appropriate hardware and software solutions that adhere to the specifications outlined in this RFCSP.

The proposer should convey prior experience with providing the proposed solution in public or private organizations of comparable size and complexity.

Security Clearance: The selected vendor MUST be compliant with the requirements of the FBI’s Criminal Justice Information System (CJIS) regarding system and network security, and personnel backgrounds. Serious proposers will be required to sign a non-disclosure agreement (NDA) to be allowed to review those requirements. Any related materials provided to a proposer must be returned. Proposers unwilling to meet these requirements will not be considered.


2.0 BACKGROUND

DPD started using its ALPR system on November 2007.

Since 2008, the DPD has encountered significant equipment difficulties and operating system limitations. The ALPR system was unable to consistently distinguish the lettering on raised license plates, and capture license plates on moving vehicles. Almost all of the ALPR hits received since the inception of the program were from stationary vehicles and when the ALPR vehicle was being operated at a slow speed. Problems continued with security restrictions and the inability of the system to receive automated vehicles updates in real time.

Over the next year summer 2008 to summer 2009 the problems with the vehicles camera system, operating system, and data-bases continued to plague the program and limit the deployment of the equipment.

The ALPR equipped vehicle has since been decommissioned and is no longer in operation.

3.0 SCOPE OF SERVICES

3.1 General

The City reserves the right to award this contract in whole to one provider or in part to more than one, whichever is in the best interest of the City.

3.2 Minimum Qualifications

The selected Respondents will be required, at a minimum, to comply with the terms and conditions set forth in this RFCSP. The City has established the following Minimum Qualifications for the successful proposer of this project. Respondents who do not meet all of the Minimum Qualifications defined in this section will not be considered for award. The City, in its sole discretion, will determine if a Respondent meets the qualifications and will base the decision on the information included in the Respondent’s proposal submitted as well as through investigations conducted by City staff.

1. VENDOR and VENDOR’s employees and subcontractors shall maintain all certifications and licensing required by law to perform the services provided for under this Agreement including a Security Contractor license issued by the Texas Department of Public Safety pursuant to Texas Occupations Code Chapter 1702.

2. Minimum of three (3) years continuous experience, within the last seven (7) years, operating under the current business organization form, to include but not limited to ownership, management and/or operation of a similar business organization as described within this RFCSP.


3. References for existing implementations of at least 3 sites of comparable complexity and size.

4. Additionally, each Respondent will attach Statements of Financial Stability. The City prefers audited Financial Statements but is also willing to accept official justifiable data which substantiates historical financial stability.

5. Respondents must not be in default or arrearage under any previous or existing contract(s) with the City, the State or any other political subdivision of the State of Texas. The City reserves the right to disqualify any respondent, or any constituent entity of respondent, that has pending litigation, claims or debt with the City, or if such proposal includes a proposed subSuccessful Proposer, sub-lessee or supplier that has pending litigation, claims or debts which, in the City’s opinion, may adversely affect the ability of the parties to work efficiently and effectively under the contract contemplated by the RFCSP.

6. All contract employees utilized under this contract shall be employed directly by the Successful Proposer and/or identified subcontractors to which the contract is awarded. I. A fully qualified labor force shall be on board at the beginning of the contract and

maintained throughout the duration of this contract. All contract employees shall receive close and continuous first line supervision by the Successful Proposer.

II. Each employee of the Successful Proposer shall be a citizen of the United States of America, or an alien who has been lawfully admitted for permanent residence, as evidenced by Alien Registration Receipt Card or who presents other evidence from the US Bureau of Citizenship and Immigration Service that employment will not affect his or her immigration status. Acceptable evidence shall consist of a Birth Certificate and appropriate naturalization papers. Each contract employee shall be a minimum of 18 years of age. Vendors shall state the company’s procedures used to verify the legal status of contract employees and the authenticity of documents provided by employees. Vendors shall submit these procedures with their bids. Note: Violation of the specified age requirement and/or employment of an undocumented alien shall be just cause for contract termination. Any contract employee who violates this requirement will be removed from City contracts with CIS.

III. The Successful Proposer shall conduct a screening/background check on each contract employee prior to being assigned to work in any capacity at a City facility. The successful Proposer shall not assign any employees not in compliance with CJIS requirements based on background checks obtained from the Dallas County Clerk. The City reserves the right to instruct the successful Proposer to remove any contract employee upon review of the employment information form and/or findings of the screening process. The successful Proposer shall maintain and provide CIS a current contract employee list showing all contract employees assigned to work under this contract. The successful Proposer shall immediately report any changes to the contract employee listing and shall furnish information reflecting the changes as they occur. Successful Proposer agrees that all contract employees shall submit to and pass a police background investigation report, a drug test and/or a polygraph examination upon request. Note: The cost


associated with the required background check shall be the sole responsibility of the awarded vendor and not be passed on to potential contract employee or the City.

IV. The selected vendor will be required to carefully review and complete the Security Addendum (Appendix K).

The selected vendor should review the attached Texas CJIS Systems Access Policy. This policy details the effect of certain criminal activity as it relates to that person being allowed to work with the City of Dallas Communications and Information Services Department. Specific attention should be given to the column labeled ORIGINAL APPLICATION FOR ACCESS.

Vendor personnel assigned to work on the City of Dallas account must have previously completed a fingerprint background investigation by the Dallas Police Department. The background investigation MUST be successfully completed BEFORE a contractor employee will be allowed access to City of Dallas facilities. Note that a background investigation will be repeated annually to ensure that individuals remain compliant with Systems Access Policy.

Each vendor employee will be required to sign the Security Addendum Certification form and it will also need to be signed by a company representative.

1. The successful Proposer shall not, during the term of this contract sub lease nany portion of this contract.


4.0 PROPOSAL PROCESS

4.1 General The City of Dallas intends to enter into a contract with a qualified Proposer to provide a state-of-the-art ALPR System and required Interfaces that will serve the current and future needs of the City. Under the format of this RFCSP, the proposer will include the following: System License and Maintenance Hardware and Related Software and Maintenance Hardware & Software System Installation & Configuration Services Training Services Ongoing System Maintenance & Support

The City may not accept a proposal if: Proposals to this RFCSP are not received by the due date and time specified; Any document or item necessary to the proposal is incomplete, improperly executed,

indefinite, ambiguous, or missing; Additionally, factors such as, but not limited to, the following may also disqualify a

Proposer without further consideration:o Reason to believe collusion exists among the proposers;o Any attempt to improperly influence any member of the City Selection

Committee;o Substantial deviations from the City’s contracts;o A Proposer’s default under any type of agreement which resulted in the

termination of that agreement;o The Proposer has a history of filing frequent, excessive, merit-less or

fraudulent claims, against the City or against other vendors on a project of the City;

o Having defaulted on a previous contract, or performing poorly on a current contract;

o The proposer is in arrears on an existing contract or has failed to perform on a previous contract with the City of Dallas within the past five (5) years

o Lack of competence, skill, judgment, financial capability, integrity, reputation, reliability or responsibility to perform the work as revealed by the proposal, questionnaires, financial statement, performance history or other relevant information obtained by the City;

o The Proposer has a conflict of interest;o The Proposer is involved in any litigation against the City;o The Proposer has delinquent property taxes or owes the City money; ando Contact with any City employee concerning this procurement other than the

buyer or his designee, associated with this procurement.

Proposals shall be prepared and submitted in accordance with the provisions of these RFCSP instructions and specifications.


4.2 Sole Point of ContactThe City of Dallas has appointed a Buyer who will generally be the sole point of contact for any and all issues pertaining to this procurement and its process. The Buyer shall designate an alternate point of contact for specific purposes. Contacting any member of the City other than the Buyer or their designated representative could result in disqualification.

No oral explanation in regard to the meaning of the proposal specifications will be made and no oral instructions will be given before the award of the contract. Request from interested Proposers for additional information or interpretation of the information included in the specifications must be directed in writing to the City’s designated point of contact.

The following person is the specific point of contact for the City of Dallas:

Susan Dunne1500 Marilla, Room 3FNorthDallas, Texas 75201(214) 670-3413 Voice(214) 670-4793 [email protected]

4.3 Consequence of Submission of ProposalThe RFCSP does not commit the City to pay any costs incurred in the submission of a proposal or in making any necessary studies or designs for the preparation thereof, nor the purchase or contract for the services.

After acceptance of the successful proposal by the City, the City and the successful Proposer shall be obligated to enter into an agreement consistent with the proposal submitted.

Should the successful Proposer fail to execute the agreement, the City shall have the right to seek legal remedies against the Proposer, including damages, and shall have the right to award to another responsive Proposer.

4.4 Public Record: Proposals Become Property of CityResponses to this RFCSP become the exclusive property of the City. At such time as the Purchasing Department recommends a Proposer to the City Council, all proposals received in response to this RFCSP become a matter of public record and shall be regarded as public records, with the exception of those elements in each proposal which are defined by the Proposer as business or trade secrets and plainly marked as “Confidential,” Trade Secret,” or “Proprietary.” The City shall not in any way be liable or responsible for the disclosure of any such proposal or portions thereof, if they are not plainly marked as “Confidential,” Trade Secret,” or “Proprietary” or if disclosure is required under the Open Records Act. Although the Texas Open Records Act recognizes that certain confidential trade secret information shall be protected from disclosure, the City of Dallas may not be in a position to establish that the information that a Proposer submits is a trade secret. If a request is


made for information marked “Confidential,” “Trade Secret,” or “Proprietary”, the City will provide the Proposer who submitted the information with reasonable notice to allow the Proposer to seek protection from disclosure by a court of competent jurisdiction.

4.5 Schedule of EventsThe following proposal schedule outlines the RFCSP process. The City reserves the right to modify this schedule at its own discretion and convenience.

LATE PROPOSALS WILL NOT BE ACCEPTED.

RFCSP Advertising dates March 29 & April 5, 2012

Pre-Proposal Meeting Wednesday, April 11, 2012

Cut-off Date for Final Questions Wednesday, April 18, 2012 by 5PM

Proposals Due Wednesday, April 25, 2012 (No later than 2PM, CST)

Vendor Presentations (tentative) Week of May 7, 2012

4.6 Pre-Proposal MeetingFor the dissemination of information related to the RFCSP Proposer Demonstration and clarification of the intent of the RFCSP and other City requirements, a pre-proposal meeting may be held. This will be an optional meeting to be held on the date indicated above in 4.5 Schedule of Events. The meeting will be held at Dallas City Hall, 1500 Marilla St.3FS, Dallas, TX 75201 in the Purchasing Department - Conference Room.

4.7 Cut-off Date for Final QuestionsThe City understands that Proposers may have last minute questions, and we have built in accommodation for these questions into our plan. Proposers should keep in mind that the City will communicate these questions and their answers back to all Proposers. Accordingly, the City will not accept questions after the “Cut Off Date for Final Questions” as noted in Section 4.5 Schedule of Events in this document.

4.8 AddendaAny interpretation of or change in the RFCSP will be made by addendum. The City will not be responsible for any other explanations or interpretations. Only formal written addenda will bind the City of Dallas.

4.9 Proposal Format Instructions and GuidelinesThese instructions present the guidelines governing the format and content of the proposal and the approach to be used in its development and presentation. Only that information which is essential to an understanding and evaluation of the proposal should be submitted. No limitation on the content of the proposal is intended in these instructions and inclusion of any pertinent data or information is permitted.RFCSP DPD ALPR System of 106

All proposals and attachments shall be in English, complete, and free of ambiguities, alterations, and erasures. A duly authorized officer or agent of Proposer shall execute it. In the event of a conflict between words and numerals, the words shall prevail.

Proposals are to be typed and prepared on preferably both sides of 8-1/2" x 11" paper. The Proposer shall provide one (1) unbound single sided (original) copy of the complete proposal and two (2) left bound copies. Proposers shall also provide eight (8) electronic versions of their proposal in Microsoft Word format along with the specifications answered in the document. This should be provided on a flash drive or similar storage device that has been formatted to be read on any Microsoft based computer. The entire package must be sealed and addressed to

Susan Dunne, Buyer III City of Dallas 1500 Marilla Street - Room 3FN Dallas, Texas, 75201

Mark plainly on the outside of the package the number and title of the procurement to which the proposal is submitted. Indicate the opening time and date on the package. Failure to do this may cause the proposal to be misplaced and not considered.

The City requires comprehensive, item-by-item responses to every section within this RFCSP. To facilitate the review of the responses, Proposers shall follow the described proposal format. The intent of the proposal format is to expedite review and evaluation. It is not the intent of the City to constrain Proposers with regard to content, but to assure that the specific requirements set forth in this RFCSP are addressed in a uniform manner amenable to committee review. Although the specifications in the following sections represent the City of Dallas’ anticipated needs, there may be instances in which it is in the City’s best interest to permit exceptions to specifications and accept alternatives.

It is extremely important that Proposers make very clear where exception is taken to the specifications and how alternatives will be provided. Therefore, exceptions, conditions, or qualifications to the provisions of the City’s specifications should be clearly identified as such, together with the reasons, and inserted in the proposal. If the Proposer does not make it clear that an exception is taken, the City will assume the proposal is responding to and will meet the specifications as written.

The following describes, in more detail, what is required of a vendor’s proposal.

4.10 Required Proposal SectionsTo assure similarity in proposal presentation and allow the evaluation team to easily compare competing proposals, Proposers shall include, in the order described, the material indicated below. Proposers shall include additional sections or appendices if desired, to present additional pertinent information.


Letter of TransmittalThis letter should include the name and address of the proposing company as well as contact individuals within the company for technical, pricing, and contractual questions. A person authorized to bind the company should sign the letter.

Table of ContentsThe Table of Contents should be a standard listing of proposal section numbers, section titles, and page numbers. Include all numbered sections of the proposal, not just major sections.

Table of IllustrationsLabel all illustrations within each major proposal section as figures. Provide a sequential number within each section. The Table of Illustrations should contain figure numbers, titles, and page numbers.

Proposal Introductions and SummaryThis section should present an overall description of the project and the general approach taken in responding to this RFCSP. It should respond to the RFCSP goals and objectives or state the Proposer’s beliefs as to what the RFCSP goals and objectives should be, and the Proposer’s overall approach in achieving them. This section summarizes the highlights of the proposal and the Proposer’s capabilities and approach to successful accomplishment of the project.

Executive SummaryEach proposal should contain an executive summary that contains a brief description of the major contents of the proposal. Submit a description of the products and services proposed, covering the main features and benefits that distinguish it, in non-technical terms, within a maximum of five pages. This executive summary should be able to function as a stand-alone document, which effectively and succinctly summarizes the Proposer’s entire proposal. Do not exceed five pages or include any pricing.

Company OverviewThis section serves as an overview and introduction to your company. This should be an introduction to your company that will be answered with details in Section 5.0: Proposers Qualifications (below). At a minimum, this section should address the company's accomplishments in the ALPR System application areas that are the subject of this RFCSP.

Include a detailed description of products and services proposed to meet the City of Dallas’ system requirements. Provide as much detail as possible. The emphasis should be on how the existing products and services meet the City of Dallas’ system requirements.


Proposers QualificationsProposer should answer the questions in Section 5.0 . Questions are mandatory and are self-explanatory.

Statement of WorkProposers should answer and provide details to Section 5.0 of this RFCSP.

Functional and Technical MatrixSection 7.0 of this RFCSP contains the Functional and Technical Requirements that lists all of the requirements that the City of Dallas requires of a Proposer’s response. Proposers shall complete this matrix and submit it with their proposals as an Appendix to their proposals.

Contract Terms and ConditionsProposers should address and accept the City’s terms and conditions that have been prepared for this RFCSP. Proposers should be aware that all technical and operational specifications, equipment descriptions, and marketing materials submitted or made available by the Proposer in connection with this RFCSP would be incorporated, by reference, into the contract. The City of Dallas discourages the inclusion of general marketing materials unless they are used to provide specific information.

Proposal PricingProposer should submit proposal pricing with their proposal. All proposal pricing to the City of Dallas should be listed in this schedule (Appendix C), as this is a “fixed price” proposal. The schedule shoud include all solution costs, including baseline software costs, software maintenance costs and hardware costs.

Required City Schedules and FormsProposers should include copies of these forms as noted in Section 10.0 completed in their proposals. Original and copies of your proposal should be executed by a company official. Electronic copies of your proposal do not require signatures.

Proposer’s Hardware and Software ConfigurationProposers should address Section 11.0 of the RFCSP in this section of their proposal.

Appendices and AttachmentsDesignate appendices with letters, such as Appendix A, Appendix B, etc. Bind the appendices within the proposal. "Attachments" are separate documents that shall accompany the proposal. Clearly, identify each attachment with letters, such as Attachment (A, B, C, etc.), proposal title, Company name, proposal date, and the fact that it is submitted to the City of Dallas.


Documents Attached to ProposalsProposers shall attach documents that substantiate their proposal claims, such as an example system design document, an example training plan, etc. When referring to these Attachment documents within the proposal, the precise page number, section number, and section title of the referenced material should be specified. Include the same number of copies of the Attachments as the proposal, so that each evaluator has access to the referenced material. If such referenced information is short, it is a better practice to place it within the proposal where applicable.

Response to RFCSP Provisions Utilizing the Proposal Form, proposers should submit information in a concise and

responsive manner to each item beginning with Section 5.0 under the response format as set forth above. The City expects a response for every requirement and every question. Non-responsive or incomplete answers to information requests and/or City requirements may lead to disqualifying the Proposer’s submittal.

It is required that Proposers’ submissions be in the following format: Proposers shall present responses in the same sequence as presented in this RFCSP Responses shall follow the soliciting RFCSP paragraph. Succinctly state all

assumptions. Title any additional information as “Additional Information”, and include it at the end of each section’s response. Make sure that the section number being addressed is listed as well. Additional information regarding products or services that may be of value is welcome

Consecutively number pages either at the top or at the bottom of each page within each volume. Include additional "header" or "footer" information (such as company or section title) on each page if desired

If unable to comply with a stated requirement, or if taking exception to a requirement, the response should include a clear, unequivocal explanation. Explain in detail if a requirement is partially but not completely satisfied. Where possible, suggest remedies or counter proposals concerning each requirement. As appropriate, include such exceptions in the Terms and Conditions section of the proposal

Proposers should identify which items will require modifications to their base software Any modifications to databases or software should become part of the standard

product. Excluded from this requirement are the interfaces. Exceptions will not necessarily be disqualifying. Requirements not specifically

addressed in the proposal indicate tacit acknowledgment that the Proposer intends to meet or provide the requirement. A partially addressed requirement is tacit acknowledgment that the proposer will meet all other elements of the requirement(s)

As noted in Section 4.2 Sole Point of Contact, Proposers shall submit written questions to the City to further clarify any RFCSP item or requirement.

4.11 Proposal Effective PeriodProposals, including pricing, shall be valid for a minimum of one hundred fifty (150) days from the proposal opening date. If the evaluation process takes longer than this, the City may have to request an extension from some, or all, Proposers. Proposers should state the effective period in your proposal Section 8.0 Contract Terms and Conditions


4.12 Method of SelectionAll Proposals received by the above referenced due date will be reviewed by an Evaluation Committee as part of a two-step selection process. The first part of this process, proposal review, will result in the creation of a short list to consist of those solution providers that are to be invited to demonstrate their solution. The second part of this process is to evaluate and rank the proposer’s demonstration(s).

The City will initiate a Best and Final Offer process with the Proposers who are ranked highest. A recommendation for award of a Contract will be made to the proposer(s) that offer the solution that best meets the needs of the City for the ALPR System and Related Interfaces.

Evaluation Procedure and CriteriaThe Selection Committee will consist of City technical, management, and end-user personnel and others designated by the City. This committee will evaluate the proposals based on criteria listed below:

A. Price / Value to the City 30%

B. Capability, Credibility & Expertise of the Proposer 10%

C. Functional Match to City Requirements 20%

D. Technical Match to City Requirements 20%

E. Training and Ease of Use of the System 5%

F. Demonstrated inclusion and commitment to and understanding of the City’s Business Inclusion and Development (BID) Plan

15%

As part of the evaluation process, the City may interview Proposers regarding specific areas of their proposals as well as their references.

Basis of EvaluationIt is the Proposer’s responsibility to effectively communicate their qualifications, services and products to the City of Dallas by thoroughly responding to each requirement contained in this RFCSP.

The evaluation is based upon the following criteria:1. Related to Criteria A – Value to the City:

1.1. Value to the City as determined through pricing and benefits.1.2. Actual cost of various elements of the system as identified in the Proposal

Pricing document.

2. Related to Criteria B - Capability and Expertise of the Proposer:2.1. Satisfactory company background, references, and financial statements as well

as qualifications and experience in the delivery, installation, and maintenance of


ALPR System. Demonstrated successful experience on similar type projects in organizations the size and complexity of the City of Dallas will be favored.

2.2. Understanding of needs and the ability to offer alternatives and new approaches to the City of Dallas.

2.3. Leadership and sustainable position in the relevant technical market place.2.4. Quality of Project Plan and Project Team

3. Related to Criteria C - Functional Match to City Requirements:3.1. The proposed system’s ease of use regarding user interaction to provide for the

utmost in an officer’s safety, and integration of modules.3.2. Satisfactory performance of all scenarios in the Proposer Demonstrations.3.3. Proposer Demonstrations prove that the Proposer’s answers to Functional

Requirements are accurate.3.4. Clear and complete responses to the functional requirements contained in the

RFCSP.3.5. Ability to meet the long-term ALPR System functional needs of the City of

Dallas. 3.6. Vendor’s provision of long term supported interfaces and/or compatible

systems.

4. Related to Criteria D - Technical Match to City Requirements:4.1. Clear and complete responses to the technical requirements contained in the

RFCSP.4.2. Ability to meet the long-term ALPR System technical needs of the City of

Dallas. 4.3. Capability as a Proposer to provide a clearly understood hardware and software

configuration that satisfactorily meets the requirements of this RFCSP.4.4. True packaged ALPR System software demonstrated by:

4.4.1. Successful history of releases and bug fixes4.4.2. Support and maintenance4.4.3. Ease of upgrading to a new release4.4.4. Future plans for the proposed ALPR System software.

4.5. Quality of Implementation Plan

5. Related to Criteria E - Training and Ease of Use of the System5.1. Intuitive nature of the application5.2. Simple design of the system5.3. Quality and completeness of proposed training

6. Related to Criteria F - Minority Women and Business Enterprise Participation6.1.Demonstrated inclusion and commitment to and understanding of the City’s

Business Inclusion & Development (BID) Plan6.2.Adherence to applicable It is the policy of the City Council policies (see 3.13) of

Dallas to involve Minority and Women Owned Business Participation) Business Enterprises (M/WBE) to the greatest extent feasible on the City’s construction, procurement and professional services contracts.The information shall be submitted with the proposal and shall include:

Submission of an affirmative action plan/policy and the Ethnic Workforce form


Submission of documentation showing history of M/WBE utilization on previous contracts on the form provided.

Firm (s) Team make-up includes a significant number of diverse M/WBE firms in meaningful roles on the project.

(1) The name, address and telephone number of each M/WBE; (2) the description of the work to be performed by each M/WBE; and (3) the approximate dollar amount/percentage of the participation.

Evidence of acknowledgement of the City’s Business Inclusion And Development (BID) Plan, signed BID affidavit that demonstrates intent to comply with the policy and evidence of M/WBE inclusion to meet the BID goal for the project

Proposer Demonstration Information regarding the Proposer Demonstration has been included in Appendix C, D, E and F.

Acceptance or Rejection of ProposalsThe award of this Agreement shall be to the Proposer whose proposal most closely satisfies the needs of the City and is deemed most advantageous to the City. The City reserves the right to accept or reject any item or group(s) of items of a proposal. The City also reserves the right to waive any minor informality or irregularity in any proposal. Additionally, the City, for any reason, may decide not to award an Agreement resulting from this RFCSP.

The City reserves the right to select from multiple vendors and/or to purchase server or network components from existing contracts.

4.13 Business InclusionThe City of Dallas encourages Proposers to consider utilization of subcontractors and to provide Minority Business Enterprise and Women Business Enterprise (MBE/WBE) subcontractors with a full and fair opportunity to submit proposals to participate on this contract. Proposers are encouraged to use the suggested voluntary outreach efforts by contacting the Buyer to obtain the necessary forms and instructions.

All proposers will complete and submit the Business Inclusion and Development (BID)forms attached to this RFP. The BID packet also include an overview of the City's program and participation goals established by the Dallas City Council.

Help in preparing the forms may be obtained by contacting a member of the ResourceLink team – Rozalind Dickerson- 214-671-9814, or by sending an email to her at this address [email protected].

4.14 Proposer’s RepresentationEach Proposer should have a representative of the company that is legally authorized to bind the company contractually sign the proposal. Each Proposer shall give their full business address on the form provided in Section 10.1 Business Information Form. Proposal’s by partnerships shall be signed by one of the members or an authorized representative and shall include the partnership name. Proposals by corporations shall be signed with the name of the corporation followed by the signature and designation of the President, Secretary, or other person authorized to bind it in this proposal.


4.15 Best and Final OffersProposers will be accorded fair and equal treatment with respect to any opportunity for discussion and revision of proposals, and such revisions will be permitted after proposal submissions and prior to award for the purpose of obtaining best and final offers. In order to be considered, sealed best and final offers (marked “RFCSP Negotiations – Confidential” on every page) should be submitted in writing to the City Buyer at a time and date subsequently specified by the City. In addition, the Proposer should provide a written guarantee that there will be no additional cost to the City for equipment, materials and labor necessary to meet the intent of this specification and contract documents.

4.16 Contract NegotiationsContract negotiations between the Proposer and the City will be completed and contracts signed by the Proposer(s) prior to award by the City Council. The City requires the use of City standard contracts.

4.17 Execution of ContractThe City Council, by City resolution, shall authorize award of a contract to the successful Proposer(s) selected by the committee and designate the successful Proposer(s) as the City’s Contractor(s), subject to execution of the requisite contract documents by City and Contractor. All necessary contract documents are prepared by the City Attorney and tailored for this project. The City will require the contractor to sign the necessary documents, enter into the required contract with the City, provide the necessary certificate of insurance evidencing proof of insurance as required under the Contract Documents. No work shall commence until the contract documents are signed by both Parties. The successful Proposer shall have ten (10) days from the date the contract documents are delivered by the City to sign and return the contract documents to the City’s Buyer.

Be aware that no contract shall be binding on the City until it has been approved as to form by the City Attorney, and executed by the City Manager. Further, no contract for this project shall be signed by the City without the authorization of the Dallas City Council.

The City’s official representative during the procurement process is the City’s Buyer. After signing of the contract, the City will be represented by the City of Dallas Director of Communications and Information Services or his or her designated representative.

After the contract is signed, the City will not make allowance for any failures by the designated contractor to become aware of factors which affect the ability to provide the System for the costs explicitly included in the contract.

In any case, where there is a difference of opinion about the intent of the specifications and/or contract documents, the decision of the City of Dallas Director of Communications and Information Services shall be final.

4.18 Recommendation to City CouncilThe evaluation committee will recommend through the City Manager’s Office that award be made to the responsible Proposer(s) whose best and final offer is determined by the City to


be the most advantageous to the City, taking into consideration the relative importance of the evaluation factors.

4.19 Execution of Appropriate BondsThe designated proposer shall execute the Performance and Payment Bonds, (Bonding Requirements) prepared by the City Attorney and provide certificate of insurance evidencing proof of insurance. The designated proposer shall pay cost for such bonds. Proof of insurance must accompany the executed contract.

4.20 Failure to Execute Contract or BondsFailure to execute the contract or the required Payment and Performance Bonds within ten (10) days after the completed contract documents are delivered by the City shall entitle the City to rescind the award. In the event the City must be required to re-advertise because of the failure to execute the contract documents, the defaulting party shall not be eligible to submit a proposal.


5.0 Proposer Qualifications

5.1 Use of SubcontractorsVarious companies may wish to combine resources in responding to the RFCSP. In such instances, the City requires the designation of a primary Proposer, accountable for the entire turnkey system proposal including the contract that shall result there from.

Proposers should discuss the work any Subcontractors are to perform and provide references for previous projects where the Proposer/Subcontractor relationship was the same as that proposed for this project.

5.2 Experience Requirements and ReferencesTo qualify for this procurement, Proposers should have successfully implemented three or more presently operational ALPR Systems similar to those required in this RFCSP and for organizations that have environments similar in size and complexity to the City of Dallas.

Proposer should have been in business in it’s current form for a minimum of 3 years.

The City requires the following:

1. A complete list of all customers using the ALPR product proposed. Proposers shall also include customers of products that preceded their current offering if they feel the list has relevance to the City.

2. Proposers should state three new or recent sales of the proposed system with the following details of these references:a. Demonstrate recent relevant deployment and system implementation services in

ALPR System.b. References should be of similar size and complexity to the City of Dallas. Joint

ventures should provide similar references for each venture partner.c. Include the following information for each reference provided:

Agency name Population served (if applicable) Customer count Implementation Date (if not implemented, then planned date) Project Duration (excluding evaluation, selection and contracting time) Contact name Contact address Contact phone Contact E-mail address Products or systems installed Brief narrative description of the project

oLocal government experienceoProject management experienceoQuality assurance capabilitiesoSystems integration experienceoTechnical design capabilities


The City will utilize these references to validate the Proposer’s past performance and delivery capabilities.

5.3 Proposer ProfileThis section requests information regarding the Proposer’s experience with ALPR Systems. Provide a complete profile with the following required information:

Company name Contact person Telephone number Fax number Local address (that will manage this project) Headquarters address Number of years in operation Number of years in the business Number of years using the current name System Experience System Staff Experience

oNumber of staffoAverage years experience with current ALPR System offering

Research and Development (R&D) ProfileoNumber of staffoAverage years experience oExpenditures in past three fiscal years

Previous business name(s), if applicable Company Size Information for current fiscal year:

oAssetsoRevenuesoNet income after taxes

Company Size Information for previous fiscal year:oAssetsoRevenuesoNet income after taxes

Percent of total income attributable to the ALPR System proposed Percent of total income dedicated to the research and development in ALPR Systems Number of employees in each of the following categories:

oManagementoMarketing/SalesoAdministrationoCustomer SupportoR&DoConsulting SupportoTotal, all categories

For each subcontractor:oNameoOffice addressoResponsibilities


If not stated above, please state whether your company or subcontractors have a local Dallas office.

NOTE: Proposer background provided should apply to the company that is seeking the contract award, not Proposer’s parent, subsidiary, supplier, or agent.

5.4 Subcontractors to Prepare Proposer ProfileThe Proposer shall have each prospective Subcontractor listed above complete a Proposer Profile (Section 5.3 Proposer Profile), to be included immediately following the primary Proposer’s profile in the original and all copies of the proposal. Subcontractors should be properly delineated to allow the City to properly understand the skills of the various team members of a given proposal.

5.5 Failure to DiscloseFailure to include a complete disclosure of all aspects of Section 5.0 for all companies proposing as a team may result in the Proposer’s proposal being deemed non-responsive.

5.6 Litigation and DisputesProposer and/or their subcontractors should list any pending or current litigation and any disputes with government sectors in North America. This list should include any contract where the project has stopped due to dispute or has entered into binding arbitration.

6.0 Statement of Work

The following represents a general statement of work required of the selected Proposer. The City of Dallas intends to work with the selected proposer to develop a detailed statement of work with specified deliverables. Upon approval of the statement of work, it shall become a part of the contract. The selected Proposer is responsible for all of the following requirements, defined in subsequent sections of this RFCSP. Proposers should respond to this section with answers to each of the following paragraphs.

6.1 Solution ConsiderationsThe ALPR System can be delivered to the City in a variety of formats that Proposer’s may submit in their RFCSP response. The City requires that the proposed solution conform to the technical and functional requirements as stated in Section 7.0 of this RFCSP.

6.2 Vendor’s MethodologyProposers should provide overviews of the project management methodology and samples.


6.3 Project ApproachHistory demonstrates that at least 40 percent of major software-acquisition programs fail to deliver the value anticipated by the organizations that sponsor them. The City will place a strong emphasis on identifying a ALPR System Solution Provider that has a strong track record of implementation success.

The proposed solution should include a work plan that identifies the major activities and resources required for a successful implementation of the proposed System Solution. Complete implementation work efforts and associated costs for all solution components should be provided.

The City will provide the management, technical, and user resources to be involved in the project effort based on the Vendor’s installation approach and associated activities. While the City requirements shall oblige the Proposer to submit a solution that may utilize the products and/or services from several proposers, the City is only interested in an implementation approach where the primary Proposer serves as a single point of responsibility regarding the successful completion of this installation effort (e.g., becomes the Primary Proposer).

The Proposer should provide the following service components:

6.3.1 Project Duration and Implementation ApproachThe City anticipates that the project will take less than six (6) months to implement, not counting normal fleet replacement with installation of new in-car equipment. The vendors’ project duration estimate and implementation approach should be outlined.

6.3.2 Project OrganizationProposers should provide specifics of their proposed project organization inclusive of City staff.

A steering committee will be established and will be operational at the commencement of the project. The steering committee will meet as needed, and it will be staffed with management who can resolve high profile issues.

6.3.3 Named Key PersonsProposer should indicate staff/positions they are willing to name as key persons to the project. Indicate if the person will be full time on the project for the defined duration (e.g. complete project or certain phases).

6.3.4 Project ManagementProject management shall be the responsibility of the Primary Proposer. The City will provide the office space and basic project coordination with City staff as needed. The City will provide liaisons from the Business Units and the Communications and Information Services Department to work with the Proposer’s Project Manager.


The Proposer, along with the City, will be responsible for managing the overall implementation effort including activities conducted by other proposers and the City personnel. Activities will include, at a minimum: project supervision; work program administration and coordination activities; project timeline and expense management; project status reporting; change control management; communications; and quality management.

The Proposer is required to provide a weekly written project status report to the City, with formal reviews as needed to be conducted with City management. The reporting period begins with the award of contract and continues through final system acceptance testing by the City. In addition the proposer should also provide a method of sharing documents and information regarding this project with the project team and project stakeholders.

6.3.5 Project PlanThe Proposer shall describe the means and procedures to be employed to assure compliance with project schedule deadlines. Microsoft Project is the standard project schedule management tool used to assist the project manager in adhering to deadlines and tracking the progress of the project by primary task and all associated sub tasks. Included in the Proposer’s response shall be a detailed Project Plan that includes at a minimum the following level of detail:

A Schedule that includes a detailed listing of all tasks to be performed with begin and end dates and person responsible for each component of the Statement of Work including City tasks;

Clearly defined Proposer and City of Dallas responsibilities; Identification of task and subtask with all known relevant dependencies; and Critical milestones.

6.3.6 Project ToolsetsProposers should specify all value added toolsets that either accompanies the ALPR System Software product or that enhance the project efforts that will be delivered by the Proposer. Proposer should also specify whether the City will be allowed to use these toolsets both during and after the project and the basis upon which such usage is conveyed.

Proposers should be specific as to the toolsets they will employ in the project. As example:

Issues Management; Status Reporting; Collection of time against tasks and time remaining to completion; Tracking of task status; Scope Change Control; Risk Management; Data Mapping; Mapping of Requirements to Processes, to Testing, to Training; and Tracking of test problem reports through resolution.


6.3.7 Product Installation, Relactions and Configuration Installation will be the primary responsibility of the successful Proposer. The Proposer will be responsible for providing the ALPR System/Video software and for installing it on server(s). During the implementation process, the Proposer will prepare the ALPR System for operation and access by the project team.

The Proposer will be responsible for training the City core team on the base product (i.e. before changes to the product have applied), assist with set-up and configuration of the base product to accommodate the City’s specific environment, and continued training of the City core project team in order to achieve a level of product proficiency.

The City requires that the system be functional to meet the City’s requirements through configuration without system modification. Any modification required to meet the City’s requirements should be included in the base system maintained and offered for sale to relevant purchasers going forward.

Each Proposal should include a schedule that outlines the specific time frames for all steps to be completed. The schedule, at minimum, should specify implementation steps and testing and training on all system components.

6.3.8 Technical SupportLimited technical support will be provided by the City’s Department of Communications and Information Services (CIS) and its existing vendors providing services under contract. Proposers are responsible for the technical aspects of this project and should request the reasonable use of these resources to help fulfill the work efforts of the project. Proposer should specify in their proposal what City resources are needed and how long these resources will be needed.

Proposers will be responsible for installation and support of all third party software to be installed for the project. Proposer will also be responsible for installation and support of their ALPR System.

6.3.9 Change ManagementProposers should adopt an Information Technology Infrastructure Library (ITIL) Change Management program for the project. As training is specified separately in this section of the RFCSP, expected aspects of Change Management should include:

Communications Management; Process Change Management; Organizational Impact and Change Management; and Controls Management.

6.3.10 Product ReportingThe Proposer will provide the City with ad-hoc reporting capabilities that make it possible for managers or other non-technical business users to generate a variety of business-oriented reports.


6.3.11 Product Documentation The Proposer will be responsible for providing soft copies of system and user documentation for the ALPR System Solution in Microsoft Word editable format. Documentation will also include technical and operational documentation (e.g. test cases, test scripts, Requirements document, Run Book documentation, etc.). The Proposer will modify the documentation as required to reflect the City’s configuration and customization, if any. Further, the Proposer will grant the City employees the right to make as many copies of the provided documentation as needed. Lastly, the Proposer will provide one master and one copy of all documentation upgrades for all future system modifications and enhancements.

Proposer’s should include in the response to this RFCSP specifics of the documentation that will be delivered with the base ALPR System and documentation to be included as a part of the final implementation. Proposers should include samples of their proposed format for documentation.

6.3.12 Initial Product Training The Proposer will provide the training to the project team at the start of the project to enable City provided staff to assist with their assigned duties on the project.

6.3.13 Product InterfacesThe Proposer will assume responsibility for conducting a product integration test. This test will ensure that the delivered product operates according to specifications and does not adversely impact City operations.

6.3.14 Risk ManagementProposers should discuss their approach, such as ISO 31000.2009, to identifying, tracking, mitigating and reporting Risk in the project.

6.3.15 Quality Control and AssuranceProposers should specify the nature of their Quality Control (QC) Program as exercised as a part of the project plan. Details should be included such as:

Frequency; Duration; Who is interviewed; and Form of Reporting after Completion

The City will also exercise other forms of QC in addition to those performed by the Proposer. These other forms of QC may involve both internal and third party resources.

6.3.16 System Testing The Proposer will be responsible for conducting a comprehensive systems test using the City environment and its data. Though the proposer is responsible for most of the testing, verification testing by the City should be allowed to take place. The Proposer will develop a test plan outlining the testing approach, methods, data participants and other items required for successful product testing. Suggested testing includes:


Unit Testing Systems Test Integration Test (inclusive of all interfaces) Volume Test Technology Failover Tests (High Availability/Local Business Continuity) “Real World” testing of both Fixed and Mobile systems.

The Proposer will assume responsibility for conducting a ALPR System volume test of the system to meet City requirements to ensure performance and service levels are met. Proposers should specify any third party software required to perform these tests in their proposal as an additional cost. If third party software is not involved in the Volume Test, Proposers should explain the technology they will employ to achieve this test.

The Proposer will provide resources for product fixes resulting from errors identified during all of the testing processes. The Proposer must conduct testing to simulate real world environments and testing location, environments, and scenarious will need to be approved by DPD.

At a minimum, the proposed solution components should include information and costs associated with all aspects of on-going product support and maintenance activities. The City expects the Proposer to provide on-going support that includes, but is not limited to, Technical Support, product fixes, product enhancements, procedural help, access to an active user group or client conference and a schedule of regular product releases.

6.3.17 End User Training The City will require that 25 user trainers be trained. For purpose of any software licenses (3rd party or otherwise), Proposers should provide cost for 900 concurrent End User sessions in a production environment at various City locations. It is expected that as many as 4,000 users will be given access to the system within the first three (3) years of implementation.

The City desires to utilize a Train-the-Trainer approach to train its staff on the ALPR System. During the phases leading up to Integration Testing, it is expected that training curriculum will be developed and Train the Trainer activities occur. It is expected that the Proposer will lead these efforts and will provision the materials necessary to accomplish training. Training will be provided locally (in Dallas) in a training facility(s) provided by the City. Proposers should plan to train 12 staff members per classroom. The City will provide the following training resources for the ALPR System training:

Dedicated training room equipped with an adequate number of desks and chairs; City staff members to be trainers; Work stations that are properly configured to support the system training; All network connections for the above work stations; Telephone with a direct number; Projector connected to a PC for the instructor(s); Projection screen; and Large white board with pens.


Proposers should be specific as to their training plan and training requirements and provide samples of the materials to be delivered as a part of the project.

6.3.18 Backup and Restore Plan and TestingProposers should provide a backup process that does not impact the performance of the system or the availability of on-line data. Proposer’s project plan should incorporate the testing of this plan.

6.3.19 Disaster Recovery Plan and TestingThe environment of ALPR System and its ongoing operation is very critical to City operations. Accordingly, Proposers should specify a full Disaster Recovery (DR) Plan. This plan should include the following:

DR Plan Planned DR Hardware and Software Environment DR Testing

Proposers should meet the following guidelines in the event of a full loss of the data/computing environment:

Recovery of all data within 72 hours; and Recovery of computing environment and support to end users within 72 hours.

Recovery procedures should be documented and included in training.

6.3.20 Acceptance TestThe City will conduct an Acceptance Test of the ALPR System after the implementation. This test will be based upon testing scenarios established by the City. Final System Acceptance of the ALPR System will be conducted after implementation of the production system.

6.3.21 Final System AcceptanceThe project is not considered complete, and the Proposer will not be released from their project obligations, until this final acceptance test is conducted and the City formally accepts the system. This test will occur after a reasonable period of production usage of the ALPR System, but no sooner than four (4) weeks after implementation. Production volume performance will be a part of this acceptance.

6.3.22 Production Cut-over PlanProposers should discuss their companies approach to Production Cut-over planning and management. A sample of the plan, staffing and the reporting and measurement of the plan is required.

6.3.23 Warranty, Maintenance, and SupportProposers should specify in detail, all warranties associated with hardware and software. The City requires the following warranties from the date of final acceptance.

ALPR System Software and associated software, sixty (60) months from date of acceptance.


Servers and associated software, sixty (60) months from date of final system acceptance. Server and associated warranty specifications are provided in Section 9.4 Options Pricing.

All Proposers should include a method to support warranty claims for the sixty (60) month warranty period.

6.3.24 Post Implementation SupportAll Proposers should bid a Post Implementation Maintenance & Support Agreement for a period of 1 month after implementation under the proposed project plan. Proposers should anticipate the need for this staffing to start at implementation. All proposers should bid a staff complement of two (2) part time consultants on site to perform this function.

6.4 Implementation Resources

Proposers should specify staff to be supplied to this project based upon a start date as referenced in Section 5.0. Staffing specified should be the staffing for the first phases of the proposed project plan. Resumes of proposed staff should be included in the appendices to the proposal. The City is keenly interested in the staff members supplied to this project and their skill sets. Part of the City’s evaluation criteria includes proposed staff and their skill sets. Accordingly, please complete a replication of the following table as a part of the proposal:

Staff Member Name

Years of Employment with Proposer’s Company

Years of Experience in all ALPR System (any vendor)

Years of Experience in Proposed ALPR System

Current Project and Expected Roll-off Date

In order to clarify the above, Proposer or its subcontractor data for the above table should include:

Staff member name Staff member’s years of employment with the Proposers or subcontractor’s

company. Years of experience in all ALPR System. Years of experience in the Proposed ALPR System. This should be specific

experience with only the proposed system and not earlier products from the same Vendor.

Current Project and Expected Roll-off date. Please indicate the staff member’s current project and the date you expect them to roll-off and be available to the ALPR System Project.


In a separate part of the proposal, please indicate which staff and positions will be full time for the duration of the project or for specific phases of the project.

7.0 Functional and Technical Requirements

7.1 Minimum Technical Requirements

7.1.1 Commercial AcceptanceALPR System solutions will be evaluated based on their business merit, but only if a Proposer can demonstrate that the underlying computing applications, tools, database and operating systems used to deliver the ALPR System has wide commercial acceptance and is working well for a large installed base of clients. Proposers should indicate any other technical features not covered in Section 6.1 Solution Considerations to help the City assess the merit of your proposal. Proposers should use an appendix for this information.


7.1.2 Data Base Environment The City requires that ALPR System Solution Proposers propose a system that utilizes Microsoft SQL Server 2005/2008 or better.

The City expects that the underlying database provide a mechanism by which information can be accessed, reported on, or simply queried. As a result, the proposed solution should provide a facility to easily support user queries and reporting.

7.1.3 Client User InterfaceThe City desires a system User Interface which is flexible, intuitive and provide extremely rapid access to information. User input should be supported by drop down boxes for standard information and relevant edit checks.

7.1.4 Regular Releases The City requires the Provider to support the solution with regular releases and will examine the Vendor’s history of providing product enhancements. Proposers should provide information about new planned releases and how these releases will affect the City.

Proposer should describe the methods by which they issue fixes and how these are applied to the ALPR System Solution. The City is looking for a system that is released or updated with minimal bugs or fixes required.

Please describe the method(s) by which the functional/technical upgrades of new releases are determined. Please describe:

Method used to identify functional and technical enhancements; Contents or functionality included in releases since Jan 1, 20011; Prioritization method; and Client user involvement in above.

Of the releases since January 1, 2011, please specify the percentage of each release that was related to client user requests versus other sources such as your marketing or sales groups.

7.1.5 Prospective TechnologyProposers should indicate any platform or technology changes they are anticipating in future releases of the ALPR System Solution during the next three years. This statement should also include the usage of third party software as a part of the ALPR System Solution.

7.1.6 Ad-Hoc ReportingProposers should indicate the method for City employees to execute ad-hoc inquiries of the data. Ad-hoc inquiries should not interrupt or negatively impact system performance or normal business operations. The City should have access to the


system, with a data dictionary, for development of an ad hoc quiries and reports using a standard reporting tool such as Crystal Enterprise 10.

7.1.7 Superior Technical SupportThe City is seeking a Proposer to deliver high-quality and readily available support services. Proposers should guarantee the delivery of technical support via clearly defined Service Level Agreements that are also supported by financial credits should the Proposer fail to deliver service at agreed-upon levels. These services should be priced as part of the Proposer’s offering.

7.1.8 Adequate Hardware Configuration for Requirements The Proposer should respond with the correct sizing of all hardware and software associated with the project. The proposed ALPR System Solution will be adequate to support existing and anticipated (over a five year useful life) processing requirements and response times.

The Proposer should identify all server hardware, software and services required to successfully implement and operate the proposed solution component.

Note that although specific make and model hardware has been referenced in this document it is for illustrative purposes only and it is not intended to be restrictive. Equivalent makes and models that are equal to or better than those listed in the specification will be evaluated.

Propose all hardware requirements and provide itemized pricing for all equipment and installation services. The City reserves the right to acquire and install any equipment under separate previously City established price agreements.

7.1.9 Client Environment & ConnectivityThe Proposer should identify and include in its price all client hardware and software configurations required to implement and operate the proposed ALPR System Solution in Section 9.0 Proposal Pricing.

7.1.10 Minimal Modifications The City is interested in pursuing only proven COTS (commercially available off the shelf) ALPR System Solutions that require minimal modifications, if any. If modifications are required, the Proposer must commit to including those modifications as a part of the base system going forward.

The Proposer should identify all product modules that are required to support the proposed solution and describe the extent of the modifications that the Proposer will undertake to deliver this product.

Any proposed modifications should become standard to your product.

7.1.11 Continuous SupportProposers should describe their business recovery plan and disaster recovery plan as it relates to their customer support functions.


7.1.12 Minimum Software SupportThe City requires the Proposer to provide software support between the hours of 8:15 AM and 5:15 PM, CT, Monday thru Friday. This support should consist of a dedicated on-call staff or center where problems can be reported and immediate help is available. Call centers should be located in the continental United States; offshore call centers will not be acceptable. The on-call support staff should respond within 1 hour and access the system within 2 hours. Fixes should occur within one (1) business day, excluding City Holidays or furlough days.

7.1.13 ALPR System Software User GroupPlease describe the third-party or vendor supported User Group for the proposed ALPR System Solution. Proposers should describe the following:

Purpose; Frequency and duration of meeting; Is the meeting combined with other products; and Location.

7.1.14 Right to Reproduce DocumentationCity shall have the right to reproduce at no charge, but at City's cost for reproduction, for use by City employees, any documentation for software owned by the Proposer or any of its subcontractors or any third party vendors that is used to perform services under the contract. If the Proposer or any of its subcontractor, or third party vendors are legally prohibited from granting such rights to the City with respect to any particular software that will be used by the Proposer or any of its subcontractors to perform services under the contract, the Proposer's proposal shall so state in express terms.

7.1.15 Software VirusesIt is critical to the overall success of the Project that no software provided by the Proposer to the City during the term of this contract contains or introduces a software virus, that results in contamination or damage to the City’s equipment or its network, personal computing or other operating environments hardware including the hardware or software of any third party authorized to be connected to the City's computing environments, or the unauthorized disclosure of the City’s data.

The Proposer shall take all precautions that are reasonable, customary, and commercially practical to avoid providing the City with any software that contains or introduces a virus.

The City uses McAFEE Virus protection as a standard. Proposers should indicate systems that do not have a proven track record of using McAFEE.


7.2 Functional RequirementsProposers should complete all of the Functional Requirements in the attached Features Response Form and return it in this format. All rows of the form should be answered as completely as possible.

7.2.1 Interfaces The project will handle interfaces from the ALPR System side and the City will

handle the other side of the interface. Specifically hours required to modify the City’s 3rd party applications to support interface requirements are the responsibility of the City and should not be included in the estimates provided by the Proposer.

The Proposer should describe their systems abitily to interface with ONSSI (the City’s standard software for video capture and storage) and MDC laptops in police vehicles.

The City runs TriTech Software Systems VisiNet Mobile and Intergraph’s inPursuit RMS software on all DPD MDCs. The Proposer must demonstrate the systems ability to interface with DPD’s RMS/CAD applications.

7.2.2 Proposer Response ColumnProposer’s response to the column titled “Proposer Response” should be utilized to indicate how the proposed ALPR System Solution meets these requirements. Proposers should indicate for each requirement one of the following answers:

10 - Yes, base system fully complies, no additional cost. 8 - Yes, next release of base system will fully comply, no additional cost,

proposer should state timing of commercially available, non-beta release of this functionality.

4 - Base system partially complies – proposer has suggested the Base System will work. If not, customizations/modifications possible to fully comply, at additional cost.

2 - Data Query will be used to comply. Data Model fully supports required function. Data Query provided, at additional cost.

1 - Programming Customizations/Modifications to base system required to comply, at additional cost. (Note: the City requires that any modifications be incorporated into the base software product.)

0 - base system does not comply, customizations/modifications not possible or such customizations will not / can not be incorporated in the base software product.

7.2.3 Additional Cost ColumnProposers should include the Additional Cost for any given requirement of the spreadsheet where your Proposer Response is 4, 2 or 1. This amount should be included in the column titled “Additional Cost”. Proposers should make this number complete in terms of the total effect to the project. Specifically, if the requirement were removed from scope, the reduction in cost would reflect the reduction of all phases of the project (e.g. design, program, unit test, system test).


7.2.4 Relationship of RequirementsIn some situations, Proposers should elect to indicate that a relationship of the requirements answer as 4, 2, or 1 exist and that the City should consider all or none of these requirements should the City elect to reduce the scope. Proposers should indicate in the Comments Column of the spreadsheet any relationships of this nature.

7.2.5 Comments ColumnA column has been provided entitled “Comments”. Proposers are encouraged to further clarify their response with comments specific to how their proposed ALPR System will meet the requirement. Proposers should not provide commentary that nullifies the requirement, or changes the definition of the requirement. Should further definition of any given requirement be needed, please send a question to the designated Point of Contact in Procurement (see Section 4.2 Sole Point of Contact).

7.3 Non-Functional Requirements List

Non-functional requirements captures conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution should remain effective or qualities that the system should have. They are also known as quality or supplementary requirements. They do not have a documented use case.

The following list represents the non-functional business requirements for the ALPR System.

Req # Requirement7.3.1 Usability

7.3.1.1The fixed system ALPRs must be able to quickly be relocated if necessary.

7.3.1.2The mobile system ALPRs must be able to quickly be relocated to other vehicles if necessary.

7.3.1.3 System configuration must be flexible and easily scalable.

7.3.2 Reliability

7.3.2.1

The system will have the ability to will provide a minimum guaranteed service availability rate (uptime rate) of at least 99.9 percent.

7.3.2.2The system will Operate continuously: 24 hours a day 365 days a year

7.3.3 Performance

7.3.3.1

The ALPR system should be able to accurately read, compare, and record license plates with an accuracy rate of 85 % for both fixed/mobile systems.

7.3.3.2The ALPR system should not have any limitations on the # of


Req # Requirementplates that may be read and processed through the entire lifespan of the system.

7.3.3.3

For interactive connections (for plate updates) for the MDCs, the City uses cellular broadband connectivity using NetMotion. The ALPR system must be able to connect & communicate with this technology.

7.3.4 Supportability

7.3.4.1

The system must enable staff to add new hardware, software upgrades, and or maintenance without disruption of service 7 days a week / 24 hours a day.

7.3.5 Security

7.3.5.1The system must have the ability to meet or exceed industry standard security requirements.

7.3.5.2The system must comply with all Criminal Justice Information Standards (CJIS) requirements.

7.3.5.3The system must utilize encryption technology to secure video feeds.

7.3.5.4The system must meet minimum FIPS and NIST security standards.

7.3.5.5The system must be active directory compliant as to user authentication.

7.3.5.6System should be secure to prevent unauthorized access and provide layers of access security for users.

7.3.6 Maintenance/Serviceability

7.3.6.1The system must be easily serviceable for repairs and maintenance.

7.3.6.2 The Vendor must provide maintenance coverage plan including:

7.3.6.3Routine services provided on a periodic basis such as onsite maintenance and cleaning.

7.3.6.4Routine and as needed lens cleaning from condensation, rain, ice, dust, dirt or any other obstruction.

7.3.6.5 Emergency response services including guaranteed response time7.3.6.6 Hours and days of coverage

7.3.6.7Equipment replacement procedures, including onsite or depot parts repair and replacement

7.3.6.8

Response time for each service call, including:a. System Outageb. Network control center outagec. Camera network outage impacting 25% of cameras

7.3.6.9 Escalation procedure from first call to highest level respondent


Req # Requirement

7.3.6.10Detailed procedure showing knowledgeable first-time response to service calls

7.3.6.11

Detailed breakdown of all maintenance costs for all equipment, software and services beginning at the end of the warranty period and extending through year five.

7.3.6.12 Any Optional Maintenance service plans.7.3.7 Support

7.3.7.1The Vendor shall detail the technical and operational support that will be provided:

7.3.7.2Telephone support (e.g., include toll-free support hotline, hours of operation, availability of 24 x 7 hotline, etc.).

7.3.7.3 Special plans defining “levels” of support (e.g., tier 1, tier 2, etc.).

7.3.7.4Delivery method of future upgrades and product enhancements including historical frequency of upgrades by module.

7.3.7.5 Problem reporting and resolution procedures.7.3.7.6 Bug fixes and patches.7.3.7.7 Support provided for third-party solutions.

7.3.7.8Other support (e.g., on-site, remote Web site access to patches, fixes and knowledge base).

7.3.8 Texas Occupational Code

7.3.8.1

The Vendor that will access the City’s network or install equipment must be appropriately licensed and certified under Texas Occupational Code 1702 as a Security Company and to maintain that license / certification for the life of the contract.

7.4 Control Requirements List

The following list represents the control requirements for the system. Control requirements include Regulatory / Legal, Financial control, and City of Dallas Policy requirements. Each of the sections below should be filled out. If there are none identified for an area, it should say “There are none identified”.

Req # Requirement7.4.1 Regulatory / Legal

7.4.1.1

The system must comply with all Criminal Justice Information Standards (CJIS) requirements.

7.4.1.2 This system must comply with all State of Texas laws

7.4.1.3 This system must comply with all City of Dallas Local Judicial Rules


Req # Requirement

7.4.1.4 The system must comply with FIPS and NIST standards

7.4.2 Financial Control

7.4.2.1 There are none identified

7.4.3 Business Continuity


7.4.4 Policy7.4.4.1 There are none identified

7.5 Functional Requirements List

The following list represents the functional business requirements for the ALPR System.

Note: Each requirement relates to a component of an Activity described and modeled in this section of the specification. Detailed functionality, business rules, constraints and conditions for each of these requirements can be found in the detailed use cases associated with the requirement. Business rules for information used by the system are found in the Information Section with the data elements.

Req # Requirement7.5.1 Hardware Specifications

7.5.1.1

System must be comprised of self-illuminating Infrared (IR) cameras for effective license plate image capture in a variety of weather and lighting conditions.

7.5.1.2The System must also be able to read temporary issues license plates. (example: paper printed plates)

7.5.1.3The Infrared (IR) Light Emitting Diodes (LEDs) must be “pulsed” to enhance license plate capture.

7.5.1.4

All cameras must have a dual lens configuration in a single camera housing featuring both an Infrared (IR) lens for license plate capture and a color overview image of the vehicle.

7.5.1.5The integrated color and infrared LPR cameras must not emit any visible light from infrared illuminators.

7.5.1.6

The System must have a “self trigger mode” to detect the presence of lawfully mounted vehicle license plates in the camera’s Field of View (FOV)

7.5.1.7

The cameras must be capable of producing multiple license plate images with varying Shutter and Gain Settings to ensure a high quality image regardless of weather or lighting conditions.

7.5.1.8 The cameras must be capable of being permanently attached to the vehicle’s emergency lightbar in a low profile manner to minimize impact on the lightbar system without drilling multiple holes or


violating the integrity of the roof structure.

7.5.1.9

Cameras should be attached to the light bar without interfering with visibility of the complete light bar. Cameras should be no larger in size than 2” height, 8” width and 4” depth.

7.5.1.10 There must be no moving parts in any of the cameras.

7.5.1.11

The cameras must have a fixed focal point or target distance from the camera to the vehicle license plates from a minimum of 6 feet to a maximum of 34 feet under a standard camera configuration.

7.5.1.12

The ALPR Processor must be designed to be trunk mounted or similarly mounted and must incorporate an intelligent Power Supply Unit (PSU) that provides for a safe start and shut – down each time the vehicle’s ignition is turned on and turned off.

7.5.1.13

The ALPR Processor must control the electrical power source supplied to each of the cameras and provide video connection points for simplified System wiring.

7.5.1.14The ALPR Processor must have an operating input range of 10.5-16.5V DC at 90W.

7.5.1.15

The ALPR Processor must be designed to meet the environmental conditions associated with a trunk-mounted unit under various temperature conditions.

7.5.1.16

The System must provide for the simultaneous display of any two (2) cameras as selected by the User and configured by the System Administrator.

7.5.1.17The System must be capable of capturing license plates in any of the following modes:

7.5.1.17.1 an adjacent lane on either side of the police vehicle while driving through traffic and/or parking lots

7.5.1.17.2 traffic in an adjacent lane while parked on the side or shoulder of a roadway;

7.5.1.17.3 any parking application from parallel to perpendicular parked car orientation with respect to the movement of the police vehicle

7.5.1.17.4 an adjacent lane to capture the rear license plate of the vehicle as it passes the police unit or vice versa.

7.5.1.18

The camera configuration must be capable of switching from one monitoring mode to another via the software application by merely “pressing” the corresponding On-Screen Function Button.

7.5.1.19

The System must provide effective license plate capture at night and in reduced light situations and total darkness with no external lighting required.

7.5.1.20

The System must have the capability to capture a still image of importance at the officer’s discretion using the color overview portion of the Camera.

7.5.1.21 The System must have the capability to capture vehicle license plates at combined speeds up to 130 mph with license plate capture and read accuracy rates (referred to as “System Efficiency”) in excess of 85%. Bidder to provide independent test results from at least three


North American law enforcement agencies verifying your accuracy claim.

7.5.1.22

When the System is configured to utilize an independent ALPR processor, the ALPR Processor and the cameras must be developed, manufactured and supported by the same vendor.

7.5.1.23

All camera cabling and camera connectors must be manufactured or assembled by the vendor that provides the ALPR System and all of the required components.

7.5.1.24All camera mounting bracket systems must be fabricated specifically for the vendor’s cameras and must be furnished by the vendor.

7.5.1.25

In addition to the camera mounting bracket systems that attach to the vehicle’s emergency lightbar, the vendor must also provide camera-mounting bracket systems that can be installed on those police vehicles commonly referred to as “unmarked units” or those with no roof-mounted lightbar.

7.5.1.26

In addition to camera mounting bracket systems for marked and unmarked police units, the vendor must also provide a magnetic mount that is made specifically for the cameras. The Magnetic Mount is designed to be used for temporary deployment of the System.

7.5.1.27The system must also be able to be mounted in fixed locations such as light poles, traffic signal poles, utility poles, bridges, or buildings.

7.5.1.28

The system must be able to read and process license plates accurately in “High Traffic” areas such as intersections, highways, or bridges.

7.5.1.29The fixed ALPR’s must be powered by an uninterrupted power source, which may include hard wiring and/or solar technology.

7.5.1.30The fixed ALPR’s must be refreshed with updated license plate database information wirelessly.

7.5.1.31

The vendor is expected to manage the entire process for installation and relocation of fixed systems: gather permits, utility agreements, camera assembly/disassembly, installations, network setup, configuration, and testing.

7.5.2 Software Specifications

7.5.2.1The application software must be capable of supporting multiple “hot list” databases including but not limited to

7.5.2.1.1 NCIC Databases7.5.2.1.2 TCIC Databases7.5.2.1.3 Registered Sex Offenders vehicles 7.5.2.1.4 North Texas Regional Wants and Warrants 7.5.2.1.5 BOLO (Be On the Lookout)

7.5.2.2The system must allow a System Administrator the ability to add additional databases as necessary.

7.5.2.3 The System Administrator must have the capability to define the police department’s database/s and assign a color code and priority level to each database to be used when a ‘match’ or a ‘hit’ occurs, i.e., stolen vehicles, stolen license plates, sexual predators, armed


felon suspects, registered parolees, etc.

7.5.2.4The data file transfer must be accomplished by either of the following methods, listed by priority, but not limited to:

7.5.2.4.1 Wireless7.5.2.4.2 Ethernet

7.5.2.4The system must utilize security encryption technology to secure all data transmissions.

7.5.2.5The System must be able to be refreshed with updated data up to once every hour.

7.5.2.6

The application software (GUI application) that resides in the police unit must be Active Directory compliant that provides for a User Name and Password as assigned by the System Administrator.

7.5.2.7

The application software must be responsive in comparing a captured license plate against multiple and voluminous databases with less than a 1.5 second response to a query of a database/s containing up to 10,000,000 records.

7.5.2.8

All license plate and system data remain the DPD’s/City’s property and is not to be shared or shared amongst any system without the City’s written consent.

7.5.2.9

The System should have the feature that allows “hot list” databases to be created in the field by authorized users and the authorized users must have the capability to add license plate data to the system’s database/s while in the field. All license plate data added by the authorized user will remain a part of the selected database until the database is ‘overwritten’ by the System Administrator or by a new or updated database/s.

7.5.2.10

The System must provide a “Rules” Feature whereby the System Administrator can define license plate numbers and/or characters that can be interpreted in different variations or “rules.”

7.5.2.11

The vendor must provide variants of the Optical Character Recognition (OCR) Engine that are tailored/designed for a specific State or regional license plate population

7.5.2.12

As part of the vendor’s system maintenance agreement with the customer, Optical Character Recognition (OCR) updates and/or revisions must be provided as determined by the vendor to address changes in the State’s license plate population during the term of the maintenance agreement.

7.5.2.13The system must provide all of the following live, simultaneous video display of data for cameras as selected by the User:

7.5.2.13.1 The IR License Plate Image7.5.2.13.2 The license plate interpretation or system read

7.5.2.13.3A corresponding color overview image of the vehicle displaying the captured IR license plate

7.5.2.13.4 The date and time the data was captured by the System

7.5.2.13.5 Identification of the Camera capturing the image

7.5.2.13.6The GPS Coordinates for every license plate captured by the System


7.5.2.14

Even though the System must provide for the simultaneous display of two (2) Cameras as selected by the User, the System must also have the capability to be configured whereby up to all 4 Cameras are operating simultaneously and matching license plate data against the databases.

7.5.2.15

When the system identifies a “match” or a “hit” of the license plate, the following additional data must be displayed in a timely manner on the system’s Hit Screen:

7.5.2.15.1

The color coded database indicating the name or title of the database as assigned by the System Administrator where the “match” occurred.

7.5.2.15.2All narrative text, if any, from the database where the “match” Occurred

7.5.2.16

The Hit Screen must remain displayed until acknowledged by the officer, and while displayed, the system must continue to process license plate data in the background and all captured data must be stored in the System during this interval without any User intervention. In the event that a subsequent “match or hit” should occur while the original Hit Screen is displayed to the officer, the System must provide an audible and visual alert to the User that a second or subsequent “hit” occurred and the System is waiting for the (User’s) officer’s intervention.

7.5.2.17

The System must provide a touch screen feature to enlarge the vehicle’s color overview image so that the User can examine it in order to gain additional information about the overview image or the verification of information.

7.5.2.18The System must provide touch screen navigation capability for the police application GUI.

7.5.2.19

The System must provide the System Administrator with the ability to customize audible alerts to differentiate between unique events within the software application.

7.5.2.20

The System must provide a visual alert for each defined event that displays in the foreground regardless of other applications in use at that time if the System’s Client-Server Architecture is utilized.

7.5.2.21The System must provide the officer with the capability to mark a license plate read as a “misread.”

7.5.2.22

The System must provide the officer with the capability to manually enter a license plate, via a vehicle’s MDC, for the purpose of searching that license plate against the System’s database/s.

7.5.2.23The System must provide the officer with the capability to review all of the following:

7.5.2.23.1

“hits” license plate images and associated data license plate searches performed by the officer indicating the date and time the search was Conducted pictures

7.5.2.24 The System must provide the officer with the ability to query the GUI application in the police vehicle to determine if a particular license plate is currently stored in the System. If the license plate data is in the System, the officer must have the ability to review each license


plate capture and the associated System data displayed on the GUI application Review Screen to include:

7.5.2.24.1 The IR License Plate Image7.5.2.24.2 The corresponding color overview image of the vehicle

7.5.2.24.3The date and time the image was captured and the GPS coordinates or the captured data

7.5.2.25

The Proposer must demonstrate the systems ability to cohabitate with TriTech Software System’s VisiNet Mobile and Intergraph’s inPursuit systems.

7.5.3 Back Office/Analysis/Admin Specifications

7.5.3.1

As part of the overall System and functionality, a customized back – office software application must be provided by the vendor so the customer can manage all the data collected by each individual police unit, manage the database functions, provide reporting data and manage the user administration functions.

7.5.3.2The System must provide the ability to assign priorities to the various databases utilized by each police agency.

7.5.3.3The System must provide the System Administrator with the ability to configure for the regular import of national and local databases.

7.5.3.4

The System must provide application security via Active Directory that requires a User Name and Password for each User as determined by the System Administrator.

7.5.3.5

The System must provide the System Administrator with the ability to determine System user access levels based upon user responsibilities.

7.5.3.6The System must provide remote web access, via Internet Explorer 6.0 or higher, to stored data for analysis and reporting.

7.5.3.7

The System must provide the ability to perform a full or partial license plate query against the databases. Examples include partial license plate numbers/letters with missing or unknown characters in varying positions on the plate.

7.5.3.8The System must provide the ability to query for license plate data based upon time, date, location and the user.

7.5.3.9

The System must provide the ability to utilize a mapping function to plot or identify the locations of a particular license plate or identify all plates captured in a particular area during a particular time. The City currently uses ESRI mapping sofware and it would be ideal for the system to leverage existing mapping software.

7.5.3.10The System must provide the ability to utilize a mapping function to plot or identify the location of all “hits.”

7.5.3.11

The System must provide multiple methods for downloading and uploading information between the vehicle and the back – office application including Wireless, and Ethernet. A centrallized uploading process may be leveraged that would allow for patrol vehicles to automatically upload information upon returning to substations via wireless technology.


7.5.3.12

System must provide a server network environment to facilitate the sharing of data between other police agencies as defined by the System Administrator.

7.5.5 Other System Requirements

7.5.5.1A full and complete set of operating instructions shall be included for the system

7.5.5.2

The vendor shall warranty the System to be free of defects in materials or workmanship. This warranty shall not extend to finish, appearance items, or malfunction due to abuse, neglect, misuse, accidents or operation under other than specified conditions.

7.5.5.3

The vendor shall have a dedicated service department locally based in the Dallas/Fort Worth area and may not contract out the warranty or the follow-on service plan. Service response shall be within four hours from notification of system casualty.

7.5.5.4

All hardware and software provided by the vendor must be covered under a 5-year parts and labor warranty at no additional cost to the customer during the first year of service.

7.5.5.5

The Provider must furnish extended warranty/maintenance costs for both hardware and software for up to five (5) years from the date of System installation.

7.5.5.6After issuance of the Purchase Order, all hardware and software must be delivered to the customer site within five (5) weeks.

7.5.5.7

The successful vendor must provide role based on-site System training for the System Users and the System Administrators as required by the customer. Vendor is responsible for providing electronic and hard copy documentations. City will be responsible for providing an environment conducive to learning.

7.5.5.8

The successful vendor must provide System installation and/or System installation oversight based upon the customer’s requirements.

7.5.5.9

The successful vendor must provide local field support and provide onsite or offsite support, at a minimum, between 8:00 AM – 5:00 PM CST.

7.5.5.10

The vendor will serve as a single point of contact, and provide the name, address and telephone number of the individual to contact when both on-site and remote maintenance is required. The vendor shall further provide escalation procedures and contact names and numbers to be used when normal maintenance procedures are not adequate to resolve problems.

7.5.5.11All System documentation must be furnished in electronic format.All training material must be furnished in modifiable electronic format.

7.5.5.12The IR cameras must meet “eye safe” certification standards, as established by an international testing agency.

7.5.5.13 The IR cameras must be sealed to IP67 Standards.

7.5.5.14Vendor must assist City of Dallas/Dallas Police Department in testing the license plate scanner implementation.


8.0 Contract Terms and Conditions

The City expects the successful Proposer to provide a complete turnkey system. The City expects the successful Proposer to utilize the City’s Turnkey Acquisition Contract, License Agreement, and Maintenance Agreement samples provided with minimal modification. The system provided needs to be fully installed and functioning as described at the end of the project and for the foreseeable future. To accomplish this, the City will need to acquire a perpetual license for any and all software required by the system as well as ownership of all the necessary hardware. If a Proposer’s business model requires other entities to be involved in the contracting process, the City is willing to consider a Proposer’s solution, but the value received by the City will be judged based on the City’s ability to ensure that the City will receive a turnkey system and be assured that the system will be properly maintained going forward. To accomplish this goal, the City will require the Proposer to provide satisfactory assurances in the form of warranties and indemnifications that third-parties selected by the Proposer will perform as expected.

The City has prepared Terms and Conditions to be used for this project. It is important for the Proposer to become familiar with the paragraph items contained in this section, as they will prevail in the event of any discrepancies or differences between project related or contractual documents.

The City’s sample contract documents are included in the RFCSP package. The blank spaces in the City’s contract documents are not to be filled in at the time of submitting the proposal. They are included to familiarize the Proposer with the form of the contract that the successful Proposer will be required to execute. The contract will be tailored to this procurement and completed by the City of Dallas Attorney’s Office.

Exceptions, conditions, or qualifications to the provisions of the City’s contract documents, if any, should be clearly identified as such (by Page, Paragraph and Line and Word Number), followed by the proposed alternate language. The City utilizes the attached sample contract documents as the basis for completing the final contracts.

Do not submit form contracts for wholesale substitution of the City contracts. The City shall consider the number and substance of alterations to the City’s sample contract documents as factors in determining the best offer.

8.1 Proposer’s ALPR System License

Proposers or their subcontractors should not include project associated labor in these license agreements. All labor that is not a part of the license fee should be contracted under the Acquisition Agreement.

Proposers should submit their ALPR System license modified as noted above for RFCSP Sections 6.0 Statement of Work, 8.0 Contract Terms and Conditions, and 9.0 Proposal Pricing. Proposers should also ensure any modifications noted as to be delivered with the Base Software in Section 7.0 are properly contracted under the license. The City will also accept a proposed base license with a written explanation of how the license is to be modified.


8.2 Proposer’s Third Party Software

Should Proposers propose third party software as a part of their proposal; the City will consider and negotiate with the respective third party ALPR System Software Provider for licenses and maintenance. The City recognizes that the Proposer may not be the ALPR System Solution Provider and the City will accept a direct contract from the software solution provider. This is subject to City policies as presented in Section 6.0 Statement of Work, Section 7.0 Functional and Technical Requirements and Section 9.0 Proposal Pricing. Proposers or their subcontractors should not include project associated labor in these license agreements. All labor that is not a part of the license fee should be contracted under the Acquisition Agreement.

Proposers should submit their third party Software licenses modified as noted above for RFCSP Sections 6.0 Statement of Work, 8.0 Contract Terms and Conditions and 9.0 Proposal Pricing The City will also accept a proposed base license with a written explanation of how the license is to be modified. Proposers should also ensure any modifications noted as to be delivered with the base software in Section 8.0 Contract Terms and Conditions are properly contracted under the license.

8.3 City’s Hardware Agreement

The maintenance agreement for hardware and related software is attached as a file entitled “Turnkey System HW SW Maintenance”.

8.4 City’s License Agreement

The City requires the use of its License Agreement for software acquisitions. This agreement is attached as a file entitled “Turnkey System License”. This agreement will be used for the following circumstances:

For software published by or licensed by the proposer and used for this project. For software developed by the proposer for this project. Where the Proposer acts as an integrator and supplies other software that may or may

not be owned by the Proposer, the City may require a perpetual license agreement directly with the software publisher.

The successful responsive/responsible Proposer is responsible to ensure that the City receives all the necessary licenses to ensure the turnkey system operates perpetually.

8.5 News Releases

The Proposer will not make any news releases, public announcements or public disclosures, nor will it have any conversations with representatives of the news media, pertaining to this RFCSP, the contract, or the services, study, data or project to which this RFCSP and the contract relate, without the prior written approval of the City, and then only in accordance with explicit written instructions from the City.

8.6 Statement of Proposal Effective Period

Proposals, including pricing, shall be valid for a minimum of one hundred fifty (150) days from the proposal opening date. If the evaluation process takes longer than this, the City may have to request an extension from some, or all Proposers. Proposers should state the effective period in your proposal Section 8.0 Contract Terms and Conditions.


9.0 Proposal Pricing Proposers are to provide pricing in accordance with the schedule below. The City is looking for the most cost-effective proposal provided by the most qualified proposer. The City desires an off-the-shelf solution. All customized software or solutions should be clearly delineated and priced. If the Proposer‘s system can accomplish the same objective in a different way, the City desires to understand the alternate approach and understand the savings associated with the alternate approach.

The City of Dallas will not pay any costs associated with the preparation, transmittal or presentation of any proposals or material submitted in response to the RFCSP. Do not include any State or Federal sales taxes in the proposed costs. The City will furnish an Exemption Certificate to take advantage of the sales tax exemption under Section 151.309 of the Texas Limited Sales, Excise and Use Tax Act. The City will not pay costs not included in the proposal, including costs associated with travel, hotel stays, etc. In order to recover any additional related costs, such costs should be accounted for and identified in the proposal. Provide a list with descriptions and quantities for all required equipment, parts and materials for the System as proposed. A separate list should show the same information for all options in this specification.

Provide pricing for all items presented in response to this RFCSP. Options that go beyond the requirements of this RFCSP are welcome, but should be priced separately. Price these options as well as recurring follow-on costs, such as hardware and software maintenance/support, separately from the rest of the project.

Provide a total price for the ALPR System project, excluding only the price of options and their recurring costs mentioned above. Include all costs associated with each phase.

Itemize pricing for individual application tailoring should be included in the answers in the Functional and Technical Requirements as a part of Section 7.0. These costs should be brought forward to be a part of the total costs in the Proposal Pricing. Identify dependency relationships between all priced items in the response to Section 7.0, as appropriate in the Functional and Technical Requirements.

A pricing template has been provided to assist in providing the City with prices by area of the RFCSP. After acceptance of the system, the successful Proposer should make available to the City of Dallas, without charge, any enhancements, or any other terms, conditions, or circumstances that favor the City and that are made generally available at no charge to the Proposer’s other customers. Other enhancements, or other terms, conditions, or circumstances offered to other customers for a charge should also be offered to the City at the same charge.

During contract negotiations with the selected proposer, the City will evaluate the detailed pricing submitted with the proposal. This pricing will assist the Proposer and the City to agree to terms for payment of services and equipment provided.The basis for these payments will be on the detailed pricing listed in the proposal and payments will be for milestones achieved.


After award of contract, any maintenance or improvements in service or other enhancements or features made generally available to customers should also be immediately extended to the City.Specific pricing should be detailed by the following areas:

9.1ALPR System License and Maintenance

The following pricing pertains to items required by the system as a whole.

9.1.1 Initial One-time ALPR System System License Fee

Proposers should include their initial one-time license fee. Such fee shall include all terms and conditions as specified in this RFCSP. Should the proposer charge maintenance during the initial first year (defined in the contract), such fees should be specified in this section of your proposal.

9.1.2 On-going ALPR System Maintenance Fees

Provide complete pricing inclusive of any price escalation clauses for the period starting on the 13th month after acceptance of the initial delivery of the ALPR System software.

9.1.3 Third-party Software License Fees

Proposers should clearly specify all one-time fees for third party software. Specifics as to first year maintenance costs should be defined. If these fees are separately charged, please specify.

9.1.4 On-going Third-party Software Maintenance Fees

Provide complete pricing inclusive of price escalation clauses for the period starting in 13th month after acceptance of the initial delivery of the ALPR System software.

9.1.5 Billing Terms

City will pay for software upon acceptance of the initial delivery of the ALPR System Software, or any other affiliated and priced software.

9.2 Proposed Hardware Environment

The proposer shall be required to make some assumptions about the City’s environment or about specific requirements. Any assumptions made by the Proposer in regard to this RFCSP shall be documented in this section. The City understands that not all Proposers are in the business of selling hardware. However, the City requires that the Proposer provide detailed hardware specifications and reasonable prices for all required hardware, and clearly indicate whether or not the Proposer is willing to supply said hardware to the City. The City will pay for hardware upon acceptance of the initial delivery of the Hardware, or any other affiliated and priced software.

All equipment proposed will be new, recently manufactured, without any used or refurbished components or sub-assembly. Equipment specified shall consist of off-the-


shelf components, and will include the latest models, versions and releases of all components, hardware, and firmware.

Original invoices for equipment purchased for the City will be the responsibility of the successful Proposer and should be turned over to the City upon acceptance of the equipment by the City following installation and proof of successful operation by the Proposer. Following acceptance, the Proposed should present the City with itemized manufacturer’s statements indicating that the City of Dallas is the registered owner of said equipment.

Proposer shall provide price options regarding service equipment, which should reflect the Proposer’s provision and installation of all service equipment. Proposals should also include the cost of maintenance for the available maintenance and extended service maintenance agreement options to cover the System for a 5 year period.

9.3 Implementation

9.3.1 Payment

As previously discussed, the City will enter into a Fixed Fee agreement for the project. Payment options will be negotiated between the City and Proposer.

Final 10% of Total Payment will be witheld for 60 days following the completion of the solution. Upon satisfactory performance the remaining 10% payment will be released. Completion is defined as successull installation of all vehicle and mobile ALPR installations, as well as succussfully installed and tested back office software

9.3.2 Pricing for Change Control Items

Proposers should provide a summary of the pricing for change control items listed as separately priced items in the Functional and Technical Requirements matrices of Section 7.0 in this section of their proposal. Please note that this total should be included in your project costs as a part of Section 9.3.1. Pricing in Section 9.3.2 simply a summarization of Section 8.0 Contract Terms and ConditionsChange control for this project shall include both increases and decreases in scope, duration and staffing. Specifics include: City shall reduce scope and related fees of functional requirements for the price

as stated in the Functional Requirements (Section 7.0) of the Proposer’s response by removing any of these functional requirments. Scope reductions for requirements that are considered in-process will be mutually negotiated.

Functional increases and deceases in scope shall be traded. Proposers should submit a fee schedule that will be the basis of their pricing of

change orders. Proposers should state this response as a rate per hour.

9.3.3 Pricing for Extensions to Post Implementation Support

Proposers should provide pricing for possible extensions of their services under the Post Implementation Support as specified in 6.3.24 Post Implementation Support

9.3.4 Base Pricing

Proposers should provide pricing for the base proposal inclusive of all hardware, software, maintenance, professional services and communications to provision the


ALPR System software to the end users of the City. This pricing should also cover your same services for the Implementation Project.

9.4 Options Pricing

Proposers should propose the scope as requested in the Sections 8.1 through 8.3 above. However, should any Proposer have options to their proposal that clearly falls outside of the scope of the project, such options should be priced separately here inclusive of any considerations for invoicing, payments, contract terms, or conditions. Proposers should ensure the City understands the scope of the proposed option and should submit an Appendix to cover the nature of any option.

9.5 Travel Expenses

As this RFCSP is requesting a fixed fee, proposers should include all costs inclusive of travel expenses as a part of the fees in the Sections 9.1 through 9.4.Travel expense must be in agreement with City of Dallas travel policies or Federal Travel Regulations (Code of Federal Regulations (CFR) chapters 300‐304 for Texas, whichever is lower.

9.6 Price Agreement

The price agreement should contain component prices for all parts and services used in the acquisition, installation, and other professional services as may be necessary to expand the utilization of the system.

10.0 Required City Schedules and FormsThe requirements presented in this section cover required City forms. Proposers should complete these forms and include them in their Proposal

10.1 Business Information Form

The Business Information Form (section 10.0), file at www.bids.dallascityhall.org

10.2 Insurance Affidavit

Proposers should indicate their compliance with City insurance requirements and provide a signed affidavit from their insurance agent as a part of their proposal in the form as attachment file to this RFCSP.

The City specific insurance requirements are specified in (section 10.2), file at www.bids.dallascityhall.org

10.3 Good Faith Effort Information

The City encourages all Proposers to understand the City’s Minority and Women Owned Business (MWBE) program and has attached documents explaining this program. The Business Inclusion and Development afidavit should be signed and included in the proposal submission.

10.4 Contracts

The City’s Sample Contracts are specified in the attached files: “Turnkey System HW SW Maintenance; “Turnkey System License; “Turnkey System Acquisition” Agreement.


http://www.bids.dallascityhall.org/

http://www.bids.dallascityhall.org/

11.0 Proposer’s Hardware and Software ConfigurationProposers should specify all hardware and software required to run the proposed ALPR System System software in the City’s technical environment. The City will disclose current license agreements during final contract negotiations with the succesfull vendor.

11.1 Development

Proposers should specify the development environments required to effectively conduct the project.

Hardware and SoftwareProposers should indicate the hardware and software by which will accomplish the project and the environments by phase of the project plan. The City desires specifics regarding:

Environments/Configurations (e.g. development, test, volume test, training, acceptance test);

Software for each phase of the project; Developer desktop requirements; Sizing of data storage and redundancy; and Server sizing related to the project phases and regions.

Software should include any tools that will be used by the Proposer for the project. Examples of this shall include performance monitoring tools, volume testing tools, project management tools and data base tools.

Additional Network RequirementsShould the proposed software require any network requirements other than the City’s current Cisco AVVID VoIP network, Proposers should indicate these requirements in this section.

The City connects with MDCs in the field via cellular broadband through NetMotion.

Proposers are required to provide bandwidth estimates and recommended infrastructure to support the bandwidth needs of the new system.

11.2 Production

Proposers should indicate the methods by which they will accomplish the production performance objectives of the City through the hardware and software environments and related upgrades for the duration of the project. The City desires specifics regarding:

Environment/Configurations that will support the City (e.g. production, development, test, training);

Business Continuity is specified later in this section of the RFCSP; Planned upgrades; Reporting architecture; Desktop configuration, if any; Sizing of disk storage; and Server sizing.

Communications Architecture


The City will be responsible for performance of the communications architecture within its own firewall. Proposers should indicate any required changes due to their proposed ALPR System Solution.

Business Continuity ArchitectureThe Proposer should put forth a Business Continuity Plan(s) that meets accepted industry standards as defined by the Business Continuity Institute’s, Good Practice Guide and Publicly Available Standard (PAS) 56.

Proposers should specify a mirrored ALPR System environment. Proposers should also plan for Disaster Recovery Plan.

Proposer’s Plans for Growth or Reduction of City’s ProcessingProposers should specify the upgrade/refresh plans for the production environment inclusive of hardware and software. Proposers should describe how growth or reductions will be accomplished addressing such factors as; increasing/decreasing licenses and their related increments, hardware sizing, and any associated network or ancillary requirements.


Appendix A – System Diagram


Appendix B – Proposal Pricing

RFCSP #___________ Pricing Page

Instructions: Please use this page to respond to Section 9.0. Failure to use this page or to provide complete information could result in proposal disqualification. Attach additional pages if necessary.

1.1 System License and Maintenance

1.1.1Initial One-time Patient Assessment License FeeThis fee includes maintenance during the initial first year. Indicate yes or no. Yes No $$$If no, cost of first year maintenance (contract sign date through 12th month)

1.1.2 On-going Maintenance Fees (include price escalation clauses if appropriate) $$$13th month thru 24th month 25th month through 36th month 37th month through 48th month 49th month through 61st month

1.1.3 Third-Party Software License Fees $$$Description: These fees include maintenance during the initial first year? Indicate. Yes NoIf no, cost of first year maintenance.

1.1.4On-going Third-party Software Maintenance Fees, including Price Escalation Clauses $$$2nd year, starting in 13th month after contract date 3rd year 4th year 5th year

1.2 Proposed Hardware Environment $$$


Description:

1.3 Implementation (Includes Professional Services Fees: Project Management, Training, etc.)

1.3.1 Implementation FeesDescription or Phase: Phase $$$

1.3.2 Change Control Items $$$Totals of Section 6.0, but price contained in 8.3.1:

Hourly Rate for Change Orders

1.3.3 Extensions for Post Implementation Support $$$Describe duration and staff size reductions or increases.

1.3.4. Base Pricing

1.4 Proposer Options: $$$Instructions: List and describe options to the above price schedule, including recurring and follow-on costs. Reference the numbered subsections above.


Appendix C – Reports

The City will be relying on the vendor to identify their reporting capabilities and the voting committee will be reviewing and evaluation the reporting capabilities of each vendor’s offerings.

Report NameSelection Criteria

Fields on Report Description

The Solution shall provide a database schema and entity relation diagram (ERD) to facilitate the creation of any necessary reports to reflect any collected data within the application.The Solution should contain the ability to create electronic reports triggered by entering a date span, choosing to view files by one officer, with the ability to sort and provide counts and viewed on screen or printed hard copy.All reports should be on-line accessible as well as have the ability to print on hard copy.


Appendix D – CIS IT Standards

City of Dallas

CIS Information Technology Standards

1.0 City’s Current Licensing

The City has licenses for software that may be of interest to Proposers. Proposers should be careful to not assume that all these licenses are structured to include the new emergency notification system environment. The purpose of this section is to simply convey current City licensing information and is not intended to indicate the City’s preference of certain enabling technologies unless otherwise noted. Should the Proposer find it advantageous to use these licenses, the City believes Proposers should be interested in the following licensing information:

Oracle

Proposers requiring the use of Oracle should include the costs for these licenses. The City will require licenses for Oracle release 11g or the most current release. Proposers should indicate the most advantageous licensing structure (e.g. per processor, per named user). The City expects the Proposer to work with City staff and the Oracle vendor to incorporate upgrade and maintenance agreements within the City’s current agreements with Oracle.

SQL Server

Proposers requiring the use of SQL should include the costs for these licenses. The City will require licenses for SQL Server 2005 or 2008 or the most current release. Proposers should indicate the most advantageous licensing structure (e.g. per processor, per named user). The City expects the Proposer to work with City staff and the Microsoft vendor to incorporate upgrade and maintenance agreements within the City’s current agreements with Microsoft.


McAfee VirusScan 8.0i

McAfee VirusScan 8.0i, managed via the Common Management Agent by the McAfee ePolicy Orchestrator, is the product of choice for the City. The City expects the Proposer to work with City staff and the McAfee vendor to incorporate upgrade and maintenance agreements within the City’s current agreements with McAfee.

BMC Performance Manager

BMC is the product of choice for the data center operations to monitor the health of the computing environment. The City expects the Proposer to work with City staff and the BMC vendor to incorporate upgrade and maintenance agreements within the City’s current agreements with BMC.

ESRI GIS ArcView 9.1

ESRI is the product of choice for the GIS needs in the City. The City expects the Proposer to work with City staff and the ESRI vendor to incorporate upgrade and maintenance agreements within the City’s current agreements with ESRI.

2.0 Product Licensing

a. All licensing of software will revert to the City. Product licensing shall grant the City full use of the product, services and upgrades.

b. Proposers should include a provision for 5-year maintenance and warranties.

c. The City may elect to present to Council a price agreement in addition to the final contract to pay for future maintenance costs. It is anticipated that the duration of the agreement will be 60 months.

d. The City desires an Enterprise license agreement. Proposers should describe their standard for concurrent users.

3.0 Third Party Licensing

The successful Proposer will provide all ancillary software related to the entire environment, including monitoring, backup and recovery software. Licensing for third party software should revert to the City. Proposers should note whether the City already has licenses for the proposed software and shall work with the City and its Vendors to incorporate these new licenses under the City’s existing maintenance agreements.

At no time will the City accept “freeware” or unsupported products in conjunction with the proposed solution. The only exception to this relates to products developed by US governmental agencies to be used by local, state, or other federal agencies.


4.0 Hardware

4.1 DesktopsThe City’s current standard is DELL desktop running Windows XP Professional SP2. The City uses IE 6.0. The City does not currently support Windows VISTA or IE 7.0

4.2 Server Hardware & OSa. The City uses Intel based rack-mounted client server technology.b. INTEL Dual-Core Xeon processorsc. Minimum 3 GHz Processorsd. Minimum 4 GB RAMe. Dual NICs

f. Dual Power Suppliesg. The proposal should include rack, KVMs, and all necessary components to be fully

functional. h. The City’s Operating System standards are:

Microsoft Server 2005 or better Solaris v10

i. The solution should employ a dual server configuration in an Active-Passive configuration to maximize use and provide redundancy.

j. The City currently uses Windows based platforms (IBM, Dell) and Sun Solaris based platforms. The successful Proposer will offer solutions to one or the other of these platforms. The Proposer should specify any exceptions.

k. Servers must be rack mounted. l. The City expects servers to contain full size 32-bit PCIe cards.m. The City expects a high availability configuration for both application and data.n. The City expects the capability for each server could be used at the same time.o. Each rack is to have redundant power supplies and include a patch panel for network

connectivity. p. Cabling within racks shall be properly secured and labeled on both ends with the port

and IP Address.q. Power requirements for all components, including amperage draw, power circuitry

required, power distribution unit (PDU) capacity rating and configuration examples that show total power draw and requirements per PDU

r. Hardware specifications shall include Temperature and Humidity requirements.s. Applications running on the server must run as a service. All servers must be able to be

logged off.t. Windows based servers are required to have McAfee installed and running. Proposers

shall include in their proposals any known issues or conflicts with their solution and McAfee.

u. Proposers shall provide a certification matrix for all software proposed for their solution including specific versions in conjunction with the hardware proposed.

v. Application Server may have a choice of using IIS, Apache, etc.w. Web Server can be a Choice of IIS, Apache, or Sun Java.x. Data management (DBMS) can be SQL or Oracle.


5.0 Application Technology

a. All resident server software must be run as a service. The service can authenticate using a Local System Account.

b. The City’s preference is for thin client browser based applications with no footprint on the workstation.

c. Proposers are to adhere to the City of Dallas’ Web Linking Policy.d. Any web applications should be developed in .NET, ASP, Java, or PHP.e. Interfaces should be XML capable wherever possible.f. The solution should take advantage of advanced caching such as navigation or content

object caching.g. The solution should take advantage of page caching to optimize performance.h. The solution should provide Application Program Interfaces that can be ‘plugged’ in as

necessary.i. The solution should address Load Balancing to assure user sessions can be passed

between all nodes transparently.j. Proposer’s software should be able to integrate easily with several other systems using

industry standard methods.k.Proposer should provide the information regarding database and file structure needed for

a third party to construct or configure interfaces.l. Additional specifications on the existing systems will be provided to short-listed

Proposers.6.0 Data Storage

The City’s current standard is a Hitachi Thunder SAN with data storage at RAID 5.

7.0 Data Back Up

The City uses Veritas to back up data.

8.0 Data Bases

a. The City’s standard databases are SQL 2005/2008 or Oracle 11g.b. Proprietary data bases are not acceptable.c. Product design and modularity should allow it to be ported to smaller and/or larger

platforms without the need for redesign and/or reconfiguration.

10.0 Security

10.1 General Security Requirements

a. The system should comply with the U.S. Department of Justice Criminal Justice Information Services (CJIS) Division CJIS Security Policy version 4.4 or better.

b. City authentication services is based on Active Directory.


c. WLAN Mobile Computing should adhere to the 802.11a, g or n standard or better;

d. Proposer to provide a diagram indicating placement of all firewalls;e. All Internet traffic should be encrypted;f. All FTP traffic should be in-flight encrypted;g. Malware Protection Requirements

oAny device attached to the City network shall install and run adequate protection against malware, if that device is vulnerable to malware infection or attacks. This includes, but is not limited to, servers, workstations, laptops and some mobile devices. Protection shall include, but is not limited to, anti-virus and anti-spyware programs.

oThe City’s preferred vendor of malware protection is McAfee from Network Associates. Other vendor products may be considered, but will be reviewed and approved by CIS Information Security. The installed malware protection should be kept up to date with all signature files and all patches, updates and upgrades that the anti-malware vendor may supply over time.

oIn addition, the devices attached to the network shall be kept current with all patches and updates to the operating system that may be released in response to discovered security vulnerabilities of that system.

h. The system/security administration should have, at minimum, the ability to assign different user profiles based on individual and group classifications and sub-classifications and assign differential access privileges; and should be active directory aware using the City’s active directory infrastructure.

i. Server User ID/Passwords should conform to City standards. At no time will a generic Server User ID/Password be assigned to Administrators;

j. The application should not grant access to the user until the application can authenticate the user based on user id and password.

k. All security administrator procedures should be supported by a detailed logging, auditing and reporting capability.l. The Offeror’s proposal should provide a detailed description of the security

roles supported by the proposed solution. At a minimum the proposal should describe the granularity, types and levels of security roles allowed by the proposed software.

m. Proposer will be required to adhere to the City’s Security Policies to be attached;

n. Proposer’s solution will fully integrate with Active Directoryi. Kerberos Authentication;ii. LDAP Authentication;

iii. NTLM Authentication WILL NOT BE ALLOWED.o. Windows based servers are required to have McAfee installed and running.

Proposers shall include in their proposals any known issues or conflicts with their solution and McAfee existing on the same server or workstation. Proposers should be prepared to defend exclusions of components from McAfee scanning;

p. Proposer’s Project Team (including any subcontractors) using their own equipment on the City’s network is required to maintain a current version of a virus protection product. Failure to do so may cause the City to hold the Proposer responsible for damages and recovery costs;

q. Winning Proposer’s Project Team to access solution through a VPN if off-site;RFCSP DPD ALPR System of 106

r. Provide a function for administrators to monitor who is logged on with the capability of killing the session;

s. Proposers should identify any limitations of their solution using the city's proxy servers.

10.2 The Proposer’s package should include the following provisions for security

a. Provision for security and auditing capabilities.b. Allowance for “inquiry only” access to system data.c. Allowance for configurable security.d. Describe the utilization of encryption technology when communicating with

remote users (i.e., handheld devices and laptops).e. Any Internet traffic must have minimum128-bit encryption

f.Any FTP traffic must have minimum 128-bit encryption.g.Server user ids/passwords must conform to City standards.h.At no time will a generic server user id/password be assigned to

Administrators.i.Proposer will be required to adhere to the City’s security policies.

10.3 Virus Protection

a. All desktop, laptop, and server computers that connect to, or share data with, any other computer on the City of Dallas network shall be protected against infection from viruses. The City’s standard for virus protection is McAfee for both servers and workstations.

b.Installation means that the product should be properly installed and functional and set to scan all files on the computer in an “on-access” mode. Files to be bypassed from scanning will be approved and documented by City’s Security Architecture division; and will be approved.

c. Proposers shall include in their proposals any known issues or conflicts with their solution and McAfee existing on the same server or workstation. Proposers should be prepared to defend exclusions of components from McAfee scanning.

10.4 Responsibility of Consultants, Vendors, and Outside Agencies

a. It is the responsibility of business associates to maintain a safe computing environment that extends to all equipment accessing the City of Dallas network; and to follow City guidelines, standards, and policies when interfacing with the City’s network whether through remote or direct access. Only after the requestor has provided evidence to the City that the systems that they propose to be attached to the City’s network have been scanned and purged of files identified as seriously detrimental to the overall functioning of their computers will that computer(s) be allowed to access the City network.

b. Maintenance means that the anti-virus product is kept up-to-date with the latest patches, upgrades and virus signature files on a daily basis.

c. Operation means that the installed product is not bypassed or disabled.


10.5 User ID / Password

The City’s standard is Active Directory. The application should integrate with an LDAP compliant directory for security services such as authentication and/or authorization.

10.6 Data Security

The City’s standard is that all data leaving the City’s network be encrypted.

10.7 Encryption

a. Must comply with the FBI CJIS security requirements.

b. Proven, standard algorithms such as 3DES, Blowfish, RSA, RC5 and IDEA should be used as the basis for encryption technologies. For example, Network Associate's Pretty Good Privacy (PGP) uses a combination of IDEA and RSA or Diffie-Hellman, while Secure Socket Layer (SSL) uses RSA encryption. Symmetric cryptosystem key lengths must be at least 128 bits. Asymmetric crypto-system keys must be of a length that yields equivalent strength.

c. The use of proprietary encryption algorithms is not allowed for any purpose, unless reviewed by qualified experts outside of the vendor in question and approved by the City’s Information Security / Security Architecture division.

d. Data Ownership & Access:

oAll data is and must remain the sole property of the City of Dallas.


oAll tools and capabilities native to the database should be available to the City of Dallas to allow for full access to that data.

oDatabase query, extract and download capabilities into external formats should be completely operational and available for appropriate City personnel to access.

oThe Proposer may not use data owned by the City of Dallas for any purpose without the express written consent of the appropriate City representative.

oThe Proposer should supply the City of Dallas with a data dictionary in electronic format.

10.8 Installation Requirements:

The Proposer will be responsible for training CIS personnel on the installation of the mobile applications as well as on-going support, maintenance and imaging of all mobile hardware. Offer should provide coordination of co-habitation and integration at the proposer’s expense. Additionally, Proposer should provide the installation kit for all automated processes that are necessary for the successful implementation of the proposed software solution. This kit should include the database installation script. The installation kit should be free of viruses and should not come with any material/configuration specific to other Proposer’s customers. The mobile client installation kit should be in the form of software installation. The City utilizes CA Desktop Management Suite and ConfigureSoft to package and deliver software for installation. Vendor will be responsible for working with CIS personnel to develop these remote installation packages for unattended installation.

10. 9 Product Support:

The City requires product support for the implemented system. The proposed method of product support that addresses problems/defects should be included in the proposal. The proposed method of product support should include a support staff access phone number for use by the City. This is to include all the support that is proposed to be used, such as a toll-free telephone number, voice mail, email, live person, etc.

10.10 Vendor Access

The City’s standard is RDP via VPN for server support.

10.11 Vendors and Consultants

a. The City maintains connectivity with outside agencies. Any connection from these agencies will be from a Virtual Private Network (VPN) connection, if Proposer (or any of their affiliates) is offering a web-based solution. Configuration for establishing the VPN connection and all associated costs should be included in proposal. Any connectivity by the Proposer from outside the City’s facilities should be Cisco-based LAN-to-LAN using Microsoft native support tools (RDP)


b. Depending on the frequency and/or number of support personnel involved, the City will disallow use of the VPN client connection for remote access or support, and may instead require vendors / consultants or outside agencies to use a site-to-site VPN tunnel for remote access to the City of Dallas network.

10.12 VPN Standards for Access and Configuration

a. It is the responsibility of all authorized users of City of Dallas VPN access to ensure that unauthorized users are not allowed access to the City of Dallas internal networks including family members or others who may normally share non-City owned equipment.

b. VPN access by individual users will be controlled through authentication to their Active Directory domain account.

c. When actively connected to the corporate network, VPNs will force all traffic to and from the PC over the VPN tunnel; all other traffic will be dropped.

d. Dual (split) tunneling is NOT permitted; only one network connection is allowed.

e. VPN gateways will be set-up and managed by the City’s Information Security division.

f. All computers connected to the City’s network via VPN or any other technology must use an up to date industry certified virus protection product in accordance with City of Dallas anti-virus standards; this includes non-City of Dallas owned or provided equipment.

g. VPN users will be automatically disconnected from the City’s network after 30 minutes of inactivity. The user should then logon again to reconnect to the network. Pings or other artificial network processes are not to be used to keep a connection open.

h. No time limit will be placed on an “active” VPN connection. The only limit on VPN connection time will be through enforcement of disconnection after 30 minutes of inactivity.

i. When practical, maintenance (any planned downtime event not in response to a system outage) of VPN will be limited to non-critical or times of least activity (if such a period is identifiable); such maintenance will be performed in accordance with City of Dallas Change Management procedures.

j. If using computers that are not City-owned equipment to access the City’s private network through a VPN connection, to minimize risk, the user should configure and maintain the equipment in accordance with, or exceeding, City of Dallas Desktop and Security standards (including an industry standard OS level, up to date software, and security patches).


k. Proposers should identify any limitations of their solution using the city's proxy servers.

10.14 Software Maintenance

The Proposer should make available to the City at no additional charge all updates to the software as they are released so long as the City is currently under the Proposer’s software maintenance agreement.

10.15 Training Requirements

The City requires a hybrid training approach that utilizes both Proposer-supplied trainers as well as a train-the-trainer (TTT).

a. The City requires that the software and network infrastructure be in go-live condition prior to the first train-the-trainer session. This should include end-to-end testing in the training environment to ensure system readiness and stability.

b. The City will provide space sufficient for conducting the training, as well as secure site for the storing of the training equipment.

c. The City requires several types of courses. The type and number of sessions required are:

i. System Administrator: One (1) class session with a maximum of twelve (12) students. The length of the session is to be proposed by offeror and will be negotiated with the City during negotiations with the successful offeror. The class session will include hands-on instruction on all content related to the technical side of administering the software, server and database.

ii. Train-the-Trainer: Class sessions with a maximum of 12 students per session. The class sessions will include the same hands-on instruction as the end-user class plus best-practices tips for delivering the material and of practice stand-up training by each participant.

d. The Proposer is responsible for syllabi and training materials to perform all levels of training adequately. End-User guides and job aids/quick reference cards shall be developed primarily by the Proposer. All material should be provided in electronic format that can be modified with no restrictions on duplication or dissemination. The DPDTraining Coordinator shall have the right to reformat all documents as deemed necessary to match internal style use.

e. If the “go live” date is significantly delayed due to the Proposer’s actions or faults, any repeat training sessions of the courses listed in Item c above of the RFP, as determined by The City, should, be performed at no cost to the City.

11.0 Network RequirementsThe Proposer should meet the following technical requirements:


a. Adherence to the City’s network standards.

b. Adherence to the City’s Wireless Standards.

c. All work shall be in accordance with the respective drawings, written specifications, supplemental information, industry standards, trade practice, and applicable regulatory agencies. All work will follow all such standards and procedures referenced by AIA, ANSI, BICSI, CFR, IEEE, NECA, NEMA, OSHA, UL, TIA/EIA-568 Wiring Standards, TIA/EIA 569, TIA/EIA 606, TIA/EIA-607.

d. All cable, racks and hardware will be bonded and grounded in accordance with the National Electric Code. All work shall be performed by competent workmen and executed in a neat and workmanlike manner providing a thorough and complete installation.

e. The engineering of cable plants will be designed by an RCDD certified engineer.

f. All onsite installation technicians will have completed the IBDN – 700 2 day Nordx training course, along with one technician, who has completed the IBDN- 950 10 day Nordx training course.

g. All workmen shall properly protect the work site during installation, including shielding of soft or fragile materials, protect against dust or dirt, protect and support cable ends off the floor from other trades and construction.

h. All workmen shall abide by all applicable state and county building and OSHA regulations. All work shall be Telecommunications Industry standard specification quality.

i. Provide System architecture diagrams and narrative for the proposed solution.

j. Submit bandwidth requirements.

k. Submit all System connectivity requirements.

12.0 City’s FTP System

a. The City maintains two anonymous FTP Servers. One is for internal use only; the other can be used internally or externally to the City.

b. The City does provide a user name and password for files placed on these servers for sensitive data. For short term use, the user account expires after 24 hours.

c. The size limitation on these servers is governed by connection speed. Current tests indicate a minimum of 20MB can be placed on these servers before the connection times out.

d. The expectation is the Proposer’s solution will be able to post/retrieve data from these sites as needed.


13.0 City’s Email System

a. The City uses Microsoft’s Outlook running on Exchange 2003

b. The expectation is the solution will be able to transmit emails as needed to the mobilization teams or to interested parties.

14.0 City’s Enterprise GIS (ESRI GIS ArcView 9.1)

a. Enterprise GIS consist of ESRI’s proprietary ArcView, ArcGIS and ArcSDE geographic information system software designed to provide spatial analysis for City decision making, mapping and planning/forecasting. Enterprise GIS components are imbedded into several enterprise programs currently running at the City of Dallas such as Computer Aided Dispatch (CAD), 311 Customer Response Management System (CRMS), Land Management System (LMS) and Capital Project Management System (CapPro).

b. Expectation is that the solution will to be able to retrieve location information by selecting an area on an ESRI map using ESRI tools. The volume of GIS data collected will vary by incident.

Appendix E Vendor Product Questionnaire


City of Dallas

CIS Business Application Evaluation Document: Vendor Product Questionnaire


Appendix E - Product Vendor Questionnaire

Company Name:

Company Representative Name and Position:

Date questionnaire completed:

1. CIS Application Development:

Product Name Product Version

Question Vendor Response

Will we have access to database schema (entity relationship diagrams, keys, etc.) and data dictionary necessary for City IT staff to understand and access database tables as needed for purposes of report development?


We need diagrams documenting the application architecture and the various components involved in its support.


We need all technical details related to the software platform (OS, RDBMS, etc.).


How often are new releases or patches released?


What is the application’s compatibility with Crystal Reports?


How much of the application’s design, components,


Note: Please provide a copy of all published white papers related to this product. These papers must be available to the City of Dallas at least one week prior to any presentation.

etc. are “proprietary”?

2. CIS Data Center Facilities:


Give a brief description of the server environment.


Provide the exact number of servers that will be involved in this project.


List the recommended vendor and model number of each server and other hardware regardless of the delivery date(s).


Give the size of each server in “u” terms.

3. CIS Database Systems:


How much information is the system expected to process?


How many people will use the system at the same time?


Will there be a reporting component to this deployment?


What type of information will the users be entering into the system?



How frequently will they be entering this information into the system?


What type of legal requirements will the system adhere to?


What type of uptime is the system expected to have? Example: 24 hours daily, 12 hours daily, 8 hours daily

Database Engine Software


What platform is the vendor’s Database Engine hosted

Options:1. Microsoft Windows SQL 2. Oracle On Microsoft Windows3. Oracle on Unix4. DB2 on Microsoft Windows5. DB2 on Unix


Does this system require a minimum database version in order to operate normally? If the answer is YES to the question, please provide responses to the questions below:


Database Engine Minimum Version:

1. Microsoft Windows SQL Version2. Oracle On Microsoft Windows Version3. Oracle on Unix Version4. DB2 on Microsoft Windows Version5. DB2 on Unix Version

Database Engine License


What is the volume of data that this system is going to handle?



What is the structure of the database engine license.

Options Include:1. Server License2. Processor License3. Client Access or Named User License


If the license structure is Processor License, what is the vendor’s recommendation for a minimum processor requirement


If the license structure is Client Access or Named User License, please provide additional responses to the questions below:What is the minimum database license count the business unit is expecting at Go-LiveWhat is the estimated growth rate in database license count by year 2.What is the estimated growth rate in database license count by year 3 and beyond


Does this system require additional licensing for the application tier components?If the answer is YES, please provide additional responses to the questions below:What is the minimum application license count the business unit is expecting at Go-LiveWhat is the estimated growth rate in application license count by year 2.What is the estimated growth rate in application license count by year 3 and beyond


Will this system have messaging capabilities built in internally or will it utilize other messaging system for messaging services?


What OUTBOUND interfaces does this system provide? This may include both vendor provided interfaces and third party interfaces, including those presently being used in the City of Dallas.


Please provide the number of interfaces, their resource requirements, whether they are automated or manual


What type of ETL tools will the vendor provide for implementation?

Database Security


How will clients connect to this system. The options are listed below

Options Include:1. Connections are through web access2. Connections are through direct client connection

Please note Network and Security groups may request additional information. Including the recommendation for the purchase of SSL (Secure Socket Layer) Certificates

Hardware


What is the vendor’s hardware recommendation?


Is this system a turnkey system?

If the response to the above question is YES, please provide responses to the following questions.How many servers is the vendor recommending for this systemHow many of these servers will be used for database hostingHow many of these servers will be used for application tier hosting How many of these servers will be used for web interface hosting Will the vendor be responsible for managing all hardware issuesWill the City of Dallas be required to provide sizing and scaling recommendations for this system


If this system is not a turnkey solution, has the vendor


provided, or will provide hardware sizing recommendation to guide the City of Dallas in sizing and scaling the hardware for this system?


Will the vendor provide an architectural design document to use during the implementation?


What is the minimum number of processor count that this system requires in order to function normally?


On what platform is the vendor’s operating system solution hosted:

1. Microsoft Windows

2. Unix Solaris

3. Unix Linux

4. Unix AIX

5. Unix System V


What type and class of server is the vendor recommending?

Examples include the following classes:SUN Servers – Sun Fire X2100, X4200, V240, V490, V890

Intel Servers – IBM 3500 series, etc.


What is the amount of physical memory that this system requires in order to function normally. This amount does not include the memory already allocated by the operating system to the database engine.


Does this system require storage on the production SAN or will it be using the storage on the local server?


If this system requires storage on the local server,


what is the minimum amount of storage required for this system? Please do not include storage of other system on the server.


If this system requires storage on the production SAN, what is the minimum amount of storage that this system requires? Please do not include global swap space already reserved by the database engine.


Does this system require exclusive access and use of the server hardware?


If the response to the above question is YES, is the reason for using this system on an exclusive server hardware because of Legal reason, business unit requirement or other reasons?


Does this system require hardware encryption to protect its data during normal operations?

If the response is YES, please provide additional information on vendor recommendation for a hardware assist encryption.


If the database type is 2 tier or 3 tier, please provide additional information on the questions below:Will this system require a separate web server in order to communicate with its dependent tiers? Select the most appropriate responses from those listed below:

1. This system requires exclusive web server2. This system will run web services inside the

database engine space3. This system will run the web services inside the

application tier space


If this system has a web component, what type of web services will it use in production?

Options Include:1. Windows IIS


2. Tomcat3. Apache4. IBM WebSphere Portal


Will this system require load balancing? In a high network traffic environment, load balancing is implemented to efficiently distribute network traffic loads evenly among the various servers.


What type of reporting will this system provide. Please select the reporting types from the list below:1. This system will provide reporting to all business

units using built-in reporting functionalities2. This system will provide reporting to all business

units using external reporting engines3. This system will not provide any reporting


If the response to the question above is 1 or 2, does vendor’s implementation allow for separation of reporting instances between separate servers?


Will there be a need to maintain a very high availability environment?

If the response is YES, please provide responses to the questions below:What type of clustering solution does the vendor recommend?

Options include:1. Hardware clustering 2. Software clustering


What mode of clustering does the vendor recommend?

Options include:1. Active-Active clustering2. Active-Passive clustering

Question Vendor ResponseRFCSP DPD ALPR System of 106

Is this system very critical, requiring a Business Continuity planning as part of the scope?

If the response to this question is YES, please provide additional information below.How long can this system be off-line and unavailable before a switch to another system is made


What type of replication is the vendor recommending for Disaster Recovery purposes?


What type of failover is the vendor recommending?


Is there a need for a separate archiving storage?

If the response to the above question is YES, please provide responses to the following questions:1. What is the estimated annual data growth rate 2. What is the size of data that needs to be archived3. Are there any legal requirements for archiving

some data and not archiving others4. What types of parameters are to be used to

process archival data. Examples include dates, types of records, etc

5. At what frequencies will the archives be performed


Will there be a need to conduct training sessions using separate hardware?

If the response to the above question is YES, how many servers is the vendor recommending.


Will this implementation require hardware, separate from the production hardware to perform data migration?



Will this implementation require hardware, separate from the production hardware to perform regular testing, development, updates, and proof-of-concepts


prior to moving to production?


Non-Database Software


Is there any customized software, interfaces that this system requires?


What type of ETL tools will the vendor provide for implementation?


Provide the names of the customized software, interfaces that this system requires.


Provide the development platform for these customized software and interfaces.


Will the City be required to maintain this customized software?


How will this software and other software for this system be installed?

Options include remote installation or direct access installation


How will patch management be implemented on this system and who will be responsible for it?


At what frequency will the vendor provide patches and upgrades to this system?



What mode will the patches and upgrades for this system be delivered in:

Options Include:1. Patches and upgrades from the vendor delivered

through installation media2. Patches and upgrades from the vendor delivered

through manual web download

Patches and upgrades from the vendor delivered by system through automatic checking and web download


Will the City need to develop additional interfaces to this system?


Does the vendor have a preference on the type of high availability software on which their product will function normally without resorting to additional third party tools?

High availability software include Clustering software, replications software and load balancing software

Please note that the City’s standard for clustering is Veritas Clustering Software


Will the vendor provide additional training for implementing high availability solutions for this system to CIS staff?


If this system has a web component, will the vendor be responsible for configuring the above web services, including the security layers?


Will anti-virus services be deployed on the server supporting this system?

Operations

Question Vendor ResponseRFCSP DPD ALPR System of 106

How will the system be administered:

1. Vendor administers the system2. Joint City/vendor administers the system3. City administers the system

If the response to the question above is 1 or 2, please provide response to the question belowHow will the vendor require access to the server for operational issues?

Options Include:Remote Access using City supplied credentialsDirect Access using City provided credentials to physically gain access to the data center


Will the system have its own internal security or will it use the City’s Active Directory. NOTE: Preference is for the system to use the City’s Active Directory. Is the application Active Directory compliant?


Please provide the server events and database events to be monitored.


Will the CIS be responsible for monitoring the server events? …database events?


Who will be responsible for providing patch management for the server, including the host operating system?


Who will be responsible for providing patch management for the database system?


Who will provide reporting enhancement to the system if the needs arise?



Who will provide continuous training on the use of the system to the users?


How will archiving of static data be managed during operations?


How will data restore be handled if there is a need?


What is the escalation process for issues that are not resolved within the allotted time?


What would be the vendor recommended maintenance schedule?

Database Networking


What type of network type and/or protocol does the vendor require this system to be on?

Options Include:1. Ethernet2. IPX/SPX3. IP

Combinations of the above


Does this system use a different communications protocol other than the default that is available on the database engine?


Does this system require a dedicated LAN or WAN?


Does this system require encrypting data during transaction processing?



Will this system encrypt data internally at the database level?

If the response to the question above is YES, please provide responses to the questions belowDoes this system require hardware assisted encryption device?


How many network cards does the vendor recommend for this system in order to function normally?

4. CIS Information Security:


Please give a very brief description of what the system is for and how it will work:


Do you have any plans for the disposal, replacement or refreshment of the system?

How long is the proposed system expected to operate?


Please can you supply us with a high-level system diagram and a diagram showing what equipment will be used, where it is located and how it is inter-connected? (Attach to the back of the questionnaire)


What information will be stored on the system?

Does the system accept data from another system and if so, what?

Does the system send data to another system and if so, what?

Please can you supply us with a reasonably detailed diagram of the information flows within the system and between it and other systems?

Once the information is no longer needed, how will it be disposed of?



What are the principle methods of transporting information? Examples include (but are not limited to): HTTP “get”; FTP; remotely mounting a file-system (e.g. Windows fileservers, Unix NFS); email.


Will there be a need to encrypt any of the information exchanges? Please give details:


Is your requirement likely to need a name registered on the Internet?


If you are decommissioning, replacing or refreshing an existing system, how are you planning to destroy any relevant data and any cryptographic keys?


Is there a need to install any hardware devices that act as servers? Please indicate the types and estimated number of devices:Examples include, but are not limited to: file-servers, web-servers, email servers, media stores; application servers etc.


Is there a need to install any network hardware? Please indicate the types and estimated number of devices Examples include, but are not limited to: hubs, switches, bridges, firewalls, modems, wireless-LAN hubs, cabling etc.


Is there a need to install any client devices? Please indicate the types and estimated number of devices Examples include, but are not limited to: desktop PCs/MACs, PDAs, phones, editing stations, modems etc.



Please indicate if any of the devices (other than the clients) will not be installed in secured (locked) frame rooms owned and managed by the City of Dallas?

If the frame rooms are not CIS or CITY owned and managed, please indicate who does own and manage them.


Please indicate what operating systems will be running on the various devices described above.

Please explain which systems will be directly accessed by users (e.g. desktop systems) and which will run in locked frame rooms (e.g. servers).


If any Operating System is based on Microsoft Windows and will ever be connected to any City of Dallas packet network (including, but not limited to, the City’s IP/Ethernet network), it should comply with current CIS standards for supported versions and should be based on a CIS build. This includes CIS fileserver builds; CIS desktop builds; CIS web-server builds etc.

If this constraint will interfere with the system’s functionality and (if compliance is not possible), please give details of how the systems will be built, patched, supported and regularly tested. [NB, non standard builds, even if approved from a security perspective, might incur an increased support charge].


If the Operating System is based on Microsoft Windows, or if the Operating System uses file-mounting technology, such as NFS or SMB, or file-transfer technology, such as FTP, the device MUST run a CIS approved, real-time virus-scanning system.

Please indicate if this constraint will interfere with the system’s functionality and (if compliance is not possible) give details of how the system will be protected from the viruses and Trojans and how it will be prevented from infecting other systems (should it become infected).


Does any of the information stored in a fileserver need to be cryptographically secured against


viewing or changing?

Does any of the information need to be “signed” to prove its origin?

How is it intended to perform the encryption/signing?

How will the keys be stored, transferred or destroyed?


Will the system require the installation of any “shrink-wrapped” software (e.g. video editing software, word-processors etc.) that will ever be run on City of Dallas standard servers and desktops, or run on systems connected to any City of Dallas network. If so, please indicate whether the software has gone through (or is going through) the CITY approval process.


Will the system require the installation of any database system (e.g. Oracle, SQLServer etc.)?

If so, please give 1) product names, 2) the expected number of Server licenses & 3) the expected number of Client licenses.


Will the system require the development of any software?

If so, please indicate whether this is being built in house or outside of the City of Dallas.


What languages/platforms are being used?


What process and procedures will be applied to ensure the software is well written and designed to avoid security design faults?

How will the software be maintained during its lifecycle?


Does the software need to exchange information directly with another internal City of Dallas application?


How is this achieved?


Does the software need to exchange information directly with an external, non-City application?

How is this achieved?


Does any of the information stored by a database or application need to be cryptographically secured against viewing or changing?

Does any of the information need to be “signed” to prove its origin?

How is it intended to perform the encryption/signing?

How will the keys be stored, transferred or destroyed?


Please give a brief description of how the system is expected to use and interact with network technologies. A diagram should also be supplied.


Is the system dependent on “addressable” network protocols, such as 1) Telephony technologies – e.g. dialed-ISDN, dialed-telephony, X25, Frame-Relay, ATM-SVCs and/or2) packet data technologies – e.g. Ethernet, NetBIOS, (TCP/UDP)/IP?


Will any computers, PCs, Servers, PDAs, appliances etc. need to operate with two network interfaces at the same time? Examples include (but are not limited to):

1) a PC with two network cards, one of which is connected to the City’s VOIP Network, and the other to a private network. 2) A PC with a network card connected to the City’s VOIP Network and a modem connected to the Internet (e.g. via dialup or DSL) or a 3rd party’s network. 3) A PC with a network card connected to any City’s VOIP Network and a modem connected to the Internet (e.g. via dialup or DSL) or a 3rd party’s


network. 4) A device connected to the City’s VOIP network and a 3rd-party Wireless Hot-spot.


Please indicate if the intention is to run the system over its own physical or logical LAN or WAN infrastructure inside the City of Dallas.

If so, please explain your reasons for not using the City’s own internal network infrastructure.


Other than via the City of Dallas’ RAS systems, externally-initiated dialed-telephony, ISDN links and IP connections are not permitted to be connected via Modem or ISDN-Terminal-Adapter to any City of Dallas systems which run Operating Systems (such as Windows, Unix, VMS etc.) or are connected to the network via Ethernet/IP connections. Please indicate if this constraint will interfere with the system’s functionality.


Internally initiated IP connections based on HTTP, HTTPS, Telnet, FTP, Real and Socks are permitted. Please indicate if these protocols are not sufficient for the system. In some cases, if a dedicated firewall is required, there may be a charge for installation and support and this will need to be budgeted for.


What requirements will the system have in terms of automated network services, such as DNS (machine naming), DHCP (machine addressing), WINS (machine naming), LDAP (user and machine directory lookup), NTP (time services) etc?


Is there any need to set-up a cryptographically secure link between two network devices (e.g. a IPSEC VPN or SSL link)?

How will this be achieved?

How will the end-nodes be protected against attack?

How will the keys be created, exchanged, stored and destroyed?



Some systems do not support user and administrator accounts. Other solutions may not be usable when accounts and logins are enabled. Please indicate if your system fits into the category and explain how the system is able to detect who is doing what to the information that it is handling.


Some systems do not offer a means of proving who the user is. Other solutions are not able to function properly if the users and administrators have to prove their identity. If your system fits into this category, please indicate this and give some details on how the system prevents a user (or even a complete stranger) from processing information that they are not supposed to have access to.


How do the users and administrators uniquely identify themselves to the system (e.g. username, smart-card etc.)?


If relevant, how do other applications or systems that need to gain access to the data uniquely identify themselves?


How do the users and administrators prove that they are who they say they are (e.g. password, smart-card, securID etc.)?

If passwords are used, will they be configured to meet the City’s Information Security guidelines for password length, complexity and frequency of updates?


If relevant, how do other applications or systems that need to gain access to the data prove that they are the system they claim to be?


How does the system hand out the necessary privileges needed for an individual to do their job?

How does it prevent people or systems accessing material or information if they don’t have the right?



If relevant, how does the system hand out the necessary privileges for another application or system to gain the correct access to information?

How does it prevent access to the wrong material?


Will your system be able to integrate with any or all of the following: Microsoft NTLM authentication? Microsoft Active Directory? RADIUS? Kerberos? PKI?


What logs are kept of successful/unsuccessful usage attempts?


What training will be needed by users and administrators to ensure they understand how to use and operate the system securely?


Appendix F - Sensitive, Personal,Commercial Information and Legal ConsiderationsThere are a number of laws and directives which might have an impact on your system design. These include (but are not limited to):

Health Insurance Portability & Accountability Act of 1996 (HIPAA) as amended

Health Information Technology for Economic and Clinical Health Act (HITECH) of 2009

Texas Health and Safety Code, Chapter 181 as amended

Texas Health and Safety Code, Chapter 773

Copyright Designs and Patents Act 1988

Computer Misuse Act 1990

Data Protection Act 1998

Human Rights Act 1998

Consumer Protection (Distance Selling) Regulations 2000

Electronic Communications Act 2000

Regulation of Investigatory Powers Act 2000

Freedom of Information Act 2000

Anti Terrorism, Crime, and Security Act 2001

Electronic Commerce Regulations 2002

Electronic Signatures Regulations 2002

Privacy and Electronic Communications (EC Directive) Regulations 2003

You will need to indicate if your system needs to comply with any of the above.


Will the system need to store information about living individuals?


Will the system be used to store financial details?

Will it need to store credit card details?


Does the system need to be registered under the terms of the Data Protection Act?


Please state which legislation applies (see the list


above).


Will the system have a site or portal enabling external users to contact the City of Dallas?


Will the system have information that is held for legal compliance reasons?


What information will an external user need to provide and what is the purpose of their interaction with the system?


Does the system need to keep functioning even if local services (such as human access to the site and mains/chilling) are restricted due to an unforeseen event?


If the system is affected by an external event, how long can it be unavailable before major problems ensue?

1. Product Documentation:

Product Documentation


What documentation is available with this product? In what formats is the documentation available? Does some or all of the documentation require online support or internet connectivity?

Data Dictionary


Do users of this product get an updated copy of the data dictionary with every release of the product?

2. Product Training:

Time To Train a CSR



How much time it take to train a CSR to use the system?

Time To Train Operations Support Personnel


How much time is required to train operations support personnel?

3. External Interfaces:

External Interfaces


What are some of the common external interfaces built into the product? How difficult is it to incorporate a new external transaction interface to the product?

4. Performance and Capacity Management:

Capacity and Performance Benchmark


Have any tests been performed to measure the throughput capacity and overall performance of the product? If yes, were these test done at an independent site or the vendor’s laboratory? If these tests were documented, please provide a copy of the document prior to any product architectural presentation.

Number of Concurrent Users


What is the maximum number of concurrent users allowed by the system without any performance degradation?

5. At the City of Dallas:

Product Currently being Used at the City of Dallas


Is this product or some other version of the product currently being used at the City of Dallas?

Other Products of Your Company


Are there any other products of your company currently being used or evaluated at the City of Dallas? Provide details.

Appendix G - Features Response FormRFCSP DPD ALPR System of 106

Proposers should complete this Features Response Form and return it in this format. All rows of the form should be answered as completely as possible. See section 7.2 above for instructions on how to respond.

7.3 Non-Functional Requirements List

Non-functional requirements captures conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution should remain effective or qualities that the system should have. They are also known as quality or supplementary requirements. They do not have a documented use case.

The following list represents the non-functional business requirements for the ALPR System.

Req # RequirementProposer’s Response

Additional Costs

Comments

7.3.1 Usability

7.3.1.1The fixed system ALPRs must be able to quickly be relocated if necessary.

7.3.1.2The mobile system ALPRs must be able to quickly be relocated to other vehicles if necessary.

7.3.1.3System configuration must be flexible and easily scalable.

7.3.2 Reliability

7.3.2.1

The system will have the ability to will provide a minimum guaranteed service availability rate (uptime rate) of at least 99.9 percent.

7.3.2.2The system will Operate continuously: 24 hours a day 365 days a year

7.3.3 Performance

7.3.3.1

The ALPR system should be able to accurately read, compare, and record license plates with an accuracy rate of 85 % for both fixed/mobile systems.

7.3.3.2

The ALPR system should not have any limitations on the # of plates that may be read and processed through the entire lifespan of the system.

7.3.3.3

For interactive connections (for plate updates) for the MDCs, the City uses cellular broadband connectivity using NetMotion. The ALPR system must be able to connect & communicate with this technology.

7.3.4 Supportability

7.3.4.1

The system must enable staff to add new hardware, software upgrades, and or maintenance without disruption of service 7 days a week / 24 hours a day.

7.3.5 Security

7.3.5.1The system must have the ability to meet or exceed industry standard security requirements.


7.3.5.2The system must comply with all Criminal Justice Information Standards (CJIS) requirements.

7.3.5.3The system must utilize encryption technology to secure video feeds.

7.3.5.4The system must meet minimum FIPS and NIST security standards.

7.3.5.5The system must be active directory compliant as to user authentication.

7.3.5.6

System should be secure to prevent unauthorized access and provide layers of access security for users.

7.3.6 Maintenance/Serviceability

7.3.6.1The system must be easily serviceable for repairs and maintenance.

7.3.6.2The Vendor must provide maintenance coverage plan including:

7.3.6.3Routine services provided on a periodic basis such as onsite maintenance and cleaning.

7.3.6.4

Routine and as needed lens cleaning from condensation, rain, ice, dust, dirt or any other obstruction.

7.3.6.5Emergency response services including guaranteed response time

7.3.6.6 Hours and days of coverage

7.3.6.7Equipment replacement procedures, including onsite or depot parts repair and replacement

7.3.6.8

Response time for each service call, including:a. System Outageb. Network control center outagec. Camera network outage impacting 25% of cameras

7.3.6.9Escalation procedure from first call to highest level respondent

7.3.6.10Detailed procedure showing knowledgeable first-time response to service calls

7.3.6.11

Detailed breakdown of all maintenance costs for all equipment, software and services beginning at the end of the warranty period and extending through year five.

7.3.6.12 Any Optional Maintenance service plans.7.3.7 Support

7.3.7.1The Vendor shall detail the technical and operational support that will be provided:

7.3.7.2

Telephone support (e.g., include toll-free support hotline, hours of operation, availability of 24 x 7 hotline, etc.).

7.3.7.3Special plans defining “levels” of support (e.g., tier 1, tier 2, etc.).

7.3.7.4

Delivery method of future upgrades and product enhancements including historical frequency of upgrades by module.

7.3.7.5 Problem reporting and resolution procedures.

7.3.7.6 Bug fixes and patches.7.3.7.7 Support provided for third-party solutions.


7.3.7.8Other support (e.g., on-site, remote Web site access to patches, fixes and knowledge base).

7.3.8 Texas Occupational Code

7.3.8.1

The Vendor that will access the City’s network or install equipment must be appropriately licensed and certified under Texas Occupational Code 1702 as a Security Company and to maintain that license / certification for the life of the contract.

7.4 Control Requirements List

The following list represents the control requirements for the system. Control requirements include Regulatory / Legal, Financial control, and City of Dallas Policy requirements. Each of the sections below should be filled out. If there are none identified for an area, it should say “There are none identified”.


Additional Costs

Comments

7.4.1 Regulatory / Legal

7.4.1.1

The system must comply with all Criminal Justice Information Standards (CJIS) requirements.

7.4.1.2 This system must comply with all State of Texas laws

7.4.1.3

This system must comply with all City of Dallas Local Judicial Rules

7.4.1.4

The system must comply with FIPS and NIST standards

7.4.2 Financial Control


7.4.3 Business Continuity


7.4.4 Policy7.4.4.1 There are none identified


7.5 Functional Requirements List

The following list represents the functional business requirements for the ALPR System.

Note: Each requirement relates to a component of an Activity described and modeled in this section of the specification. Detailed functionality, business rules, constraints and conditions for each of these requirements can be found in the detailed use cases associated with the requirement. Business rules for information used by the system are found in the Information Section with the data elements.


Additional Costs Comments

7.5.1 Hardware Specifications

7.5.1.1

System must be comprised of self-illuminating Infrared (IR) cameras for effective license plate image capture in a variety of weather and lighting conditions.

7.5.1.2

The System must also be able to read temporary issues license plates. (example: paper printed plates)

7.5.1.3The Infrared (IR) Light Emitting Diodes (LEDs) must be “pulsed” to enhance license plate capture.

7.5.1.4

All cameras must have a dual lens configuration in a single camera housing featuring both an Infrared (IR) lens for license plate capture and a color overview image of the vehicle.

7.5.1.5

The integrated color and infrared LPR cameras must not emit any visible light from infrared illuminators.

7.5.1.6

The System must have a “self trigger mode” to detect the presence of lawfully mounted vehicle license plates in the camera’s Field of View (FOV)

7.5.1.7

The cameras must be capable of producing multiple license plate images with varying Shutter and Gain Settings to ensure a high quality image regardless of weather or lighting conditions.

7.5.1.8

The cameras must be capable of being permanently attached to the vehicle’s emergency lightbar in a low profile manner to minimize impact on the lightbar system without drilling multiple holes or violating the integrity of the roof structure.

7.5.1.9

Cameras should be attached to the light bar without interfering with visibility of the complete light bar. Cameras should be no larger in size than 2” height, 8” width and 4” depth.

7.5.1.10There must be no moving parts in any of the cameras.

7.5.1.11 The cameras must have a fixed focal point or target distance from the camera to the vehicle license plates from a minimum of 6 feet to a maximum of 34




feet under a standard camera configuration.

7.5.1.12

The ALPR Processor must be designed to be trunk mounted or similarly mounted and must incorporate an intelligent Power Supply Unit (PSU) that provides for a safe start and shut – down each time the vehicle’s ignition is turned on and turned off.

7.5.1.13

The ALPR Processor must control the electrical power source supplied to each of the cameras and provide video connection points for simplified System wiring.

7.5.1.14The ALPR Processor must have an operating input range of 10.5-16.5V DC at 90W.

7.5.1.15

The ALPR Processor must be designed to meet the environmental conditions associated with a trunk-mounted unit under various temperature conditions.

7.5.1.16

The System must provide for the simultaneous display of any two (2) cameras as selected by the User and configured by the System Administrator.

7.5.1.17The System must be capable of capturing license plates in any of the following modes:

7.5.1.17.1

an adjacent lane on either side of the police vehicle while driving through traffic and/or parking lots

7.5.1.17.2

traffic in an adjacent lane while parked on the side or shoulder of a roadway;

7.5.1.17.3

any parking application from parallel to perpendicular parked car orientation with respect to the movement of the police vehicle

7.5.1.17.4

an adjacent lane to capture the rear license plate of the vehicle as it passes the police unit or vice versa.

7.5.1.18

The camera configuration must be capable of switching from one monitoring mode to another via the software application by merely “pressing” the corresponding On-Screen Function Button.

7.5.1.19

The System must provide effective license plate capture at night and in reduced light situations and total darkness with no external lighting required.

7.5.1.20

The System must have the capability to capture a still image of importance at the officer’s discretion using the color overview portion of the Camera.

7.5.1.21

The System must have the capability to capture vehicle license plates at combined speeds up to 130 mph with license plate capture and read accuracy rates (referred to as “System Efficiency”) in excess of 85%. Bidder to provide independent test results from at least three North American law enforcement agencies verifying your accuracy claim.

7.5.1.22

When the System is configured to utilize an independent ALPR processor, the ALPR Processor and the cameras must be developed, manufactured and supported by the same vendor.

7.5.1.23 All camera cabling and camera connectors must be RFCSP DPD ALPR System of 106



manufactured or assembled by the vendor that provides the ALPR System and all of the required components.

7.5.1.24

All camera mounting bracket systems must be fabricated specifically for the vendor’s cameras and must be furnished by the vendor.

7.5.1.25

In addition to the camera mounting bracket systems that attach to the vehicle’s emergency lightbar, the vendor must also provide camera-mounting bracket systems that can be installed on those police vehicles commonly referred to as “unmarked units” or those with no roof-mounted lightbar.

7.5.1.26

In addition to camera mounting bracket systems for marked and unmarked police units, the vendor must also provide a magnetic mount that is made specifically for the cameras. The Magnetic Mount is designed to be used for temporary deployment of the System.

7.5.1.27

The system must also be able to be mounted in fixed locations such as light poles, traffic signal poles, utility poles, bridges, or buildings.

7.5.1.28

The system must be able to read and process license plates accurately in “High Traffic” areas such as intersections, highways, or bridges.

7.5.1.29

The fixed ALPR’s must be powered by an uninterrupted power source, which may include hard wiring and/or solar technology.

7.5.1.30The fixed ALPR’s must be refreshed with updated license plate database information wirelessly.

7.5.1.31

The vendor is expected to manage the entire process for installation and relocation of fixed systems: gather permits, utility agreements, camera assembly/disassembly, installations, network setup, configuration, and testing.

7.5.2 Software Specifications

7.5.2.1

The application software must be capable of supporting multiple “hot list” databases including but not limited to

7.5.2.1.1 NCIC Databases7.5.2.1.2 TCIC Databases7.5.2.1.3 Registered Sex Offenders vehicles 7.5.2.1.4 North Texas Regional Wants and Warrants

7.5.2.1.5 BOLO (Be On the Lookout)

7.5.2.2The system must allow a System Administrator the ability to add additional databases as necessary.

7.5.2.3

The System Administrator must have the capability to define the police department’s database/s and assign a color code and priority level to each database to be used when a ‘match’ or a ‘hit’ occurs, i.e., stolen vehicles, stolen license plates, sexual predators, armed felon suspects, registered parolees, etc.

7.5.2.4The data file transfer must be accomplished by either of the following methods, listed by priority, but




not limited to:7.5.2.4.1 Wireless7.5.2.4.2 Ethernet

7.5.2.4The system must utilize security encryption technology to secure all data transmissions.

7.5.2.5The System must be able to be refreshed with updated data up to once every hour.

7.5.2.6

The application software (GUI application) that resides in the police unit must be Active Directory compliant that provides for a User Name and Password as assigned by the System Administrator.

7.5.2.7

The application software must be responsive in comparing a captured license plate against multiple and voluminous databases with less than a 1.5 second response to a query of a database/s containing up to 10,000,000 records.

7.5.2.8

All license plate and system data remain the DPD’s/City’s property and is not to be shared or shared amongst any system without the City’s written consent.

7.5.2.9

The System should have the feature that allows “hot list” databases to be created in the field by authorized users and the authorized users must have the capability to add license plate data to the system’s database/s while in the field. All license plate data added by the authorized user will remain a part of the selected database until the database is ‘overwritten’ by the System Administrator or by a new or updated database/s.

7.5.2.10

The System must provide a “Rules” Feature whereby the System Administrator can define license plate numbers and/or characters that can be interpreted in different variations or “rules.”

7.5.2.11

The vendor must provide variants of the Optical Character Recognition (OCR) Engine that are tailored/designed for a specific State or regional license plate population

7.5.2.12

As part of the vendor’s system maintenance agreement with the customer, Optical Character Recognition (OCR) updates and/or revisions must be provided as determined by the vendor to address changes in the State’s license plate population during the term of the maintenance agreement.

7.5.2.13

The system must provide all of the following live, simultaneous video display of data for cameras as selected by the User:

7.5.2.13.1 The IR License Plate Image7.5.2.13.2 The license plate interpretation or system read

7.5.2.13.3A corresponding color overview image of the vehicle displaying the captured IR license plate

7.5.2.13.4The date and time the data was captured by the System

7.5.2.13.5 Identification of the Camera capturing the image

7.5.2.13.6 The GPS Coordinates for every license plate




captured by the System

7.5.2.14

Even though the System must provide for the simultaneous display of two (2) Cameras as selected by the User, the System must also have the capability to be configured whereby up to all 4 Cameras are operating simultaneously and matching license plate data against the databases.

7.5.2.15

When the system identifies a “match” or a “hit” of the license plate, the following additional data must be displayed in a timely manner on the system’s Hit Screen:

7.5.2.15.1

The color coded database indicating the name or title of the database as assigned by the System Administrator where the “match” occurred.

7.5.2.15.2All narrative text, if any, from the database where the “match” Occurred

7.5.2.16

The Hit Screen must remain displayed until acknowledged by the officer, and while displayed, the system must continue to process license plate data in the background and all captured data must be stored in the System during this interval without any User intervention. In the event that a subsequent “match or hit” should occur while the original Hit Screen is displayed to the officer, the System must provide an audible and visual alert to the User that a second or subsequent “hit” occurred and the System is waiting for the (User’s) officer’s intervention.

7.5.2.17

The System must provide a touch screen feature to enlarge the vehicle’s color overview image so that the User can examine it in order to gain additional information about the overview image or the verification of information.

7.5.2.18The System must provide touch screen navigation capability for the police application GUI.

7.5.2.19

The System must provide the System Administrator with the ability to customize audible alerts to differentiate between unique events within the software application.

7.5.2.20

The System must provide a visual alert for each defined event that displays in the foreground regardless of other applications in use at that time if the System’s Client-Server Architecture is utilized.

7.5.2.21

The System must provide the officer with the capability to mark a license plate read as a “misread.”

7.5.2.22

The System must provide the officer with the capability to manually enter a license plate, via a vehicle’s MDC, for the purpose of searching that license plate against the System’s database/s.

7.5.2.23The System must provide the officer with the capability to review all of the following:

7.5.2.23.1 “hits” license plate images and associated data license plate searches performed by the officer indicating the date and time the search was




Conducted pictures

7.5.2.24

The System must provide the officer with the ability to query the GUI application in the police vehicle to determine if a particular license plate is currently stored in the System. If the license plate data is in the System, the officer must have the ability to review each license plate capture and the associated System data displayed on the GUI application Review Screen to include:

7.5.2.24.1 The IR License Plate Image

7.5.2.24.2The corresponding color overview image of the vehicle

7.5.2.24.3The date and time the image was captured and the GPS coordinates or the captured data

7.5.2.25

The Proposer must demonstrate the systems ability to cohabitate with TriTech Software System’s VisiNet Mobile and Intergraph’s inPursuit systems.

7.5.3 Back Office/Analysis/Admin Specifications

7.5.3.1

As part of the overall System and functionality, a customized back – office software application must be provided by the vendor so the customer can manage all the data collected by each individual police unit, manage the database functions, provide reporting data and manage the user administration functions.

7.5.3.2

The System must provide the ability to assign priorities to the various databases utilized by each police agency.

7.5.3.3

The System must provide the System Administrator with the ability to configure for the regular import of national and local databases.

7.5.3.4

The System must provide application security via Active Directory that requires a User Name and Password for each User as determined by the System Administrator.

7.5.3.5

The System must provide the System Administrator with the ability to determine System user access levels based upon user responsibilities.

7.5.3.6

The System must provide remote web access, via Internet Explorer 6.0 or higher, to stored data for analysis and reporting.

7.5.3.7

The System must provide the ability to perform a full or partial license plate query against the databases. Examples include partial license plate numbers/letters with missing or unknown characters in varying positions on the plate.

7.5.3.8

The System must provide the ability to query for license plate data based upon time, date, location and the user.

7.5.3.9 The System must provide the ability to utilize a mapping function to plot or identify the locations of a particular license plate or identify all plates captured




in a particular area during a particular time. The City currently uses ESRI mapping sofware and it would be ideal for the system to leverage existing mapping software.

7.5.3.10

The System must provide the ability to utilize a mapping function to plot or identify the location of all “hits.”

7.5.3.11

The System must provide multiple methods for downloading and uploading information between the vehicle and the back – office application including Wireless, and Ethernet. A centrallized uploading process may be leveraged that would allow for patrol vehicles to automatically upload information upon returning to substations via wireless technology.

7.5.3.12

System must provide a server network environment to facilitate the sharing of data between other police agencies as defined by the System Administrator.

7.5.5 Other System Requirements

7.5.5.1A full and complete set of operating instructions shall be included for the system

7.5.5.2

The vendor shall warranty the System to be free of defects in materials or workmanship. This warranty shall not extend to finish, appearance items, or malfunction due to abuse, neglect, misuse, accidents or operation under other than specified conditions.

7.5.5.3

The vendor shall have a dedicated service department locally based in the Dallas/Fort Worth area and may not contract out the warranty or the follow-on service plan. Service response shall be within four hours from notification of system casualty.

7.5.5.4

All hardware and software provided by the vendor must be covered under a 5-year parts and labor warranty at no additional cost to the customer during the first year of service.

7.5.5.5

The Provider must furnish extended warranty/maintenance costs for both hardware and software for up to five (5) years from the date of System installation.

7.5.5.6

After issuance of the Purchase Order, all hardware and software must be delivered to the customer site within five (5) weeks.

7.5.5.7

The successful vendor must provide role based on-site System training for the System Users and the System Administrators as required by the customer. Vendor is responsible for providing electronic and hard copy documentations. City will be responsible for providing an environment conducive to learning.

7.5.5.8

The successful vendor must provide System installation and/or System installation oversight based upon the customer’s requirements.




7.5.5.9

The successful vendor must provide local field support and provide onsite or offsite support, at a minimum, between 8:00 AM – 5:00 PM CST.

7.5.5.10

The vendor will serve as a single point of contact, and provide the name, address and telephone number of the individual to contact when both on-site and remote maintenance is required. The vendor shall further provide escalation procedures and contact names and numbers to be used when normal maintenance procedures are not adequate to resolve problems.

7.5.5.11

All System documentation must be furnished in electronic format.All training material must be furnished in modifiable electronic format.

7.5.5.12

The IR cameras must meet “eye safe” certification standards, as established by an international testing agency.

7.5.5.13 The IR cameras must be sealed to IP67 Standards.

7.5.5.14

Vendor must assist City of Dallas/Dallas Police Department in testing the license plate scanner implementation.
