IT-Analyse III – das Modell im Überblick

In einem ersten Schritt wird der Inhalt des Berufsbild IT-Analyse in einer Kurz-Form dargestellt. Im zweiten Schritt wird die in den bisherigen Folgen – unhinterfragt – verwendete Bezeichnung „IT-Analytiker“ diskutiert. Darauf aufbauend werden die einzelnen Elemente des im ersten Schritt skizzierten Berufsbildes erläutert.

IT-Analyse – kurz gefasst

In der konkreten Ausprägung wird die Analyse in jedem Projekt anders gelebt. Und doch gibt es einen gemeinsamen Kern, auf den sich die Tätigkeit in allen Varianten reduzieren lässt.

Dieser gemeinsame Kern lässt sich in einem Satz ausdrücken:

IT-Analyse ist das Transformieren von Anforderungen in den Entwurf eines IT-Systems

Diese Definition enthält drei Elemente:

• die Anforderungen als den Input für die Analyse-Tätigkeit.
• den Entwurf, der das Ziel und Ergebnis der Tätigkeit ist.
• das Transformieren, was aus den Anforderungen einen Entwurf macht.

Diese Elemente sollen in weiterer Folge im Detail behandelt werden. Zuvor wollen wir uns aber noch Gedanken über die Bezeichnung für die Funktion machen, deren Hauptaufgabe diese Transformation ist.

Der Job-Title – mehr als Schall und Rauch?

Namen sind Schall und Rauch. Wichtig ist der Inhalt der Tätigkeit. Wie man das dazu gehörige Berufsbild dann nennt, ist zweitrangig. Aber es erleichtert doch die Kommunikation, wenn man eine gemeinsame Bezeichnung dafür hat.

Im bisherigen Verlauf dieser Artikel-Serie wurde unhinterfragt die Bezeichnung „IT-Analyse“ für das Berufsbild verwendet. Das soll nun begründet werden.

Zwei Anforderungen seien hier für einen geeigneten Job-Title genannt:

1. Der Job-Title soll den Inhalt der Tätigkeit zum Ausdruck bringen
2. Der Job-Title soll geschäftstauglich sein: d. h. er soll nicht zu lang sein und er soll keine sehr ungebräuchlichen Ausdrücke verwenden.

Würde man nur die erste Anforderung berücksichtigen, so müsste die Berufsbezeichnung „Anforderungs-Transformator“ oder so lauten. Das klingt aber erstens nicht besonders attraktiv, und würde auch nicht verstanden werden.

Sehen wir uns heute übliche Berufsbezeichnungen unter diesen Gesichtspunkten an:

Requirements Engineer ist ein eingeführter Job-Title, der sich auf vielen Job-Profilen und Visitenkarten findet. Eigentlich beschreibt er die Tätigkeit aber nicht richtig, denn das „Engineering“ bezieht sich in der Realität nicht auf die Anforderungen, sondern auf die zu entwickelnde Lösung. Das kann zu falschen Erwartungen führen.

Mehr und mehr hat sich in den letzten Jahren die Berufsbezeichnung Business Analyst durchgesetzt. Viele Ausübende der hier beschriebenen Funktion – so auch der Autor – haben sich gleichzeitig mit beiden Job-Titles bezeichnet: Business Analyst/Requirements Engineer. Die Business Analyse ist jedoch ein weites Feld und wird nicht überall mit IT in Verbindung betrachtet. So ist diese Bezeichnung sehr unspezifisch.

Systemanalytiker war vor einigen Jahrzehnten ein eingeführter Begriff für die Analyse in IT-Projekten. Heute wirkt diese Bezeichnung aber etwas verstaubt und veraltet.

Die genannten Job-Titles drücken den Inhalt der Tätigkeit nicht sehr gut aus. Teils verweisen sie lediglich auf einen Teilaspekt der Funktion, teils sind sie sehr unspezifisch.

Der Teil der Bezeichnung „Analytiker“ macht – im Allgemeinen – schon eine sehr treffende Aussage. Damit diese spezifischer wird, wird sie – im vorliegenden Vorschlag um das Präfix „IT-“ ergänzt, sodass sich „IT-Analytiker“ als Berufsbezeichnung ergibt. Allerdings ist auch diese Bezeichnung nicht perfekt. „Analyse“ kommt aus dem Griechischen und bedeutet „Zerlegung“. Das trifft den Inhalt gut – die Anforderungen werden in ihre Elemente zerlegt. Sie werden im Anschluss jedoch auch wieder zum Entwurf zusammengesetzt – diese „Synthese“ ist in der Bezeichnung nicht enthalten. Trotzdem erscheint „IT-Analyse“ als die beste der aktuell in Verwendung stehenden Optionen und wird hier in Folge weiter verwendet.

