aiMOOC

Softwareanforderungen Tickets und Akzeptanzkriterien erstellen

QR-Code

Einleitung

Du entwickelst im zweiten bis dritten Ausbildungsjahr einen Ticketvorrat für digitale Prüfprotokolle. Du zerlegst eine fiktive Messdaten-App in kleine, einzeln testbare Teilprodukte. Für jedes Teilprodukt nennst du Eingabe, Sollverhalten und Fachabnahme. Das Ziel ist nicht eine fertige Maschinensteuerung, sondern eine überprüfbare Entwicklungsplanung.

Voraussetzungen: A1 oder Grundkenntnisse in Python, Dateien, Git und einfachen Tests. Wiederhole diese Grundlagen bei Bedarf im vorherigen Lernangebot. Dessen konkreter Seiteninhalt ließ sich bei dieser Recherche nicht abrufen; deshalb werden ihm keine unbestätigten Inhalte zugeschrieben. Arbeitsweise: papierbasiert, mit lokalen Textdateien oder kostenloser Entwicklungsumgebung; kein kostenpflichtiges KI-Konto nötig. Sämtliche Messreihen, Namen und Rollen sind synthetisch. Keine reale Maschinensteuerung, keine Sicherheitsfreigabe.

Leitfrage: Woran erkennt eine zweite Person anhand eines Tickets, was eingegeben wird, was anschließend gelten soll und wer das Ergebnis fachlich abnimmt? Lernpfad: zunächst Begriffe verstehen, anschließend ein gemeinsames Muster-Ticket beurteilen, schließlich deinen eigenen priorisierten Ticketvorrat entwerfen. Vertiefung: Grenzwerte, Negativtests und Rechteverletzungen nachweisen.

Anforderungen aus Nutzungssituationen gewinnen

Eine Anforderung beschreibt das überprüfbare Ziel

Eine Anforderung legt eine benötigte Eigenschaft des Systems fest. Funktional heißt: Was soll die App tun, etwa eine CSV-Datei einlesen? Nichtfunktional beschreibt Qualitäts- und Randbedingungen, etwa Verständlichkeit von Fehlerhinweisen, nachvollziehbare Änderungen oder den Schutz von Prüfprotokollen. Ein Ticket ist ein dokumentiertes, bearbeitbares Arbeitspaket. Eine User Story nennt Rolle, Ziel und Nutzen; ein Fehlerticket dagegen nennt Schritte, Ist- und Sollverhalten. Nicht jedes Ticket muss eine User Story sein.

Modellfall: Eine Übungswerkstatt legt erfundene Messwerte in einer CSV-Datei mit den Spalten pruef_id,zeitpunkt,wert_mm ab. Beispielzeile: P-017,2026-10-02T09:30,12.4. Ein digitales Prüfprotokoll soll vor der Übernahme prüfen, ob alle Spalten vorhanden sind und ob wert_mm eine Zahl ist. Ein protokollierter Fehler darf keine unbemerkte Datenänderung verursachen. Eine Grenzwertentscheidung ist nicht Teil des ersten Importtickets.

Bedarfssatz: „Als dokumentierende Fachkraft möchte ich fehlerhafte Importzeilen erkennen, damit das Prüfprotokoll keine falschen Werte übernimmt.“ Das zeigt den Nutzen, ersetzt aber nicht die konkreten Regeln. Ein Akzeptanzkriterium macht die Regel beobachtbar und fachlich abnehmbar.

Kreisdiagramm eines Softwareentwicklungszyklus mit Planung, Entwicklung, Test und Betrieb — Überblick: Entwicklung und Prüfung gehören zusammen.

Bildalternative: Anforderungen, Planung, Umsetzung, Test und Pflege bilden wiederkehrende Schritte, keine einmalige Abfolge. Quelle: Wikimedia Commons, Shawn Rider, CC BY-SA 4.0. Es wurde nicht bearbeitet.

Unklarheit als Rückfrage erkennen

„Der Import soll schnell und sicher sein“ ist zu unbestimmt: Welche Dateigröße, welche unerlaubten Eingaben, welche Zugriffsrechte? Formuliere statt einer Vermutung die Klärungsfrage: „Wie viele Zeilen werden in der Übung maximal verarbeitet?“ Für die Fallstudie gelten explizit vereinbarte Übungsregeln: Dateien bis 1 MiB, Spaltennamen genau wie oben, Dezimalpunkt statt Komma, keine Speicherung bei ungültiger Datei. Diese Zahlen sind Fallannahmen und keine Branchenstandards.

Merksatz: Trenne geforderte Funktion, fachliche Geschäftsregel, technische Lösungsentscheidung und offenen Klärungsbedarf. Binde unsichere Aussagen nicht als vermeintlich bestätigte Anforderungen ein.

