Nach den Vorstellungen des klassischen Wasserfall-Modells müsste der Business Analyst das DV-Konzept abnehmen und die Realisierung müsste auf der Basis dieses abgenommenen DV-Konzeptes erfolgen. Das ist aber nur zum Teil richtig.

Richtig ist, dass der Business Analyst das DV-Konzept eingehend prüfen muss, er soll ermitteln, ob alle Anforderungen der Fachseite im DV-Konzept aufgenommen wurden und ob Richtlinien und Vorgaben berücksichtigt worden sind. Eine Abnahme aber würde bedeuten, dass der Business Analyst die Verantwortung dafür übernimmt, dass das DV-Konzept die Anforderungen der Fachseite erfüllt – und das ist nicht möglich. Dem Lieferanten würde sozusagen eine Zwischen-Entlastung erteilt ohne dass er sicherstellt, dass die Software den Anforderungen der Fachseite wirklich gerecht werden wird. Das aber ist nicht möglich.

Zum einen kann der Business Analyst im Allgemeinen die Spezifikationsdetails des DV-Konzeptes nicht einschätzen, da es sich dabei um Vorgaben an den Entwickler handelt, dessen technische Know How der Business Analyst nicht hat und nicht haben muss. Zum Anderen kann eine Spezifikation nicht getestet werden wie eine Software, und nur wenn das möglich wäre, wenn man durch einen Test, durch Ausprobieren könnte, ob die Spezifikation “funktioniert”, könnte man auf das technische Know How zur Prüfung des DV-Konzeptes verzichten.

Das heißt jedoch nicht, dass das DV-Konzept nicht abgenommen werden sollte. Die Abnahme soll prüfen, ob die Anforderungen berücksichtigt werden, ob nicht-funktionale und funktionale Anforderungen abgestimmt sind, ob Richtlinien eingehalten wurden. Die Abnahme stellt fest, dass keine Mängel gefunden wurden – nicht, dass keine Mängel vorhanden sind.

Werden im Software-Abnahmetest Fehler gefunden und stellt sich heraus, dass diese Fehler bereits im DV-Konzept vorhanden sind, so hat der Auftraggeber ein Nachbesserungsrecht sowohl auf das DV-Konzept als auch auf die Software. Optimal ist allerdings, wenn vereinbart wird, dass dies nur für Fehler gilt, die der Business Analyst bei der Abnahme des DV-Konzeptes nicht finden konnte.

Das klingt kompliziert – und ehrlich gesagt, das ist auch kompliziert. Wie ein solcher Vertrag ausgestaltet werden kann, hängt sehr stark vom konkreten Projekt ab. Letztlich ist natürlich das Vertrauensverhältnis zwischen den Partnern und die Bereitschaft zum pragmatischen Kompromis ausschlaggebend – aber das lässt sich im Vertrag nicht festschreiben.

Der Beitrag Spezifikationen abnehmen? erschien zuerst auf INDAL Software-Spezialist.

Zunächst einmal ist eine begriffliche Klärung notwendig. Viele Projektbeteiligte bezeichnen quasi alles, was in irgendeiner Form bereitgestellt wird, damit die Entwicklungs-Firma ihre Arbeit machen kann, als Spezifikation – oft als Anforderungs-Spezifikation, bezeichnet. Das erweckt den Eindruck, als ob in all diesen Dokumenten irgendwie das Gleiche stehen würde. Aber es gibt riesige Unterschiede.

Ein Beispiel aus einem ganz anderen Bereich soll das verdeutlichen:

Stellen Sie sich vor, Sie wollen ein Haus für Ihre Familie bauen. Sie gehen also zum Architekten, und der fragt Sie erst einmal aus:

• Wieviele Personen sollen in dem Haus wohnen, welches Alter haben diese Menschen (Kinder, Großeltern,…)?
• Welche Hobbies haben Sie, kochen Sie gern, sind Sie Handwerker,…?
• Was ist Ihnen sonst noch wichtig?

Das alles fasst der Architekt in einem Dokument zusammen und stimmt es mit Ihnen ab. Das ist das Anforderungsdokument.

Dann macht der Architekt Ansichten, Zeichnungen, Grundrisse, das alles sind Modelle, die Ihnen zeigen, wie Ihr Haus einmal aussehen wird, die Ihnen schon jetzt sichtbar machen, was Sie auch später einmal sehen werden. Diese Modelle bilden das, was wir im Software-Projekt das Fachkonzept nennen. Das Fachkonzept zeigt, wie das fertige System einmal für den Nutzer aussehen wird, wie es sich sozusagen an der Außen-Schnittstelle zeigt.

Dann kommen die Ingenieure ins Spiel. Sie entwerfen die eigentliche Struktur des Hauses:

• Wie sind die Wände und die Decken aufgebaut?
• Wie wird die Statik sicher gestellt?
• Woraus besteht das Dach?

Diesen Dokumenten entspricht das DV-Konzept im Softwareprojekt.

Es ist klar, dass Sie als Bauherr nicht an der Statik erkennen können, ob Ihre Kinder sich in dem Haus einmal wohl fühlen werden. Deshalb wird ein guter Architekt mit Ihnen zuerst Ihre Anforderungen aufschreiben, und Ihnen dann zeigen, wie diese Anforderungen in den Außenansichten und Grundrissen umgesetzt werden.

Damit ein gutes Ergebnis entsteht, sind also drei Schritte notwendig, und in jedem Schritt braucht man

• eine geeignete Sprache, in der die Beteiligten das Dokument verstehen,
• einen optimalen Detaillierungsgrad
• ein spezielles Know-How bei dem, der das jeweilige Dokument erstellt.

Genauso ist es beim Software-Projekt.

1. Der Business Analyst erfasst die Anforderungen und dokumentiert diese in einer strukturierten Form. Er stellt sicher, dass alle Anforderungs-Typen berücksichtigt werden und mögliche Wechselwirkungen zwischen Anforderungen bereits frühzeitig mit dem Nutzer erkannt werden.
2. Der Funktionale Analyst stellt dar, wie das System für externe Akteuer aussieht. Dabei kann es sich um Benutzer, aber auch um andere Systeme handeln.
3. Der System-Architekt konstruiert das eigentliche System, er entwirft Schichten und Module. Diese Arbeit kann in unterschiedlichem Detaillierungs-Grad erfolgen.

Wichtig ist, dass sich jeder Autor mit sowohl mit dem versteht, der ihm Informationen liefert, als auch mit demjenigen, der als Adressat seine Ergebnisse weiter verarbeitet.

Der Beitrag Der Sinn unterschiedlicher Spezifikationen erschien zuerst auf INDAL Software-Spezialist.