Tag 9: KI-Anforderungen sauber spezifizieren

Marc

Weisst du, Stefan, ich sehe das in der Praxis beim Schweizer Arbeitsmarkt und in Projekten ständig. Da kommt ein Vorstand zusammen, schaut sich um und sagt ganz stolz: Wir brauchen jetzt unbedingt was mit KI für unser Marketing, die Konkurrenz ist auf LinkedIn viel aktiver, baut uns da mal eine Plattform bis Ende Q2, Budget ist knapp.

Stefan

Oh ja. Ein klassisches Briefing aus der Hölle. Ein vages Gefühl, eine harte Frist und schon ein fertiger Lösungswunsch, bevor überhaupt klar ist, welches Problem gelöst werden soll.

Marc

Und genau an der Stelle verbrennen Firmen regelmässig Millionen. Aber, um, wenn man sich die Zahlen anschaut, ist das gar kein neues Phänomen, oder?

Stefan

Absolut nicht. Wenn wir den berühmten CHAOS Report der Standish Group heranziehen, auch wenn die Methodik aus den Neunzigern stammte und oft diskutiert wurde, zeigt er ein extrem stabiles Bild. 13,1 Prozent aller gescheiterten Projekte scheitern direkt an unvollständigen Anforderungen. Weitere 12,4 Prozent an fehlender Nutzereinbindung. Zusammen mit sich ändernden Wünschen sind das über 34 Prozent aller Fehlschläge, die rein auf Verständigungsprobleme zwischen Menschen zurückgehen. Nicht auf die Technik.

Marc

34 Prozent. Das muss man sich mal auf der Zunge zergehen lassen. Es scheitert fast nie daran, dass der Algorithmus nicht rechnen kann, sondern daran, dass die beteiligten Leute völlig unterschiedliche Dinge im Kopf hatten, als sie Ja gesagt haben.

Stefan

Genau das ist der Punkt. Alfonso Papa zeigt das an Tag 9 im AIBS Kurs sehr präzise auf. Er baut eine Kette über fünf Felder auf. Es beginnt mit dem Wunsch: Die Plattform soll schnell sein. Das ist rein gar nichts, worauf man ein System testen kann. Ein Wunsch ist nur ein Gefühl.

Marc

Weil schnell für die Redaktion etwas ganz anderes bedeutet als für den IT Betrieb im Hintergrund.

Stefan

Richtig. Erst wenn du nach dem Warum fragst, kommst du zum Bedürfnis. Die Redaktion verliert zum Beispiel wertvolle Zeit im Freigabeprozess. Daraus machst du die Anforderung: Das System zeigt den Entwurf in unter zwei Sekunden an. Daraus wird das Kriterium: p95 Latenz kleiner gleich zwei Sekunden bei 50 parallelen Nutzerinnen. Und erst mit diesem Kriterium hast du am Ende einen Lasttest im UAT, den der IT Betrieb unterschreiben kann.

Marc

Das, das, das ist der entscheidende Sprung. Der Sprung vom Bedürfnis zum messbaren Kriterium. In der Realität springen aber die meisten Entscheider vom ersten Wunsch direkt in die Codierung. Und Stefan, du als AI Spezialist, wie ordnet der IREB Standard diesen ganzen Prozess eigentlich ein?

Stefan

Nach IREB gibt es vier Grundaufgaben, die kontinuierlich nebeneinander laufen. Ermitteln, Dokumentieren, Validieren und Verwalten. Und das Wort kontinuierlich ist hier extrem wichtig. Requirements Engineering ist kein Projektabschnitt, den man nach Phase eins abhakt und dann nie wieder anfasst. Wer das tut, hat nach drei Monaten ein Dokument, das mit der Wirklichkeit nichts mehr zu tun hat. Man muss das mindestens quartalsweise nachführen.

Marc

Und vor allem bei KI Projekten, wo sich die Modelle und die Daten ja ständig verändern. Ein Adjektiv wie benutzerfreundlich oder fair ist eben keine Anforderung. Erst wenn Wert, Messverfahren und Schwelle im Satz stehen, wird daraus eine Vereinbarung, die man rechtlich oder technisch abnehmen kann.

Stefan

Wenn wir von Anforderungen sprechen, kennen wir aus der klassischen Softwarewelt traditionell drei Säulen: Die funktionale Anforderung, was das System tut. Die Qualitätsanforderung, wie gut es das tut. Und die Randbedingung, was von aussen vorgegeben ist. Bei KI kommt jetzt aber eine vierte, völlig eigenständige Säule dazu: Die Datenanforderung.

Marc

Weil bei einem Lernmodell die Daten ja praktisch der Code sind. Wenn die Daten falsch sind, nützt der beste Algorithmus nichts.

Stefan

