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.

 

 

Schreibe einen Kommentar

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