13  Domain Requirements Contracts

13.1 Start With the Story

Imagine a review meeting where every domain claim must become a contract before a team can build. This chapter turns application differences into explicit requirement boundaries so safety, privacy, latency, support, and data-retention promises can be tested instead of assumed.

13.2 Learning Objectives

After this page, you should be able to:

• Explain why domain requirements are measurable operating constraints, not technology preferences.
• Translate healthcare, agriculture, industrial, transport, retail, and smart-home needs into requirement envelopes.
• Compare candidate radios, protocols, platforms, and governance controls against pass/fail boundaries.
• Define latency, reliability, power, security, data, lifecycle, and integration budgets for an IoT system.
• Preserve traceability from requirement to technology decision, validation test, and fallback plan.

13.3 After Domain Requirements

Comparing Domain Requirements introduces latency, reliability, scale, power, data volume, regulation, and cost as domain-selection dimensions. This page isolates the design contract underneath those comparisons: the measurable envelope that proves a chosen technology can support the domain decision and the operating context around it.

Use it when a project team says a domain needs “low latency”, “high reliability”, “long battery life”, “medical compliance”, or “industrial integration” but has not converted those claims into budgets, interfaces, ownership, validation tests, and failure behavior.

13.4 Requirements Constraints

A domain requirement is not a preference for a fashionable sensor, radio, cloud, or dashboard. It is a measurable constraint created by the decision the IoT system has to support. A patient-alert system, irrigation controller, factory line, delivery vehicle, and smart home lock can all measure temperature or motion, but they do not have the same consequence of delay, missed data, power loss, privacy exposure, or maintenance failure.

Start by writing the job in operational terms: who acts, how quickly, what happens if the signal is wrong, how many devices are involved, how the device is powered, and which rules apply. Those answers narrow the design space before the team argues about LoRaWAN, NB-IoT, Wi-Fi, BLE, Zigbee, Ethernet, MQTT, HTTP, edge computing, or cloud dashboards.

Figure 13.1: Requirement profiles split devices into different operating quadrants: LoRa sensors and smart meters optimize for low-power infrastructure, while factory robots and CNC machines accept higher power use to meet industrial control needs.

The important shift is from feature thinking to constraint thinking. “We need temperature monitoring” is too broad to design. “We need a calibrated temperature record that proves vaccine storage stayed within policy, alerts a responsible person before excursion, and survives an audit” is a requirement. “We need a field temperature reading that warns a grower before frost damage and can run through a growing season” is a different requirement. Both may use a thermistor, but their acceptable latency, connectivity, calibration evidence, battery replacement, and data retention are different.

• Time constraint: how much delay is allowed from physical event to useful action?
• Failure constraint: what harm, cost, or lost trust follows a missed, late, duplicated, or false reading?
• Operating constraint: who installs, powers, patches, calibrates, replaces, and retires the device fleet?

A requirements comparison should also include the people and systems around the device. A hospital monitor may need a nurse workflow, biomedical engineering ownership, EHR context, clinical alarm policy, privacy controls, and cleaning procedures. A city air-quality node may need public-space permissions, calibration visits, publication rules, and a way to explain uncertainty. A factory sensor may need plant-network segmentation, scheduled downtime for installation, CMMS integration, and clear authority to stop or inspect equipment. These are requirements because they decide whether the telemetry can safely become action.

13.5 Measurable Domain Envelopes

A useful requirements comparison gives every candidate technology a pass/fail boundary. For a remote soil-moisture node, the envelope may include a 15-minute sampling interval, five-year battery target, LoRaWAN Class A uplink, IP67 enclosure, local rainfall context, and seasonal service visit. For a hospital asset tracker, it may include BLE tags, Wi-Fi access-point location or Ultra-Wideband anchors, patient-area privacy rules, HL7 FHIR integration, and a support path that does not interrupt care.

Write the envelope as numbers, interfaces, and operational commitments. Latency should be an end-to-end budget, not only a network figure: sampling interval, edge processing, radio access, broker routing, rule evaluation, notification, and human response all count. Reliability should include how the system behaves when a node is silent, a gateway is offline, a certificate expires, a firmware update fails, or an integration API is unavailable. Scale should name not just device count but provisioning rate, event rate, data retention, support tickets, and replacement logistics.

