20 IoT Requirements: Classification and Connectivity

20.1 Start With the Decision

Write the promise from the resident’s point of view. Name the physical event, range, place, update time, allowed error, reader, action, and safe fallback.

20.2 Route Overview

This is part 1 of 2. Continue with IoT Requirements: Definition and Value Flow.

20.3 Part Objectives

• Define related chapters and resources with explicit inputs, errors, and change rules.
• Trace requirements cross the five layers across its components and failure boundaries.

20.4 Overview

This first route turns vague IoT claims into measurable classifications, layers, minimum requirements, and a defensible connectivity shortlist.

This is part 1 of 2. Continue with IoT Requirements: TCO and Design Trade-offs for the second focused route.

20.5 Start With the Story

Turn a Useful Idea Into a Testable Promise

Picture a care-home team proposing a room sensor that warns when heat may harm a resident. The idea sounds useful, but the owner still needs to know what is sensed, who gets the warning, how soon it arrives, and what happens when power or the link fails.

Write the promise from the resident’s point of view. Name the physical event, range, place, update time, allowed error, reader, action, and safe fallback. Add battery life, service life, repair owner, data retention, access rule, and the way the unit receives a safe update.

Turn each word such as fast, secure, reliable, or low cost into a measured check. Try weak power, lost contact, a moved sensor, a wrong user, a full store, an old clock, and a failed update. Record which result passes, which fails, and who decides whether the limit is acceptable.

Keep any urgent safe response in the room or building if a remote round trip could miss the deadline. A distant service may store, compare, and notify, but it must not be the only path to immediate protection. Keep source, time, unit, quality, and version through each hand-off.

This opening does not choose all parts or settle every trade-off. Practitioner turns the promise into acceptance tests. Under the Hood maps power, sensing, links, data, trust, updates, and operations to the full design.

Use this promise check:

• Name one real user.
• Name one real need.
• Name one sensed event.
• Name the useful range.
• State the allowed error.
• Set the response time.
• Set the data age.
• Set the safe state.
• Mark the local owner.
• Mark the service owner.
• Mark the repair owner.
• Mark the data owner.
• Keep the source name.
• Keep the event time.
• Keep the stated unit.
• Keep the quality mark.
• Keep the code version.
• Count each power draw.
• Test the weak cell.
• Test the dead cell.
• Test the lost link.
• Test the slow link.
• Test the bad clock.
• Test the wrong user.
• Test the moved probe.
• Test the loose wire.
• Test the full store.
• Test the stale view.
• Test the failed rule.
• Test the safe stop.
• Test the hard restart.
• Test the bad update.
• Test the safe roll back.
• Record each failed case.
• Record each passed case.
• Keep the raw proof.
• Keep the final view.
• Link proof to claim.
• Price the normal case.
• Price the hard case.
• Plan the field check.
• Plan the next check.
• State each known limit.
• State who accepts it.
• Reopen when parts change.
• Reopen when use changes.

Begin with a device idea that sounds useful until someone asks how it will be powered, reached, secured, updated, and trusted. This chapter turns IoT enthusiasm into requirements evidence: the system must keep its promise across the physical environment, network path, data model, and operations workflow.

20.6 Learning Objectives

By the end of this chapter, you will be able to:

• Explain IoT architecture: Describe the complete data flow through the five IoT system layers from sensor to application
• Apply minimum requirements: Identify and verify the three essential components every IoT device must have using the Three Ingredients Test
• Evaluate IoT characteristics: Assess IoT systems against eleven ideal characteristics and assign priority weights by domain
• Select appropriate technologies: Compare connectivity options (Wi-Fi, LoRaWAN, cellular) and justify choices based on application requirements

20.7 Related Chapters and Resources

IoT Overview Series:

• IoT Introduction - Getting started with IoT and the Five Verbs
• IoT Perspectives and Definitions - Different stakeholder views on IoT
• Device Evolution - Embedded vs Connected vs IoT products
• IoT History and Paradigm Shifts - Lessons from technology evolution

Deep Dive Chapters:

• Application Domains - Industry-specific IoT applications
• IoT Use Cases - Real-world implementation examples

Learning Hubs:

• Concept Navigator - Test your understanding
• Simulation Playground - Interactive tools
• Video Gallery - Visual learning resources