Aus Anforderungen testbare Tickets schneiden

Kleine vertikale Teilprodukte statt riesiger Sammelaufgaben

Ein Backlog ist eine geordnete Liste noch zu bearbeitender Aufgaben. Eine Abhängigkeit bedeutet, dass ein Ticket ein anderes Arbeitsergebnis benötigt. Ein Inkrement liefert einen kleinen überprüfbaren Nutzen. Teile daher „Komplette Messdaten-App bauen“ in Importprüfung, Fehleranzeige, lokale Tests, Rollenprüfung und Protokollexport auf. Vermeide ausschließlich technische Schichten ohne beobachtbaren Nutzen. Jeder Teilschritt benötigt eine begrenzte Eingabe, ein Sollverhalten und ein Abnahmekriterium. Die Reihenfolge bleibt begründbar und kann nach Feedback angepasst werden.

Bildalternative: Tickets wandern von noch offen über in Bearbeitung und Prüfung zu erledigt. Die Tafel selbst beweist keine erfolgreiche Fachabnahme. Quelle: Wikimedia Commons, Garbanea, CC BY-SA 4.0, unverändert.

Ein Ticketformular, das eine zweite Person bearbeiten kann

Pflichtfeld	Prüfbare Formulierung im Muster
Kennung und Titel	MP-01: CSV-Spalten vor dem Import prüfen
Nutzen und Umfang	Nur synthetische Datei einlesen; einheitliche Fehlermeldung bei fehlender Pflichtspalte
Eingabe	CSV-Datei, etwa pruef_id,zeitpunkt,wert_mm; Negativfall ohne wert_mm
Sollverhalten	Bei fehlender Pflichtspalte kein Prüfprotokoll anlegen; Fehler mit Spaltenname ausgeben
Akzeptanzkriterien	AK1 gültiger Kopf wird angenommen; AK2 fehlende Pflichtspalte wird benannt; AK3 bei Fehler keine Datei gespeichert
Testbeleg	Lokaler Test mit zwei künstlichen CSV-Dateien; Ergebnis und Versionsstand protokollieren
Fachabnahme	Fiktive Rolle „Fachverantwortung Prüfprotokoll“ entscheidet anhand Testbeleg und Kriterien
Abgrenzung	Keine realen Sensordaten, Grenzwertentscheidung oder Freigabe eines Prüfgeräts

Geführte Prüfung: Wo steht die Eingabe? Im Feld Eingabe. Ist „Fehler soll sichtbar sein“ ausreichend? Nein: Es fehlen Auslöser, Meldungsinhalt und die Wirkung auf die Speicherung. Wer nimmt fachlich ab? Die eigens benannte Rolle; eine bestandene Python-Testfunktion ersetzt diese Entscheidung nicht. Hilfefrage: Kann jemand ohne Rückfrage die Negativdatei herstellen und das Sollverhalten vergleichen?

Bildalternative: Anforderungen und Änderungen durchlaufen Abstimmung, Bearbeitung und Rückmeldung; Verantwortung bleibt bei benannten Menschen. Quelle: Wikimedia Commons, Henning (WMDE), CC BY-SA 4.0, unverändert.

Akzeptanzkriterien und Fehlerfälle präzisieren

Eingabe, Aktion und sichtbares Ergebnis

Akzeptanztest bedeutet: Ein festgelegter Fall wird ausgeführt, das beobachtete Ergebnis mit dem vereinbarten Soll verglichen. Ein übliches Muster ist Angenommen – Wenn – Dann: Angenommen eine Datei besitzt die drei Pflichtspalten; wenn die Fachkraft den Import startet; dann bestätigt die App den Import und stellt eine prüfbare Vorschau bereit. Für den Negativfall: Angenommen wert_mm fehlt; wenn importiert wird; dann erscheint „Pflichtspalte wert_mm fehlt“ und es wird kein Protokoll erzeugt. Die drei Teile sind keine Programmiersprache; sie helfen bei der präzisen Beschreibung. Die offizielle Gherkin-Referenz enthält auch deutsche Schlüsselwörter.

Prüffall	Synthetische Eingabe	Erwartetes Ergebnis	Beleg
Normalfall	P-017,2026-10-02T09:30,12.4 mit vollständigem Kopf	Vorschau zeigt P-017 und 12.4; Speicherung nur nach bestätigtem Schritt	Screenshot oder textueller Testbericht
Fehlende Spalte	Kopf nur pruef_id,zeitpunkt	Benannte Fehlermeldung; keinerlei Protokolldatei angelegt	Dateiliste vor und nach Ausführung
Ungültiger Wert	P-018,2026-10-02T09:31,nichtmessbar	Zeile zurückweisen und verständlichen Hinweis ausgeben	Testprotokoll mit Eingabe und Ist-Ergebnis
Größenlimit	Fiktive Datei größer als 1 MiB	Import abweisen, ohne vorhandene Daten zu verändern	Grenzwerttest für 1 MiB und darüber

