Vom Kundenwunsch zur messbaren Anforderung

Worum es geht

Die Obstgenossenschaft Thurland lagert in acht Kühlzellen rund 2000 Tonnen Äpfel. Bis jetzt läuft der Lagerchef Ruedi Gamper zweimal am Tag durch die Halle, liest die Thermometer ab und trägt die Werte in eine Liste ein. Fällt nachts ein Kühlaggregat aus, merkt es niemand bis zum Morgen. Bei einer Zelle mit 250 Tonnen Äpfeln kann das schnell einen fünfstelligen Schaden geben.

Alina, Lernende im 3. Lehrjahr bei der Sensorik Bodensee AG in Kreuzlingen, soll einen Dienst bauen, der die Zellen rund um die Uhr überwacht. Ihr erster Impuls: Sensoren bestellen, Broker aufsetzen, Dashboard bauen. Ihr Berufsbildner Marco bremst sie: «Was genau soll der Dienst können? Und woran merkt der Kunde bei der Abnahme, dass er es kann?»

Genau darum geht es in dieser Lektion. IoT-Projekte scheitern selten an der Technik. Sie scheitern daran, dass der Kunde etwas anderes erwartet hat, als gebaut wurde: Der Alarm kommt «zu spät», die Daten reichen nicht für das Audit, die Kosten laufen davon. Du lernst, ein Kundengespräch vorzubereiten, Wünsche in messbare Anforderungen zu übersetzen, sie zu priorisieren und Zielkonflikte zwischen Beteiligten sauber aufzulösen.

Das Kundengespräch vorbereiten

Stell dir vor, du planst mit Freunden eine Wanderung. «Wir gehen in die Berge» reicht nicht: Wie lange? Wie steil? Was, wenn es regnet? Bei einem IoT-Service ist es genau gleich. Geh deshalb nie ohne Frageliste in ein Kundengespräch. Sie sorgt dafür, dass du nichts vergisst und am Schluss Zahlen statt Eindrücke hast.

Drei Gesprächstechniken machen den Unterschied:

1. Nach den Folgen fragen. Statt «Wie schnell soll der Alarm kommen?» fragst du: «Was passiert mit den Äpfeln, wenn eine Zelle eine Stunde lang 6 Grad hat?» Die Antwort zeigt dir, welche Reaktionszeit wirklich nötig ist.
2. Zahlen erfragen. «Oft», «schnell» und «lange» sind keine Anforderungen. Frag nach: «Wie oft heisst das, alle 5 Minuten oder jede Stunde?»
3. Zusammenfassen. Am Ende fasst du das Gehörte in eigenen Worten zusammen und lässt es bestätigen. So fallen Missverständnisse noch im Gespräch auf.

Funktional, nicht-funktional, und warum «schnell» keine Anforderung ist

Anforderungen teilst du in zwei Arten ein:

• Funktionale Anforderungen beschreiben, was der Dienst tut: Temperatur erfassen, SMS senden, Monatsbericht erzeugen.
• Nicht-funktionale Anforderungen beschreiben, wie gut oder unter welchen Bedingungen er es tut: Genauigkeit, Reaktionszeit, Verfügbarkeit, Aufbewahrungsdauer, Sicherheit, Hosting-Ort, Batterielaufzeit.

Eine einfache Eselsbrücke: Funktional ist ein Verb («Der Dienst sendet ...»), nicht-funktional ist eine Eigenschaft mit Zahl («... innert 5 Minuten, in 99 % der Fälle»).

Jede Anforderung muss messbar sein. Sonst kann bei der Abnahme niemand sagen, ob sie erfüllt ist. So machst du aus Wünschen Anforderungen:

Achte auf jedes Wort: «Länger als 15 Minuten über 4.0 °C» ist etwas anderes als «innert 15 Minuten nach der Überschreitung». Im ersten Fall wartet der Dienst bewusst 15 Minuten ab, damit kurzes Türöffnen keinen Alarm auslöst. Im zweiten Fall muss die SMS schon 15 Minuten nach dem ersten zu warmen Wert auf dem Handy sein. Beides ist legitim, aber es ergibt unterschiedliche Alarmregeln.

Priorisieren mit MoSCoW und Abnahmekriterien festlegen

Nach einem guten Gespräch hast du mehr Wünsche, als Budget und Zeit hergeben. Mit MoSCoW ordnest du sie:

Die Kategorie Won't wird oft unterschätzt. Sie schützt dich davor, dass mitten im Projekt «noch schnell» etwas dazukommt. Steht es schriftlich als Won't in der Liste, ist klar: Das ist ein neues Projekt mit neuer Offerte.

Zu jeder Muss-Anforderung gehört ein Abnahmekriterium: ein konkreter Test, den du zusammen mit dem Kunden durchführst. Ein gutes Abnahmekriterium beschreibt Ausgangslage, Handlung und erwartetes Ergebnis.

