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. Lastenheft_vs_Pflichtenheft

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.

Aus der Praxis eines Troubleshooters

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen