Geschrieben am

„Das Produkt muss einen wertigen Eindruck machen“ — von Anforderungs-Esoterik Teil 1

five_elements

„Das Produkt muss einen wertigen Eindruck machen“ — von Anforderungs-Esoterik Teil 1

Wenn ich gebeten werde, Anforderungen zu reviewen und ich die Branche fachlich nicht kenne, habe ich nur zwei Möglichkeiten, Spezifikationen auf ihre Qualität hin zu untersuchen:

  1. Ich lasse mir das spezifizierte Produkt erklären — das geht nur eingeschränkt, weil dazu andere Leute viel Zeit opfern müssen und ich ein volles Branchenverständnis selbstverständlich in kurzer Zeit nicht aneignen kann; oder
  2. Ich schaue mir an, ob die Anforderungen, die ich vorfinde, formal sauber sind — das geht schon wesentlich besser, denn das kann ich alleine und ohne jede Zuarbeit erledigen.

Für letzteres möchte ich hier mal ein paar Kriterien zum Besten geben.

Am meisten Spaß macht das natürlich anhand von Beispielen. Ich habe also mal tief in die Historie geschaut.

Pattern 1: „Zwei auf einen Streich“

Das System muss American Express-Kreditkarten und Paypal als Zahlungsmittel akzeptieren.

Die Anforderung klingt erst einmal völlig in Ordnung. Jeder weiß, was damit gemeint ist, Entwickler wissen, welche APIs sie verwenden müssen, es sollte doch alles paletti sein. Das Problem liegt hier im Wörtchen „und“, denn hier handelt es sich um zwei Anforderungen versteckt in einer. Die Implementierung der einen Zahlweise ist ja völlig unabhängig von der Implementierung der anderen.

Nun sollte man meinen, dass das ja nicht weiter schlimm ist, denn schließlich werden ja beide Anforderungen umgesetzt und ob sie dann nun in einem Satz stehen oder in zwei Sätzen, kann doch egal sein.

Für die Entwicklung stimmt das auch.

Allerdings wird es spätestens im Test schwierig, weil es vielleicht keine disjunkten Tests für die Kreditkartenzahlung und die Paypal-Zahlung gibt. Das bedeutet dann auch, dass ein Report darüber, welche Anforderungen bereits erfolgreich umgesetzt sind, hier keine Antwort liefert.

Und dann kann es zur folgenden unglücklichen Situation kommen:

Der Kunde ruft an und sagt, er wüsste gerne den Stand der bisher umgesetzten Features, denn er braucht das Feature „Paypal-Zahlung“ bereits früher als geplant und würde ein Vorziehen des nächsten Releases wünschen. Ob denn die Paypal-Zahlung bereits funktioniert. Der Projektleiter beim Auftragnehmer kann ihm diese Frage nicht beantworten (er sieht nur, das Requirement ist im Report auf rot – aber das kann heißen, dass Paypal funktioniert und die Kreditkarte nicht). Und wie es so kommt, sind alle diejenigen gerade nicht greifbar, die die Information haben.

Es gibt einen weiteren Nachteil: Wenn Entwicklungsabteilungen eine erste grobe Aufwandsschätzung bspw. standardisiert nach Function Point Verfahren durchführen, kommen trügerisch geringe Aufwandsabschätzungen heraus, sobald man mehrere Dinge in einer einzigen Anforderung unterbringt. Wenn auf einer Function Point-Schätzung dem Kunden gegenüber grobe erste Schätzungen kommuniziert werden, kommt man in die missliche Lage, die genauere Schätzung deutlich nach oben korrigieren zu müssen. Der Unmut des Sales Personals ist einem gewiss.

Pattern 2: „Es fehlt was“

Das Problem hier ist schwieriger auszumachen und es ist auch meistens ohne fachliche Expertise schwierig feststellbar, ob in einer Spezifikation etwas fehlt. Ein Hinweis, auf den ich rein formell einfach prüfen kann, ist, nach bedingten Anforderungen zu suchen:

Wenn das Ventil B geschlossen ist und eine Verbindung zwischen Komponente K und L besteht, die Spannung an Abtastpunkt A nicht größer ist als 0,5 V oder an Abtastpunkt B größer als 0,7 V ist, dann soll das System Verbindung zu Steuereinheit S aufbauen.

In dieser Anforderung ist eine komplexe Bedingung vorgeschaltet. Wenn sie erfüllt ist, sollen bestimmte Dinge passieren.

Die offene Frage ist: Was, wenn die Bedingung nicht erfüllt ist? Soll dann einfach gar nichts passieren? Oder soll etwas anderes passieren?

Nach solchen bedingten Anforderungen lässt sich suchen ohne jegliche tiefere fachliche Kenntnis des beschriebenen Produkts. An jeder einzelnen von ihnen ist die Frage legitim: Was soll sonst passieren? Warum steht das da nicht?

 

Weiter geht’s in Teil 2.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.