Die Formulierung von Anforderungen für Softwareprojekte erzeugt oft eine Kommunikationslücke. Entwickler sprechen in Code. Geschäftsinteressenten sprechen in Nutzen. Akzeptanzkriterien (AK) befinden sich dazwischen und fungieren als Brücke zwischen dem, was benötigt wird, und dem, was gebaut wird. Wenn diese Brücke mit technischen Fachbegriffen errichtet wird, wird sie instabil. Nicht-technische Teammitglieder können nicht überprüfen, ob die Arbeit korrekt ist. Interessenten verlieren das Vertrauen in den Prozess. Dieser Leitfaden erklärt, wie Akzeptanzkriterien ohne technische Fachbegriffe formuliert werden können, um Klarheit, Zusammenarbeit und qualitativ hochwertige Lieferung zu gewährleisten.
🧩 Was sind Akzeptanzkriterien?
Akzeptanzkriterien definieren die Bedingungen, die ein Softwareprodukt erfüllen muss, um von einem Nutzer oder Interessenten akzeptiert zu werden. Es handelt sich nicht um eine Liste von Funktionen, sondern um eine Definition von Grenzen. Sie beantworten die Frage: „Wie sieht „fertig“ aus?“. Im Kontext einer Benutzergeschichte liefert die AK die notwendigen Details, damit das Entwicklungsteam den Umfang versteht.
Wirksame Akzeptanzkriterien sollten folgende Eigenschaften aufweisen:
- Klar:Keine Mehrdeutigkeit. Jeder liest die gleiche Bedeutung.
- Prüfbar:Sie können einen Testfall formulieren, um sie zu überprüfen.
- Spezifisch:Sie verwenden konkrete Zahlen und Zustände, keine vagen Begriffe.
- Verständlich:Sie sind in einer Sprache verfasst, die das gesamte Team versteht.
🗣️ Warum technische Fachbegriffe die Zusammenarbeit beeinträchtigen
Wenn Entwickler Akzeptanzkriterien schreiben, besteht die natürliche Neigung, Implementierungsdetails zu beschreiben. Das geschieht, weil sie wissen, wie das System funktioniert. Doch die Beschreibung der Lösung, bevor das Problem gelöst ist, birgt Risiken. Sie reduziert die Flexibilität und erzeugt Verwirrung bei Personen, die nicht programmieren.
Die Kosten des Missverständnisses
Stellen Sie sich eine Situation vor, in der ein Interessent eine Anforderung liest und eine andere Bedeutung annimmt als der Entwickler. Diese Diskrepanz führt zu Nacharbeit. Nacharbeit verschwendet Zeit und Budget. Sie verzögert zudem die Freigabe von Wert. Die Vermeidung von Fachbegriffen verringert die Wahrscheinlichkeit, dass diese Lücke entsteht.
- Entwickler:Könnten sich auf Datenbankfelder konzentrieren statt auf Nutzerergebnisse.
- QA-Testpersonen:Könnten nicht wissen, wie das Verhalten überprüft werden kann, ohne die Struktur der API zu verstehen.
- Geschäftsleiter:Könnten die Geschichte genehmigen, weil sie meinen, sie erfülle ihre Bedürfnisse, nur um festzustellen, dass dies nicht der Fall ist.
Häufige technische Begriffe, die vermieden werden sollten
Um die Kriterien verständlich zu halten, sollten bestimmte Wörter durch einfache Sprache ersetzt werden. Ziel ist es, das Verhalten zu beschreiben, nicht die Mechanik.
- Vermeiden:„Aktualisieren Sie den Datensatz in der Datenbank.“
Verwenden Sie:„Speichern Sie die Kundendaten.“ - Vermeiden: „Rufen Sie die API-Endpunkt auf.“
Verwenden Sie: „Senden Sie die Anfrage an den Server.“ - Vermeiden Sie: „Rendern Sie das Komponente.“
Verwenden Sie: „Zeigen Sie die Schaltfläche auf dem Bildschirm an.“ - Vermeiden Sie: „Werfen Sie eine Ausnahme.“
Verwenden Sie: „Zeigen Sie eine Fehlermeldung an.“
📝 Prinzipien für klare Anforderungen
Das Schreiben ohne Fachjargon erfordert Disziplin. Es verlangt von Ihnen, sich von der technischen Lösung zurückzuziehen und sich auf die Benutzererfahrung zu konzentrieren. Die folgenden Prinzipien helfen dabei, diesen Fokus zu bewahren.
1. Fokussieren Sie sich auf das Verhalten, nicht auf die Implementierung
Beschreiben Sie, was das System tut, nicht, wie es es tut. Das System sollte die interne Logik verarbeiten. Der Benutzer interessiert sich für das Ergebnis. Wenn das System seine interne Datenbankstruktur ändert, sollte der Benutzer dies nicht bemerken. Daher sollte die Akzeptanzkriterium die Datenbank nicht erwähnen.
- Schlecht: „Fügen Sie eine Zeile in die Tabelle Bestellungen ein.“
- Gut: „Erstellen Sie einen neuen Auftragseintrag im System.“
2. Verwenden Sie die aktive Stimme
Die passive Stimme verschleiert, wer was tut. Die aktive Stimme klärt die Handlung. Sie macht die Kriterien leichter lesbar und verständlich.
- Schlecht: „Der Button sollte vom Benutzer angeklickt werden.“
- Gut: „Der Benutzer klickt auf den Button.“
3. Definieren Sie konkrete Zahlen
Wörter wie „schnell“, „viel“ oder „bald“ sind subjektiv. Sie führen zu Streitigkeiten darüber, was Erfolg ausmacht. Verwenden Sie stattdessen messbare Werte.
- Schlecht: „Die Seite sollte schnell laden.“
- Gut:„Die Seite lädt innerhalb von 3 Sekunden.“
4. Vermeide Annahmen
Gehen Sie nicht davon aus, dass der Benutzer weiß, wie das System funktioniert. Geben Sie die Bedingungen ausdrücklich an. Wenn ein Schritt erforderlich ist, um eine Aktion durchzuführen, führen Sie ihn als Voraussetzung auf.
- Schlecht: „Sie können die Datei löschen.“
- Gut: „Wenn eine Datei ausgewählt ist, kann der Benutzer sie löschen.“
🧪 Das Given-When-Then-Muster (vereinfacht)
Eine der effektivsten Möglichkeiten, nicht-technische Akzeptanzkriterien zu formulieren, ist das Given-When-Then-Format. Diese Struktur ist oft mit der verhaltensbasierten Entwicklung verbunden, funktioniert aber auch hervorragend für Anforderungen in einfacher Sprache. Sie unterteilt die Szene in Kontext, Aktion und Ergebnis.
Aufteilung des Musters
- Gegeben: Der ursprüngliche Zustand oder Kontext. Was geschieht vor der Aktion?
- Wenn: Die Aktion, die vom Benutzer oder System durchgeführt wird. Was löst die Änderung aus?
- Dann: Das erwartete Ergebnis. Was geschieht nach der Aktion?
Beispiel-Szene: Anmelden
Stellen Sie sich eine Benutzergeschichte zum Anmelden bei einem sicheren Konto vor. Eine technische Version könnte Sitzungstoken erwähnen. Eine Version in einfacher Sprache konzentriert sich auf die Erfahrung.
- Gegeben: Der Benutzer befindet sich auf dem Anmeldebildschirm.
- Wenn: Der Benutzer gibt eine gültige E-Mail-Adresse und ein Passwort ein und klickt dann auf „Anmelden“.
- Dann: Der Benutzer wird auf die Startseite weitergeleitet.
Diese Struktur zwingt den Autor, über den Ablauf der Ereignisse statt über die Codestruktur nachzudenken. Sie ist einfach für einen Business Analysten zu lesen und zu überprüfen.
📊 Vergleich technischer vs. einfacher Sprache
Das Sehen von Beispielen nebeneinander hilft, den Unterschied zu verdeutlichen. Die folgende Tabelle zeigt, wie technische Anforderungen in benutzerzentrierte Sprache übersetzt werden können.
| ❌ Technische Version | ✅ Einfache Sprachversion |
|---|---|
| Wenn der Benutzer das Formular abschickt, führen Sie eine POST-Anfrage an /api/submit mit JSON-Nutzlast aus. | Wenn der Benutzer auf „Absenden“ klickt, wird die Information an das System gesendet. |
| Stellen Sie sicher, dass die Datenbanktransaktion zurückgesetzt wird, wenn die Verbindung abläuft. | Wenn die Verbindung fehlschlägt, speichert das System die Daten nicht und bittet den Benutzer, es erneut zu versuchen. |
| Überprüfen Sie die Eingabe anhand des Regex-Musters für E-Mail-Adressen. | Stellen Sie sicher, dass die E-Mail-Adresse korrekt formatiert ist, bevor sie gespeichert wird. |
| Geben Sie HTTP 404 zurück, wenn die Ressourcen-ID nicht existiert. | Zeigen Sie eine Nachricht an, dass die angeforderte Ressource nicht gefunden werden konnte. |
| Bereinigen Sie Sitzungs-Cookies beim Abmelden. | Entfernen Sie den Anmeldestatus, wenn der Benutzer auf „Abmelden“ klickt. |
🤝 Die Rolle der Zusammenarbeit
Die Erstellung von Akzeptanzkriterien ist selten eine Einzelpersonenaufgabe. Sie erfordert Input vom Product Owner, dem Entwicklungsteam und der Qualitätssicherung. Die Zusammenarbeit stellt sicher, dass die einfache Sprache genau ist und die technischen Beschränkungen respektiert werden, ohne explizit zu sein.
Vorbereitung auf die Diskussion
Bevor Sie die endgültigen Kriterien schreiben, sammeln Sie Informationen. Fragen Sie die Geschäftssachverwalter, was sie benötigen. Fragen Sie die Entwickler, was machbar ist. Diese Vorbereitung reduziert später den Austausch.
- Überprüfen Sie bestehende Dokumentation: Überprüfen Sie, ob bereits ähnliche Funktionen vorhanden sind.
- Identifizieren Sie Randfälle: Was passiert, wenn das Internet ausfällt? Was passiert, wenn der Benutzer falsche Daten eingibt?
- Legen Sie Beschränkungen fest: Gibt es Zeitbegrenzungen oder Sicherheitsanforderungen, die erfüllt werden müssen?
Verfeinern der Kriterien
Sobald der Entwurf fertig ist, überprüfen Sie ihn mit dem Team. Verwenden Sie die Kriterien als Diskussionspunkt, nicht als endgültigen Vertrag. Dadurch können Anpassungen aufgrund neuer technischer Erkenntnisse vorgenommen werden.
- Durchläufe: Lesen Sie die Kriterien laut vor. Macht es für eine nicht-technische Person Sinn?
- Fragen stellen:Stellen Sie „Was wäre, wenn?“-Fragen, um die Grenzen zu testen.
- Testen:Lassen Sie einen Tester versuchen, einen Testfall basierend auf den Kriterien zu schreiben. Wenn sie Schwierigkeiten haben, sind die Kriterien zu ungenau.
🛠️ Umgang mit Randfällen ohne Komplexität
Randfälle sind Szenarien, die selten auftreten, aber funktionieren müssen, wenn sie eintreten. Ihre Beschreibung ohne Fachjargon kann herausfordernd sein. Der Schlüssel besteht darin, die Benutzererfahrung während des Fehlers zu beschreiben, nicht den Fehlercode selbst.
Häufige Randfälle
- Netzwerkfehler: „Wenn die Internetverbindung verloren geht, speichert das System die Daten lokal und informiert den Benutzer.“
- Ungültige Eingabe: „Wenn der Benutzer Buchstaben in das Feld für die Telefonnummer eingibt, zeigt das System einen Fehler an und hebt das Feld hervor.“
- Fehlende Daten: „Wenn ein Pflichtfeld leer ist, verhindert das System das Speichern und bittet um die Angabe der Informationen.“
- Berechtigungsprobleme: „Wenn der Benutzer keinen Zugriff hat, versteckt das System die Schaltfläche.“
Indem Sie sich auf die sichtbare Reaktion konzentrieren, halten Sie die Kriterien zugänglich. Der Entwickler weiß, wie die Lösung im Hintergrund umgesetzt wird.
📈 Messen von Erfolg und Qualität
Wie stellen Sie fest, ob Ihre Akzeptanzkriterien funktionieren? Sie messen sie an der Qualität der gelieferten Arbeit und der Effizienz des Prozesses.
Indikatoren für gute Kriterien
- Weniger Nacharbeiten: Das Team baut das Richtige beim ersten Mal.
- Schnelleres Testen: Tester können die Geschichte schnell überprüfen, ohne nach Klärung zu fragen.
- Klare Freigabe: Stakeholder können bestätigen, dass die Arbeit erledigt ist, ohne Verwirrung zu stiften.
- Geringere Mehrdeutigkeit: Weniger Fragen entstehen während der Entwicklungsphase.
Definition of Done im Vergleich zu Akzeptanzkriterien
Es ist wichtig, zwischen Akzeptanzkriterien und der Definition von Fertigstellung (DoD) zu unterscheiden. Die DoD gilt für jede einzelne Aufgabe, unabhängig vom Feature. Sie umfasst Dinge wie Code-Reviews, Sicherheitsprüfungen und Unit-Tests. Akzeptanzkriterien sind spezifisch für die Nutzergeschichte.
- DoD: „Der Code wird geprüft, die Tests bestehen, und die Dokumentation wird aktualisiert.“
- AC: „Der Benutzer kann Produkte nach Preisbereich filtern.“
Beide sind für die Qualität notwendig. Die DoD sorgt für die technische Gesundheit. Die AC sichert den Geschäftswert.
🚧 Häufige Fehler, die vermieden werden sollten
Selbst mit guten Absichten geraten Teams oft in Fallen. Die Aufmerksamkeit auf diese häufigen Fehler hilft, hohe Standards zu bewahren.
Fehler 1: Zu ungenau sein
Die Aussage „Das System sollte schnell sein“ reicht nicht aus. Sie ruft Debatten hervor. Definieren Sie, was „schnell“ in Ihrem Kontext bedeutet. Ist es unter einer Sekunde? Unter fünf Sekunden?
Fehler 2: Vermischung von Akzeptanzkriterien mit Aufgaben
Listen Sie nicht die Schritte auf, die der Entwickler durchführen muss. Zum Beispiel ist „Erstellen einer neuen Datenbanktabelle“ eine Aufgabe, keine Akzeptanzbedingung. Die Bedingung ist das Ergebnis, nicht die Methode.
Fehler 3: Ignorieren negativer Fälle
Nur darüber zu schreiben, was passiert, wenn alles gut geht, ist unvollständig. Eine robuste Reihe von Kriterien beinhaltet auch, was passiert, wenn Dinge schief laufen. Dies schützt die Benutzererfahrung.
Fehler 4: Zu viele Bedingungen verwenden
Wenn eine User Story zwanzig Akzeptanzkriterien hat, könnte sie zu groß sein. Versuchen Sie, sie in kleinere Geschichten aufzuteilen. Kleinere Geschichten sind leichter zu verstehen und zu testen.
🛡️ Sicherstellung von Barrierefreiheit und Klarheit
Einfache Sprache geht nicht nur darum, Fachbegriffe zu vermeiden. Es geht darum, den Inhalt für alle im Team zugänglich zu machen. Dazu gehören auch Personen mit unterschiedlichen Lernstilen oder Sprachkenntnissen.
Tipps für Barrierefreiheit
- Kurze Sätze:Halten Sie Sätze bei Gelegenheit unter 20 Wörtern.
- Einfache Wörter:Verwenden Sie alltägliche Wörter statt Branchenjargon.
- Visuelle Hilfen:Hängen Sie bei Gelegenheit Screenshots oder Wireframes an, um die Kriterien zu klären.
- Konsistente Terminologie:Verwenden Sie in ganzem Projekt die gleichen Wörter für die gleichen Konzepte.
🔄 Der Überprüfungsprozess
Sobald die Kriterien verfasst sind, müssen sie überprüft werden. Dies ist kein einmaliger Vorgang. Je nach Entwicklung des Projekts können die Kriterien aktualisiert werden müssen. Ein lebendiges Dokument stellt sicher, dass die Anforderungen aktuell bleiben.
Überprüfungsliste
- Ist es testbar?Können wir dies mit einem Test verifizieren?
- Ist es vollständig?Deckt es alle Benutzerabläufe ab?
- Ist es klar?Kann ein neues Teammitglied es verstehen?
- Ist es konsistent?Stimmt es mit anderen Geschichten im Backlog überein?
🎯 Letzte Überlegungen zu klaren Anforderungen
Die Anstrengung, komplexe Fachbegriffe zu vermeiden, zahlt sich in einer reibungsloseren Kommunikation und schnelleren Lieferung aus. Wenn alle das Ziel verstehen, bewegt sich das Team mit Vertrauen voran. Dieser Ansatz führt zu besseren Produkten und glücklicheren Teams.
Die Anstrengung, komplexe Fachbegriffe zu vermeiden, zahlt sich in einer reibungsloseren Kommunikation und schnelleren Lieferung aus. Wenn alle das Ziel verstehen, bewegt sich das Team mit Vertrauen voran. Dieser Ansatz führt zu besseren Produkten und glücklicheren Teams.
