Ein Pflichtenheft verbindet Ihren Bedarf mit einer überprüfbaren Umsetzung. Für KI-Projekte ist besonders wichtig, erlaubtes Verhalten, unzulässige Ergebnisse und die Grenzen der Prüfung ausdrücklich zu beschreiben.
Den Begriff gemeinsam festlegen
Unternehmen verwenden Lastenheft, Pflichtenheft und Anforderungskatalog unterschiedlich. Vereinbaren Sie deshalb zunächst den Zweck Ihres Dokuments. In diesem Beitrag bezeichnet Pflichtenheft die gemeinsam abgestimmte Beschreibung dessen, was die vorgesehene Lösung innerhalb eines begrenzten Auftrags leisten soll.
Das Dokument muss nicht jedes technische Detail vorwegnehmen. Es sollte aber zeigen, welche Aufgabe gelöst wird, unter welchen Bedingungen und mit welchem Nachweis. Bei offenen Voraussetzungen wird festgehalten, wann und von wem sie geklärt werden.
Ein umfangreiches Dokument schafft keine Sicherheit, wenn die entscheidenden Begriffe unklar bleiben. Wenige präzise Anforderungen können für einen kleinen Pilot sinnvoller sein als viele allgemein gehaltene Seiten.
Jede Anforderung erhält sechs Bestandteile
Verwenden Sie eine feste Struktur:
Kennung: eine eindeutige Nummer für spätere Rückfragen.
Aufgabe: das Verhalten aus Sicht der betroffenen Person.
Bedingungen: Datenbestand, Rolle, Sprache und Einsatzsituation.
Grenze: was die Lösung nicht tun darf oder noch nicht abdeckt.
Nachweis: ein konkreter Test oder eine überprüfbare Unterlage.
Verantwortlichkeit: wer fachlich prüft und die Entscheidung dokumentiert.
Ergänzen Sie Priorität und Status, wenn mehrere Anforderungen parallel bearbeitet werden. Eine offene Anforderung bleibt als offen markiert. Streichen Sie sie nicht einfach aus der aktuellen Fassung, weil sie gerade schwierig umzusetzen ist.
Die KI-Beschaffungsleitlinien der britischen Regierung empfehlen, Anforderungen aus der zu lösenden Aufgabe abzuleiten. Die hier vorgeschlagene Struktur ist eine eigene Arbeitshilfe für KMU.
Aus einer vagen Aussage eine prüfbare machen
Die Formulierung «Die KI beantwortet Produktfragen zuverlässig» lässt offen, welche Produkte gemeint sind und wann eine Antwort als richtig gilt. Eine fiktive präzisere Anforderung könnte lauten:
«Berechtigte Mitarbeitende können Fragen zu den freigegebenen deutschsprachigen Unterlagen der Produktfamilie A stellen. Jede sachliche Produktaussage muss sich auf eine angezeigte gültige Quelle zurückführen lassen. Fehlt eine ausreichende Grundlage, weist die Anwendung darauf hin. Die fachliche Prüfung erfolgt anhand des vereinbarten Testkatalogs.»
Dazu gehört die Definition einer gültigen Quelle. Vielleicht entscheidet ein Freigabestatus im Dokumentenregister darüber. Ohne diese Regel verschiebt das Pflichtenheft nur die Unklarheit in einen anderen Begriff.
Fehler und Ausschlüsse konkret beschreiben
Nicht jede Abweichung hat dieselbe Bedeutung. Eine ungeschickte Formulierung unterscheidet sich von einer falsch zugeordneten Wartungsanweisung. Legen Sie gemeinsam fest, welche Fehler eine Nutzung ausschliessen und welche nachgebessert werden können.
Ein fiktiver Ausschluss lautet: «Die Anwendung löst keine Bestellungen aus und versendet keine externen Nachrichten.» Der Nachweis prüft dann auch entsprechende Eingaben. Eine reine Beschreibung der vorgesehenen Schaltflächen reicht dafür nicht.
Die NCSC-Empfehlungen zum sicheren Design berücksichtigen Sicherheitsanforderungen neben Funktion und Leistung. Übertragen Sie dieses Prinzip in konkrete Fragen zu Rollen, Eingaben und möglichen Aktionen. Die Ausgestaltung muss zum jeweiligen Risiko passen.
Qualitätsziele mit ihrem Messverfahren verbinden
Eine Zahl wie «95 Prozent Genauigkeit» bleibt ohne Testgrundlage mehrdeutig. Bestimmen Sie mindestens Fallauswahl, erwartetes Ergebnis, Bewertungsregel und Umgang mit Grenzfällen. Vereinbaren Sie ausserdem, welche Testfälle bei der Entwicklung bekannt sein dürfen.
Für einen kleinen Pilot kann eine fachlich geprüfte Auswahl genügen, um die nächste Entscheidung vorzubereiten. Sie erlaubt jedoch keine unbegrenzte Aussage über alle zukünftigen Eingaben. Schreiben Sie diese Grenze ausdrücklich auf.
Bei Zeitvorgaben gehört die Messbedingung dazu. Wird die Antwortzeit mit wenigen gleichzeitigen Nutzern oder unter einer vereinbarten Last gemessen? Zählt die Quellenanzeige dazu? Solche Details sind für einen fairen Nachweis wichtiger als eine besonders ehrgeizige Zahl.
Annahmen und Entscheidungen versionieren
Führen Sie drei getrennte Listen: bestätigte Anforderungen, offene Annahmen und beschlossene Änderungen. Eine Annahme könnte sein, dass ein bestehendes System lesenden API-Zugriff erlaubt. Bis zur Prüfung sollte darauf keine unbedingte Zusage zur Integration aufbauen.
Jede relevante Änderung erhält Datum, Grund und Auswirkung. Beispiel: Eine zweite Sprache erweitert Datenaufbereitung und Tests. Die Änderung wird sichtbar beschlossen, statt stillschweigend in einer neuen Textfassung zu erscheinen.
Verknüpfen Sie die Kennungen mit Testprotokollen. Dann lässt sich später erkennen, welche Anforderung geprüft wurde und welche noch auf eine Entscheidung wartet.
Das Pflichtenheft in einer Lesesitzung prüfen
Lassen Sie eine Fachperson, eine technische Person und die Projektverantwortung einen konkreten Fall durchgehen. Können alle erklären, was die Anwendung dabei tun soll? Wissen sie, wie der Nachweis aussieht? Uneinigkeit ist ein Hinweis auf eine zu offene Formulierung.
Die spätere Abnahme vor dem Produktivbetrieb baut auf solchen geklärten Anforderungen auf. Das Pflichtenheft ersetzt diese Prüfung nicht, macht sie aber planbar.
Eine Anforderung sollte ausserdem einen eindeutigen Status tragen: vorgeschlagen, bestätigt, umgesetzt oder geprüft. Diese Zustände sind nicht austauschbar. Eine fertig entwickelte Funktion kann noch auf ihre fachliche Prüfung warten; eine bestätigte Anforderung kann noch völlig unbearbeitet sein.
Mit einclick als KI-Agentur aus Zürich können Sie aus einem groben Vorhaben einen begrenzten Anforderungskatalog mit nachvollziehbaren Ergebnissen entwickeln.
