Requirements Engineering Methoden

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.

Ein tolles Beispiel, das ich bei Martin Glinz vom Institut für Informatik der Universität Zürich gefunden habe:
Tanja hat ihr Studium abgeschlossen und erhält keine Unterstützung von ihren Eltern mehr.
Sie ist daher mit der Anforderung konfrontiert, ihren Lebensunterhalt zu sichern.
Sie wohnt in Neumarkt und hat ein Stellenangebot bei einer Firma in Bamberg.
Sie hat einen reichen Freund und eine ebenso reiche Erbtante.

Im Bild sind diese Anforderungen und Lösungen dafür gezeigt, auf verschiedenen Abstraktionsebenen.


Martin Glinz gibt in seiner Vorlesung (hier das pdf) einen sehr guten Überblick über das Thema RE. Darin unter anderem eine kurze Diskussion zu Abstraktionsebenen und dem Was und Wie.