• Connectivity: compare BLE, Zigbee/Thread/Matter, Wi-Fi 6, Ethernet/PoE, LoRaWAN, NB-IoT, LTE-M, 5G, and satellite links against range, duty cycle, handoff, gateway ownership, and subscription cost.
• Message path: specify MQTT QoS, Sparkplug B state, OPC UA tags, DDS topics, CoAP resources, REST APIs, broker retention, duplicate handling, and offline queue behavior.
• Platform fit: map the domain to AWS IoT Core, Azure IoT Hub, ThingsBoard, Home Assistant, Ignition, AVEVA PI System, or a custom service only after the latency, lifecycle, security, and data-retention envelope is written.
• Governance: name the actual rules where they apply: HIPAA and FDA expectations for some healthcare workflows, IEC 62443 for industrial cybersecurity, ISO 26262 for automotive safety work, GDPR for personal data, and GS1 EPCIS or Digital Link for supply-chain traceability.

Use the envelope to eliminate attractive but incompatible choices. A battery node that must sleep most of the day should not be forced into high-frequency telemetry just because a dashboard looks better with live charts. A safety-critical machine-control loop should not depend on a distant cloud rule engine when deterministic local control is needed. A consumer smart-home device may accept cloud-assisted features, but a door lock or smoke alarm still needs local behavior when the internet is unavailable. A retail shelf sensor may prioritize low cost and easy installation, while a pharmaceutical cold-chain sensor may prioritize auditability and chain-of-custody evidence.

The practitioner review should end with a traceable decision record. For every selected technology, record the requirement it satisfies, the requirement it weakens, the test that will prove it, and the fallback if it fails. That record prevents later scope drift, such as adding video analytics to a low-power sensor network, changing a daily reporting system into a safety alert path, or expanding personal-data collection without updating retention and consent controls.

13.6 Budgets and Interfaces

The six dimensions become engineering budgets. Latency is divided across sensor sampling, filtering, edge inference, radio access, gateway processing, broker routing, database write, alert rule, and human or actuator response. Reliability is divided across device hardware, firmware watchdogs, network coverage, broker availability, cloud region design, alert escalation, and field replacement. Power is divided across sleep current, sensor warm-up, radio join, transmit time, retries, firmware updates, and battery chemistry.

Those budgets should be represented in interfaces, not only in architecture diagrams. A telemetry event should carry units, timestamp source, sequence or message id, firmware version, calibration state, quality flags, and enough asset or user context to support the domain decision. A command interface should separate requested, accepted, dispatched, acknowledged, applied, failed, and timed-out states. An alert interface should distinguish raw threshold crossing from validated event, suppressed event, escalated event, and operator acknowledgement. Without these states, the system cannot explain whether it acted late, acted twice, or failed to act.

• Security budget: define device identity, X.509 certificate or secure-element storage, TLS policy, topic or API authorization, key rotation, OTA signing, and decommissioning.
• Data budget: define payload schema, units, timestamp source, clock drift tolerance, compression, edge aggregation, retention period, lineage, and deletion behavior.
• Lifecycle budget: define provisioning, calibration, firmware versioning, configuration state, replacement mapping, support logs, rollback, and end-of-life handling.
• Integration budget: define which systems consume the event: EHR, CMMS, MES, ERP, SCADA, GIS, mobile app, analytics warehouse, or customer notification service.

A technology is a candidate only when it fits all of the budgets at the same time. A radio that meets the range target but cannot meet the latency, power, provisioning, or regulatory budget is not a domain fit.

Implementation details vary by stack. MQTT topics may need tenant, site, device, and capability boundaries so authorization can be enforced without brittle string parsing. OPC UA nodes may need units, engineering ranges, quality status, and references to the physical asset. HL7 FHIR integrations may need device, observation, encounter, and patient identity handled with clinical safety checks. A LoRaWAN payload decoder may need to preserve battery voltage, frame counter, spreading factor, RSSI, SNR, and decoder version so field failures can be diagnosed later.

The hidden cost of poor requirements is usually paid during operations. If the team does not budget for certificate rotation, calibration expiry, alert fatigue, firmware rollback, gateway replacement, schema versioning, or decommissioning, the first successful pilot becomes hard to scale. Under the hood, good domain requirements are a way of making those future operating costs visible while the architecture can still change.

13.6.1 Under-the-Hood Knowledge Check

13.7 What To Carry Forward

Domain requirements become useful when they describe the operating decision, the measurable budget, the validation test, and the fallback behavior. The technology choice is defensible only when it fits that complete contract, not just one attractive metric.