20.8 Prerequisites

This chapter assumes you have read IoT Introduction or have basic familiarity with what IoT means. No technical background is required.

20.9 Quick Mental Model

Use two passes whenever you evaluate a product:

1. Three Ingredients Test: Is there a physical thing, embedded computation, and internet reach, directly or through a gateway?
2. Characteristics Test: Once it qualifies as IoT, which 3-4 of the eleven qualities matter most for this domain?

• Qualification: Ask whether the product has a thing, computation, and internet reach. A timer microwave fails here because it is embedded; a Bluetooth-only lock is connected, but not full IoT.
• Quality: Ask which characteristics must be strongest for the use case. A farm sensor optimized for millisecond response while ignoring battery life is solving the wrong problem.
• Architecture: Ask where sensing, filtering, networking, and decisions should happen. Streaming everything raw to the cloud raises latency, cost, and fragility.

Fast classification examples:

• Timer microwave: Thing + computation, but no internet reach -> Embedded device
• Bluetooth lock: Thing + computation + local wireless, but no internet reach -> Connected product
• Soil sensor with LoRaWAN gateway: Thing + computation + gateway path to cloud -> IoT device

This framing keeps the chapter disciplined: first decide whether something qualifies as IoT, then decide whether it is good IoT for the job.

20.10 Minimum Viable Understanding

• Three ingredients define IoT: A physical thing, embedded computation, and internet connectivity. If any one is missing, the device is not IoT — it may be embedded (no connectivity) or connected (no internet reach), but not IoT.
• Eleven characteristics separate good from great: Ubiquitous, Smart, Agile, On Demand, Blend into Background, Secure, Low Maintenance, Fast, Upgradable, Growing, and Adaptable are quality benchmarks. No device excels at all eleven; prioritize 3-4 for your domain.
• Requirements drive technology, not the reverse: Start with application constraints (range, power budget, update frequency, environment) and select connectivity technology accordingly. Wi-Fi suits high-bandwidth local devices; LoRaWAN suits long-range battery-powered sensors; cellular suits mobile assets.

20.11 Make Classification Testable

The Three Ingredients Test is a requirement filter, not a vocabulary exercise. A product qualifies as IoT only when the physical thing, local computation, and internet reach work together to support a useful data or control loop. The test forces you to name the asset, the embedded logic, and the path that carries telemetry, commands, alerts, configuration, or updates beyond the local environment.

Use the linked figure in Part 2 to make the classification test explicit. A qualifying service path combines a physical thing, local computation, and direct or gateway-mediated internet reach; removing any one ingredient changes what the product can observe, decide, or control remotely.

A Bluetooth-only lock may be connected, but it is not the same requirement set as a lock that reaches a cloud service through a Wi-Fi bridge or integrated Wi-Fi radio. A LoRaWAN soil sensor may qualify through a gateway even though the sensor itself never opens a TCP connection. A factory vibration sensor may reach a historian through an edge gateway and still count as IoT if the end-to-end path supports remote visibility or action. The requirement is the service path, not a specific radio.

Classification is only the first pass. The second pass asks whether the device is good IoT for its job. A smart thermostat, cold-chain tracker, irrigation valve, medication dispenser, and fleet sensor all satisfy the three ingredients, but their strongest characteristics differ. A cold-chain tracker may prioritize battery life, location coverage, tamper evidence, and data retention. A thermostat may prioritize local control, comfort, update safety, and household privacy. A fleet sensor may prioritize mobility, cellular roaming, ruggedness, and remote diagnostics.

• Thing: Name the physical asset, installation point, user, operating environment, enclosure limits, and expected lifetime.
• Computation: Name the local logic that samples, filters, stores, controls, protects, compresses, or signs device data.
• Internet reach: Name the direct or gateway-mediated path that carries data, commands, updates, or alerts beyond the local link.
• Usefulness: Name the action, decision, maintenance task, safety response, or service workflow that changes because the device is connected.

This framing prevents technology-first design. You do not choose Wi-Fi, LoRaWAN, cellular, MQTT, or a cloud platform because it sounds modern. You choose the weakest acceptable combination that still satisfies range, power, latency, security, maintenance, data-quality, and user-experience requirements.

