Requirements Engineering Methoden

Das Lastenheft eines Projekts wird häufig als das "Was" und das Pflichtenheft als das "Wie" bezeichnet. Siehe auch Wikipedia im Artikel zum Lastenheft.

Die Aussage ist richtig. Ich finde sie jedoch irreführend. Jede Anforderung sowohl im Lasten- als auch im Pflichtenheft beschreibt sowohl das "Was" als auch das "Wie" - es kommt auf den Standpunkt an.

Das Lastenheft enthält Anforderungen ("Was"), die vom Konzept ("Wie", im Pflichtenheft) erfüllt werden. Andererseits beschreibt das Lastenheft, wie die Ziele erreicht werden!

In der Pyramide aus dem Post "Abstraktionsgrad von Anforderungen" suche ich mir eine Anforderung. Oberhalb und unterhalb stehen andere Anforderungen. Für die Anforderungen oberhalb beschreibt unsere Anforderung das "Wie", für die unterhalb das "Was".

Anforderungen gibt es auf verschiedenen Abstraktionsebenen, das ist eigentlich nichts Neues.
Sich dessen bewusst zu sein bei der Spezifikation eines Systems ist jedoch notwendig und hilfreich. Am folgenden Bild mit der "Pyramide" ist mir das bewusst geworden.


In der Pyramide befinden sich Beschreibungen eines Systems auf verschiedenen Abstraktionsebenen (vertikal) und zu allen Bereichen des Systems (horizontal).
An der Spitze der Pyramide stehen Ziele, die in wenigen Sätzen das komplexe System beschreiben. Am Fundament steht die 100% detaillierte Spezifikation im Sourcecode.
Irgendwo in der Mitte steht die Trennung von Blackbox zu Whitebox.

Lastenheft und Pflichtenheft beschreiben z. B. das gesamte System, bewegen sich allerdings auf verschiedenen Abstraktionsebenen. Das Pflichtenheft spezifiziert das System und erfüllt die Anforderungen aus dem Lastenheft.

In Chris Rupps Buch "Requirements Engineering und -Management" werden z. B. Anforderungen auf 5 Detailebenen unterschieden. Level 0 sind die Systemziele, Vision, Business Goals an der Spitze der Pyramide. Level 4 die System Requirements Specification, Technische Anforderungen, Schnittstellenbeschreibung, welche an der Grenze zur White-Box-Beschreibung liegen.
Die Pyramide löst die Stufen in einen fließenden Übergang auf. Theoretisch gibt es unendlich viele Ebenen.
In einem Projekt sind allerdings nur wenige (1-5) davon nützlich. Ich nutze in den typischen Projekten bei Spirit Link 2 der Ebenen: Lastenheft und Pflichtenheft.

Ein wichtiges Kriterium für Spezifikationen lässt sich hier anschaulich zeigen: Eine gute Spezifikation bewegt sich auf einer Ebene und beschreibt das ganze System in seiner Breite. Anforderungen auf verschiedenen Abstraktionsebenen sind schwer miteinander vergleichbar. Konsistenz oder Vollständigkeit sind so schwer nachweisbar.
Eine wichtige Ausnahme sind frühe Untersuchungen z. B. nach Risiko oder für die Aufwandsplanung des Projekts. Sie benötigen detaillierte Informationen für einzelne Anforderungen, um ein Risiko abschätzen zu können oder unbekannte Funktionalitäten zu analysieren.