Ganz genau. Bei Datenanforderungen fragen wir: Woher kommen die Daten? Was ist die Rechtsgrundlage, etwa nach dem revidierten Schweizer Datenschutzgesetz? Wie steht es um die Labelqualität, die Repräsentativität und wie wird der Datensatz aktualisiert? Ein Modell ist nur so gut wie das Bauteil Datenbestand.

Marc

Lass uns das mal an einem konkreten Beispiel festmachen, das im AIBS Kurs behandelt wird. Der Fall ISA Reach, eine fiktive Marketingplattform für den Innovationsverband Schweizer Arbeitsmarkt. Wenn man da eine Stakeholder Analyse macht, nutzen erfahrene Leute oft das Mendelow Raster, also Macht gegenüber Interesse. Und Stefan, mir fällt in der Schweizer Praxis immer wieder auf, dass Teams dieselben vier Gruppen schlicht vergessen.

Stefan

Welche vier blinden Flecken meinst du genau?

Marc

Erstens, die externe Kreativagentur. Die hat oft Angst um ihr Mandat, sagt das aber nie offen, sondern blockiert das Projekt ganz leise über Schnittstellen und Fristen. Zweitens, Behördenpartner wie das RAV oder das AWA. Die haben strikte Neutralitätsansprüche. Wenn die KI zu reisserische Marketingtexte generiert, verliert der Verband seine Glaubwürdigkeit bei den Ämtern. Drittens, der spätere IT Betrieb, wer pflegt das Modell in zwei Jahren und bezahlt die Tokens? Und viertens, die Community selbst, die man oft nur als passive Zielgruppe denkt, statt als Stakeholder, deren Vertrauen entscheidet.

Stefan

Sehr spannend. Und wie sieht das mit dem Rechtsdienst aus? Der wird ja oft einfach nur als Bremser wahrgenommen.

Marc

Das ist der grösste Fehler überhaupt! Im Schweizer Markt sehe ich das dauernd. Wenn man den Rechtsdienst ab Tag eins nicht als defensives Hindernis, sondern als primäre Anforderung Quelle in die Mendelow Matrix aufnimmt, spart man sich Monate. Der Rechtsdienst nennt dir sofort die harten Leitplanken wie Zweckbindung und Datensparsamkeit. Wenn du die erst zwei Wochen vor dem Go Live erfährst, kannst du den ganzen Bau verwerfen.

Stefan

Absolut. Und das bringt uns direkt zur Messlatte für KI Qualität nach ISO IEC 25 0 1 0 und der KI Erweiterung 25 0 5 9. Ein Satz wie Das Modell muss zuverlässig Texte generieren ist wertlos. Nach ISO musst du vier Komponenten liefern: Die Grösse, das Messverfahren, die Schwelle und den Geltungsbereich.

Marc

Gib mir dafür mal ein handfestes Beispiel.

Stefan

Gerne. Statt verlässlich sagst du: Das System ISA Reach MUSS bei generierten Faktenaussagen eine Beleg Rate von mindestens 95 Prozent erreichen, gemessen an einem monatlich gezogenen Stichprobenset von 100 Textbausteinen durch die Redaktion. Da hast du den Wert von 95 Prozent, das Verfahren mit den 100 Stichproben und die klare Schwelle.

Marc

Das führt uns direkt zu der Frage: Wie erfahre ich überhaupt, was die Leute wirklich brauchen? Wenn man Stakeholder in einen Raum setzt und einfach fragt: Was wünscht ihr euch?, bekommt man doch nur eine endlose Wunschliste.

Stefan

Richtig. Und da hilft das Kano Modell von Noriaki Kano aus dem Jahr 1984. Kano unterscheidet drei Arten von Faktoren: Begeisterungsfaktoren, Leistungsfaktoren und Basisfaktoren. Leistungsfaktoren sind das, was Leute im Interview von selbst nennen. Je mehr davon da ist, desto zufriedener sind sie. Begeisterungsfaktoren erwartet niemand, die muss man gemeinsam in Workshops erfinden.

Marc

Aber die eigentliche Gefahr lauert bei den Basisfaktoren, stimmts?

Stefan

Ganz genau. Basisfaktoren sind so selbstverständlich, dass niemand sie ausspricht. Dass ein System keine ungeprüften Entwürfe veröffentlicht, dass das Corporate Design exakt eingehalten wird oder dass das Login mit dem bestehenden Verbandskonto funktioniert. Wenn ein Basisfaktor fehlt, ist das Projekt auf der Stelle tot, egal wie viele tolle KI Funktionen du gebaut hast. Und Basisfaktoren findest du nie durch Fragen allein, sondern nur durch Beobachtung und Dokumentenanalyse.

Marc

Deshalb verfechten wir in der Praxis ja auch das Prinzip Beobachten vor Fragen, Stichwort Contextual Inquiry. Statt den Leuten ein Formular vorzulegen, setzt man sich an ihren Arbeitsplatz und sagt: Zeig mir doch mal, wie du das heute machst.

Stefan

Diese eine Frage, Zeig mir wie du das heute machst, schlägt jede klassische Feature Wunschliste. Weil du plötzlich die Umwege siehst, die improvisierten Tabellen, die manuellen Klicks. Bano und ihr Team haben 2019 in einer empirischen Studie die häufigsten Interviewfehler untersucht. Ungeübte Interviewer fragen viel zu früh nach Lösungen oder stellen geschlossene Fragen wie Brauchen Sie ein Dashboard?

Marc

Und die Befragten antworten natürlich sofort mit Ja, klar, ein Dashboard wäre super! Und schon hast du ein Feature auf der Liste, das niemand wirklich nutzt.

Stefan

Genau. Alfonso Papa nutzt im Kurs die Regel vom zweimaligen Warum Fragen. Wenn der Stakeholder sagt: Ich will ein Dashboard mit Lead Scoring, dann fragst du zum ersten Mal: Warum? Der Stakeholder antwortet: Damit ich sehe, welches Mitglied gerade aktiv ist. Dann fragst du zum zweiten Mal: Und warum ist das für deine tägliche Arbeit entscheidend? Und plötzlich kommt heraus: Ich verliere heute wöchentlich einen halben Tag damit, Informationen aus vier Systemen manuell zusammenzusuchen, und ich habe Angst, falsche Auskünfte zu geben.

Marc

Aha! Das eigentliche Bedürfnis ist also gar nicht das Dashboard, sondern Zeitersparnis bei der Recherche und Reputationsschutz vor Fehlinformationen. Das Dashboard war nur die erstbeste Idee des Anwenders.

Stefan

Genau so ist es. Wir haben das im AIBS Kurs in einer Fishbowl Übung simuliert. Ein Team interviewt live drei Rollen: Die Leitung Kommunikation, die Mitgliederbetreuung und den Datenschutz. Wenn die Kommunikationsleiterin sagt: Ich unterschreibe nichts, was ungeprüft rausgeht, klingt das erst mal nach sturer Kontrolle. Erst wenn du nachbohrst, erfährst du, dass vor zwei Jahren ein fehlerhafter Post einen Riesenreputationsschaden verursacht hat. Es geht ihr um Sicherheit, nicht um Bürokratie.

Stefan

Wenn wir die Bedürfnisse verstanden haben, müssen wir sie aufschreiben. Und zwar so, dass Verträge und Entwicklungsteams damit arbeiten können. Die Norm ISO IEC IEEE 29148 definiert dafür die präzise Anatomie einer Anforderung. Sie besteht aus genau fünf Bausteinen: Bedingung, Subjekt, Aktion, Objekt und Einschränkung. Und ganz wichtig: Genau ein Vollverb pro Satz.

Marc

Warum ist dieses eine Vollverb so kritisch? Klingt im ersten Moment sehr akademisch.

Stefan

Weil zwei Verben in einem Satz bedeuten, dass zwei verschiedene Dinge passieren, die man separat testen muss. Wenn ein Element in der Syntax fehlt, muss die Entwicklerin oder der Entwickler beim Programmieren eine eigene Annahme treffen. Und diese Annahme entspricht selten dem, was die Fachabteilung wollte.

Marc

Um solche Lücken zu vermeiden, nutzen wir ja Satzschablonen wie EARS aus dem Englischen oder MASTeR auf Deutsch. Stefan, erklär doch kurz, wie MASTeR das schwammige deutsche Wort wenn eliminiert.

Stefan

Das Wort wenn ist im Deutschen extrem gefährlich, weil es sowohl eine Bedingung als auch einen Zeitpunkt ausdrücken kann. MASTeR ersetzt das strikt durch drei Signalwörter: SOBALD für ein schaltendes Ereignis, FALLS für eine logische Bedingung und SOLANGE für einen andauernden Zustand. Dazu kommen die verbindlichen Rechtswörter MUSS für Pflicht, SOLLTE für Wunsch und WIRD für spätere Releases.

Marc

Ein konkreter Satz für ISA Reach lautet dann also: SOBALD eine Nutzerin einen Kampagnenentwurf freigibt, MUSS ISA Reach den Entwurf mit Zeitstempel, Nutzerkennung und Modellversion protokollieren.

Stefan

Wunderschön! Da kann niemand mehr diskutieren, wann was zu tun ist.

Marc

Jetzt muss ich als Praktiker aber doch mal kurz einhaken, Stefan. Wie viel Formalismus braucht ein normales Schweizer KMU denn wirklich? Wenn ich einer KMU Geschäftsleitung mit ISO 29 1 4 8 und MASTeR Schablonen komme, schütteln die doch den Kopf und sagen, wir sind doch nicht bei der NASA.