20.12 Make Requirements Measurable

After classification, the practical work is to turn desirable qualities into measurable design constraints. “Low maintenance” becomes battery access, enclosure sealing, calibration interval, replacement process, spare-device handling, and OTA update policy. “Fast” becomes latency budget, sampling rate, queue behavior, command timeout, and local fallback. “Secure” becomes provisioning, credential storage, access control, audit logging, firmware signing, and revocation. The words are only useful when they become testable acceptance criteria.

Connectivity choices then become easier to defend. Wi-Fi fits mains-powered devices with local bandwidth and installation support. Thread or Zigbee may fit home and building meshes where a border router is acceptable. BLE can work for phone-assisted setup, short-range sensing, or local wearables. LoRaWAN fits small, infrequent telemetry over long range when downlink limits are acceptable. LTE-M or NB-IoT may fit wide-area assets when gateway ownership is impractical and the business model can carry subscription cost.

Write each requirement as a budget, threshold, or operational rule. A cold-chain sensor might require temperature samples every five minutes, upload within fifteen minutes when coverage exists, buffer seventy-two hours offline, survive washdown, rotate credentials on ownership transfer, and preserve audit records for a defined retention period. A smart-home lock might require local unlock when the cloud is down, revocation within minutes, low-battery warning before failure, and a clear household recovery path. These statements are design inputs, not after-the-fact documentation.

1. Prioritize characteristics. Pick the few qualities that matter most for the domain instead of claiming all eleven equally. Record the tradeoff you are accepting.
2. Translate each quality. Write a measurable requirement for power, latency, data freshness, update rate, range, identity, maintenance, recovery, privacy, and support.
3. Check the tradeoff. Confirm which requirement worsens when another improves, such as lower latency versus battery life, higher sample rate versus data cost, or stronger authentication versus setup friction.
4. Attach a verification method. Decide whether the evidence comes from a bench test, field trial, protocol trace, security review, battery calculation, accessibility check, or support drill.
5. Keep the requirement alive. Revisit assumptions when the deployment moves from prototype to pilot, from pilot to fleet, or from one domain to another.

20.13 Requirements Cross the Five Layers

A requirement usually touches more than one architecture layer. A freshness requirement may need a sensor timestamp, device clock behavior, gateway buffering rule, MQTT or HTTPS message policy, cloud ingestion timestamp, application stale-data label, and operator response rule. Treating freshness as a dashboard label alone leaves the system ambiguous. The physical layer, edge layer, connectivity layer, cloud layer, and application layer all need a share of the requirement.

The same applies to recovery. A device may need local safe behavior when the radio is down, a gateway may need store-and-forward queues, the cloud may need idempotent command handling, and the app may need to show whether a command is pending, applied, rejected, expired, or unsafe to retry. Without those rules, a retry storm, duplicated command, stale reading, or silent offline device can look like normal operation until the user notices the failure.

Identity requirements also cross layers. Manufacturing may assign a device identifier and certificate. Provisioning may bind the device to an owner, site, room, vehicle, patient, or asset. The gateway may authorize which devices can join. The cloud may map device identity to tenant identity and permissions. The application may expose ownership transfer and decommissioning. If any step is vague, support teams cannot safely replace, resell, retire, or investigate the device.

Data semantics are the other hidden dependency. Units, timestamp source, calibration state, location precision, firmware version, quality flags, and command meaning must be defined before analytics or automation use the data. A temperature value in Celsius, sampled inside an enclosure, averaged over one minute, and marked stale has a different meaning from an instant probe reading in Fahrenheit. Requirements make those meanings explicit.

• Identity: Define provisioning, authentication, authorization, ownership transfer, credential rotation, and decommissioning before field rollout.
• Semantics: Define units, timestamps, quality flags, calibration state, device state, and command meaning before building analytics or automation.
• Reliability: Define offline behavior, buffering, retry limits, duplicate handling, command expiry, and safe local behavior for each failure mode.
• Observability: Define logs, counters, health checks, trace ids, fleet reports, and alert thresholds for each layer that can fail.

20.14 Continue to the Next Part

Carry this evidence into IoT Requirements: Definition and Value Flow, which begins with What is Internet of Things (IoT).