Appendix 2-CAD Services Requirements Response Form.docx

Appendix 2: CAD Services Requirements Response Form

RFP: 354-PD27-07

Project Title: Computer Aided Dispatch (CAD) Replacement Project

INTRODUCTION//DOCUMENT PURPOSE

This Appendix sets forth the minimum service requirements (“Service Requirements”) that the Town expects from the Vendor. These requirements are intended for inclusion in the Statement of Work (SOW) of the final contract with the selected Vendor.

Each section of Service Requirements (SR-01, SR-02, etc.) contain:

A. Requirements Description: The specific expectations of the services the Vendor is expected to provide and perform B. Deliverables: Specific document-based deliverables the Vendor is expected to provide.

While the Town prefers adherence to the Service Requirements as specified, proposed revisions will be considered that might better serve the project or align with the Vendor’s proposed solution as an exception.

Deliverable Types and Definitions:

· E (Execution): A document or deliverable where the Owner is responsible for carrying out or implementing the specified tasks or requirements.

· P (Planning): A document or deliverable where the Owner is responsible for outlining the approach, resources, and steps needed to achieve the project objectives.

· V (Verification): A document or deliverable where the Owner is responsible for confirming that the requirements or standards have been met.

Owner: The term "Owner" refers to the party responsible for overseeing, planning, or executing specific deliverables as defined by the type in this document.

Vendors are required to respond to the Service Requirements sections as follows:

· Requirements Descriptions: Select a response choice – 1, 2, or 3 – and where necessary, provide a written response:

1. Acceptance of the provided service requirement language, or proposed revisions to the specified text.

2. Agreement to deliver the identified document-based project management and implementation artifacts (“deliverables”) or propose alternative deliverables from the Vendor’s methodology that fulfill the intent of the requirement.

3. (Optional) Additional narrative describing the Vendor’s approach as it applies to the Town. This narrative is for evaluation purposes only and will not be included in the final SOW unless mutually agreed during contracting.

· Deliverables: Select a response choice for each individual deliverable required:

1. Compliant – The Vendor will provide the deliverable to required expectations

2. Partially Compliant – The Vendor will provide a deliverable as named but to slightly different expectations that will be negotiated and mutually agreed to prior to contract execution, or the deliverable expectations will be satisfied directly by an alternative deliverable or work product within the Vendor’s implementation methodology

3. Non-Compliant – The Vendor will not provide the deliverable required.

Note: Service Requirements are not intended to constrain or override the Vendor’s project management, implementation, or software development methodologies. Rather, they establish the minimum expected activities and deliverables necessary for a successful CAD implementation.

The Town’s Service Requirements (SR-01 through SR-12) shall serve as the primary and governing basis for the SOW. Any Vendor-provided attachments, exhibits, or samples are for illustrative purposes only. In case of any conflict or ambiguity, the Town’s Service Requirements shall prevail.

Vendors must integrate these activities and deliverables into their proposed approaches. Vendors using agile or iterative methods may describe incremental preparation and submission of deliverables; however, formal acceptance by the Town will occur only upon review and approval of the final version of each deliverable.

CAD SERVICE REQUIREMENTS

Requirement SR-01: Deliverables Management Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

2. Vendor requests alternate language for this SOW section (see below).

3. Vendor proposed alternative deliverables(s) that satisfy the required deliverable(s)

Vendor’s proposed alternate//additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

Requirements Description:

The services requirements described in Appendix #2 and the associated deliverable descriptions are intended to serve as the baseline for the Vendor’s Deliverable Expectation Documents (DEDs) as referenced in this Section, SR-01.

Prior to the commencement of implementation activities, the Vendor is required to review the content of Appendix #2 in detail and use it as the foundation for preparing DEDs for each document-based deliverable specified in this Appendix and/or as identified in the Vendor’s proposal.

The Vendor shall engage with the Town to review, discuss, and confirm the expectations for each deliverable, ensuring a mutual understanding of the required content, format, and acceptance criteria. Any mutually agreed-upon revisions or clarifications to the baseline expectations provided in Appendix #2 shall be incorporated into the final DEDs.

The complete set of DEDs, as finalized and agreed upon by both the Vendor and the Town will serve as the formal deliverable expectations for the project and will be included as an appendix to the contract. These DEDs will govern the preparation, submission, review, and acceptance of all project deliverables, ensuring clear alignment between the Vendor and the Town throughout the implementation lifecycle.