Ein Modell der IT-Analyse

„IT-Analyse ist das Transformieren von Anforderungen in den Entwurf eines IT-Systems“. Diese Definition für das Berufsbild IT-Analyse wurde oben eingeführt. In diesem Abschnitt soll diese Definition näher betrachtet werden.

Die Anforderungen
Um die Anforderungen dreht sich alles. Sie sind die Existenzberechtigung für den gesamten Software-Entwicklungsprozess. Ein Fachbereich, ein Unternehmen benötigt eine bestimmte Funktionalität – und formuliert diese als Anforderung. Das Team, das diese Anforderung umsetzen soll, erhält einen Auftrag, der meistens durch ein Dokument beschrieben wird.

Dieses Dokument, das z. B. eine Ausschreibung sein könnte, ist der Ausgangspunkt. In seltenen, einfachen, Fällen kann diese Anforderung unmittelbar in Software umgesetzt werden.

Meistens jedoch bestehen Fragen, Unklarheiten, Widersprüchlichkeiten, die geklärt werden müssen, damit das fertige Software-Produkt nicht ihren gewünschten Zweck verfehlt.

Die Klärung dieser Fragen, Unklarheiten, Widersprüchlichkeiten wird Anforderungserhebung genannt. Dafür gibt es eine Reihe von Methoden. Die wichtigste davon ist das Gespräch mit den sogenannten Stakeholdern, also mit allen, die von der zu entwickelnden Software betroffen sind.

Manchmal wird dieses Gespräch auch durch eine schriftliche Befragung ersetzt, etwa dann, wenn es sehr viele von diesen Stakeholdern gibt. In vielen Fällen wird auf vorhandene schriftliche Dokumente zurückgegriffen.

Um diese Anforderungen auch verstehen zu können, muss der Analytiker selbst Experte in der Fachdomäne werden. Das passiert mehr oder weniger automatisch, wenn man für längere Zeit im gleichen Gebiet tätig ist. Bei einem Wechsel in ein neues Fachgebiet, geht es darum, dieses Expertentum schnell zu erwerben. Nur dann ist es möglich, mit den Stakeholdern auf Augenhöhe zu sprechen. Andernfalls können die Anforderungen nur kritiklos entgegengenommen werden.

Der Entwurf
Das Ergebnis der Analyse-Tätigkeit ist ein Entwurf des geplanten Software-Systems, bzw. der Änderung an einem bestehenden System. Obwohl jedes Projekt anders ist, gibt es doch eine Systematik, wie ein derartiger Entwurf aussieht – eine Systematik, die für jedes Projekt anwendbar ist. So kann jeder Entwurf unter drei Aspekten betrachtet werden:

• Der statische Aspekt: Die Daten
• Der dynamische Aspekt: Die Prozesse
• Die Schnittstellen.

Statik – die Daten
Es geht immer um Daten. „Datenverarbeitung“ ist ein etwas verstaubter Begriff für das Fachgebiet, in dem sich auch die IT-Analyse bewegt. Der aktuelle Begriff IT („Information Technology“) sagt letztlich nichts anderes aus. Inhalt und Ziel jedes Software-Entwicklungsprozesses sind immer Daten:

• Daten, die ans Finanzamt geliefert werden müssen,
• Daten, die Maschinen steuern,
• Daten, die dazu dienen, Aufträge von Kunden zu bearbeiten,
• Daten, die Informationen über Lagerbestände abbilden,
• Daten, mit denen die Entwicklung von Unternehmen analysiert werden.
• Das sind nur einige wenige Anwendungsfälle, für die Daten, die verwaltet werden.

In jedem Fall haben diese Daten eine bestimmte Struktur, die Inhalt des Entwurfes ist, der in der Analyse entsteht. Das ist der statische Aspekt des Entwurfes.

Dynamik – die Prozesse
Diese Daten unterliegen einem Prozess. Sie entstehen irgendwo, sie wandern durch verschiedene Stellen innerhalb der Organisation, sie werden transformiert, aggregiert, angezeigt. Diese Prozesse werden im dynamischen Aspekt des Entwurfs beschrieben. Prozesse gibt es auf drei Ebenen:

• Workflow-Ebene: Ein Geschäftsfall wandert durch mehrere Stellen, bis der Prozess abgeschlossen ist. Zum Beispiel: ein Kreditantrag muss je nach Höhe von mehreren Stellen genehmigt werden, bis es zur Auszahlung kommen kann.
• Orchestrierungs-Ebene: Mehrere Services (oder andere Software-Bausteine) werden hintereinander – oder auch parallel – aktiv, damit ein bestimmtes Ziel erreicht wird.
• Algorithmus-Ebene: das ist der Ablauf innerhalb eines Software-Bausteines, der benötigt wird, um – zum Beispiel – eine bestimmte Berechnung durchzuführen

