The Internet of Things (IoT) is a hot buzzword right now. It simply states that we take physical devices and connect them to the Internet. As with many buzz words, this is not really new: This has been done for decades. But in the past, this was typically about industrial niche applications. Now IoT is moving into the consumer space. A few years ago, there was quite a bit of snickering, when people discussed the “need” to connect toasters and coffee makers to the Internet. But now the car is the hottest “Thing” to be connected to the Internet. Due to the high value and all the possibilities, this gave IoT a huge push.

But what does this mean for requirements engineering? We already discussed some disruptive trends recently. Also there are many trends that are not related to IoT (e.g. work agile, in short iterations, etc.). But here we talk about the influence of IoT specifically.

Hardware and Software Evolve Together

In the past, hardware and software were not created equal: Either the hardware was developed first, and then the software to drive it. Think about a computer-controlled cutter, for instance.

There were also scenarios where the software was of primary concern, with hardware attached to it “after the fact”. Think about a coin-operated coffee machine, for instance.

But today, hardware and software should evolve together, so that they are optimized for the task at hand. This will lead to new and innovative designs.

Over-The-Air Software Updates

Today, we click “update” on apps without thinking, but the concept has not been around for that long. The game changes significantly, once these updates are safety-critical, as it is the case with cars or medical equipment.

Over-The-Air updates pose huge opportunities, but also threats. Therefore, safety and security are core requirements, certainly not afterthoughts.

Another aspect is that hardware cannot be updated as easily as software. Therefore, hardware will be built as simple and generic as possible. This is already happening: Network equipment often  ships “ready” for non-existing new technologies that are already in the works, but not yet finalized as a standard (e.g. 5G networks). Or consider Tesla, who can enable paid features wirelessly by uploading the feature as a software package.

Requirements are Evaluated at Run-Time

Requirements Engineers know that the context of a system must be clearly defined, as requirements can only be fulfilled in a valid environment. It’s easy to define the context of a radiator (size of the room, outside temperature, insulation). But the context of an IoT-device is completely out of control. Consider an autonomous car, where the street with all its participants represents the context.

Traditionally, requirements and context are defined beforehand and used as the foundation for a design. But there is an alternative that is not yet applied widely: Rather than evaluating the requirements at design time, evaluate them at run time. The theory behind this has been developed by Gunter, Gunter, Jackson and Zave. The result is that the system can select at runtime from a list of valid “designs”, and activate the one that corresponds best to the situation (context) at hand.

Requirements are Behavior-Descriptions of Black Boxes

Systems typically have a “black box” description, a description that explains the behavior, without explaining how it is achieved. Consider a computer screen: We only care about the input (HDMI-Plug) and output (a picture on the screen). How this is achieved is irrelevant, whether with an LCD screen, LEDs or an old-fashioned picture tube. That information is part of the “white box” description.

We will see more and more behavior-driven descriptions, for several reasons:

1. It makes it easier to use off-the-shelf components.
2. Technology changes so fast that this makes it much easier to replace the innards of a component.
3. The implementation could be an artificial intelligence (AI). Having properly described behavior also makes monitoring for plausible behaviour during run-time possible.
4. It makes testing easier, in two ways: The behavior of the component can be thoroughly tested (and the test reused), and the component can be replaced with a mock-component, if the component itself is not yet available.

Conclusion

Make no mistake: With the advent of IoT the job of the requirements engineer will change significantly. It’s not just “more of the usual”, it’s a real paradigm shift. These developments are driven by the need to change: Not just during development, but also during run-time. They are also driven by an exponential growth of complexity, which can only be handled via “divide and conquer”, resulting in much more black-box thinking.