Deliverables:

2. Partially Compliant

3. Non-Compliant

A set of DEDs shall be provided by the Vendor at the start of the implementation phase, reviewed and mutually agreed upon with the Town, specifically:

· Each DED shall include the deliverable’s purpose and intended contents

· If any deliverable is to be delivered more than once (e.g., recurring status//progress reports), the DED for that deliverable should note the frequency

· Each DED shall include the deliverable author(s), intended recipient(s) and approvals

2. Partially Compliant

3. Non-Compliant

The Vendor shall provide and maintain a tracker of all deliverables including but not limited to: their version(s), status and links or other references to where they are being stored//maintained.

Requirement SR-02: Project Management Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

Vendor’s proposed alternate/additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

The Vendor shall assign a dedicated, certified Project Manager (PMP or equivalent) who will serve as the primary point of contact and be responsible for all aspects of project delivery.

Within thirty (30) days of contract execution, the Vendor shall submit a comprehensive Project Management Plan for the Town review and approval. The plan shall address project scope, schedule with milestones, resource assignments, risk management, communications, change control, and quality assurance.

The Vendor shall establish and maintain a project control and reporting system to provide regular, accurate assessments of project progress against approved milestones and plans.

In coordination with the Town’s Project Manager(s), the Vendor shall define roles, responsibilities, communication protocols, record-keeping, and procedures for quality assurance, configuration management, and change control.

The Vendor shall provide ongoing project management, including regular project plan updates, weekly status reports, and weekly status meetings.

The Vendor shall prepare a baseline Risk Management Plan and update it at least monthly throughout the project lifecycle.

Deliverables:

2. Partially Compliant

3. Non-Compliant

The Project Management Plan shall serve as the foundational document guiding all aspects of project delivery. The Plan shall include, at a minimum:

· Project organization and governance structure, including a project charter.

· Change management and integration management strategies.

· Defined roles and responsibilities for all vendor and Town participants.

· Stakeholder identification and engagement plan.

· Comprehensive list of project deliverables, receivables, and scope management approach.

· Supplier and subcontractor (if relevant) management protocols.

· Ongoing and event-based project communication plans.

· Security and proprietary/protected data handling considerations.

· Risks and issues management processes.

· Knowledge management and transfer strategies.

· Resource and capacity management, including a detailed Work Breakdown Structure (WBS).

· Communications management plan.

· Overview of the SDLC methodology to be utilized.

· Summary of the project tracking and oversight procedures, including weekly status meetings, schedule reports and updates, project reports, action item tracking, and RIDA (Risks, Issues, Dependencies, Assumptions) management.

2. Partially Comply

3. Non-Compliant

The Vendor shall provide a detailed, baseline Project Schedule and Gantt chart for the CAD implementation. The schedule shall include, at a minimum:

· A comprehensive Work Breakdown Structure (WBS).

· All major project tasks, action items, and deliverables.

· Duration estimates for each task.

· Task inter-dependencies and sequencing.

· Principal schedule milestones, including documentation, software, hardware, and solution-based deliverables.

· Resource allocation for all tasks.

· Identification of the critical path.

· Overall projected time to completion.

2. Partially Compliant

3. Non-Compliant

The Vendor shall provide monthly updates to the Project Schedule. Each update shall include, at a minimum:

· Percent complete updates for all major tasks and deliverables, including variance analysis against the baseline plan.

· Addition of any new tasks, as necessary or appropriate.

· Documentation of adherence to or changes in schedule change/approval processes as defined by the Town.

· Recommendations for changes to the baseline schedule or critical path, with supporting rationale.

· Updates on adherence to key project management processes and results.

· Documentation of change control items and approvals.

· Reporting of schedule variances and adherence to revised dates.

· Updates on risks and issues management, including acceptance, resolution, and closure.

· Status of quality-controlled deliverables, tasks, and results.

· Tracking of contractual deliverable target dates versus actual completion dates.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit a Project Communications Plan to the Town. The Plan shall include, at a minimum:

· Communication objectives and guiding principles for the project.

· Identification of all key stakeholders, including roles, responsibilities, and contact information.

· Defined communication methods and channels (e.g., email, meetings, reports, dashboards, emergency notifications).

· Communication schedule and frequency for all regular and event-driven communications (e.g., status meetings, milestone reviews, issue escalations).

· Description of communication content and format for each communication type (e.g., agendas, meeting minutes, status reports, action items).

· Procedures for documenting, tracking, and distributing project decisions, action items, and follow-ups.

· Escalation paths and protocols for urgent or unresolved issues.

· Methods for collecting and incorporating stakeholder feedback throughout the project.

· Change management communications approach, including notifications for key changes in scope, schedule, or resources.

· Plan for maintaining and updating the Communications Plan as project needs evolve.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit Weekly Project Status//Progress Reports to the Town. Each report shall include, at a minimum:

· Status of tasks planned for the current period, completed tasks, outstanding tasks, and tasks planned for the next period.

· Summary of deliverables by project stage/phase, including due dates, estimated and actual delivery dates, and relevant comments.

· Project control Key Performance Indicator (KPI) status, including scope, schedule, budget, resources, and quality.

· Upcoming Town resource needs or requests.

· Current issues or impediments impacting project progress.

· Identified risks and risk mitigation actions.

· Summary of change control activities, including scope or priority changes.

· Actions summary, including the status of all open, in-progress, late, and closed actions.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and maintain a comprehensive Risks-Actions-Issues-Decisions (RAID) Log, to be submitted to the Town and updated on a weekly basis. The format of the RAID Log may be at the Vendor’s discretion, using whichever tool or platform they prefer and have had the most success with. At a minimum, the RAID Log may be maintained as a shared spreadsheet or similar collaborative file format; however, the use of vendor-provided tools or platforms is welcome and encouraged.

The RAID Log shall include, at a minimum:

· A complete and current listing of all identified project risks, including descriptions, likelihood, impact, owner, mitigation actions, and status updates.

· Documentation of all key project assumptions, including rationale, potential impacts if assumptions change, and status of validation.

· A log of all project issues, including descriptions, date identified, owner, resolution actions, target and actual resolution dates, and current status.

· A record of all major project decisions, including decision description, date, decision-maker(s), rationale, and any resulting actions or dependencies.

· Clear tracking of the status of all RAID items (open, in progress, resolved/closed).

· Assignment of owners for each risk, assumption, issue, and decision.

· Weekly updates reflecting new entries, changes in status, and progress on mitigation or resolution actions.

· Summary of critical or overdue RAID items requiring escalation or immediate attention.

· Procedures for review and validation of the RAID Log during regular project status meetings.

Requirement SR-03: Solution Requirements Verification Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

Vendor’s proposed alternate//additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

The Vendor shall review and validate the requirements included in this RFP with the Town.

The Vendor shall facilitate requirements validation workshops to elaborate on baseline requirements and identify any additions or changes. All proposed changes shall be documented and evaluated through the formal Change Control Process, referencing both RFP requirements and the out-of-the-box CAD product capabilities.

The Vendor shall ensure all confirmed functional and technical requirements are addressed by the CAD solution and documented in a Requirements Traceability Matrix (RTM). The Vendor shall maintain and update the RTM throughout the project lifecycle.

The Vendor shall develop a Master Test Plan and comprehensive baseline Test Cases/Scripts, mapped to the RTM, covering both functional and performance/stress testing. The Town will provide operational scenarios to augment the Vendor’s test cases and will execute User Acceptance Testing (UAT) using the Vendor-provided scripts.

The Vendor shall conduct workshops with the Town’s subject matter experts (SMEs) to determine optimal CAD usage and configuration to support business processes. Where appropriate, the Vendor shall use functional prototypes or out-of-the-box demonstrations to facilitate configuration decisions.

The Vendor shall work with the Town to identify and document business process changes and/or system configuration changes needed to address gaps between current processes and CAD capabilities, including documenting business process flows in the context of the CAD solution.

The Vendor shall review the Town’s reporting requirements, identify CAD system reporting capabilities (fixed and ad hoc), and map reporting requirements to available CAD features.

Deliverables:

2. Partially Compliant

3. Non-Compliant

The RTM is intended to map requirements to system configuration, testing, and validation results. For each requirement, the RTM shall include:

· Reference to the detailed CAD Requirements in RFP Attachment C

· The specific CAD component (e.g., screen, report, workflow, data field, regulatory compliance, etc.) where the requirement is met

· Prioritization levels of each requirement

· Definition of Ready & Definition of Done

· The test scenario(s) where the requirement is tested

· The training module where instruction is provided for the requirement (if applicable)

2. Partially Compliant

3. Non-Compliant

The Deliverable shall include (at a minimum):

· Context diagrams (or similar) to provide an overall functional view of how CAD will operate and support the Town’s PSAPs and the field resources for each

· Elaborated or revised functional requirements (as necessary)

· Elaborated or revised non-functional requirements (as necessary)

· Elaborated or revised interface requirements (as necessary)

Requirement SR-04: Solution Design Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

Vendor’s proposed alternate//additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

The Vendor shall provide a comprehensive Solution Design Document describing the proposed CAD system architecture, including all relevant architectural layers (e.g., data, user experience, reporting, security) and major system components, with integration methods for each.

The Vendor shall confirm and update all technical environment specifications required to host the CAD solution in a cloud-based or vendor-hosted environment. If proposing an on-premise solution, the Vendor shall specify any additional infrastructure requirements and support the Town in accommodating these needs.

The Vendor shall provide, install, configure, and test all required infrastructure and CAD application components for cloud-based or vendor-hosted deployments. For on-premise variants, the Vendor shall oversee installation, configuration, and testing of application components, with the Town responsible for providing and installing the specified infrastructure.

The Vendor shall specify, provision, configure, and test a minimum of four (4) environments (e.g., development, test/UAT, training, production) as appropriate for the solution, whether cloud-based, vendor-hosted, or on-premise.

The Vendor shall evaluate existing Town infrastructure, including network connectivity and any required integration points, and recommend any remediation activities necessary for successful deployment and integration with the cloud or hosted CAD system.

The Vendor shall provide logical and physical data models for the CAD solution, leveraging the existing CAD data model where applicable.

The Vendor shall deliver a Disaster Recovery Plan detailing strategies, procedures, roles, responsibilities, recovery time objectives (RTO), recovery point objectives (RPO), and periodic testing requirements, tailored for a cloud-based or vendor-hosted environment (and including on-premise considerations if applicable).

The Vendor shall submit a Cybersecurity Plan demonstrating compliance with Criminal Justice Information Services (CJIS), National Institute of Standards and Technology (NIST), and applicable local and state requirements, addressing security controls, regular assessments, penetration testing, incident response, and breach notification procedures for the proposed cloud-based or vendor-hosted solution.

Deliverables:

2. Partially Compliant

3. Non-Compliant

The Solution Design Deliverable shall include, at a minimum, as necessary for the proposed solution type (Cloud, Hosted, Hybrid, On-Premise etc.):

· Solution Architecture:

· Comprehensive models and supporting narrative descriptions detailing the overall architecture of the CAD system, including all architectural layers (data, user experience, reporting, security, etc.) and how they support the elaborated requirements.

· Integration Plan and High-Level Interface Architecture:

· A description with supporting diagram of all major CAD solution components, their scope, and the methods for integrating each with external and internal systems, including third-party interfaces. This should be a precursor and high-level summary of what will be elaborated up via the deliverables in SR-06.

· Reporting Architecture and Tools:

· An overview of the reporting framework, including available reporting tools, fixed and ad hoc reporting capabilities, and how reporting requirements are met within the CAD solution.

· Security and Access Management Design:

· A comprehensive design of security controls, user authentication and authorization mechanisms, access management policies, and compliance with relevant standards (e.g., CJIS, NIST, local/state requirements).

· CAD Logical and Physical Data Models:

· Detailed logical and physical data models for the CAD solution, leveraging existing CAD data models where applicable, and illustrating data structures, relationships, and data flow within the system.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit a Technical Architecture deliverable in a format at the Vendor’s discretion, using their preferred documentation tools or platforms.

The Technical Architecture deliverable shall include, as necessary for the proposed solution type (Cloud, Hosted, Hybrid, On-Premise etc.):

· Specifications for all required infrastructure components (e.g., servers, storage, network, virtualization, cloud resources) necessary to host and operate the CAD system, aligned with the Solution Design.

· Environment architecture, including descriptions and diagrams for each environment (e.g., development, test/UAT, training, production), and the relationships and data flows between them.

· Details on scalability, performance, and high availability features of the proposed technical solution, including any load balancing, clustering, or failover mechanisms.

· Alignment with the Town’s existing technical standards, integration points, and infrastructure, including identification of any required remediation or upgrades.

· Specifications for system monitoring, logging, and alerting capabilities to ensure operational health and support troubleshooting.

· Data backup and retention architecture (excluding recovery procedures, which are addressed in the Disaster Recovery Design deliverable).

· Technical requirements and recommendations for ongoing system maintenance, patching, and upgrades.

· Description of how the technical architecture will be maintained and updated to support future growth and evolving requirements.

· Any third-party technical dependencies or prerequisites not already covered in the Solution Design.

2. Partially Compliant

3. Non-Compliant

The Cybersecurity Plan deliverable shall include, at a minimum:

· Documentation of compliance with any applicable CJIS, NIST or other local/state cybersecurity requirements.

· Description of implemented security controls and regular security assessment procedures.

· Plan for conducting penetration testing and addressing identified vulnerabilities.

· Incident response procedures, including roles, responsibilities, and escalation paths.

· Breach notification protocols and timelines.

2. Partially Compliant

3. Non-Compliant

The Disaster Recovery Design deliverable shall include, at a minimum:

· Strategies and procedures for restoring CAD operations following a disaster or major system outage.

· Defined roles and responsibilities for disaster recovery activities.

· Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for all critical system components.

· Requirements and schedule for periodic testing of disaster recovery processes.

Requirement SR-05: Application Configuration and Development Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

Vendor’s proposed alternate//additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

The Vendor shall configure the CAD application and perform any necessary custom development to meet all requirements defined in the Requirements Traceability Matrix (RTM) and Solution Design specifications.

The Vendor shall manage all configuration and development activities in accordance with the approved Configuration Management Plan.

The Vendor shall describe and follow a structured development approach, including the use of application development environments and platforms, build and integration processes, unit testing, and progress monitoring methods (e.g., backlog management, sprint planning, burn-down charts, retrospectives).

The Vendor shall document all as-built components, system configuration values, and system changes, and update this documentation for any subsequent changes performed by the Vendor.

Deliverables:

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit an Environments Plan that defines the specifications, controls, and processes for all environments required to support the CAD implementation, including development, test, training, staging, and production environments. The plan shall address any variations in environment types and requirements based on whether a cloud-based or on-premise CAD solution is proposed.

The Environments Plan shall include, at a minimum:

· A description of each environment (development, test, training, staging, production), including purpose, scope, and user access levels.

· Technical specifications for each environment as necessary and relevant, such as hardware, software, network configurations, storage, and security controls.

· Environment provisioning and configuration processes as necessary and relevant, including initial setup, cloning, and refresh procedures.

· Data management policies for each environment, including data masking, anonymization, refresh frequency, and retention, with special consideration for sensitive or production data.

· Access controls and user authorization requirements for each environment, ensuring appropriate segregation of duties and compliance with security standards (e.g., CJIS, NIST).

· Environment-specific integration points and interface requirements as necessary and relevant, including how external systems are simulated or connected in non-production environments.

· Procedures for promoting code, configuration, and data changes between environments, including change control, versioning, and rollback mechanisms.

· Monitoring, logging, and alerting requirements for each environment to ensure operational integrity and facilitate troubleshooting.

· Any unique requirements or constraints for cloud-based deployments (e.g., tenant isolation, cloud resource allocation, network security groups, automated scaling) or for on-premise deployments (e.g., physical infrastructure, local network segmentation, backup and restore procedures).

· Roles and responsibilities for environment management, including Vendor and Town staff.

2. Partially Compliant

3. Non-Compliant

The CAD Configuration Plan shall contain at a minimum:

· Documentation and descriptions of agreed-upon approach//method for configuring the replacement CAD system including activities, roles, responsibilities and communication between the Vendor team and the relevant parties within the Town

· Description of the methods for managing configuration, progress reporting, quality assurance, and change control.

2. Partially Compliant

3. Non-Compliant

Should any custom development of the CAD system be necessary, the CAD Customization Plan may be included as an additional section or appendix to the CAD Configuration Plan and shall contain at a minimum:

· Description of the application development process(es) required to customize any aspects of the CAD system, with the roles and responsibilities and communication between the Vendor team and the relevant parties within the Town.

· Description of the methods for managing custom development processes, progress reporting, quality assurance, and change control.

2. Partially Compliant

3. Non-Compliant

The Application Completion Report shall at a minimum:

· Confirmation that the CAD application has been fully configured and developed according to the approved requirements and is ready for User Acceptance Testing (UAT).

· The report shall include a summary of completed work and reference any relevant documentation delivered previously, or anticipated to be forthcoming

Requirement SR-06: System Interfaces and Integration Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

Vendor’s proposed alternate//additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

The Vendor shall prepare a System Integration Plan that describes the approach for integrating the CAD solution with all required external systems (e.g., RMS, AVL, radio, mobile, GIS), including interface specifications, data exchange protocols, testing procedures, and an integration schedule.

The Vendor shall review all existing CAD interfaces and provide recommendations for leveraging or improving current interface methods. The Vendor shall also recommend interface methods for any new interfaces required by the project.

The Vendor shall collaborate with the Town, and interfacing agencies to finalize the interface method and details for each required interface.

For each CAD interface, the Vendor shall prepare an Interface Control Document (ICD) aligned with the approved interface method, interface details, and the CAD interface architecture described in the Solution Design. The Vendor shall conduct a walk-through of each ICD with the relevant interface partner and obtain their written approval.

The Vendor shall assemble all approved ICDs in Appendix #3 (CAD Interfaces List within the Detailed Requirements document) for review and approval by the Town, and for inclusion in the Application Configuration and Development documentation.

Deliverables:

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit Interface Control Documents (ICDs) for each in-scope integration, to be reviewed and approved by the Town and relevant interface partners. Each ICD shall include, at a minimum:

· Detailed definitions of integration data formats, field-level specifications, and supported data types.

· Communication protocols and transport mechanisms (e.g., web services, APIs, file transfer, message queues).

· Interface trigger events or schedules, including frequency and timing.

· Validation rules, error handling, and exception processing procedures.

· Security and access controls for data exchange, including authentication and authorization requirements.

· Testing considerations, including test data requirements and partner test environment needs.

· Contact information and responsibilities for all interfacing parties.

The ICDs shall be updated as interfaces are refined and must be approved prior to interface development and deployment.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit an Integration Architecture document describing the overall system interaction and data flow for all CAD integrations. The Integration Architecture shall include, at a minimum:

· High-level diagrams illustrating system-to-system interactions, data flows, and integration points.

· Descriptions of integration patterns and methods used (e.g., real-time, batch, event-driven).

· Identification of all internal and external systems involved in integrations.

· Data flow mapping, including directionality and sequencing of exchanges.

· Considerations for scalability, reliability, and fault tolerance within the integration architecture.

· Security considerations for data in transit and at rest.

· Alignment with the overall Solution Design and Technical Architecture.

The Integration Architecture shall be reviewed and approved prior to interface development.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and maintain an Interface Inventory during the implementation and finalize it at Go-Live, providing a comprehensive and current list of all CAD system integrations.

The Interface Inventory shall include, at a minimum:

· Identification of each interface (name, type, purpose).

· Source and target systems for each integration.

· Status of each interface (e.g., planned, in development, tested, deployed, in production).

· Versioning information and change history.

· Key contacts for each interface.

· Notes on any dependencies, constraints, or special considerations.

The Interface Inventory shall be updated throughout the project and provided as part of regular project reporting.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit Interface Build Documentation for each implemented integration. The documentation shall include, at a minimum:

· Technical implementation details, including configuration settings, code samples, and deployment steps.

· Instructions for installation, setup, and initialization of each interface.

· Reference to the corresponding Interface Control Document (ICD).

· Troubleshooting tips and known issues.

· Procedures for ongoing maintenance, monitoring, and support.

The Interface Build Documentation shall be delivered prior to interface go-live and updated as changes are made during the project lifecycle.

Requirement SR-07: Data Migration and Conversion Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

Vendor’s proposed alternate//additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

The Vendor shall develop and deliver a Data Migration Plan detailing the approach, methodology, and timeline for migrating data from all legacy CAD systems to the new solution. The plan shall address data mapping, cleansing, validation, and final cutover, and define roles and responsibilities for both Vendor and Town staff.

The Vendor shall collaborate with the Town to identify all data to be migrated or converted from legacy systems.

The Vendor shall develop, test, and execute extract, transform, and load (ETL) scripts to migrate data, ensuring no degradation to either source or target systems.

The Vendor shall provide exception reporting for all data that fails conversion, with recommendations for remediation, including updates to conversion scripts or corrections to source data.

The Vendor shall perform at least four (4) full test data conversions, providing exception reports and remediation recommendations after each cycle, and adjust scripts as needed.

The Vendor shall perform and confirm the final data conversion as part of User Acceptance Testing (UAT) and at solution cutover.

Deliverables:

2. Partially Compliant

3. Non-Compliant

The Data Migration//Conversion Plan shall include, at a minimum:

· The scope of source data to be migrated and/or converted (e.g., source systems, databases, date ranges, case types).

· A comprehensive data inventory and assessment.

· Detailed source-to-target data mappings and methodology for all fields to be migrated or converted.

· Data transformation rules and technology utilization.

· Data testing, validation, and exception handling rules.

· Recommendations for remediation of source system data quality issues.

· An incremental data conversion approach, if the CAD rollout is phased.

2. Partially Compliant

3. Non-Compliant

The Data Migration//Conversion Completion Report shall include, at a minimum:

· A listing of all test data conversions completed.

· Documentation of data mapping and transformation outcomes resulting from the conversion process.

· Results of the final test data conversion, including summary and detailed data exception reports.

· Updates to the Data Migration/Conversion Plan based on lessons learned and process improvements.

Requirement SR-08: Testing Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

Vendor’s proposed alternate/additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

The Vendor is fully responsible for planning, coordinating, executing, and validating all testing activities and outcomes across all environments and system components. The Town will participate as required, including monitoring, reviewing results, and direct involvement in activities such as User Acceptance Testing (UAT).

The Vendor shall develop and maintain a comprehensive testing strategy and plan covering all testing phases (integration, operational scenario, UAT, performance/load, data migration, cutover, and post-go-live validation), with defined objectives, scope, schedules, roles and responsibilities (including Town participation), environments, tools, entry/exit criteria, and success metrics.

The Vendor shall coordinate integration testing with all third-party system providers and remain accountable for successful end-to-end validation of all interfaces and workflows, including those spanning multiple agencies.

UAT shall be vendor-led, with the Vendor providing test scripts and coordination, while Town and agency personnel execute test cases, validate workflows, and provide feedback.

The Vendor shall perform performance, load, and data migration testing; validate system scalability, availability, disaster recovery, and network performance for cloud/vendor-hosted solutions; and ensure secure data segregation.

The Vendor shall implement and maintain a formal defect management process, with transparent reporting and Town access for review and prioritization.

The Vendor shall define and meet acceptance criteria for system readiness, conduct cutover simulations, and support go/no-go decision-making, with Town participation in reviews and approvals.

The Vendor shall perform regression testing as necessary and post-go-live validation testing, ensuring all activities, results, and defects are fully documented, auditable, and accessible to the Town.

Deliverables:

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit a Master Test Plan that defines the full testing lifecycle and governance for the CAD project.

The plan shall include testing phases, objectives, scope, schedules, roles and responsibilities, environments, tools, entry/exit criteria, success metrics, and overall test management processes.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit an Integration Test Plan detailing the approach, procedures, and criteria for testing all system interfaces.

The plan shall specify test scenarios, data requirements, validation steps, partner involvement, and expected results for each integration.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit a User Acceptance Testing (UAT) Plan that defines the approach, scope, participant roles, test scripts, acceptance criteria, and process for user validation and approval of the CAD system.

2. Partially Compliant

3. Non-Compliant

The Vendor shall develop and submit comprehensive test scenarios and test cases that define all testing steps, preconditions, data requirements, execution instructions, and expected outcomes for each requirement and workflow.

2. Partially Compliant

3. Non-Compliant

The Vendor shall document and submit Integration Test Results, providing evidence of validation for all interface functionality.

The results shall include test execution records, outcomes (pass/fail), defects identified, resolutions, and retest results.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit a Data Migration Testing Report validating the integrity, completeness, and usability of migrated data.

The report shall include reconciliation results, exception reports, issue resolutions, and confirmation that data supports operational workflows.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit a Performance Testing Report that validates system behavior under load conditions.

The report shall include test scenarios, load profiles, results for response times and throughput, issues identified, and remediation actions.

2. Partially Compliant

3. Non-Compliant

The Vendor shall document and submit Operational Testing Results, validating that real-world workflows across all agencies function as intended.

The results shall include test execution records, outcomes, issues encountered, and resolutions.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit UAT Results documenting user validation and acceptance of the system.

The results shall include executed test cases, participant feedback, defects identified, resolutions, and final acceptance sign-off.

2. Partially Compliant

3. Non-Compliant

The Vendor shall maintain and submit a Defect Log tracking all testing defects from identification to resolution. The format and tool used is at the discretion of the Vendor, based on experience and preference.

The log shall include defect descriptions, severity, status, owner, resolution actions, and closure dates.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit a Test Summary that provides an overall assessment of testing readiness and outcomes.

The summary shall include key metrics, pass/fail rates, outstanding issues, and a recommendation for go/no-go decision.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit Go-Live Validation documentation confirming system readiness based on simulation and rehearsal results.

The deliverable shall include test execution details, outcomes, and any issues requiring resolution prior to go-live.

2. Partially Compliant

3. Non-Compliant

The Vendor shall provide a formal Operational Readiness Certification, attesting that all required testing has been completed successfully and the system is ready for live public safety operations.

2. Partially Compliant

3. Non-Compliant

The Vendor shall prepare and submit a Post-Go-Live Validation report, validating system performance, stability, and functionality after launch.

The report shall include monitoring results, issues encountered, resolutions, and confirmation of successful stabilization.

Requirement SR-09: Training Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

Vendor’s proposed alternate/additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

The Vendor shall provide comprehensive, role-based training for stakeholder agencies, including on-site instruction for all user groups. Initial training must begin and be completed within a sixty to ninety (60–90) day period prior to system Go-Live.

The Vendor shall employ a “Train-the-Trainer” approach, training at least two (2) qualified “super users” per agency in all CAD modules and system functionality. Super users must be able to resolve issues, identify problems, and subsequently train other Town employees.

The Vendor shall provide targeted training for the following example roles, with curriculum tailored to each group’s responsibilities and system interactions:

· System Administrator

· Database Administrator

· Super Users (“Train-the-Trainer”)

· Desktop CAD End User (e.g., dispatchers, call-takers, supervisors)

· Mobile CAD Users (e.g., patrol officers, firefighters, incident commanders)

· Ad-Hoc Report Writer, including any third-party analytics or reporting tools The Vendor shall deliver a comprehensive Training Plan for all user groups, including:

· Clearly defined training objectives and learning outcomes

· Detailed curriculum and lesson plans for each role

· Delivery methods, including in-person, virtual, and e-learning options

· Training schedules coordinated with agency operations, including provisions for refresher and make-up sessions

· Integration of the “Train-the-Trainer” model and ongoing refresher training The Vendor shall provide all training materials — for example user guides, quick reference materials, e-learning modules, and scenario-based exercises—for review and approval by the Town.

The Vendor shall conduct pre- and post-training assessments to evaluate participant knowledge, training effectiveness, and readiness for Go-Live, and shall adjust training content or methods as needed based on assessment results.

The Vendor shall offer virtual training options for any follow-up, refresher, or add-on training required due to unforeseen circumstances or system updates.

The Vendor shall ensure all training environments are properly configured and available for hands-on practice, and shall coordinate with the Town to schedule and support all training activities.

The Vendor shall provide support and guidance to super users and trainers during the transition to the Train-the-Trainer model and throughout the post-Go-Live stabilization period.

Deliverables:

2. Partially Compliant

3. Non-Compliant

The Deliverable shall include (at a minimum):

· Course list

· Target audience role descriptions

· Specific learning objectives for each user and support role, to be used to assess each individual’s readiness to perform their expected roles

· Lists of materials, facilities, equipment, user profiles, access procedures, work samples, and other items needed for each training session, including items that Town is to furnish

· Training calendar indicating the specific attendees and locations for all user training sessions. The calendar shall also indicate any planned phases or iterations in the delivery of training Vendor shall provide electronic versions of all deliverables. Town shall retain perpetual ownership of such deliverables with no constraints on modifications or use of such deliverables.

2. Partially Compliant

3. Non-Compliant

For each course identified in the Training Plan, the Deliverable shall include (at a minimum):

· Course presentation materials available in a digital and editable format

· Student training exercises

· Pre- and post-assessment materials

· Training data specifications for training exercises (if applicable), including training data initialization procedures

2. Partially Compliant

3. Non-Compliant

The Deliverable shall include:

· Summary of all training provided including course, date, and attendees

· Summarized training exercise results

· General observations of completed training and future training recommendations

Requirement SR-10: Solution Documentation Vendor Response (select one)

1. Vendor accepts the Service Requirement Description for this section as provided.

Vendor’s proposed alternate/additional SOW language (provide if option 2 is selected above):

Vendor’s alternative Deliverables (provide if option 3 is selected above):

The Vendor shall deliver all system documentation, including administration guides, configuration documentation, interface/API specifications, and as-built documentation, and shall update documentation throughout the project and maintenance period to reflect all changes.

Vendor shall provide user manuals of sufficient depth and clarity to enable users to utilize all relevant system features in the course of their work duties.