Stefan

Das verstehe ich gut. Aber der EU AI Act in den Artikeln 9 bis 15 sowie das revidierte Schweizer Datenschutzgesetz schreiben genau diese Dokumentation für Hochrisiko KI und automatisierte Einzelentscheidungen zwingend vor. Artikel 12 verlangt automatische Protokollierung, Artikel 14 fordert wirksame menschliche Aufsicht. Wer da keine präzisen Schablonen nutzt, riskiert bei Audits oder Haftungsfällen extrem hohe Bussen.

Marc

Das leuchtet ein. Law and Order greift also auch bei der Software Spezifikation. Wie sieht das denn konkret bei den Datenanforderungen für ISA Reach aus?

Stefan

Wir haben das im Kurs sehr klar abgegrenzt. Eine saubere Datenspezifikation definiert positiv und negativ, was verwendet werden darf. Für ISA Reach gilt: Das System DARF für die Personalisierung ausschliesslich selbst deklarierte Interessen und Mitgliedsstammdaten verwenden. Verhaltensbasierte Trackingprofile von Community Mitgliedern kommen explizit auf die Sperrliste. Das schafft rechtliche Klarheit noch bevor die erste Zeile Code geschrieben wird.

Marc

Das bringt uns zum vielleicht spannendsten Punkt des ganzen RE Prozesses: Den Konflikten. Stakeholder haben nun mal gegensätzliche Interessen. Die Mitgliederbetreuung will maximale Personalisierung und viele Leads, der Datenschutz will minimale Datenerhebung. Nach IREB gibt es sechs Konflikttypen: Sachkonflikt, Datenkonflikt, Interessenkonflikt, Wertekonflikt, Beziehungskonflikt und Strukturkonflikt.

Stefan

Und die Unterscheidung dieser Typen ist überlebenswichtig! Der häufigste Fehler in Projekten ist nämlich, einen Wertekonflikt wie ein Sachkonflikt zu behandeln. Man versucht dann, einen prinzipiellen Streit zwischen Datenschutz und Marketing durch noch mehr Zahlen und Datenanalysen zu lösen. Das funktioniert nie, weil beide Seiten aus ihrer Grundhaltung heraus recht haben.

Marc

Genau. Ein Wertekonflikt lässt sich nicht errechnen, sondern muss verhandelt oder von oben entschieden werden. Der Werkzeugkasten bietet dafür verschiedene Techniken an: Kompromiss, Abstimmung, Ober sticht Unter oder Variantenbildung. Und jede dieser Entscheidungen gehört zwingend in eine Stakeholder Konflikt Map.

Stefan

Wie sieht so ein Eintrag in der Konflikt Map genau aus?

Marc

Fünf Felder: Beteiligte Rollen, betroffene Anforderungen, identifizierter Konflikttyp, gewählte Lösungstechnik und ganz wichtig: Die finale Entscheidung inklusive Begründung und Datum. Wenn du die Begründung nicht aufschreibst, sitzt du in drei Monaten wieder im selben Sitzungszimmer und führst exakt dieselbe Diskussion noch einmal von vorne, weil sich niemand mehr an die Argumente erinnert.

Stefan

Sehr wahr. Und um den Umfang realistisch zu halten, nutzen wir das MoSCoW Framework. Must, Should, Could und Won't have this time. Eine goldene Regel besagt: Der Must Anteil darf maximal 60 Prozent des verfügbaren Aufwands ausmachen. Wenn du 90 Prozent Must hast, hast du keine Priorisierung, sondern ein Wunschelement.

Marc

Und die Won't Liste ist das unterschätzteste Werkzeug überhaupt! Nicht gelieferte Features explizit aufzuschreiben schützt vor dem schleichenden Scope Creep. Wenn im Dokument schwarz auf weiss steht: Automatisierte Community Verhaltensprofile werden in Phase eins NICHT gebaut, gibt es beim Go Live keine enttäuschten Gesichter.

Stefan

Das ist die perfekte Brücke zu Tag 10 des AIBS Kurses. Erst wenn du diese glasklaren, messbaren und konfliktfreien Anforderungssätze in der Hand hast, kannst du im nächsten Schritt fundierte Make or Buy Entscheidungen treffen und die richtige Modellarchitektur auswählen. Wer anfängt Modelle zu evaluieren, bevor die Anforderungen stehen, baut eine wunderschöne Garage für ein Auto, das er gar nicht besitzt.

Marc

Ein schönes Schlusswort, Stefan. Am Ende geht es immer um denselben einfachen Sprung: Vom vagen Adjektiv zur messbaren Schwelle. Wer den beherrscht, hält das Projektrisiko im Griff.