Requirements Engineering ist eine Schlüsseldisziplin der Systementwicklung. Sie entscheidet häufig über den Erfolg oder Misserfolg eines Projekts. Für die erfolgreiche Realisierung von Projekten gibt es glücklicherweise Hilfestellung: ein strukturiertes Vorgehen mit 6 Schritten zur Ermittlung und zum Umgang mit Anforderungen, empfohlen vom International Requirements Engineering Board (IREB e.V.).
Das Projekt steht am Anfang
Stellen Sie sich vor, Sie haben einen Projektauftrag mit einer Beschreibung. Diese Beschreibung beinhaltet, was sich das Unternehmen von dem zu entwickelnden System erwartet. Er enthält auch den Business Case und somit die kaufmännische Rechtfertigung des Projekts, sowie mögliche terminliche und finanzielle Rahmenbedingungen. Auf dieser Basis kann es losgehen mit dem Ermitteln der Anforderungen. Leider ist es in der Realität nicht so einfach, die richtigen und relevanten Anforderungen zu ermitteln – und das möglichst vollständig. Und daraus dann die Anforderungen zu gewinnen, die finanziell, organisatorisch, personell und technisch realisierbar sind.
Vollständigkeit im Fokus
Anforderungen konkretisieren Ziele. Der Projektauftrag ist meistens zu grob, um daraus konkrete Anforderungen abzuleiten. Daher müssen zunächst die Ziele der Stakeholder detailliert werden. Stakeholder sind die Personen, Gruppen und Organisationseinheiten, die ein Interesse an dem zu entwickelnden System haben. Sie nehmen somit direkt oder indirekt Einfluss auf die Anforderungen. Aber ist jeder, der Ziele mit dem System verfolgt und durch Anforderungen Einfluss auf die Entwicklung nehmen will, tatsächlich ein relevanter Stakeholder?
Um das zu entscheiden, müssen Sie die Umgebung des Systems – den Systemkontext – genau kennen. Wird der Systemkontext nicht vollständig definiert, werden auch die Anforderungen unvollständig bleiben. Bei der Analyse hilft ein Systemkontextdiagramm. Das Systemkontextdiagramm zeigt auf, welche Elemente – und dazu gehören u.a. fremde Systeme – aber auch Akteure oder Regelungen, Normen und Standards, sich in der Umgebung des geplanten Systems befinden und für die Definition und das Verständnis der Anforderungen relevant sind.
Stakeholder verfolgen Absichten. Sie versprechen sich von einem zu entwickelnden System etwas ganz einfaches: Es soll ihnen dabei helfen, diese Absichten umzusetzen. Damit das gelingt, muss das System aus Sicht eines Stakeholders bestimmte Merkmale besitzen. Die Beschreibung eines solchen Merkmals vor dem Hintergrund der Absichten eines Stakeholders wird als ein Ziel bezeichnet. Um konkurrierende oder abhängige Ziele zu erkennen und Zielkonflikte zusammen mit den Stakeholdern zu lösen, hilft es, Ziele, ihre Verfeinerung und ihre Beziehungen untereinander in Zieldiagrammen abzubilden.
Kontext – Stakeholder – Ziele
Iterativ stabilisieren
Mit Diagrammen beschreiben Sie ein System unter verschiedenen Aspekten. Geht es mit einem Aspekt nicht richtig voran, wechseln Sie die Blickrichtung. So kann es helfen, Szenarios für Ziele zu entwickeln. Szenarios beantworten die Frage: Wie wird ein Ziel in Interaktion mit dem System erreicht? Sowohl aus Zielen als auch aus Szenarios lassen sich oft Anforderungen ableiten. Anforderungen können wiederum durch Szenarios beschreiben werden, um daraus möglicherweise detailliertere Anforderungen zu gewinnen. Das Vorgehen ist hochgradig iterativ.
Ziele – Szenarios – Anforderungen
Parallel detaillieren
Je mehr Anforderungen entstehen, desto schwieriger wird es, Zusammenhänge zu erkennen und sich zu orientieren. Ableitungen, Verfeinerungen, beteiligte Stakeholder, betroffene Anforderungen, Testfälle, die Systemarchitektur und vieles mehr wollen bedacht werden. Der Ruf nach Anforderungen, die auch realisierbar sind, legt es nahe, Anforderungen parallel zur Systemarchitektur zu detaillieren. Als Ausdrucksmittel bieten sich in der Praxis dafür Klassen- und Packagediagramme aus der UML sowie Blockdefinitions- und interne Blockdiagramme aus der SysML an.
Paralleles Verfeinern von Anforderungen und Systemarchitektur nach dem Twin Peaks Model
Prüfen und dokumentieren
Schließlich muss die Qualität der Anforderungen geprüft und die Anforderungen selbst dokumentiert werden. Anforderungsabdeckung, Änderungen, Varianten und Systemabgrenzung sind nur einige Stichwörter, die im Kontext des Prüfens relevant sind. Die Dokumentation läuft dann auf ein Lastenheft, ein Pflichtenheft oder ein Vision-Dokument hinaus. Und wenn Sie verschiedene Aspekte mit grafischen Ausdrucksmitteln beleuchtet haben, wollen Sie diese Ergebnisse vermutlich auch entsprechend dokumentieren, oder?
Prüfen und dokumentieren
Zusammengefasst führen also 6 Schritte zu guten Anforderungen. Sie grenzen das System ab und analysieren die Stakeholder. Die Stakeholder verfolgen Ziele, aus denen sich Anforderungen ableiten. Szenarien können dabei helfen, ein besseres Verständnis zu gewinnen und somit auf weitere Anforderungen zu kommen. Parallel zur Anforderungsermittlung modellieren Sie das System und auch daraus resultieren Anforderungen. Das Ganze gilt es zu prüfen. Und zu dokumentieren.
6-Schritte-nach-IREB
Fazit
Das Requirements Engineering beeinflusst maßgeblich den Erfolg eines Projektes. Mit den 6 Schritten möchte der IREB e.V. letztlich die Praxis im Requirements Engineering und der Business Analyse verbessern. Sie schaffen eine Grundlage für ein gemeinsames Verständnis innerhalb eines Projektes und zwischen Geschäftspartnern. Die Kommunikation wird wesentlich effizienter, wenn die Beteiligten die gleiche Sprache sprechen. So entstehen Anforderungsspezifikationen, Lastenhefte und Pflichtenhefte, und damit bessere Grundlagen für die Planung von Vorhaben, sowie die Entwicklung und das Testen der Produkte. Mit den 6 Schritten gehen Sie somit den richtigen Weg.
Testen Sie in 2 Minuten Ihr Wissen im Bereich Requirements Engineering.
Können Sie diese CPRE Prüfungsfragen sicher beantworten?