Was ist Requirements Modeling?

Beim Requirements Modeling werden grafische Modelle (vorwiegend aus UML/SysML) eingesetzt, um komplexe Anforderungen durch das gezielte Hervorheben relevanter Aspekte und das Ausblenden von Details verständlich und prüfbar zu machen. Requirements Modeling bedeutet also die systematische Abstraktion der Realität mit dem Ziel Komplexität zu reduzieren.

Die Sichten des Requirements Modeling nach IREB

Strukturdiagramm der Sichten im Requirements Modeling: Die Anforderungssicht umschließt die Kontextsicht, Informationsstruktursicht, dynamische Sicht (Use Case Sicht, datenfluss-, kontrollfluss- und zustandsorientierte Sicht, Szenariosicht), Qualitätssicht und Constraints-Sicht. Zu fast jeder Sicht werden Beispiel-Diagramme wie Kontextdiagramm, Klassendiagramm, Use Case Diagramm und Aktivitätsdiagramm aufgeführt.

Um ein System vollständig zu spezifizieren, muss man es unter mehreren Aspekten betrachten. Deshalb schlägt der Standard des IREB (International Requirements Engineering Board) vor, Anforderungen grundlegend aus drei Perspektiven zu betrachten: der statisch-strukturellen Sicht, der Verhaltenssicht und der Funktionssicht (nach CPRE Foundation Level).

Aber: Moderne Systeme werden immer komplexer. Um die Komplexität beherrschbar zu machen, ist es hilfreich, noch differenzierter auf Anforderungen zu blicken. Im Requirements Modeling des CPRE Advanced Level werden detailliertere Anforderungssichten und passende Modelle zu ihrer Beschreibung vorgeschlagen. Die Modelle haben ihren Ursprung überwiegend in der UML/SysML. Hier sind die Anforderungssichten im Überblick:

Die Kontextsicht

Die Kontextsicht markiert den Startpunkt jeder Modellierung. Sie dient dem Verständnis der Systemumgebung (externe Systeme, Rollen/Personen, relevante Eigenschaften) und hilft Schnittstellen zur Umgebung zu identifizieren. Die Kernfrage lautet hier also: Wer und was interagiert mit dem System?

Wichtige Diagrammtypen: Kontextdiagramm, Use Case Diagramm der UML, Blockdiagramme der SysML

Die Informationsstruktursicht

Diese Sicht konzentriert sich auf die statisch-strukturellen Aspekte der Systemfunktionalität, speziell auf die zu verarbeitenden Datenstrukturen.

Wichtige Diagrammtypen: Klassendiagramm oder spezielle Ausprägungen des Entity-Relationship-Modells

Die Qualitätssicht

Diese Sicht betrachtet Anforderungen, die sich auf die Qualitätseigenschaften des betrachteten Systems bzw. seiner Bestandteile beziehen. In der Praxis werden Qualitätsanforderungen überwiegend textuell beschrieben. Modellbasierte Ansätze haben sich hier nicht durchgesetzt.

Die Constraints-Sicht

Diese Sicht umfasst Anforderungen als Randbedingungen (externe Einschränkungen) an das System oder den Entwicklungsprozess. Dazu gehören organisatorische, normative oder technische Vorgaben. Hier überwiegt zunächst die textliche Dokumentation. Insbesondere organisatorische und technische Randbedingungen können jedoch mit Hilfe von Diagrammtypen wie dem Klassendiagramm oder dem Komponentendiagramm modelliert werden.

Die dynamische Sicht

Diese Sicht betrachtet Anforderungen an die dynamischen Aspekte der Systemfunktionalität. Um mit Vielfalt und Komplexität des dynamischen Verhaltens eines Systems umzugehen, wird die dynamische Sicht ihrerseits in weitere Sichten unterteilt:

  • Use-Case-Sicht: Beschreibt die groben Nutzerfunktionen und ihre Beziehungen zu Akteuren im Systemkontext (Einsatz von Use-Case-Diagrammen)
  • Datenfluss­orientierte Sicht: Spezifiziert die an den System­schnitt­stellen wahrnehmbaren Funktionen und ihre Datenabhängigkeiten untereinander sowie zu den Akteuren im Kontext (Einsatz u.a. von Aktivitätsdiagrammen mit Objektfluss)
  • Kontroll­fluss­orientierte Sicht: Beschreibt die Prozesse/Aktionen, die an den System­schnitt­stellen sichtbar sind, sowie ihre Ablauflogik (z. B. sequenziell, alternativ, nebenläufig) (Einsatz u.a. von Aktivitäts­diagrammen)
  • Zustandsorientierte Sicht: Modelliert den Zustandsraum sowie Zustände/­Zustands­wechsel (u. a. ereignis- oder zeitgetrieben) an der System­schnitt­stelle (Einsatz u.a. von Zustands­diagrammen)
  • Szenariosicht: Beschreibt Interaktions­sequenzen zwischen Akteuren und dem System, durch die Akteure ein Ziel erreichen oder einen Mehrwert erhalten. Szenarien konkretisieren Use Cases in Use Case Diagrammen. (Einsatz u.a. von Sequenz­diagrammen)

