Der Prozess zum Tool

Kennen Sie schon den elementaren Requirements Engineering Prozess, den wir bei der Entwicklung von objectiF RM im Kopf hatten? Diesen Prozess stelle ich Ihnen heute vor.

• Es ist ein Basisprozess, d. h., er enthält nur Aktivitäten und Artefakte, die im Rahmen des Requirements Engineering unbedingt nötig sind.
• Er ist modellorientiert, folgt aber nicht blindlings einem Standard wie UML oder SysML.
• Er lässt sich gleichermaßen mit schwergewichtigen Prozessen und agilem Vorgehen kombinieren. So können Sie ihn zur Grundlage Ihres eigenen Vorgehens machen.

Ausgangspunkt: Projektauftrag

Gehen wir an den Anfang eines Projekts – zu dem Punkt, an dem es noch nichts gibt außer einem Projektauftrag. Der begründet im günstigsten Fall das Projekt und beschreibt, was sich das Unternehmen oder der Kunde von dem zu entwickelnden System verspricht. Dazu enthält er (hoffentlich) den Business Case, also die betriebswirtschaftliche Rechtfertigung des Projekts und den terminlichen und finanziellen Rahmen. Wenn das neue System Geschäftsprozesse unterstützen soll, dann steht vermutlich im Projektauftrag, welche strategischen Ziele das Unternehmen mit der Neugestaltung der Prozesse verfolgt. Wenn es um die Entwicklung von Softwareprodukten oder softwareintensiven Systemen für den Markt geht, dann erläutert der Projektauftrag wahrscheinlich die zugrunde liegende Produktstrategie. Auf dieser Basis kann es dann losgehen mit dem Ermitteln der Anforderungen. Sie wissen ja: So einfach ist die Sache in der Unternehmensrealität leider nicht. Es ist einiges an Vorarbeit nötig, damit Sie:

• nicht nur irgendwelche, sondern die richtigen und relevanten Anforderungen ermitteln – und das möglichst vollständig,
• wissen, wer die Anforderungen bewerten muss und mit wem Sie die Anforderungen abstimmen müssen.
• Anforderungen entwickeln, die finanziell, organisatorisch, personell und technisch realisierbar sind.

Was ist konkret zu tun und was muss dabei herauskommen? Der objectiF Requirements Engineering Prozess gibt darauf diese Antworten:

Vollständigkeit im Visier: Systemkontext – Stakeholder – Ziele

Anforderungen konkretisieren Ziele. Der Projektauftrag steckt mit den dort beschriebenen strategischen und wirtschaftlichen Zielen und dem skizzierten Scope des zu entwickelnden Systems nur einen groben Rahmen ab. Er ist meistens zu grob, um daraus konkrete Anforderungen abzuleiten. Zunächst müssen die Ziele – gemeinsam mit den Stakeholdern – detailliert werden.

Stakeholder sind die Personen, Gruppen und Organisationseinheiten, die ein – wie auch immer geartetes – Interesse an dem zu entwickelnden System haben. Sie nehmen 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. Um den Systemkontext abzubilden, kann man Anwendungsfalldiagramme oder Blockdiagramme der UML/SysML verwenden. Wir finden eine Darstellung hilfreicher, die sich an den klassischen Datenflussplänen von DeMarco orientiert.

Die ersten Schritte

Das Systemkontextdiagramm beantwortet die Frage: Welche Elemente (dazu gehören u.a. fremde Systeme, aber auch Akteure) befinden sich in der Umgebung des geplanten Systems und sind für die Definition und das Verständnis der Anforderungen relevant? Wir haben in diesem Diagrammtyp speziell die Möglichkeit geschaffen, auch Regelungen, Normen und Standards abzubilden, die das zu entwickelnde System erfüllen muss.

Bei der Definition des Systemkontextes ist noch eine weitere Frage zu beantworten: Was ist im System und was liegt außerhalb? Also, wie grenzt sich das System gegen seinen Kontext ab? Ist das geklärt und in der Beschreibung des Systems im Systemkontextdiagramm festgehalten, kann es losgehen mit der Analyse der Stakeholder und ihrer Ziele.

Stakeholder verfolgen Absichten. Sie versprechen sich von einem zu entwickelnden System, dass es ihnen dabei hilft, diese Absichten umzusetzen. Damit das gelingt, muss das System aus Sicht eines Stakeholders spezielle Merkmale besitzen. Die Beschreibung eines solchen Merkmals vor dem Hintergrund der Absichten eines Stakeholders wird als ein Ziel bezeichnet.

