The file's text, extracted by GovTribe without its formatting.
Detailed Requirements Document Next Generation 911 (NG911) Call Handling System For: Oglethorpe County, Georgia 911 Service Area: ~19,000 population | ~442 square miles Staffing: 3 Dispatcher/Call‑Taker Consoles | 1 Supervisor Console
1. Purpose of This Document This document defines the functional, technical, operational, and non‑functional requirements for the selection and implementation of a Next Generation 911 (NG911) call handling system. It is intended to:
· Provide objective, testable requirements against which vendors can be evaluated
· Support a fair and defensible procurement process
· Ensure the selected solution meets current operational needs while remaining scalable and future‑ready
· Avoid unnecessary complexity or cost inappropriate for a small PSAP Vendors shall clearly indicate Compliant, Partially Compliant, or Non‑Compliant for each requirement and provide explanatory notes where applicable.
2. Functional Requirements
2.1 Call Intake and Processing
| F‑1 |
| The system shall support SIP‑based NG911 voice call handling compliant with NENA i3 standards |
| F‑2 |
| The system shall receive and process wireline, wireless, and VoIP 911 calls |
| F‑3 |
| The system shall support automatic number identification (ANI) and automatic location information (ALI) where applicable |
| F‑4 |
| The system shall support call transfer, conference, and re‑route without call termination |
| F‑5 |
| The system shall support configurable call queues and priority handling |
| F‑6 |
| The system shall provide audible and visual alerts for incoming calls |
2.2 Text‑to‑911 and Multimedia
| F‑7 |
| The system shall support Text‑to‑911 at initial deployment |
| F‑8 |
| The system shall allow dispatchers to respond to text sessions using a native interface |
| F‑9 |
| The system shall support future expansion to multimedia (images, video, data) without replacement of core infrastructure |
| F‑10 |
| The system shall provide policies for handling abandoned or incomplete text sessions |
2.3 Call Control and Recording
| F‑11 |
| Dispatchers shall be able to place calls on hold and retrieve them |
| F‑12 |
| The system shall support call recording for all 911 calls |
| F‑13 |
| Recordings shall be searchable by date, time, ANI, dispatcher, or incident number |
| F‑14 |
| Supervisors shall have access to call playback and review tools |
3. Console and User Requirements
3.1 Dispatcher Consoles
| C‑1 |
| The system shall support a minimum of three (3) dispatcher/call‑taker consoles |
| C‑2 |
| Consoles shall support configurable layouts and workflows |
| C‑3 |
| Dispatchers shall be able to manage multiple concurrent calls or text sessions |
3.2 Supervisor Console
| C‑4 |
| The system shall support at least one (1) supervisor console |
| C‑5 |
| Supervisors shall be able to silently monitor live calls |
| C‑6 |
| Supervisors shall be able to barge‑in or take over calls when necessary |
| C‑7 |
| Supervisors shall have access to system performance dashboards |
3.3 User Management
| C‑8 |
| The system shall support role‑based access control |
| C‑9 |
| Administrative privileges shall be restricted to authorized users |
| C‑10 |
| User actions shall be logged for audit purposes |
4. Location, GIS, and Data Requirements
| G‑1 |
| The system shall integrate with GIS‑based location services |
| G‑2 |
| Location data shall update dynamically as new information becomes available |
| G‑3 |
| The system shall support state or regional GIS data sources |
| G‑4 |
| The system shall display confidence or accuracy indicators for location data |
5. Integration Requirements
| I‑1 |
| The system shall integrate with the agency’s CAD system |
| I‑2 |
| Call and location data shall be passed electronically to CAD |
| I‑3 |
| The system shall integrate with existing radio/dispatch console systems |
| I‑4 |
| The vendor shall document all APIs and supported integration methods |
| I‑5 |
| Integration shall not require proprietary or vendor‑locked hardware |
6. Reliability, Redundancy, and Continuity
| R‑1 |
| The system shall provide geographic redundancy |
| R‑2 |
| The system shall automatically fail over during outages |
| R‑3 |
| The system shall support call re‑routing to alternate PSAPs |
| R‑4 |
| The vendor shall specify Recovery Time Objective (RTO) |
| R‑5 |
| The vendor shall specify Recovery Point Objective (RPO) |
7. Cybersecurity and Compliance Requirements
| S‑1 |
| The system shall comply with CJIS Security Policy requirements |
| S‑2 |
| Data shall be encrypted in transit and at rest |
| S‑3 |
| The system shall support multi‑factor authentication |
| S‑4 |
| The vendor shall maintain documented vulnerability management processes |
| S‑5 |
| The system shall provide audit logs and reporting |
8. Performance and Usability
| P‑1 |
| Call setup times shall meet or exceed industry standards |
| P‑2 |
| The system shall be designed for high availability (99.9% or greater) |
| P‑3 |
| Interfaces shall be intuitive and require minimal dispatcher interaction |
| P‑4 |
| The system shall minimize cognitive load during high‑stress events |
9. Training and Support Requirements
| T‑1 |
| Vendor shall provide initial dispatcher training |
| T‑2 |
| Vendor shall provide supervisor and administrator training |
| T‑3 |
| Training shall include both live and reference materials |
| T‑4 |
| Vendor shall provide 24/7 technical support |
| T‑5 |
| Vendor shall define support SLAs and escalation procedures |
10. Implementation and Acceptance
| IM‑1 |
| Vendor shall provide a detailed project plan |
| IM‑2 |
| Vendor shall support parallel testing prior to cutover |
| IM‑3 |
| Vendor shall provide on‑site or remote go‑live support |
| IM‑4 |
| Final acceptance shall be contingent on successful testing |
11. Cost and Licensing Requirements
| L‑1 |
| Licensing shall be clearly defined per console or user |
| L‑2 |
| Recurring costs shall be clearly itemized |
| L‑3 |
| Optional features shall be priced separately |
| L‑4 |
| The solution shall scale without punitive cost increases |
12. Vendor Disclosure Requirements
| V‑1 |
| Vendor shall disclose any subcontractors |
| V‑2 |
| Vendor shall disclose known litigation related to NG911 |
| V‑3 |
| Vendor shall disclose security incidents within the past five (5) years |
13. Compliance Matrix Instructions Vendors shall complete a compliance matrix using this document, indicating compliance status for each requirement and providing explanatory comments. Failure to complete the matrix may result in disqualification.
End of Requirements Document