Geschrieben am

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

five_elements

Den ersten Teil dieser Serie finden Sie hier, den zweiten hier und den dritten hier.

Pattern 7: „Mit langen Stangen im Nebel rühren“

Geschwurbelte Nebel-Anforderungen sind eigentlich die schönsten. Ich habe schon viele davon erlebt. Hier ein paar Beispiele:

„Der Komfort, mit dem Gerät zu arbeiten, soll vergleichbar sein mit einem Mobiltelefon.“

Oder auch

„Die Farbe des Produkts soll so beschaffen sein, dass der übliche Käufer damit zufrieden ist.“

Oder

„Die Reaktionszeit des Systems soll so schnell sein, dass der Benutzer nicht genervt ist.“

Oder schlussendlich auch der Name dieser Serie:

„Das Produkt muss einen wertigen Eindruck machen.“

Anforderungen wie diese lesen sich zunächst einmal recht flüssig. Wenn man nicht darauf achtet, liest man über sie auch schon einmal hinweg, weil sie eigentlich auf den ersten Blick schlüssig und klar erscheinen.

Erst auf den zweiten Blick haben diese Anforderungen ihre Probleme:

  • Ist Ihnen bspw. im ersten Requirement aufgefallen, dass Komfort nicht mit Komfort verglichen wird, sondern Komfort mit Mobiltelefon? Also Äpfel und Birnen?
  • Könnten Sie aus dem Stand die SI-Einheit benennen, in der man gängigerweise Komfort misst?
  • Haben Sie gemerkt, dass da nicht von „gleich“, sondern von „vergleichbar“ die Rede ist? Also wenn man Komfort in Einheiten messen könnte, würde das ausreichen — von „gleich komfortabel“ ist da nicht die Rede.
  • Haben Sie sich schon überlegt, mit welchem Mobiltelefon verglichen werden soll?

In der zweiten Anforderung oben wird die „Zufriedenheit des Käufers“ erwartet. Es bleibt unklar, wann der Käufer zufrieden ist und wer er überhaupt ist.

Probleme derselben Kategorie hat auch das dritte und vierte o.g. Requirement.

Allen Beispielen ist gemeinsam, dass ihre Erfülltheit nicht gemessen werden kann. Und das ist eine absolut notwendige Bedingung für Anforderungen:

Ist die Erfülltheit einer Anforderung nicht messbar, kann niemand sagen, ob das Produkt tut, was es soll.

Eine Anforderung muss entweder so geschrieben sein, dass sie direkt messbar ist — oder es ist notwendig, zu ihr ein Akzeptanzkriterium anzugeben. Das kann schon mal schwierig sein, gerade wenn es nicht um wissenschaftlich messbare Phänomene geht (Komfort, Zufriedenheit, Nerverei, Wertigkeit).

In den o.g. Fällen lässt sich das beabsichtigte z.B. durch eine Befragung von potentiellen Anwendern oder Käufern erreichen.

Ein Akzeptanzkriterium könnte dann etwa wie folgt lauten:

„Die Anforderung gilt als erfüllt, wenn von 50 befragten Käufern des Vorgängerprodukts mindestens 40 angeben, mit der Farbe zufrieden zu sein.“

Geschrieben am

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

Den ersten Teil dieser Serie finden Sie hier, den zweiten hier.

Pattern 5: „Schnee von gestern“

Anforderungen gehören nur dann in eine Spezifikation, wenn sie für das spezifizierte Produkt zeitlos gültig sind. Auch das kann man sehr einfach ohne fachlichen Hintergrund checken — es gibt zwei Kandidaten von Anforderungen, die bei diesem Check mit schöner Regelmäßigkeit auffallen und herausgesiebt werden können (oft nur mit zähem Diskutieren):

  • Projektanforderungen: Anforderungen, die eigentlich nur für das Projekt gelten, aber nicht für das Produkt, das in dem Projekt entwickelt worden ist. Also so Sachen wie „Die Entwicklung des Produkts soll am Ende nicht mehr gekostet haben als 200.000 €.“ oder „Das Entwicklungsteam soll mindestens zwei Tester enthalten.“ Beides ist für den Verlauf des Projekts interessant, danach kräht kein Hahn mehr danach. Näheres zu Projektanforderungen, die sich in eine Produktspezifikation verirrt haben, habe ich schon in einem eigenen Blog beschrieben, siehe hier.
  • Zeitlich beschränkte Produktanforderungen: Beispielsweise so etwas wie „Im Jahr der Auslieferung, also 2016, soll das Produkt mindestens 2 Millionen Datensätze verarbeiten können.“  — Da stellt sich die Frage: Nachher nicht mehr? Hier verbirgt sich meist eine nicht-funktionale Skalierbarkeitsanforderung, bei der der Autor nicht recht wußte, wie er sie formulieren sollte. Aber so wird das eben nichts.

