Das Internet der Dinge (IoT) ist derzeit ein heißes Schlagwort. Es besagt einfach, dass wir physische Geräte nehmen und sie mit dem Internet verbinden. Wie bei vielen Schlagwörtern ist dies nichts wirklich Neues: Dies geschieht seit Jahrzehnten. Aber früher ging es dabei typischerweise um industrielle Nischenanwendungen. Jetzt bewegt sich IoT in den Verbraucherbereich. Vor einigen Jahren gab es einiges Gelächter, als die Leute über die “Notwendigkeit” diskutierten, Toaster und Kaffeemaschinen mit dem Internet zu verbinden. Aber jetzt ist das Auto das heißeste “Ding”, das mit dem Internet verbunden werden kann. Aufgrund des hohen Werts und all der Möglichkeiten hat dies dem IoT einen enormen Schub gegeben.
Aber was bedeutet das für das Requirements Engineering? Wir haben bereits besprochen einige disruptive Trends kürzlich. Außerdem gibt es viele Trends, die nicht mit dem IoT zusammenhängen (z. B. agile Arbeit, in kurzen Iterationen usw.). Aber hier sprechen wir spezifisch über den Einfluss des IoT.
Hardware und Software entwickeln sich gemeinsam weiter
Früher wurden Hardware und Software nicht gleichberechtigt entwickelt: Entweder wurde zuerst die Hardware entwickelt und dann die Software, um sie anzusteuern. Denken Sie zum Beispiel an eine computergesteuerte Schneidemaschine.
Es gab auch Szenarien, in denen die Software im Vordergrund stand und die Hardware “nachträglich” daran angebracht wurde. Denken Sie zum Beispiel an einen Münzkaffeeautomaten.
Aber heute sollten Hardware und Software gemeinsam weiterentwickelt werden, damit sie für die jeweilige Aufgabe optimiert sind. Dies wird zu neuen und innovativen Designs führen.
Over-the-Air-Softwareupdates
Heute klicken wir gedankenlos auf “Aktualisieren” bei Apps, aber die Idee gibt es noch gar nicht so lange. Das Spiel ändert sich grundlegend, sobald diese Updates sicherheitskritisch sind, wie es bei Autos oder medizinischen Geräten der Fall ist.
Over-The-Air-Updates bieten riesige Chancen, bergen aber auch Gefahren. Daher sind Sicherheit und Schutz Kernanforderungen und keinesfalls etwas, das man nachträglich bedenkt.
Ein weiterer Aspekt ist, dass Hardware nicht so einfach wie Software aktualisiert werden kann. Daher wird Hardware so einfach und generisch wie möglich gebaut. Das geschieht bereits: Netzwerkausrüstung wird oft “bereit” für nicht existierende neue Technologien ausgeliefert, an denen bereits gearbeitet wird, die aber noch nicht als Standard finalisiert sind (z. B. 5G-Netzwerke). Oder denken Sie an Tesla, das kostenpflichtige Funktionen drahtlos aktivieren kann, indem es die Funktion als Softwarepaket hochlädt.
Anforderungen werden zur Laufzeit ausgewertet
Requirements-Ingenieure wissen, dass der Kontext eines Systems klar definiert sein muss, da Anforderungen nur in einer gültigen Umgebung erfüllt werden können. Es ist einfach, den Kontext eines Heizkörpers zu definieren (Größe des Raumes, Außentemperatur, Isolierung). Aber der Kontext eines IoT-Geräts liegt völlig außerhalb der Kontrolle. Betrachten Sie ein autonomes Auto, bei dem die Straße mit all ihren Teilnehmern den Kontext darstellt.
Traditionell werden Anforderungen und Kontext im Voraus definiert und als Grundlage für ein Design verwendet. Aber es gibt eine Alternative, die noch nicht weit verbreitet ist: Anstatt die Anforderungen zur Entwurfszeit zu bewerten, bewerten Sie sie zur Laufzeit. Die Theorie dahinter wurde von Gunter, Gunter, Jackson und Zave. Das Ergebnis ist, dass das System zur Laufzeit aus einer Liste gültiger “Designs” auswählen und jenes aktivieren kann, das der gegebenen Situation (dem Kontext) am besten entspricht.
Anforderungen sind Verhaltensbeschreibungen von Black Boxes
Systeme haben typischerweise eine “Black-Box”-Beschreibung, eine Beschreibung, die das Verhalten erklärt, ohne zu erklären, wie es erreicht wird. Betrachten Sie einen Computermonitor: Uns interessieren nur Eingabe (HDMI-Stecker) und Ausgabe (ein Bild auf dem Bildschirm). Wie dies erreicht wird, ist irrelevant, sei es mit einem LCD-Bildschirm, LEDs oder einer altmodischen Bildröhre. Diese Informationen sind Teil der “White-Box”-Beschreibung.
Wir werden immer mehr sehen verhaltensorientierte Beschreibungen, aus mehreren Gründen:
- Es erleichtert die Verwendung von Standardkomponenten.
- Technologie verändert sich so schnell, dass es viel einfacher wird, das Innenleben einer Komponente auszutauschen.
- Die Implementierung könnte eine künstliche Intelligenz (KI) sein. Ein richtig beschriebenes Verhalten ermöglicht auch die Überwachung auf plausibles Verhalten während der Laufzeit.
- Es vereinfacht das Testen auf zwei Arten: das Verhalten der Komponente kann gründlich getestet werden (und der Test wiederverwendet werden) und die Komponente kann durch eine Mock-Komponente ersetzt werden, falls die Komponente selbst noch nicht verfügbar ist.
Schlussfolgerung
Machen Sie keinen Fehler: Mit dem Aufkommen des IoT wird sich die Arbeit des Requirement Engineers grundlegend verändern. Es handelt sich nicht nur um “mehr vom Üblichen”, sondern um einen echten Paradigmenwechsel. Diese Entwicklungen werden durch die Notwendigkeit von Veränderungen vorangetrieben: Nicht nur während der Entwicklung, sondern auch während des Betriebs. Sie werden auch durch ein exponentielles Wachstum der Komplexität angetrieben, das nur durch “Teile und Herrsche” bewältigt werden kann und zu deutlich mehr Black-Box-Denken führt.
