Lastenheft vs. Pflichtenheft – Die verschiedenen Ebenen von Spezifikationen

Wie können Projekte pragmatisch mit Lastenheft und Pflichtenheft umgehen? Ein Thema, das zurzeit eine Menge Leute beschäftigt und bei dem wir einige Zusammenhänge besprechen müssen, um später die Umsetzung besser zu verstehen.

Ein Aspekt, der in diesem ganzen Zusammenhang mit Lastenheften und Pflichtenheften mitspielt: Es gibt Spezifikationen auf verschiedenen Ebenen. Ich erkläre ganz bewusst ein paar neue Begriffe, weil Lastenheft und Pflichtenheft aus meiner Sicht heraus alte Begriffe sind und damit zu allgemein für diese Herausforderung.

Die oberste Ebene ist die Kundenebene. Dort gibt es die sogenannten Customer Requirements oder Kundenanforderungen. Das sind beispielsweise ganz klassische Lastenhefte, die sie vom Kunden oder dem Produktmanagement bekommen. Dann gibt es zusätzliche auch noch Stakeholder Requirements. Das sind Anforderungen von Interessensgruppen, beispielsweise fixiert in internen oder externen Anforderungsdokumenten oder Normen und Richtlinien. In einer Normenkommission wird festgelegt, dass ein gewisses Thema von den Anforderungen her immer gleich definiert wird. Die Ebene auf denen diese Dokumente wird als Kundenebene bezeichnet, obwohl nicht alle vom Kunden oder dem Produktmanagement kommen. Da sie aber als EIngabe in die Entwicklung des Systems oder  Produkt dienen, werden sie hier erfasst und einsortiert. Aus klassischer Sicht ist die Ebene der Lastenhefte, wie sie im allgemeinen Sprachgebrauch bekannt sind.

Abb. 1: Ebenen der Spezifikationen

Dann haben wir bei komplexeren Systemen noch eine direkt darunter liegende Ebene,  die Systemebene. Auf dieser nächsten Ebene – klassisch ist das immer so im allgemeinen Sprachgebrauch das Pflichtenheft – gibt es im englischen Sprachgebrauch die System Requirements Specification (SRS). Das ist die Spezifikation der Systemanfordungen. Dazu kommt ein zweites Dokument, die System Architecture Specification (SAS), beziehungsweise die Architekturbeschreibung des Systems auf dieser Ebene. Und der darunter liegende Teil ist dann die Technologieebene. Hier werden jetzt die Anforderungen sehr detailliert ausformuliert, zum Beispiel die Software Requirement Specification und auch die Software Architecture Specification. Genauso gilt das aber natürlich auch für das ganze Thema Hardwareentwicklung. Das heißt, da hätten wir dann die Hardwareanforderungen und die Hardwarearchitekturbeschreibung und eben auch in einem konstruktiven Bereich die Konstruktionsanforderungen und auch die Konstruktionsarchitektur.

Diese Dokumente hängen zusammen und bedingen einander. Also wir haben immer die Abhängigkeiten von unten nach oben. Das heißt, am Ende kann ich nachvollziehen, warum eine Softwarefunktion umgesetzt worden ist, wie sie umgesetzt wurde, aber auch genauso eine konstruktive Anforderung.

Das ist erst einmal die normale Sicht auf Spezifikationen. Aus meiner Erfahrung ist hier ein pragmatischer Umgang damit notwendig, denn je nach Größe des Projektes muss nicht jede Spezifikation in ihrer epischen Breite vorhanden sein. Gerade bei komplexen Systemen ist das sicherlich sehr sinnvoll, aber hier ist mit Sinn und Verstand zu entscheiden, was ich wirklich brauche.

Aus der Praxis für die Praxis