Lastenheft vs. Pflichtenheft – Die verschiedenen Ebenen von Spezifikationen
Wie können Projekte pragmatisch mit Lastenheft und Pflichtenheft umgehen? Ein Thema, das zur Zeit 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, 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 Normen. In einer Normenkommission wird festgelegt, dass ein gewisses Thema von den Anforderungen her immer gleich definiert wird. Diese beiden Artefakte sind die Spezifikation auf der Kundenebene, klassisch die Lastenhefte im allgemeinen Sprachgebrauch.
Dann haben wir bei komplexeren Systemen noch eine direkt darunter liegende Ebene, die Systemebene. Auf diese 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. 
Ebenen der Spezifikationen
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.