Pattern 6: „Paragraphendeutsch“

Eine Anforderung muss eindeutig und klar verständlich sein für die gesamte Leserschaft sein. Viele Anforderungen leben in einem sehr technischen und hochspezialisierten Umfeld. Diese Umfelder neigen naturgemäß dazu, ihren eigenen Jargon zu haben — das ist völlig normal, denn ansonsten wäre eine Kommunikation zeitaufwändig.

Bei Spezifikationen kann es jedoch jederzeit dazu kommen, dass sie von Personen gelesen werden (müssen), die nicht direkt diesem Umfeld entstammen. Sei es, weil der neue Kollege eingearbeitet werden muss, sei es, dass Teile doch an einen Dienstleister übergeben werden.

Wenn Spezifikationen dann völlig kryptisch sind, geht es nicht weiter und das Projekt bekommt Sand ins Getriebe.

Es gibt einige Dinge, die man überprüfen kann:

  • Kommen Fachwörter in den Spezifikationen vor, die Leser, die ausschließlich über normales Branchenwissen verfügen, nicht verstehen würden? Wenn ja, dann empfiehlt es sich, darauf zu verzichten oder ein Glossar anzulegen und die Fachwörter dort zu erklären.
  • Wird eine Domain Specific Language (DSL) zur Spezifikation verwendet? Auch hier ist eine Referenz auf ihre Definition unerlässlich.
  • Sind die Sätze lang, verschachtelt und schwierig zu lesen? Dann muss was geändert werden, denn niemand hat Lust, durch solches Wirrwarr durchzusteigen. Mit der Konsequenz, dass die Spezifikation nicht korrekt umgesetzt wird.

 

 

Geschrieben am

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

five_elements

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

Den ersten Teil dieser Serie lesen Sie hier.

Pattern 3: „Widersprüche“

Auch auf Widersprüche lässt sich eine Spezifikation einfach überprüfen. Eine Anforderung sollte sich nicht selbst widersprechen — und es sollte auch keine anderen Anforderungen geben, die ihr widersprechen. Auch hier wieder ein Beispiel:

Das System soll jegliche Aktion verweigern, wenn der Benutzer nicht mindestens die Benutzerrechte X und Y hat.

[..]

Das System soll es jedem Benutzer ermöglichen, die Systemaktion „Logfile anschauen“ auszuführen.

Der Sinn dieses Patterns erschließt sich von selbst. Wenn das System widersprüchlich definiert ist, zeugt das von einer schlechten Anforderungserfassung beim Kunden — oder auf tieferen technischen Ebenen auf einem unvollständigen Verständnis der darüber liegenden fachlichen Anforderungen. Die Umsetzung leidet dadurch und es kann zu unerwartetem Systemverhalten kommen, jenachdem in welcher Situation das System ist.

Pattern 4: „Woher kommt das?“

Auch auf dieses Pattern kann ich sehr gut prüfen, ohne ein tieferes fachliches Verständnis des konzipierten Produkts zu haben. Es geht hier um die sogenannte Traceability: Für jede Anforderung muss nachvollziehbar sein, woher sie kommt.

Auf fachlicher Ebene kann dies über eine an der Anforderung genannte Rationale kenntlich gemacht werden (die wiederum auf Dokumentation von Kundengesprächen oder -interview verweist), auf technischer Ebene durch eine  Bezugnahme auf das zugrunde liegende fachliche Problem — bzw. die zugrunde liegende fachliche Anforderung.

Finde ich ein solches Tracing nicht vor, dann haben sich entweder Anforderungen eingeschlichen, die eigentlich out of scope sind und Geld kosten, das eigentlich niemand bezahlen möchte — oder es wurde einfach das Tracing vergessen.

Ein vollständiges Tracing ist nicht einfach nur art pour l’art — es hat den Sinn, drei Fragen sofort beantworten zu können:

  1. Welche technischen Anforderungen werde nicht mehr benötigt, wenn eine bestimmte Kundenanforderung (Teil der Problembeschreibung) wegfällt?
  2. Welche Kundenanforderung wird nicht mehr erfüllt, wenn man eine bestimmte technische Anforderung (Teil der Lösung) weglässt oder modifiziert — bspw. weil sie zu teuer ist?
  3. Lässt sich eine bestimmte technische Anforderung eventuell ersetzen durch eine andere — und zwar so, dass der zugrunde liegende Kundenwunsch immer noch erfüllt ist?

Alles drei sind wertvolle Informationen, auf die man nicht ohne Not verzichten sollte.

 

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.