Anforderung F-03: Temperaturalarm
Ausgangslage: Zelle 3 im Normalbetrieb, Sensor meldet 2.8 °C.
Handlung:     Sensor wird in einer Kühlbox mit 8 °C für 25 Minuten gelagert.
Erwartet:     Der Lagerchef erhält spätestens 20 Minuten nach dem ersten
              Messwert über 4.0 °C eine SMS mit Zellennummer und Temperatur.

Zielkonflikte erkennen und auflösen

Im Gespräch bei Thurland prallen Wünsche aufeinander. Ruedi Gamper will bei jeder Abweichung von 0.5 Grad sofort eine SMS. Die Qualitätsverantwortliche Corinne Stäheli braucht die Daten zwei Jahre lang für Audits. Die Geschäftsleitung will, dass alles möglichst wenig kostet.

Solche Konflikte löst du nicht, indem du einer Person recht gibst. Du fragst nach dem Interesse hinter dem Wunsch und zeigst die Folgen auf:

Alina fragt im Gespräch: «Herr Gamper, wie schnell nimmt ein Apfel bei 6 Grad wirklich Schaden?» Die Antwort: Erst nach mehreren Stunden wird es kritisch. Damit ist klar, dass 15 Minuten Verzögerung kein Risiko sind, aber viele Fehlalarme vermeiden. Den Entscheid schreibt sie mit Datum und Namen ins Protokoll.

Schritt für Schritt: Die Anforderungsliste für das Obstlager

So geht Alina nach dem Gespräch vor:

Schritt 1: Notizen sortieren. Jede Aussage wird als Wunsch, Rahmenbedingung oder offene Frage markiert. Ergebnis: 19 Wünsche, 4 Rahmenbedingungen, 3 offene Fragen.

Schritt 2: Offene Fragen klären. Per Mail: Wer ist die Stellvertretung des Lagerchefs? Welches Format braucht das Audit?

Schritt 3: Duplikate zusammenführen. «Alarm aufs Handy» und «SMS an Ruedi» sind dieselbe Anforderung. Aus 19 Wünschen werden 14 Anforderungen.

Schritt 4: Messbar formulieren und einteilen. Jede Anforderung bekommt eine ID (F für funktional, NF für nicht-funktional), eine Zahl und eine Priorität:

Schritt 5: Zählen und prüfen. 9 Muss, 4 Soll, 1 Kann. Als Won't notiert: Erfassung von Türöffnungen mit Badge.

Schritt 6: Abnahmekriterien ergänzen. Für jede Muss-Anforderung ein Test wie oben. F-01 zum Beispiel: «In der Datenbank liegen für jede Zelle über 24 Stunden mindestens 274 von 288 erwarteten Werten» (also mindestens 95 %, einzelne Funkverluste sind bei LoRaWAN normal).

Schritt 7: Review. Alina schickt die Liste an alle drei Beteiligten und bittet um Freigabe bis Freitag. Erst danach beginnt sie mit der Architektur.

Im Code-Labor wertest du einen Abnahmetest automatisch aus: Welche Anforderungen sind erfüllt, und ist der Dienst abnahmebereit?

Typische Fehler

• Mit der Technik beginnen. Wer zuerst Sensoren bestellt, merkt später, dass sie die geforderte Genauigkeit nicht schaffen. Erst Anforderungen, dann Architektur, dann Einkauf.
• Unmessbare Wörter stehen lassen. «Schnell», «zuverlässig», «einfach» gehören nicht in eine Anforderungsliste. Ersetze sie durch Zahlen und Bedingungen.
• Nur mit einer Person reden. Der Lagerchef denkt an Alarme, die Qualitätsverantwortliche an Audits, die Geschäftsleitung an Kosten. Fehlt eine Sicht, fehlen Anforderungen.
• Alles ist Muss. Wenn 14 von 14 Anforderungen Muss sind, hast du nicht priorisiert. Frag: «Wäre der Dienst ohne das wirklich unbrauchbar?»
• Keine Abnahmekriterien. Ohne vereinbarten Test wird die Abnahme zur Diskussion über Gefühle. Schreib den Test auf, bevor du baust.

Zusammenfassung

• Ein Kundengespräch braucht eine Frageliste: Messgrössen, Intervall, Orte, Personen, Alarme, Aufbewahrung, Rahmen, Betrieb.
• Funktionale Anforderungen sagen, was der Dienst tut. Nicht-funktionale sagen, wie gut und unter welchen Bedingungen.
• Jede Anforderung ist messbar formuliert und hat ein Abnahmekriterium.
• MoSCoW priorisiert in Muss, Soll, Kann und bewusst Nicht. Won't schützt vor schleichendem Mehraufwand.
• Bei Zielkonflikten fragst du nach dem Interesse hinter dem Wunsch, zeigst Folgen auf und lässt die verantwortliche Person entscheiden.
• Die freigegebene Anforderungsliste ist die Grundlage für Architektur, Offerte und Abnahme.