← All reports
PDF Excel ReqIF

Emergency Dispatch System

System Requirements Specification (SyRS) — ISO/IEC/IEEE 15289 — Specification | IEEE 29148 §6.2–6.4
Generated 2026-03-27 — UHT Journal / universalhex.org

Referenced Standards

StandardTitle
IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
NFPA 1221

Acronyms & Abbreviations

AcronymExpansion
ARC Architecture Decisions
CCCS Completeness, Consistency, Correctness, Stability
DFSI Digital Fixed Station Interface
EARS Easy Approach to Requirements Syntax
ESN Emergency Service Number
IFC Interface Requirements
MSAG Master Street Address Guide
OTAR Air Rekeying
STK Stakeholder Requirements
SUB Subsystem Requirements
SYS System Requirements
UHT Universal Hex Taxonomy
VER Verification Plan

Stakeholder Requirements (STK)

RefRequirementV&VTags
STK-NEEDS-001 The Emergency Dispatch System SHALL answer 90% of incoming emergency calls within 15 seconds and 95% within 20 seconds.
Rationale: NENA standard 56-005 specifies 90 percent at 15 seconds and 95 percent at 20 seconds answer-time targets for E911 PSAPs. Exceeding these thresholds directly correlates with increased mortality in cardiac arrest and trauma cases where every second of delayed response reduces survival probability by approximately 10 percent.
Test stakeholder, session-252
STK-NEEDS-002 The Emergency Dispatch System SHALL determine the location of an emergency caller with sufficient accuracy to dispatch the nearest appropriate unit, including for wireless and VoIP callers.
Rationale: FCC wireless E911 mandates require location accuracy for emergency calls. Without accurate caller location, dispatchers must rely on verbal information that may be unreliable when callers are distressed, unfamiliar with the area, or unconscious. Incorrect unit dispatch wastes critical response time and can be fatal in time-sensitive emergencies.
Test stakeholder, superseded-by-session-260
STK-NEEDS-003 The Emergency Dispatch System SHALL deliver incident type, location, caller information, and any hazard warnings to dispatched field units prior to their arrival on scene.
Rationale: Field units arriving without incident context face elevated risk and delayed effective response. Pre-arrival information on hazmat, weapons, building layout enables en-route tactical planning and appropriate resource staging, directly improving both responder safety and victim outcomes.
Demonstration stakeholder, session-252
STK-NEEDS-004 The Emergency Dispatch System SHALL maintain 99.999% operational availability, with no single point of failure causing complete loss of dispatch capability.
Rationale: Emergency dispatch is life-safety critical with no acceptable downtime. 99.999 percent availability aligns with NENA NG911 core service reliability standards. Complete dispatch failure during a mass-casualty event could result in preventable deaths across the served jurisdiction, typically covering 100,000+ residents.
Analysis stakeholder, session-252
STK-NEEDS-005 The Emergency Dispatch System SHALL record all emergency call audio, radio transmissions, and CAD operator actions, and retain these records in accordance with applicable state retention statutes.
Rationale: State and federal regulations mandate retention of 911 call recordings as public safety records and potential legal evidence. Failure to record or retain creates legal liability for the PSAP, undermines post-incident review and quality assurance, and may violate discovery obligations in litigation arising from emergency response.
Inspection stakeholder, session-252
STK-NEEDS-006 The Emergency Dispatch System SHALL provide supervisors with real-time visibility into call queue depth, unit deployment status, response times, and dispatcher workload to enable dynamic resource management.
Rationale: Without real-time operational visibility, supervisors cannot detect queue overflows, unbalanced dispatcher workloads, or degraded response times until callers complain or incidents escalate. Dynamic resource management requires continuous metrics to trigger overtime callbacks, mutual aid activation, or position reassignment.
Demonstration stakeholder, session-252
STK-NEEDS-007 The Emergency Dispatch System SHALL support call transfer and mutual aid coordination with neighboring PSAPs, including transfer of caller location data and incident context.
Rationale: PSAPs must handle calls outside their jurisdiction and coordinate mutual aid during large-scale incidents. NENA i3 standards require location and context transfer between PSAPs. Without seamless transfer, callers must repeat information to receiving dispatchers, wasting time and risking transcription errors during high-stress situations.
Test stakeholder, session-252
STK-NEEDS-008 The Emergency Dispatch System SHALL accept emergency requests via voice call, text-to-911, and telematics (automatic crash notification), ensuring equitable access for persons who are deaf, hard-of-hearing, or speech-impaired.
Rationale: The Americans with Disabilities Act and FCC mandate that 911 services be accessible to persons who are deaf, hard-of-hearing, or speech-impaired. Text-to-911 and telematics channels are legally required access methods. Telematics automatic crash notification provides critical data for unresponsive vehicle occupants who cannot place voice calls.
Test stakeholder, session-252
STK-NEEDS-009 The Emergency Dispatch System SHALL determine the location of an emergency caller to within 50 metres horizontal accuracy for wireless callers and 10 metres for wireline/VoIP callers within 10 seconds of call answer, enabling dispatch of the geographically nearest available unit from the correct response zone.
Rationale: FCC E911 Phase II mandates 50-metre accuracy for 67 percent of wireless calls. Wireline ALI provides street-address-level accuracy. The 10-second time constraint ensures location is available before the call-taker finishes initial questioning.
Test stakeholder, duplicate-of-STK-NEEDS-010, session-260
STK-NEEDS-010 The Emergency Dispatch System SHALL determine the location of an emergency caller to within 50 metres horizontal accuracy for wireless callers and 10 metres for wireline/VoIP callers within 10 seconds of call answer, enabling dispatch of the geographically nearest available unit from the correct response zone.
Rationale: FCC E911 Phase II mandates 50-metre accuracy for 67 percent of wireless calls. Wireline ALI provides street-address-level accuracy. The 10-second time constraint ensures location is available before the call-taker finishes initial questioning.
Test stakeholder, supersedes-STK-NEEDS-002, session-260
STK-NEEDS-011 The Emergency Dispatch System SHALL support software updates, security patches, and hardware maintenance without requiring complete system shutdown, maintaining minimum dispatch capability for voice calls and radio communications during maintenance windows.
Rationale: Emergency dispatch is a 24/7 life-safety service that cannot tolerate scheduled downtime. PSAP administrators need the ability to apply security patches and perform hardware maintenance without interrupting dispatch operations. Maintaining voice call and radio capability during maintenance ensures the public can still reach 911 and dispatchers can still communicate with field units.
Demonstration stakeholder, session-261
STK-NEEDS-012 The Emergency Dispatch System SHALL support software updates, security patches, and hardware maintenance without requiring complete system shutdown, maintaining minimum dispatch capability for voice calls and radio communications during maintenance windows.
Rationale: Duplicate of STK-NEEDS-011 — created during validation session. This requirement restates the maintainability need for zero-downtime updates to the emergency dispatch system, ensuring 24/7 service continuity during maintenance windows.
Demonstration stakeholder, session-261, duplicate-of-STK-NEEDS-011