Fehlerbegründung: Würde das Programm nichtmessbar stillschweigend zu Null machen, entstünde ein falscher Messwert. Damit wäre die geforderte Nachvollziehbarkeit verletzt. Deshalb darf es in unserem Beispiel keine heimliche Korrektur geben. Vertiefung: Unterscheide einen Fehler im Anforderungstext von einem Fehler im Programm und von einer fachlich geänderten Regel. Dokumentiere jeweils andere nächste Schritte.

Akzeptanzkriterium, Testfall, Definition of Done

Ein Akzeptanzkriterium beschreibt fachliche Erfolgsbedingungen eines konkreten Tickets; ein Testfall gibt ausführbare Testdaten, Ablauf und erwartete Ergebnisse an. Die Definition of Done sind übergreifende Teamkriterien wie dokumentierter Testlauf und erfolgtes Review. Keines davon allein bedeutet behördliche, technische oder sicherheitsbezogene Freigabe.

Diagnose einer schlechten Aussage: „CSV funktioniert einwandfrei“ ist weder messbar noch grenzt sie Fehlerfälle ein. Verbesserung: „Wenn wert_mm im Dateikopf fehlt, zeigt die App den Spaltennamen und verändert keine vorhandene Protokolldatei.“ Prüfe, ob die fachliche Rolle diesen Sollsatz verstehen und die Programmierrolle einen reproduzierbaren Test dazu schreiben kann.

Ticketvorrat für digitale Prüfprotokolle erarbeiten

Muster-Backlog mit schrittweisem Nutzen

Die folgenden Kennungen sind erfunden. Priorität ist eine begründete Reihenfolge, keine Zusage über reale Projekttermine. Das Beispiel verwendet lokal erzeugte Dateien ohne personenbezogene Daten.

Rang	Ticket und kleiner Nutzen	Eingabe	Sollverhalten	Fachabnahme
1	MP-01 Pflichtspalten erkennen	vollständige und unvollständige CSV-Köpfe	importieren oder begründet ablehnen; keine Speicherung bei Fehler	Fachrolle prüft Kopf- und Negativtest
2	MP-02 Zahlenformat prüfen	12.4, nichtmessbar, leeres Feld	nur eindeutige Zahlen annehmen, Fehlerzeile markieren	Fachrolle gleicht Beispielwerte ab
3	MP-03 Import ohne Seiteneffekt testen	Testdateien, vorhandene Protokolldatei	Fehlimporte lassen Bestandsdateien unverändert	Fachrolle prüft Vorher-nachher-Beleg
4	MP-04 Vorschau anzeigen	gültige Zeilen	Protokollvorschau mit Prüffallkennung und Wert	Fachrolle bestätigt Lesbarkeit und Vollständigkeit
5	MP-05 Leserechte begrenzen	fiktive Rolle „Prüfer“ oder „Gast“	Gast sieht keine nicht freigegebenen Protokolle	fachliche und zuständige Berechtigungsrolle prüfen Ablehnungsfall
6	MP-06 Änderungen reviewen	Änderungsanforderung mit Testbelegen	zweite berechtigte Person bewertet die Änderung vor Übernahme	Reviewprotokoll plus getrennte Fachabnahme
7	MP-07 Protokoll exportieren	bestätigte Vorschau	lokale Exportdatei mit Kennung, Zeit und Wert	Fachrolle gleicht Export mit Eingabebeleg ab

Abhängigkeiten: MP-02 folgt auf vereinbarten CSV-Kopf aus MP-01; MP-03 wird mit beiden verbunden. MP-07 folgt erst, wenn Vorschau und Rechte geklärt sind. MP-05 darf nicht auf eine bloße Oberfläche reduziert werden: Unerlaubter Zugriff muss im Testfall als verweigertes Ergebnis sichtbar sein.

Dein Lernprodukt: Erstelle mindestens sechs Tickets in einer Tabelle oder sechs lokalen Markdown-Dateien; je Ticket: Kennung, Ziel, Eingabe, Soll, positives und negatives Akzeptanzkriterium, Abnahmeverantwortung, Abhängigkeit und Testbeleg. Markiere offene Fragen ausdrücklich. Gib anschließend eine begründete Prioritätenfolge an.

Bildalternative: Mehrere kleine Ergebnisse werden früher geprüft als eine einzige große Lieferung; nach jedem Schritt kann gelernt werden. Quelle: Wikimedia Commons, Steveprutz, CC BY-SA 4.0, unverändert.

Videohilfe und Alternative ohne externes Medium