CPRE Advanced Level – Werden Sie Experte

Das Requirements Modeling ist ein spezialisierter Teilbereich des Requirements Engineering. Für Fachkräfte bietet das IREB die Zertifizierung zum CPRE Advanced Level Requirements Modeling an. Auf diesem Niveau lernen Teilnehmer, Modelle nicht nur zu lesen, sondern sie gezielt einzusetzen, um die Qualität der Anforderungsspezifikation zu erhöhen und Fehlinterpretationen zu eliminieren.

Ihr Weg zum Zertifikat

microTOOL ist nicht nur Tool-Hersteller, sondern auch anerkannter Trainingsanbieter. Absolvieren Sie bei uns das CPRE Advanced Level Requirements Modeling Training. In unseren Seminaren lernen Sie die Theorie des IREB-Lehrplans kombiniert mit praktischen Übungen.

Die größte Schwierigkeit beim Requirements Modeling besteht darin, die verschiedenen Sichten konsistent zu halten. In herkömmlichen Zeichentools sind Diagramme isolierte Grafiken. Änderungen müssen mühsam über mehrere Dokumente nachgezogen werden. Ohne eine Verbindung zwischen Modellen und textuellen Anforderungen besteht die Gefahr, ein „Dokumentengrab“ voller Inkonsistenzen zu produzieren.

Mit objectiF RPM wird Requirements Modeling lebendig. Die Software unterstützt die gängigen Diagrammtypen der UML und SysML und speichert die Modelle, ihre Elemente, Beziehungen und zugehörigen Texte ohne Redundanzen in einem zentralen Repository. Die Wirkung:

  • Single Source of Truth: Wenn Sie ein Element zum Beispiel in einem Diagramm umbenennen, wird diese Änderung in Echtzeit überall vorgenommen, wo das Element vorkommt. Das Ergebnis ist ein konsistentes Anforderungsmodell.
  • Traceability: Immer aktuell und nachvollziehbar bleiben dabei auch die Zusammenhänge der Modelle und ihrer Elemente (z.B. von Use Cases und Anforderungen, Anforderungen und ihren Verfeinerungen, Anforderungen und Testfällen, Anforderungen und den sie erfüllenden Systemelementen).
  • Versionssicherheit: Änderungsstände werden durch sichere Versionierung festgehalten. Änderungen bleiben nachvollziehbar (Differenzenbildung).
  • Automatisierte Dokumentation: Lastenheft oder Systemspezifikation werden direkt und immer aktuell aus dem Repository generiert. Text und Grafiken der Modelle haben immer einen konsistenten Stand.
CPRE Logos 2026 microTOOL

CPRE Zertifizierung nach IREB

Unsere 3-tägigen CPRE-Seminare für Foundation und Advanced Level verbinden Methodenkompetenz mit Praxisrelevanz.

Häufige Fragen

Ersetzt das Modell die Textform?

Nein. In der Regel ergänzen sich Modell und Text. Das Modell bietet die Struktur und Logik, während Texte in natürlicher Sprache Details und Erklärungen liefern.

Ist Modellierung nicht viel aufwendiger als reine Text-Spezifikation?

Ein initialer Aufwand ist natürlich vorhanden, auch wenn er mit einem Tool wie objectiF RPM gering bleibt. Aber er amortisiert sich sehr schnell. Modelle erleichtern die Orientierung je umfangreicher die Spezifikation wird. Sie sind hervorragende Kommunikationsinstrumente und decken Logikfehler und Lücken auf, die in Textwüsten gar nicht erkannt werden. Das rechnet sich.

Welche Notation ist am wichtigsten?

Das hängt vom Ziel ab. Starten Sie immer mit der Kontextsicht, d.h. mit Kontextdiagrammen. Bei datenintensiven Systemen bietet sich die Informationsstruktursicht an. Bei prozessgesteuerten Systemen (z. B. Automatisierung) sind die daten-, kontrollfluss- und zustandsorientierte Sicht entscheidend. Hier kommen also Aktivitäts- und Zustandsdiagramme zum Einsatz. Liegt ein Schwerpunkt Ihrer Arbeit auf der Kommunikation mit den Stakeholdern sind Use Case Diagramme gut geeignet. Der CPRE Advanced Level vermittelt die Auswahl des jeweils richtigen Typs.

Mehr Wissen

Entdecken Sie weitere Wissensbeiträge online oder laden Sie unsere Whitepaper herunter.