Die gute Anforderung
Kurz gesagt: Eine gute Anforderung ist notwendig, eindeutig, vollständig, einzeln, machbar, prüfbar und korrekt. Eine Menge von Anforderungen darf sich außerdem nicht selbst widersprechen. Eine schlechte Anforderung ist ein Fehler, den du beim Lesen findest, bevor es Code gibt.
Problem
„Der Rabatt wird deutlich angezeigt“
Die Anforderung ist ein Satz: „Der Rabatt wird im Warenkorb deutlich angezeigt.“ Der Designer setzt ihn in grauem Text unter die Summe. Der Tester sieht ihn: angezeigt, lesbar, bestanden. Der Inhaber sieht ihn zum Start und fragt, wo die rote durchgestrichene Zeile ist, die er wollte.
Alle haben „deutlich“ auf ihre Weise gelesen. Niemand hat etwas falsch gemacht, und das Produkt ist trotzdem nicht, was es sein soll.
Der Fehler steckt im Satz. Man findet ihn beim Lesen, bevor jemand etwas gezeichnet oder geschrieben hat.
Die Idee
Was eine Anforderung gut macht
Der Standard ISO/IEC/IEEE 29148 listet die Merkmale einer guten Anforderung auf. Hier sind sie mit dem Shop:
| Merkmal | Bedeutet | Beispiel für einen Verstoß |
|---|---|---|
| Notwendig | nimmst du sie weg, fehlt etwas Wichtiges | „Das Logo sitzt oben links“, als Anforderung geschrieben, die niemand verlangt hat. |
| Angemessen | die Detailstufe passt; sie sagt nicht, wie, wenn sie sagen soll, was | „Die Bestellung wird in eine Tabelle mit drei Spalten geschrieben“ auf der Ebene von „was die Buchhaltung braucht“. |
| Eindeutig | man kann sie nur auf eine Weise lesen | „Der Code gilt einmal“: pro Kunde oder pro Bestellung? |
| Vollständig | man braucht nichts weiter, um sie zu verstehen und zu prüfen | „Rückgabe innerhalb von 14 Tagen“: ab wann? |
| Einzeln | sie sagt eine Sache | „Zeigt die Summe und erlaubt, die Adresse zu ändern.“ |
| Machbar | sie lässt sich mit der vorhandenen Zeit, dem Geld und der Technik bauen | Echtzeit-Bestand von Lieferanten ohne Verbindung |
| Prüfbar | es gibt einen Weg zu zeigen, dass sie erfüllt ist | „Der Warenkorb öffnet sich schnell.“ |
| Korrekt | sie gibt genau den Bedarf wieder | „Über 50 €“, wenn der Inhaber „ab 50 €“ will. |
| Konform | sie folgt dem Format, auf das sich das Team geeinigt hat | jede Anforderung ist „A-Nummer, Satz, Maß“, und diese ist ein Absatz ohne Nummer. |
Lern die Tabelle nicht auswendig. Wichtig sind drei Fragen: Lässt sie sich nur auf eine Weise lesen, lässt sie sich prüfen, und ist es der Bedarf?
Genauer, für Neugierige
Die neun Merkmale oben stammen aus der zweiten Ausgabe von ISO/IEC/IEEE 29148 (2018), für eine einzelne Anforderung: notwendig, angemessen, eindeutig, vollständig, einzeln, machbar, prüfbar, korrekt, konform.
Die Liste hat sich zwischen den Ausgaben und zwischen den Quellen verändert. Ältere Texte nennen außerdem „rückverfolgbar“ und „implementierungsfrei“. Die Rückverfolgbarkeit hat hier ein eigenes Modul, und „implementierungsfrei“ steckt in „angemessen“: Eine Lösung ist ein Fehler, wenn sie auf einer Ebene steht, die einen Bedarf verlangt.
IREB CPRE hat eine eigene Liste von Merkmalen, ähnlich, aber nicht mit denselben Namen. Wenn du dich auf eine Prüfung vorbereitest, lerne die Liste aus dem Lehrplan, den du ablegst. Der Gedanke ist in beiden derselbe: Die Anforderung muss sich auf eine Weise lesen lassen, prüfbar sein und den echten Bedarf nennen.
Probier es aus
Welches Merkmal fehlt?
Die Idee
Signalwörter
Manche Wörter bedeuten fast immer einen Fehler. Wenn du sie siehst, halt an:
- „schnell“, „bequem“, „einfach“, „übersichtlich“, „modern“: kein Maß. Jeder liest sie auf seine Weise, und kein Test kann fehlschlagen. Das ist nicht prüfbar.
- „usw.“, „und andere“, „nach Bedarf“: die Liste ist offen. Der Entwickler ergänzt das eine, der Tester das andere. Das ist unvollständig.
- „wenn möglich“, „soweit machbar“, „sofern angemessen“: ein Schlupfloch. Eine Anforderung, die unerfüllt bleiben darf, ohne verletzt zu sein, ist keine Anforderung. Das ist ebenfalls nicht prüfbar.
- „einmal“, „über“, „innerhalb von 14 Tagen“: Wörter, die man auf zwei Weisen lesen kann. Das ist mehrdeutig.
- „der Benutzer“, „das System erlaubt“: wer genau? Ein Kunde, ein Mitarbeiter, irgendein Besucher? Das ist eine Anforderung ohne Rolle.
- „Button“, „Tabelle“, „im Browser“ in einer Anforderung für einen Bedarf: eine Lösung statt eines Bedarfs.
- Und wenn zwei Anforderungen über denselben Fall Verschiedenes sagen, sind sie widersprüchlich.
Diese sechs Arten sind dieselben, die du in den Aufgaben unten auswählst.
Die Idee
Wie man es behebt
Die Lösung ist nicht ein schöneres Wort. Es ist ein Maß, eine Bedingung und eine Rolle. Eine Anforderung an eine Lösung hat meistens diese Teile:
[wann] [wer] [muss] [was tun] [womit] [wie gut]
Aus „Der Warenkorb öffnet sich schnell“ wird:
„Wenn der Kunde den Warenkorb öffnet, wird die Seite in 95 % der Fälle in unter 2 Sekunden angezeigt, bei 500 Kunden gleichzeitig, im Mobilfunknetz.“
Aus „Der Code gilt einmal“ wird:
„Ein Kunde kann jeden Gutscheincode in einer bezahlten Bestellung verwenden. Ein zweiter Versuch mit demselben Code wird mit der Meldung ‚Der Code wurde bereits verwendet‘ abgelehnt.“
Die Sätze sind länger geworden, und das ist der Preis. Aber jetzt liest sie jeder auf dieselbe Weise, und der Tester weiß, was er prüfen soll. Die stärkste Prüfung ist ein Beispiel: „Maria bezahlt heute mit HERBST10 und morgen noch einmal. Was passiert?“
Genauer, für Neugierige
IREB CPRE empfiehlt Satzschablonen für Anforderungen. Eine der bekanntesten in der Praxis ist EARS (Easy Approach to Requirements Syntax): „When [event], the [system] shall [response]“, „While [state], …“, „If [unwanted event], then …“. In englischen Spezifikationen heißt shall verpflichtend, should empfohlen, may optional.
29148 gibt auch eine Liste von Wörtern und Konstruktionen, die man vermeiden soll, zum Beispiel: Superlative („der beste“), subjektive Wörter („bequem“), unklare Pronomen („es“), Schlupflöcher („wenn möglich“, „soweit anwendbar“), Allaussagen, die sich nicht prüfen lassen („alle“, „immer“, „nie“), und Verneinungen, wo man sagen könnte, was verlangt ist.
Probier es aus
Prüfung: der Warenkorb
Markiere die Wörter, die die Anforderung schlecht machen, und wähle, welche Art von Problem jedes ist.
Klicke auf die Wörter, die ein Problem sind; noch einmal, um die Markierung zu entfernen. Mit den Pfeiltasten geht es von Wort zu Wort.
Die Probleme im Text
- „schnell“ nicht prüfbar: Wie schnell, auf welchem Gerät, bei wie vielen Kunden? Ohne Zahl gibt es keinen Test, der fehlschlagen kann. Besser: „95 % der Aufrufe des Warenkorbs dauern unter 2 Sekunden bei 500 Kunden gleichzeitig“.
- „bequem“ nicht prüfbar: Bequem für wen, und wie wird das gemessen? Es kann zu „ein neuer Kunde bezahlt ohne Hilfe in unter 2 Minuten“ werden oder auf eine konkrete Anforderung an die Barrierefreiheit verweisen.
- „usw.“ unvollständig: Was noch? Der Gutscheincode, die Punkte, der Liefertermin? Der Entwickler ergänzt das eine, der Tester das andere. Die Liste muss geschlossen sein.
Drei Korrekturen: eine Zahl für die Zeit („unter 2 Sekunden bei 500 Kunden“), ein Maß für die Bequemlichkeit („ein neuer Kunde bezahlt ohne Hilfe in unter 2 Minuten“) und eine geschlossene Liste: die Summe, die Lieferung, der Rabatt und die Punkte, und sonst nichts.
Die Idee
Die Menge der Anforderungen
Jede Anforderung kann für sich gut sein, und die Menge trotzdem schlecht. 29148 listet auch die Merkmale der ganzen Menge auf:
- vollständig: sie hat alles, was nötig ist. Fehlen Rückgabe, Stornierung oder das Lager, ist die Menge unvollständig, so gut jeder Satz auch ist;
- konsistent: keine zwei Anforderungen sagen über denselben Fall Verschiedenes;
- machbar: alles zusammen lässt sich mit der vorhandenen Zeit und dem Geld bauen;
- verständlich: es ist klar, was vom System als Ganzem erwartet wird;
- validierbar: du kannst zeigen, dass die Menge die Bedürfnisse des Unternehmens erfüllt.
Widersprüche sind heimtückisch, weil jede der beiden Anforderungen gut aussieht. „Kostenlose Lieferung über 50 €“ auf Seite 3 und „keine Gebühr ab 50 € einschließlich“ auf Seite 17 bestehen jede Prüfung für sich. Du findest sie, wenn du sie am selben Fall suchst: genau 50,00 €.
Übung
Prüfe die Anforderungen
1. Gutscheincodes. Die Anforderungen an die Gutscheincodes, so wie sie aus der Besprechung kamen.
Markiere jede Stelle, die die Anforderung schlecht macht.
Klicke auf die Wörter, die ein Problem sind; noch einmal, um die Markierung zu entfernen. Mit den Pfeiltasten geht es von Wort zu Wort.
Die Probleme im Text
- „Der Benutzer“ ohne Rolle: Welcher Benutzer: jeder Besucher, ein registrierter Kunde, ein Mitarbeiter des Shops? Davon hängt ab, wer den Code verwenden darf und wer nicht.
- „usw.“ unvollständig: Nur Gutscheincodes, oder auch Gutscheine und Treuepunkte? Eine offene Liste lässt sich nicht bis zum Ende prüfen.
- „einmal“ mehrdeutig: Einmal pro Kunde oder einmal pro Bestellung? Die beiden Lesarten geben unterschiedliche Antworten, wenn der Kunde ein zweites Mal mit dem Code bestellt. Genau diesen Fehler haben wir schon gesehen.
- „Wenn möglich,“ nicht prüfbar: Ein Schlupfloch: Wird der Rabatt nicht angezeigt, kann man immer sagen „es war nicht möglich“. Die Anforderung ist entweder gewollt oder nicht.
Korrigiert: „Ein registrierter Kunde kann einen Gutscheincode in einer bezahlten Bestellung verwenden. Der Rabatt wird im Warenkorb als eigene Zeile mit dem Betrag angezeigt.“ Gutscheine und Punkte bekommen eigene Anforderungen.
2. Lieferung. Vier Anforderungen aus der Spezifikation der Lieferung, von verschiedenen Seiten.
Markiere die Probleme und wähle die Art jedes einzelnen. Achte auf Anforderungen, die einander widersprechen.
Klicke auf die Wörter, die ein Problem sind; noch einmal, um die Markierung zu entfernen. Mit den Pfeiltasten geht es von Wort zu Wort.
Die Probleme im Text
- „über 50 €“ widersprüchlich: A-27 sagt „ab 50 € einschließlich“. Bei einem Warenkorb von genau 50,00 € geben die beiden Anforderungen einen unterschiedlichen Preis. Der Inhaber hat „ab 50 €“ gesagt, deshalb wird A-12 korrigiert.
- „Wenn möglich,“ nicht prüfbar: Ein Schlupfloch: Eine solche Anforderung kann nie bei einem Test durchfallen. Entweder wird die Lieferung automatisch berechnet, oder die Anforderung sagt, wann nicht.
- „im Browser des Kunden“ Lösung statt Bedarf: Wo der Preis berechnet wird, entscheidet das Team. Der Bedarf lautet „der Kunde sieht die Lieferkosten vor dem Bezahlen“.
- „ab 50 € einschließlich“ widersprüchlich: Sie widerspricht A-12 bei genau 50,00 €. In der Menge der Anforderungen können nicht beide bleiben: Eine wird korrigiert, die andere kann als Duplikat entfallen.
A-12 und A-27 werden eine: „Die Lieferung kostet 0,00 € bei Bestellungen ab 50,00 € einschließlich, sonst 4,90 €.“ A-13 verliert „wenn möglich“. A-14 wird zu „Der Kunde sieht die Lieferkosten im Warenkorb vor dem Bezahlen“, und wo sie berechnet werden, entscheidet das Team.
3. Rückgabe. Die Anforderungen an die Rückgabe eines Produkts.
Markiere jede Stelle, die die Anforderung schlecht macht.
Klicke auf die Wörter, die ein Problem sind; noch einmal, um die Markierung zu entfernen. Mit den Pfeiltasten geht es von Wort zu Wort.
Die Probleme im Text
- „innerhalb von 14 Tagen“ mehrdeutig: Ab wann: ab der Bestellung, ab der Zahlung oder ab dem Erhalt der Ware? Das EU-Recht zählt ab dem Erhalt der Ware, und die Anforderung muss das sagen.
- „schnell“ nicht prüfbar: In wie vielen Tagen? Das EU-Recht gibt dem Händler höchstens 14 Tage, nachdem der Kunde den Widerruf erklärt hat. Der Shop darf weniger versprechen, aber mit einer Zahl.
- „für alle einfach“ nicht prüfbar: Wie wird „einfach“ gemessen, und wer sind „alle“? Es kann eine konkrete Anforderung werden: zum Beispiel gibt ein Kunde mit Screenreader ein Produkt selbstständig zurück.
Korrigiert: „Der Kunde kann innerhalb von 14 Tagen nach Erhalt des Pakets eine Rückgabe beantragen. Der Shop erstattet das Geld innerhalb von 14 Tagen nach dem Antrag.“ Und „für alle einfach“ wird durch konkrete Anforderungen an die Barrierefreiheit ersetzt, die sich prüfen lassen.
Test