System Requirements (SYS)

RefRequirementV&VTags
SYS-REQS-001 The Emergency Dispatch System SHALL process a minimum of 150 concurrent incoming emergency calls across all media types (voice, text, telematics) without degradation of call answer time or audio quality.
Rationale: Derived from STK-NEEDS-001. A metropolitan PSAP serving 500,000+ population may receive 3,000+ calls per day with peak concurrency during severe weather or mass events. 150 concurrent calls represents a 3x peak margin over typical busy-hour loads of 50 concurrent calls, ensuring the system does not become a bottleneck during surge events.
Test system, session-252
SYS-REQS-002 The Emergency Dispatch System SHALL complete call setup from ESInet SIP INVITE receipt to dispatcher audio presentation within 2 seconds, including ANI/ALI lookup.
Rationale: Derived from STK-NEEDS-001. The 2-second end-to-end target allocates processing budget across ESInet gateway, ACD routing, ANI/ALI lookup, and workstation presentation. Exceeding 2 seconds adds directly to the call answer time measured by NENA standards, and each additional second of silence causes callers to hang up and redial, creating phantom load on the system.
Test system, session-252
SYS-REQS-003 The Emergency Dispatch System SHALL display the location of wireless callers with horizontal accuracy of 50 metres or better for 80% of calls, using the best available location source (device-based, network-based, or hybrid).
Rationale: Derived from STK-NEEDS-002. The FCC E911 location accuracy benchmark requires 50-metre horizontal accuracy for 80 percent of wireless calls. This is the minimum needed to dispatch to the correct building in urban environments. Without this accuracy, responders may search the wrong location while the caller is in distress at a different address.
Test system, session-252
SYS-REQS-004 The Emergency Dispatch System SHALL deliver a complete dispatch assignment (incident type, location, caller data, hazard flags) to the assigned field unit's mobile data terminal within 5 seconds of the dispatcher initiating dispatch.
Rationale: Derived from STK-NEEDS-003. The 5-second dispatch delivery target ensures field units receive assignment data while still en route from their station. Longer delivery times mean units arrive at intersections without knowing which direction to proceed, or arrive on scene without hazard awareness. 5 seconds allows the MDT to display and the crew to acknowledge before reaching the response zone.
Test system, session-252
SYS-REQS-005 The Emergency Dispatch System SHALL achieve 99.999% availability measured annually, with automatic failover to redundant components completing within 30 seconds and without loss of active call audio or in-progress incident data.
Rationale: Derived from STK-NEEDS-004. 99.999 percent availability permits 5.26 minutes annual downtime. The 30-second failover window ensures active calls are not dropped during component failure. Loss of in-progress incident data during failover could cause dispatched units to lose their assignment or duplicate dispatches to be generated, creating confusion during active emergencies.
Analysis system, session-252
SYS-REQS-006 The Emergency Dispatch System SHALL record 100% of emergency call audio and radio transmissions with dual-redundant recorders, and SHALL retain recordings for a minimum of 5 years with chain-of-custody metadata.
Rationale: Derived from STK-NEEDS-005. Dual-redundant recording eliminates single-point recording failure which would create unrecoverable evidence gaps. 5-year retention satisfies the most stringent state statutes. Chain-of-custody metadata is required for recordings to be admissible as evidence in criminal proceedings and civil liability cases arising from emergency response.
Test system, session-252
SYS-REQS-007 The Emergency Dispatch System SHALL present supervisors with a real-time dashboard refreshed at least every 5 seconds, showing call queue depth, oldest call in queue, unit status counts by discipline, and aggregate response time metrics.
Rationale: Derived from STK-NEEDS-006. The 5-second refresh interval provides near-real-time situational awareness without imposing excessive query load on the CAD database. Supervisors use this dashboard to detect queue depth spikes within 10 seconds of onset, enabling immediate intervention such as activating overflow routing or recalling off-duty dispatchers.
Demonstration system, session-252
SYS-REQS-008 The Emergency Dispatch System SHALL transfer calls to neighboring PSAPs via NENA i3 SIP REFER with caller location (PIDF-LO), callback number, and incident context delivered to the receiving PSAP within 3 seconds of transfer initiation.
Rationale: Derived from STK-NEEDS-007. NENA i3 SIP REFER is the standard inter-PSAP transfer mechanism. The 3-second transfer completion target ensures the receiving PSAP has caller context before audio connects, preventing the caller from having to repeat their emergency while the receiving dispatcher has no information. Location and callback number transfer eliminates manual re-entry errors.
Test system, session-252
SYS-REQS-009 The Emergency Dispatch System SHALL accept text-to-911 messages via the ESInet text control centre and SHALL present text sessions to dispatchers with the same priority queuing, location display, and incident creation workflow as voice calls.
Rationale: Derived from STK-NEEDS-008. Equal priority queuing for text sessions ensures ADA-mandated equitable access. Text callers in active-shooter or domestic-violence situations cannot use voice and must not be relegated to a secondary queue. Unified workflow means dispatchers handle text with the same incident-creation and location-display tools as voice, reducing training burden and error rates.
Test system, session-252
SYS-REQS-010 The Emergency Dispatch System SHALL implement CJIS Security Policy v5.9 controls including encryption of data at rest and in transit, multi-factor authentication for administrative access, and network segmentation isolating PSAP systems from external networks.
Rationale: Derived from STK-NEEDS-004. CJIS Security Policy v5.9 is mandatory for any system accessing criminal justice information. PSAPs routinely query NCIC and state criminal databases during dispatch. Failure to implement CJIS controls results in decertification, loss of database access, and potential federal enforcement action. Network segmentation prevents lateral movement from compromised external-facing systems into the PSAP core.
Inspection system, session-252
SYS-REQS-011 The Emergency Dispatch System SHALL provide a training mode that simulates call intake, incident creation, dispatch, and radio operations using synthetic data, isolated from the production environment with no risk of dispatching real units or generating real radio transmissions.
Rationale: Cross-domain insight from air traffic control and naval CMS domains: complex real-time dispatch systems require training environments to certify new operators and validate procedure changes without risk to live operations. Isolation from production prevents synthetic training data from generating real dispatches, a failure mode documented in multiple PSAP incidents where test calls triggered real unit responses.
Demonstration system, session-261, cross-domain-insight
SYS-REQS-012 When one or more subsystems experience failure, the Emergency Dispatch System SHALL maintain degraded dispatch capability for a minimum of 150 concurrent voice calls and radio channel access to all active talk groups, with call-to-dispatch time not exceeding 120 seconds for Priority Emergency incidents, until full capability is restored.
Rationale: NENA standards require PSAPs to maintain minimum dispatch capability during partial system failures. The 150 concurrent voice call floor reflects a medium-sized PSAP peak load. The 120-second call-to-dispatch ceiling for Priority Emergency ensures life-threatening incidents still receive timely response even when CAD, GIS, or records subsystems are unavailable and dispatchers fall back to manual procedures.
Test system, session-261
SYS-REQS-013 The Emergency Dispatch System SHALL support failover to a geographically diverse backup PSAP site located a minimum of 25 miles from the primary site, with automatic failover completing within 60 seconds and the backup site capable of sustaining 100% of primary site dispatch capacity.
Rationale: Geographic diversity of backup PSAPs protects against regional disasters (earthquakes, hurricanes, flooding) that could disable the primary site. The 25-mile minimum separation is derived from FEMA regional disaster impact zones. The 60-second failover target ensures callers experience minimal disruption during site transition. 100 percent capacity at the backup site prevents capacity degradation during extended primary outages.
Test system, session-261
SYS-REQS-014 The Emergency Dispatch System SHALL support rolling software updates to any individual subsystem without interrupting active call processing, active radio channels, or active CAD sessions, with the update process completing within a 30-minute maintenance window per subsystem.
Rationale: Derives from STK-NEEDS-011 maintainability need. Rolling updates to individual subsystems allow patching security vulnerabilities and deploying bug fixes without system-wide downtime. The 30-minute window per subsystem bounds maintenance impact and enables scheduling updates across subsystems sequentially during low-traffic periods while keeping all other subsystems operational.
Demonstration system, session-261

