Appendix C - CAD Technical Requirements Response .docx

Appendix C: Technical Requirements Response

RFP #354-PD25-34

Project Title: Computer Aided Dispatch (CAD) System Replacement Project v.04.15.24

TECHNICAL REQUIREMENTS RESPONSE

Cary expects the CAD system to satisfy the capabilities described in the Use Cases in Appendix A and meet the detailed Functional and Non-Functional requirements described in Appendix B.

For Appendix C (this Form) the Bidder is encouraged to provide a narrative response to each of the items listed and, where relevant and appropriate, provide any diagrams, screenshots or other visual information to support the narrative response. The objective of the information provided in this document is to gain some specific insight into the Bidder’s proposal and their perspectives as it relates to priority domains and technical attributes associated with the Bidder’s proposed solution.

1. Alignment with CAD guiding principles

1.1. Describe how the proposed Solution aligns with Cary’s CAD Guiding Principles, as presented below:

· Equitable Service. The CAD approach must deliver an equitable service to all PSAPs and their users.

· Enhanced User Experience. The CAD must promote user experience efficiencies, provide the most appropriate/informed decision-making capabilities, including dynamic dispatching of predetermined customized responses, reduce the risk of human error, and enhance the user experience.

· Enhanced Navigation. The CAD must deliver accurate real-time mapping capabilities, eliminating the need for manual validation and enabling timely turn-by-turn navigation.

· Enhanced Situational Awareness. The CAD must provide the ability to view multijurisdictional responses, closest unit capable response, provide situational data on facility premise needs, provide up-to-date weather statistics, and provide live status capabilities of on-scene assets and personnel.

· CAD Independence. The CAD will provide a set of common capabilities for all PSAPs, without constraining a PSAP’s local CAD strategy. The CAD must afford the capability to work remotely without any degradation to user capability.

The adoption of the CAD will be considered optional for regionalized PSAP optimization, aligning with Cary’s strategy for enhanced interoperability.

· Integration and Interoperability. The CAD must enable interconnectivity between as many Public Safety PSAPs as possible to provide the required capabilities to best achieve scalable regionalized interoperability capabilities.

· Bi-Directional Communication. The CAD must allow bi-directional communication between multiple PSAPs and CAD platforms while complying with existing operational controls and tiered response agreements. CAD-to-CAD transfers should be fast, reliable, secure, and maintain a consistent, compatible format, allowing additional interfaces to be added as required.

· Feasibility and Scalability. The CAD system must be realistically achievable, meet the fundamental needs of each of the PSAP stakeholders, and enable future business requirements to be met with a flexible solution architecture that provides for greater mobility and scalability.

· Optimal Security. The CAD must incorporate cybersecurity mechanisms to meet requisite security and trust standards for PSAPs and stakeholder access and data exchange.

· Affordability. The CAD must be affordable and cost-efficient for Cary’s PSAP and each of the Stakeholders.

· Resilience and Robustness. The CAD must be designed for resilience to ensure minimal business disruptions. It should maintain system continuity by meeting network access requirements and providing both cloud-capable and infrastructural redundancies.

· Change-Friendly. The CAD adoption must not disrupt current operations and minimize change management requirements. The CAD must also allow for the adjustment of nature codes, response planning, and predictive structure parameters.

· Cloud Optimization. The Vendor should offer cloud optimization capabilities to ensure efficiency and high levels of performance.

2. Data

2.1. Data will be readily accessible and extractable, in a non-proprietary and human-readable format. Cary seeks on-demand and comprehensive access to all its data, in an open format, regardless of how it is managed by applications in the solution. Please describe the proposed solution’s details relevant to this item.

2.2. CAD is expected to share / send data with other CAD systems (see Appendix E – CAD Interfaces) and therefore is the transport mechanism and is responsible for the translation of certain data (such as type / nature codes, addresses). Describe how the CAD system ensures that incident data from one CAD system can be effectively and accurately sent to and received by another CAD system. The response could include the design, architecture, security and/or monitoring aspects of the proposed solution.

2.3. CAD is expected to share / send data with RMS systems and therefore is the transport mechanism and is responsible for the translation of certain data types. Describe how the CAD system ensures that the correct predefined data can be effectively and accurately sent in a format that is reliable and consistent to meet reporting and compliance requirements.

2.4. CAD is expected to interface with external data sources and seamlessly ingest the relative information, formatting it appropriately to populate within the calls for service information accurately.

3. Technology Ecosystem

3.1. The CAD solution is expected to interface with external systems. Cary favors solutions with loose coupling and commonly used integration platforms. Cary seeks to utilize only mainstream middleware that is widely used. Please describe the proposed solution’s details relevant to this item.

3.2. The underlying technology stack used to develop the CAD must be proven. Cary is not an early adopter of new application platforms and technologies within this emergency communication environment. Cary favors proven application / IT technologies over “bleeding edge” alternatives. Please describe the proposed solution’s details relevant to this item.

4. Solution Components

4.1. Provide a diagram with a supporting overview of the overall proposed Solution architecture, including components and dependencies. Describe how the components interact with one another and where, if any, risks or single points of failure may exist.

