Das leicht verständliche Fachkonzept

Die Grundlage für eine robuste und nachhaltige Softwareentwicklung in großen IT-Projekten ist immer ein klares Fachkonzept. Doch bin ich erstaunt wie oft ich umfangreichen schriftlichen Anforderungen oder Spezifikationen begegne, die ohne eine zusätzliche Erläuterung oder Recherche kaum zu verstehen sind. Die beiden wesentlichen Hindernisse zum schnellen Verständnis sind dabei immer gleich: unklarer Kontext in dem die Anforderung stattfindet und unverständliche Struktur der Anforderung selbst. Meist treten sie gemeinsam auf. In IT-Abteilungen großer Unternehmen existieren scheinbar zwei Irrglauben, die regelmäßig zu minderwertigen Spezifikationen und damit zu überzogen hohen IT-Aufwänden führen. Zum Einen der Glaube, dass es zum Zeitpunkt der Spezifikation ausreicht wenn ein einziger Entwickler / Requirements Engineer (oder ein Team solcher) die Anforderung verstehen muss. Zum Anderen die Überzeugung, dass ein Anforderungsdokument einmalig für die Entwicklung zu gebrauchen ist, also zum späteren Zeitpunkt nicht mehr wiederverwendet werden kann. Die Folgen schwer verwertbarer Spezifikationen liegen auf der Hand:

  1. Ein Mitarbeiter, der an einer Spezifikation arbeitet und ausfällt ist schwer ersetzbar. Die Lernkurve eines neuen Kollegen ist flach, weil er sich alle Informationen durch Gespräche mit anderen Kollegen aneignen muss. Eine Situation, die ein schweres Projektrisiko darstellen kann.
  2. Einbindung anderer Kollegen erschöpft zudem Ressourcen, die nicht vorgesehen waren.
  3. Eine schwer verständliche Spezifikation kann nachträglich nur mit Aufwand als Grundlage für weitere Anforderungen fungieren. Sie kann auch nicht dem Fachbereich übergeben werden, um als Dokumentation zu dienen.
  4. Verbleibt das Wissen in einem Kopf, bildet sich eine Know-How-Insel. Dies führt unweigerlich zu Know-How Verlusten. Scheidet der Know-Howträger aus dem Unternehmen aus, was bei Großunternehmen mit externen Mitarbeitern oft der Fall ist, nimmt er das ganze Wissen mit.

Entscheidend für das schnelle Verständnis ist die Klarheit einer Spezifikation. Eine Spezifikation, die keine Fragen offen lässt nenne ich eine “Don’t let me think” – Spezifikation. Entscheidend dabei ist, dass ein Leser ohne Vorkenntnisse mit minimalen Verständnisaufwand die Spezifikation eigenständig und ohne Hilfe Dritter verstehen kann. Folgend sind meine Anforderungen für klare Spezifikationen:

  1. Spezifikationen sollen Kundenorientiert geschrieben sein. Dabei ist der Leser der Kunde. Eine Spezifikation soll so wenig Verständnisaufwand erzeugen wie möglich. Das heißt sie soll ohne vorherige Einführung und weiterführende Erläuterungen durch dritte lesbar sein.
  2. Eine Spezifikation soll sowohl von der Fachseite wie auch von einem Entwickler verstanden werden können.
  3. Kontext: Eine Spezifikation soll einen inhaltlichen Kontext angeben, in dem die Anforderung stattfindet, damit das große “Ganze” schnell verstanden werden kann.
    1. Wenn ein Prozess für Kundentransfers verbessert wird, welche anderen Prozesse gehören zur gleichen Klasse?
    2. Wenn eine neues System aufgebaut wird. Wie sieht die Systemlandschaft aus?
    3. Wenn eine neues iPad-System (App) spezifiziert wird und bestehende Apps als Module in ihm übernommen werden sollen, welche sind das? Warum diese?
  4. Struktur: Die Struktur einer Spezifikation sollte in sich widerspruchsfrei sein
    1. Die Struktur sollte alle Bereiche einer Anforderung ausschöpfen
    2. Die Struktur sollte keine Überschneidungen der Bereiche beinhalten
  5. Qualität der Syntax: Die im Rahmen einer Spezifikation verwendete Begriffe müssen korrekt gewählt sein.
    1. Wird z.B. eine neue iPad-App spezifiziert, so können ihre Teilmodule nicht auch “Apps” heißen. Apps sind Apps, Module sind Module.
  6. Qualität der Semantik: Die Sprache in einer Spezifikation sollte stets eindeutig sein
    1. Beispiel: “Die Fachseite folgte der Empfehlung, die ungefähr 5 Anforderungen aus der Spezifikation ausschloss”. Handelt es sich hier um 5 Anforderungen aus der Spezifikation, die irgendwo anders ausgeschlossen wurden, oder sind hier 5 Anforderungen gemeint, die aus dem Spezifikationsdokument ausgeschlossen wurden?
Anton

Anton

Anton ist freiberuflicher Software-Ingenieur und Projektleiter mit den Schwerpunkten: Prozessdesign, strukturierte Business Analyse / Fachkonzeption sowie fachliche Entscheidungsunterstützung.

More Posts - Website