Deutschsprachiges Video: „Was ist eine User Story?“ (Sebastian Burkart, 21.10.2018); Videoseite. Im Suchindex ist der Beitrag auffindbar; die aktuelle Abspielbarkeit am Lernort kann sich ändern. Ohne Video: Formuliere eine Story in der Form Als [Rolle] möchte ich [Ziel], um [Nutzen]; zerlege sie in ein prüfbares Ticket und ergänze drei Akzeptanzkriterien. Das Beispiel aus MP-01 reicht vollständig als Textgrundlage.

Deutschsprachiges Video: „Akzeptanzkriterien – User Story Beispiel“ (Unsuck Work, 09.09.2020); Videoseite. Die Metadaten waren über den Suchindex prüfbar, der direkte Abruf nicht zuverlässig: Verfügbarkeit am Lernort ungeprüft. Ohne Video: Vergleiche das unklare Kriterium „Import arbeitet korrekt“ mit den beiden Negativtests zu MP-01 und MP-02.

Rechte, Review und fachliche Abnahme unterscheiden

Trennung der Verantwortungen

Entwicklungsrolle schreibt Änderung und automatische Tests. Reviewrolle kontrolliert die Änderung, Testbelege und offene Risiken. Fachabnahme bestätigt die vereinbarten Geschäftsergebnisse; sie ist nicht mit dem Code-Review gleichzusetzen. Freigabe für reale Anlagen wird in diesem Kurs ausdrücklich nicht erteilt. Ein lokaler Test ist ein Nachweis zu einem Übungsfall und niemals eine reale Sicherheitszusage.

Beispiel Berechtigungsgrenze: Die fiktive Rolle „Gast“ versucht, ein als intern gekennzeichnetes Prüfprotokoll zu öffnen. Das Soll lautet „Zugriff verweigert; Protokolldaten werden nicht angezeigt“. Ein negativer Berechtigungstest prüft, dass eine unerlaubte Handlung wirklich verhindert wird. Der Test allein legt keine betriebliche Rechteordnung fest: Diese muss von zuständigen Personen entschieden werden.

Reviewgrenze: Ein Coding-Agent kann einen Ticketentwurf, Codevorschlag oder Test erzeugen, aber nicht eigenmächtig Produktionszugang, Fachabnahme, Rechteänderung oder Sicherheitsfreigabe übernehmen. Beschränke Eingaben, Dateizugriff und Bearbeitungsumfang; führe Tests zuerst in einer isolierten Übungsumgebung aus. Die MCP-Sicherheitsempfehlungen adressieren unter anderem die Abgrenzung von Berechtigungen und den Schutz vor unzulässiger Weitergabe von Autorisierung. Das NIST-GAI-Profil bietet eine freiwillige Orientierung für Governance und Risikoprüfung bei generativer KI; beides ist kein Prüfzeugnis für unsere App.

Bildalternative: Eine Entscheidung erzeugt unterschiedliche Folgewege. Übertrage das Prinzip auf „Eingabe gültig?“ und „Fachabnahme erteilt?“, ohne eine Maschinenaktion auszuführen. Quelle: Wikimedia Commons, Abbas2024, CC0 1.0, unverändert.

Abnahmegespräch simulieren

Bereite ein fünfminütiges Rollenspiel vor: Eine Person stellt als Entwicklungsteam MP-02 und die Testergebnisse vor, die andere handelt als fiktive Fachverantwortung. Sie prüft (1) bezeichnete Eingabe, (2) fachliches Soll, (3) nachweisbare Kriterien und entscheidet angenommen, zurückgestellt, oder abgelehnt mit Begründung. Danach werden Rollen getauscht. Schreibe die Entscheidung inklusive offener Punkte in ein Abnahmeprotokoll. Eine echte Sicherheitsabnahme ist ausgeschlossen.

Transferfrage: Wenn die CSV zwar korrekt gelesen wird, aber ein Gast vertrauliche Protokolle sehen kann, ist MP-01 möglicherweise erfüllt, MP-05 aber nicht. Ein Gesamtsystem darf nicht als vollständig freigegeben bezeichnet werden. Kleine prüfbare Teilprodukte verhindern, dass ein bestandener Einzelschritt andere Risiken verdeckt.

Interaktive Aufgaben

Quiz: Teste dein Wissen

Wähle jeweils eine Aussage. Achte besonders auf Eingabe, Sollverhalten, konkrete Belege und menschliche Entscheidung.

1. Was macht eine Aussage als Akzeptanzkriterium prüfbar? (Sie nennt einen beobachtbaren Auslöser und ein erwartetes Ergebnis) (!Sie enthält möglichst viele Adjektive) (!Sie verspricht absolute Fehlerfreiheit) (!Sie nennt nur den verwendeten Editor)