4.2. Provide a technical description of the proposed Solution’s hardware and infrastructure software components and how the proposed architecture / deployment model supports the specified availability and performance expectations.

5. Implementation Method

5.1. Describe the Bidder’s proposed approach to:

· requirements elicitation and how that approach leads to consensus building across multiple stakeholder groups.

· requirements traceability from the point of elicitation through application sustainment

· data modeling and database design

· management and monitoring of application development activities and progress,

· testing and demonstrating the security of the code and software developed

· user and technical training

· quality assurance including testing and defect management

6. Hardware / Sizing

6.1. Describe the number of servers, as well as the size and specifications that will be required to achieve target service levels/performance targets. (For Cloud solutions, describe how the solution is designed to achieve target service levels/performance targets).

6.2. Describe how the system’s recommended sizing specifications support optimal growth in response to ongoing municipal expansion and agency consolidation.

6.3. Describe the Operating System(s) proposed to run on servers and any other relevant solution components.

6.4. Describe the proposed hosting model for the solution.

6.5. Provide a detailed explanation of how your architectural design incorporates resilience and redundancy.

7. Deployment

7.1. Describe your approach to implementing patches/fixes, minor and major upgrades to CAD, and any sub-components, after the initial release (CAD ‘go-live’).

7.2. Maintenance windows should be minimized for major changes, while minor changes should not require planned downtime. Cary favors solutions that support a maintenance model where changes can be rolled out to users without taking the system offline. For major changes, where this is not feasible, the maintenance windows should be minimized and predictable. Please describe the proposed solution’s details relevant to this item.

7.3. Deployments in test and production environment will be simple, low-risk, and automated. Deployment of new versions of the solution into test, and ultimately production environments, will be automated, following DevOps best practices. The deployments will be simple and entirely predictable, with a proven fallback/restore of service option. Please describe the proposed solution’s details relevant to this item.

8. Licensing

8.1. Describe the licensing and/or subscription model(s) available for any applicable licensed components of the CAD (concurrent users, total users, server cores, enterprise, other). Indicate the specific licensing model to be provided to Cary and used to quote the price found in the RFB Cost Proposal.

8.2. Describe how the licensing model accommodates scaling up or down of users or agencies on a quarterly or yearly basis.

8.3. Describe the compliance requirements for licensing, whether there are regular system audits, and how they are addressed annually.

8.4. Describe how the licensing model addresses disaster and recovery environments (cloud and on-premises).

9. Auditability

9.1. Describe the auditing/logging functions of the CAD such as what in CAD is audited, how the audit trail is created and stored, and how the audit trail is accessed by the CAD Administrator or other appropriate user(s). (ex. User Access, Version Control, Compliance & Standards, Security Measures, Data Retention Policies, Integrations, Training and Support)

10. Service Level Availability and Response Times

10.1. Describe characteristics of the Solution in terms of:

· The ability to meet the requested uptime and high availability performance expectations described in the RFP and detailed requirements.

· Other assumptions and/or parameters that Cary should be aware of in order to meet the service level objectives/performance expectations.

· Disaster recovery and business continuity, how the system will be backed up as part of the continuity planning process to ensure data integrity and system availability in case of a failure.

11. Security

· Describe the Bidder’s approach to security and the proposed Solution’s security capabilities in terms of the following:

· Use of industry-standard protocols and open systems technology, such as: American National Standards Institute (ANSI); National Committee for Information Technology Standards (NCTIS); Object Management Group (OMG); Organization for the Advancement of Structured Information Standards (OASIS); National Information Exchange Model (NIEM).

· How the Solution audits user access and privilege use and the information that is logged, including a sample report if possible.

· Describe layers and types of encryptions used and the type of data to which the encryption is applied and when.

· Describe how the Solution encrypts data between the servers and clients, including if that encryption is FIPS 140-2 certified.

· Describe the ability to protect data “at rest” and “in transit” so that unauthorized users cannot access it. Describe how the Solution will accomplish this.

· Describe how the Solution provides real-time monitors for potential security violations, anomalies, and/or breaches and provides alerts, notifications, and reports regarding security violations and breaches.

12. Supportability

12.1. Describe how the Solution is monitored, including internal capabilities and the use of third-party system monitoring tools.

12.2. Describe how the Bidder proposes to provide support for Cary and its CAD users. Explain the frequency and communication methodology for each of the stakeholders surrounding system maintenance.

12.3. Describe how the Bidder proposes to provide a comprehensive system documentation (User Manuals, technical guides, and troubleshooting documentation)

12.4. Describe how training and onboarding for new users and ongoing training for existing users will ensure proficiency in system utilization (Access to online tutorials, webinars, and training materials).

12.5. Describe your routine and schedule for system maintenance, including how updates and service packs are handled. And the process by which they will be implemented to reduce overall disruption to operations.

13. Interfaces

13.3. Provide a detailed list of supported interface protocols (e.g. RESTful APIs, SOAP, XML, JSON, etc.) and how the system can integrate with existing systems, such as records management systems (RMS), geographic information systems (GIS), and other public safety applications.

image1.png