Was sind die Prinzipien des Requirements Engineering (nach IREB)?

Die Prinzipien des Requirements Engineering sind 9 fundamentale Grundsätze des IREB (International Requirements Engineering Board), die als universelle Leitplanken für den Projekterfolg dienen. Sie definieren die notwendige Haltung und professionelle Arbeitsweise, um durch Requirements Engineering echten Mehrwert zu schaffen – unabhängig davon, ob agil oder klassisch gearbeitet wird.

Die 9 Prinzipien im Detail

Erfolg im Requirements Engineering basiert auf der konsequenten Anwendung dieser 9 Kernprinzipien. Hier ist die detaillierte Beschreibung nach dem aktuellen CPRE-Standard:

Prinzip 1: Wertorientierung

Anforderungen sind Mittel zum Zweck, kein Selbstzweck. Der Wert einer Anforderung wird bestimmt durch den Nutzen minus aller Kosten für Ermittlung, Dokumentation und Verwaltung. RE legt den Fokus auf die Wertschöpfung, was auch in agilen Methoden wie Scrum durch kurze Feedbackzyklen sichergestellt wird.

Prinzip 2: Stakeholder

Im RE geht es darum, die Bedürfnisse der Stakeholder zu befriedigen. Kernaufgaben sind die Stakeholder-Identifikation, die Stakeholder-Analyse und das Stakeholder-Management. Um unbekannte Nutzergruppen zu repräsentieren, werden oft Personas eingesetzt. Wichtig ist, dass kein Stakeholder übersehen wird, Konflikte zwischen Stakeholdern früh gelöst werden und regelmäßig Feedback von den Stakeholdern eingeholt wird. Nur so können Fehlentwicklungen frühzeitig identifiziert und behoben werden.

Prinzip 3: Gemeinsames Verständnis

Erfolgreiche Entwicklung braucht eine gemeinsame Basis. IREB unterscheidet explizites Verständnis durch dokumentierte und vereinbarte Anforderungen und implizites Verständnis basierend auf gemeinsamem Wissen. Ein Glossar, vorhandene Referenzsysteme oder Prototypen helfen, dieses Verständnis über Teamgrenzen hinweg zu sichern.

Prinzip 4: Kontext

Systeme können nicht isoliert verstanden werden. Um Systeme korrekt zu spezifizieren, muss zunächst der Systemkontext bestimmt werden. Er ist maßgeblich für Definition und Verständnis der Anforderungen verantwortlich. Systeme stehen in Wechselwirkung mit ihrer Umgebung, beispielsweise über Schnittstellen. Die Systemgrenze legt den Scope des zu entwickelnden Systems fest und verhindert eine unkontrollierte Ausweitung der Anforderungen, den gefürchteten Scope Creep. Da sich die Systemgrenze im Projektverlauf verschieben kann, ist es Aufgabe des Requirements Engineering, solche Veränderungen zu erkennen und die Anforderungen entsprechend anzupassen.

Prinzip 5: Problem – Anforderung – Lösung

Diese drei Aspekte sind eng verflochten. Klassisch gilt: Aus einem Problem der Stakeholder werden Anforderungen abgeleitet, die als Basis für die Entwicklung einer Lösung für das Problem dienen. Diese Abfolge gilt bei Innovationen oft nicht. Lösungen entstehen hier meist experimentell. Requirements Engineers sollten dennoch bestrebt sein, Probleme, Anforderungen und Lösungen beim Denken, in der Kommunikation und Dokumentation methodisch zu trennen.

Prinzip 6: Validierung

Nicht validierte Anforderungen sind nutzlos. Die Prüfung gegen Stakeholder-Wünsche muss frühzeitig beim Requirements Engineering beginnen. Zu prüfen ist: Sind die Stakeholder sich über die Anforderungen einig? Sind Bedürfnisse und Wünsche der Stakeholder abgedeckt? Sind die Annahmen über den Kontext richtig und vernünftig? Techniken wie Inspektionen, Reviews, Walkthroughs oder die Erstellung eines MVP (Minimum Viable Product) sind hierfür essenziell.

Prinzip 7: Evolution

Änderungen sind kein Unfall, sondern der Normalfall. Ursachen sind geändert Geschäftsprozesse, Marktveränderungen, technischer Fortschritt, geänderte Vorschriften und Gesetze, geänderte Prioritäten und Wünsche der Stakeholder sowie Feedbackschleifen. Der Requirements Engineer muss zwischen stabilen Anforderungen und wertstiftender Flexibilität abwägen (siehe Anforderungsmanagement).

Prinzip 8: Innovation

Mehr vom Gleichen ist nicht genug. Ziel ist es, Stakeholder nicht nur zufrieden zu stellen, sondern zu begeistern. Das Kano-Modell verdeutlicht diesen Zusammenhang. Für das Requirements Engineering bedeutet das, nach aufregenden, neuen Funktionen im Kleinen und disruptiven Ideen im Großen zu streben. Techniken wie Design Thinking helfen dabei, disruptive Ideen in Anforderungen zu übersetzen.

Prinzip 9: Systematische und disziplinierte Arbeit

Systematik und Disziplin im Requirements Engineering verbessert die Qualität des zu entwickelnden Systems. Dies bedeutet jedoch nicht, dass es nur einen einzigen richtigen RE-Prozess gibt. Requirements Engineers müssen ihr Vorgehen, ihre Praktiken, die zu erzielenden Ergebnistypen immer an das spezifische Problem und die Umgebung anpassen.

Prinzip vs. Methode

Von Prinzipien zur Praxis

Prinzipien wie „Gemeinsames Verständnis“ oder „Evolution von Anforderungen“ klingen in der Theorie gut, scheitern aber oft an der Realität: Silo-Wissen, verstreute Dokumente und Angst vor Änderungen (Change). Ohne Tool-Unterstützung bleiben Prinzipien oft nur Lippenbekenntnisse.

objectiF RM und objectiF RPM sind so konzipiert, dass sie Methoden nicht nur verwalten, sondern die Prinzipien technisch unterstützen. Hier einige Beispiele:

• Das Prinzip „Kontext“ wird durch integrierte System-Kontext-Diagramme unterstützt.
• Das Prinzip „Gemeinsames Verständnis“ wird durch ein zentrales Repository für alle Ergebnisse des RE-Teams gefördert.
• Das Prinzip „Evolution“ wird durch Versionierung und Baselining technisch beherrschbar.
• Das Prinzip „Wertorientierung“ wird durch die Verknüpfung von Anforderungen mit Business-Zielen (Business Goals) sichergestellt.

Prinzipien wirksam umsetzen

Verankern Sie die zentralen RE-Prinzipien direkt in Ihrem Projekt mit  objectiF RM und objectiF RPM. So werden aus guten Vorsätzen belastbare Ergebnisse.