Die Gestaltung jeder dieser Ebenen ist Inhalt des Entwurfs, der durch die Analyse entsteht.

Schnittstellen
Der dritte Aspekt, der im Entwurf zu berücksichtigen ist, ist der der Schnittstellen. In der Analyse müssen sowohl die Schnittstellen nach außen als auch innerhalb der einzelnen Bestandteile des zu entwerfenden Systems definiert werden.

Benutzer-Schnittstelle
Eine besondere Rolle unter den Schnittstellen nimmt die Benutzer-Schnittstelle ein. Vor allem dann, wenn es um die Schnittstelle zu Kunden hin geht, spielen hier nicht nur technische Gesichtspunkte eine Rolle. Es muss auch eine User-Experience geschaffen werden. Deshalb liegt die Aufgabe der Schaffung der Schnittstelle nach außen häufig bei spezialisierten Experten, mit denen der IT-Analyst zusammenarbeitet.

System-Schnittstellen nach außen
Wenn externe Systeme angebunden werden müssen, dann besteht häufig ein sehr geringer Gestaltungsspielraum. Das externe System bietet eine Schnittstelle an, die von dem neu zu entwickelnden System erfüllt werden muss, wenn diese mit dem externen System Daten austauschen möchte.

Schnittstellen nach innen
Auch die Bausteine innerhalb eines Systems sind durch Schnittstellen miteinander verbunden. Und auch diese werden in der Tätigkeit des Entwerfens gestaltet.

Die Analyse – von der Anforderung zum Entwurf

Zwischen Anforderung und Entwurf steht die Analyse. Analyse ist die Tätigkeit, in der die Anforderungen zum Entwurf werden.

Analyse ist ein geistiger, kreativer Prozess, der im Kopf des Analytikers stattfindet und der sich deshalb einer exakten Beschreibung entzieht.

Es gelten jedoch auch hier die allgemeinen Regeln für kreative Prozesse, wie sie unter anderem von Graham Wallas ^[1] beschrieben wurden. Demgemäß besteht ein kreativer Prozess aus vier Schritten:

1. Vorbereitung: Hier wird Wissen über das zu lösende Problem aufgebaut. Im Fall der Analyse ist das die intensive Beschäftigung mit den Anforderungen und – darüber hinaus gehend – mit der Fachdomäne, in der das geplante IT-System angesiedelt ist. Das Erstellen eines Entwurfs ist keine triviale Angelegenheit. Der Entwurf ergibt sich nicht unmittelbar aus den Anforderungen. Es bedarf Überlegungen – und diese Überlegungen stoßen in vielen Fällen auf Widersprüche, die aufzulösen sind.
2. Inkubation: Wenn sich das Problem in der Vorbereitungsphase nicht lösen lässt, dann ist es zweckmäßig, sich gedanklich vom Problem zu lösen. Das Unterbewusstsein arbeitet dann weiter am Problem.
3. Illumination: Das Unterbewusstsein meldet sich, wenn es eine Lösung gefunden hat. Das kennt jeder Analytiker, wenn ihm eine Entwurfsidee in der Dusche oder beim Radfahren kommt.
4. Verifikation: Dieser Geistesblitz aus dem Unterbewusstsein muss dann aber bewusst überprüft und mit den Stakeholdern abgestimmt werden. Das passiert in der vierten Phase des Kreativitätsprozesses.

Der so entstehende Entwurf ist in weiterer Folge die Basis für die Entwicklung, wo der Entwurf in die Lösung umgesetzt wird.

Dieses Modell gilt unabhängig vom Grad der Agilität, die im jeweiligen Projekt eingesetzt wird. Der Entwurf muss nicht vollständig vorliegen, wenn mit der Entwicklung begonnen wird. Es muss jedoch einen Gesamtüberblick geben und einen Detail-Entwurf jener Teile, die in die Entwicklung gehen.

Zusammenfassung und Ausblick

In diesem Artikel wurde der Überblick eines Modells für die IT-Analyse vorgestellt. Nach diesem Modell ist IT-Analyse „die Transformation von Anforderungen in einen Entwurf“.

Im nächsten Beitrag wird dieses Modell noch weiter im Detail dargestellt.

Quellen:
^[1] Graham Wallas: The Art of Thought

Weitere Artikel aus dieser Reihe:
IT-Analyse I – Wer braucht eigentlich IT-Analyse?

IT-Analyse II – Eine Bestandsaufnahme