Requirements by Category (IEEE 29148)

4
Functional Requirements
9
Performance Requirements
14
Safety Requirements
1
Security Requirements
3
Reliability & Availability
3
Compliance & Regulatory

Traceability Matrix — STK to SYS

SourceTargetTypeDescription
STK-NEEDS-011 SYS-REQS-014 derives
STK-NEEDS-010 SYS-REQS-003 derives
STK-NEEDS-012 SYS-REQS-014 derives
STK-NEEDS-004 SYS-REQS-013 derives
STK-NEEDS-004 SYS-REQS-012 derives
STK-NEEDS-012 SYS-REQS-011 derives
STK-NEEDS-007 SYS-REQS-004 derives
STK-NEEDS-004 SYS-REQS-010 derives
STK-NEEDS-008 SYS-REQS-009 derives
STK-NEEDS-007 SYS-REQS-008 derives
STK-NEEDS-006 SYS-REQS-007 derives
STK-NEEDS-005 SYS-REQS-006 derives
STK-NEEDS-004 SYS-REQS-005 derives
STK-NEEDS-003 SYS-REQS-004 derives
STK-NEEDS-002 SYS-REQS-003 derives
STK-NEEDS-001 SYS-REQS-002 derives
STK-NEEDS-001 SYS-REQS-001 derives