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.

 

Schreibe einen Kommentar

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