Because this is not a system intended to be used for real, the non-functional requirements are only described very briefly here. Also, many of them are very much overkill for the actual intended use. Some of them won't even be testable because of lacking hardware, but hey, shoot for the stars...

Availability

• It shall be possible to deploy the system in a High Availability setup with hot failover for every single component.
• It shall also be possible to deploy the system on a single server with no failover at all (this is how it will actually be deployed).

Operating Environment

• It shall be possible to run the entire system behind a NAT-router with port forwarding and dynamic DNS.
• It shall be possible to run the entire system in the cloud.
• The server applications shall run on Linux or FreeBSD (recent versions).
• The mobile applications shall run on Android (recent versions).
• The dispatcher workstation shall run on Windows, macOS and Linux (recent versions) if implemented as a native application.
• The dispatcher workstation shall run on Edge, Chrome and FireFox (recent versions) if implemented as a web application.
• The server applications shall be memory efficient and fast so that they can run on cheap virtual servers on the cloud (when serving a handful or two of users).

Consistency and Integrity

• The general principle shall be "append only", with a purge of old data at some point (either removal or archiving). Exactly what data should be stored for how long shall be shall be specified in more detail later.
• For data changes within a single module or application, immediate consistency shall be applied. For data propagation between modules or applications, eventual consistency is enough.

Security

• Data shall be encrypted in transit and at rest.
• Runboards and Mobile Terminals shall use client certificates or bearer authentication when authenticating themselves. This shall also work when the servers are behind a reverse proxy.
• Dispatchers shall use usernames and one-time passwords when authenticating themselves.
• Dispatchers shall not be able to change OTP generators themselves.
• There shall be an upper limit on the number of connections allowed.
• It shall be possible to disconnect and disable active Runboards, Mobile Terminals and Dispatchers from a management user interface.
• It shall not be possible for an alert recipient to listen for alerts addressed to other alert recipients.
• It shall be possible to gradually roll out new encryption keys and certificates without operational interruptions.
• Everything that happens in the system must be logged and stored for a configurable amount of time. It shall be possible to store the log file on a separate server, outside the reach of the server administrator.
• It shall be possible to protect the system against DDoS attacks.

Performance

• The system shall be able to support 1000 simultaneous Runboard connections.
• The system shall be able to support 3000 simultaneous Mobile Terminal connections.
• The system shall be able to support 60 simultaneous Dispatcher Workstation connections.
• The Dispatcher Workstations shall have an maximum average user interface response time of 300 ms.
• It shall take no longer than 10 seconds for an alert to be delivered to at least one alert recipient per resource when dispatching 30 resources simultaneously.