Eine Zielbeschreibung ist Text, der formularbasiert erfasst und somit einheitlich strukturiert wird. 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. Zieldiagramme sind im Kern UND/ODER- Bäume.

Iterativ stabilisieren: Ziele – Szenarien – Anforderungen

Diagramme beschreiben ein System unter verschiedenen Aspekten. Geht es mit einem Aspekt nicht richtig voran, dann wechselt man – und das ist eine besondere Stärke modellbasierter Methoden – einfach den Blick. Also „hakt“ es beim Verstehen oder Verfeinern von Zielen, dann hilft es, Szenarios für Ziele zu entwickeln. Szenarios beantworten die Frage: Wie wird ein Ziel in Interaktion mit dem System erreicht? Szenarios können als Anwendungsfälle der UML modelliert und formularbasiert mit strukturierten Texten spezifiziert werden. Oder man entwickelt dafür Aktivitätsdiagramme der UML.

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 hier hochgradig iterativ.

Genau wie Ziele werden auch Anforderungen nach einem einheitlichen Schema mit Text beschrieben. Aber je mehr Anforderungen entstehen, desto schwieriger wird es, Zusammenhänge zu erkennen und sich zu orientieren. Hier helfen Anforderungsdiagramme der SysML. Sie zeigen unter anderem:

• welche Anforderungen durch Verfeinern auseinander hervorgegangen sind,
• welche Anforderungen voneinander abgeleitet wurden,
• welche Stakeholder an den Anforderungen in welchem Maße interessiert sind,
•  welche Testfälle zu einer Anforderung definiert sind,
• welche Anwendungsfalldiagramme eine Anforderung detaillieren.

Schritte und Ergebnistypen der Anforderungsermittlung

Parallel detaillieren: Anforderungen – Systemarchitektur

Das ist aber noch nicht alles. In Anforderungsdiagrammen können Sie außerdem abbilden:

• welche Systemkomponenten – beschrieben mit Block-, Package- oder Klassendiagrammen der UML/SysML – eine Anforderung verfeinern,
• welche Systemkomponenten – definiert als Blöcke im Sinne der SysML – eine Anforderung erfüllen.

Moment – wie kommt zum Zeitpunkt der Anforderungsermittlung mit einem Mal die Systemarchitektur ins Spiel? Die Forderung nach Anforderungen, die auch realisierbar sind, legt es nahe, Anforderungen parallel zur Systemarchitektur zu detaillieren.

Twin Peaks Model zum parallelen Verfeinern von Anforderungen und Systemarchitektur

Für die parallele Verfeinerung von Anforderungen und Systemarchitektur (nach dem Twin Peaks Model, siehe z. B. Bashar Nuseibeh: „Weaving Together Requirements and Architectures“) findet der Systemarchitekt in objectiF RM die erwähnten Klassen- und Packagediagramme sowie Blockdefinitions- und interne Blockdiagramme vor.

Diagrammtypen zur Beschreibung der Systemarchitektur

Per Vorlagen auf Knopfdruck: Auswertungen – Dokumente

Schließlich muss die Qualität der Anforderungen geprüft und die Anforderungen müssen dokumentiert werden.

Die automatisch geführte Historie und die sichtbar gemachten Entwicklungszustände (die Zustandswechsel können Sie übrigens über eigene Zustandsautomaten steuern), helfen Ihnen, bei der Qualitätssicherung den Überblick zu behalten. Sind die Stakeholder-Ziele durch Anforderungen abgedeckt? Haben Sie alle Anforderungen eines Stakeholders tatsächlich erfasst? – Das Tool hilft Ihnen, Fragen wie diese mithilfe von Auswertungen zu beantworten: Auswertungen sind dynamische Abfragen. Sie basieren auf Vorlagen – wir nennen sie Abfragetypen –, die der Tool-Administrator vorbereiten kann. Als Requirements Engineer passen Sie sie dann nur noch an Ihren Bedarf an.

Die letzten Schritte bis zum Lasten- und Pflichtenheft

Ein Lastenheft, ein Pflichtenheft oder auch ein Vision-Dokument – darauf läuft die Arbeit letztlich hinaus. Mit objectiF RM erzeugen Sie ein solches Dokument in Microsoft Word einfach per Knopfdruck. Denn auch für Dokumente werden Vorlagen verwendet. Darin können Sie festlegen, welche Artefakte, Diagramme und Abfragen in das Dokument aufgenommen werden sollen. So erzeugen Sie sehr schnell eine aussagekräftige Dokumentation.