IT-Analyse II – Eine Bestandsaufnahme

Darauf aufbauend wollen wir uns in diesem Artikel dem Wesenskern der IT-Analyse von verschiedenen Seiten nähern. Wir werden uns einerseits die zeitliche Komponente ansehen. Seit wann gibt es IT-Analyse? Und wie hat sich ihr Inhalt im Lauf der Zeit geändert? Andererseits wollen wir verschiedene moderne Ansätze über dieses Berufsbild betrachten. Worin unterscheiden sie sich? Wo liegen die jeweiligen Schwerpunkte?

Aus diesen Komponenten soll in weiterer Folge die Beschreibung eines praxistauglichen Berufsbilds der IT-Analyse entstehen.

IT-Analyse im Lauf der Zeit

Nicht nur im Bereich der IT-Analyse behaupten neue Ansätze von sich, dass sie etwas bieten, was es nie zuvor gab. Als Beispiel sei der Ansatz des „Digital Design“ erwähnt, von dem dessen Autoren sagen, dass die moderne Digitalisierung dieses – bisher nicht vorhandene – Berufsbild erforderlich macht. Stellen wir diese Aussagen auf den Prüfstand. Zu diesem Zweck blicken wir einmal fast 50 Jahre zurück.

Aus dem Jahr 1976 stammt das Buch „Systemanalyse“ von Hartmut Wedekind^[1]. Der sehr altmodisch anmutende Untertitel dieses Buches lautet „Die Entwicklung von Anwendungssystemen für Datenverarbeitungsanlagen“.

Hier wird folgender Prozess für den IT-Entwicklungsprozess vorgeschlagen:

1. Istanalyse
2. Zielsetzung, Sollkonzept und Rechtfertigung eines neuen Anwendungssystems
3. Systementwurf
4. Systemimplementierung
5. Systembetrieb.

Alle fünf Phasen dieses Modells gemeinsam werden als „Systemanalyse“ verstanden. Das Berufsbild, das dafür zuständig ist, wird „Systemanalytiker“ genannt. Wobei auch hier schon Arbeitsteilung zwischen Entwurf und Schreiben des Codes vorgesehen ist. Es gibt jedoch eine ganz andere Gewichtung als sie heute üblich ist. Die Systemanalyse geht sehr weit ins Detail; der Algorithmus wird so weit spezifiziert, dass „das Codieren ein einfacher Vorgang“ ist, den „oftmals Hilfskräfte verrichten können“^[2]. Entwicklung ist in dieser Betrachtungsweise das einfache Umsetzen des vom Systemanalytiker erstellten Entwurfs in Programmcode. Entsprechend detailliert muss der Entwurf sein.

Die Arbeitsteilung zwischen Analyse und Development ist also schon damals angelegt, wenn auch die Grenzen der Aufgaben anders verlaufen als heute.

Man hat auch im Jahr 1976 schon gesehen, dass die einzelnen Phasen im Software-Entwicklungsprozess nicht strikt – im Sinne eines Wasserfalls – voneinander getrennt werden dürfen: „Die Entwicklung eines Systems ist ein iterativer Prozess, in dem sehr viele Rücksprünge auf schon entwickelte Teile und deren Korrektur erforderlich sind“^[3].

Im Buch Wirtschaftsinformatik I von Hans Robert Hansen aus dem Jahr 1983 werden einzelne Berufsbilder beschrieben, darunter auch das des Systemanalytikers. Dessen Aufgaben werden unter anderem folgendermaßen zusammengefasst^[4]:

• Analyse des Istzustandes bestehender Systeme
• Entwicklung von Lösungsvorschlägen und von Sollkonzepten für neue Informationssysteme
• Entwurf der Ausgaben, Eingaben, Dateien und Verarbeitungsalgorithmen für neue Systeme.

Auch hier gibt es also ein Berufsbild, das sich auf den Entwurf und das Erstellen eines Sollkonzeptes spezialisiert – die Aufgaben der Systemanalyse sind von denen der Entwickler personell getrennt. In der Entwicklung wird außerdem noch zwischen „Anwendungsprogrammierer“ und „Systemprogrammierer“ unterschieden. Die Aufgaben der Anwendungsprogrammierer werden angegeben mit:

• Analyse zu programmierender, vorgegebener, anwendungsbezogener Aufgaben
• Entwicklung einer programmiertechnischen Lösung mit Leistungsspezifikationen wie Speicherbedarf, Maschinenzeit, usw.

Den beiden genannten Ansätzen ist gemeinsam, dass es mit der Systemanalyse ein Berufsbild gibt, das für den Entwurf eines IT-Systems zuständig ist. Der Unterschied zwischen beiden Ansätzen ist, dass der erste den Entwurf deutlich weiter gehend sieht, sodass dieser auch weit in den technischen Bereich hineinreicht, die Aufgabe der Entwicklung ist es nur noch, den Entwurf 1:1 in Code umzusetzen. Der zweite Ansatz beschränkt den Entwurf auf den fachlichen Bereich. Bei der Entwicklung bleibt die Expertise für die technischen Algorithmen und Strukturen.

IT-Analyse in aktuellen Ansätzen

Im Folgenden werden drei aktuelle Ansätze, die für die IT-Analyse relevant sind, beschrieben:

• Requirements Engineering
• Business Analyse
• Digital Design.

Requirements Engineering
Der Ansatz des Requirements Engineering stellt einen Begriff in den Vordergrund, der für die IT-Analyse von grundlegender Bedeutung ist: die Anforderung. Die Anforderung ist gewissermaßen Ausgangspunkt und Rohstoff für jede Software-Entwicklung. Es beschreibt das, was das entstehende System können muss. Große Bekanntheit und Verbreitung hat der Ansatz des Requirements Engineerings durch die Zertifizierungsprüfungen zum Certified Professional for Requirements Engineering (CPRE) des IREB (International Requirements Engineering Board) gefunden.

So hat die Berufsbezeichnung „Requirements Engineer“ die frühere Bezeichnung „Systemanalytiker“ nahezu vollständig abgelöst.

Requirements Engineering nach dem CPRE-Lehrplan des IREB kennt vier Haupttätigkeiten:

• Ermitteln von Anforderungen
• Dokumentieren von Anforderungen
• Prüfen/Abstimmen von Anforderungen
• Verwalten von Anforderungen.

Es ist das Verdienst des Requirements Engineering, den Begriff der „Anforderung“, der zuvor nur implizit im IT-Entwicklungsprozess präsent war, in den Fokus gerückt zu haben. Im Gegenzug ist jedoch in diesem Ansatz vom Entwurf des Systems, das in der Systemanalyse noch Hauptzweck der Tätigkeit war, nicht mehr die Rede. Es wird strikt zwischen Anforderung und Lösung entschieden. Wer aus den sauber dokumentierten Anforderungen des Requirements Engineering den Entwurf des Systems macht, bleibt offen. So war es zumindest bis zur Version 2 des Lehrplans.
Die Version 3 des CPRE-Lehrplans ^[5], die 2020 veröffentlicht wurde, behebt diesen Mangel zum Teil. Hier spielt die Lösung eine wesentlich größere Rolle, als es noch in der Version 2 der Fall war. So wird etwa im fünften Prinzip des Requirements Engineering anerkannt, dass die Begriffe, „Problem“, „Anforderung“, „Lösung“ untrennbar ineinander verwoben sind. Manche Anforderungen treten erst durch die Entwurfsentscheidung für eine bestimmte Lösung auf – andererseits kann eine von einem Stakeholder formulierte Anforderung bei der Entscheidung für eine bestimmte Lösungsalternative überhaupt keine Rolle mehr spielen.

Diese neue Sichtweise kommt auch im Prinzip 8 zum Ausdruck: „Gute Requirements Engineers gehen über das hinaus, was ihre Stakeholder Ihnen sagen“. Es kommt nicht nur auf das genaue Erheben der Anforderungen an, sondern auch um das kreative Finden von neuen – nicht geäußerten – Anforderungen.

Dennoch gibt es auch in der Version 3 nicht die Tätigkeit des Entwurfs in dem Sinne, dass die Anforderungen in ein Lösungskonzept transformiert werden. Es wird in der Begrifflichkeit nicht unterschieden, was ist „Anforderung“, die von einem Stakeholder kommt, und was ist eine Entwurfsentscheidung des Analytikers – in beiden Fällen wird von „Anforderung“ gesprochen.

Business Analyse
Ein weiterer Ansatz, der großen Einfluss auf das Berufsbild der IT-Analyse erlangt hat, ist die Business Analyse. Insbesondere als Job-Title für IT-Analysten hat „Business Analyst“ große Beliebtheit gewonnen – und wird häufig als Synonym für „Requirements Engineer“ verwendet.

Der Inhalt dieses Ansatzes wurde insbesondere vom „International Institute of Business Analysis“ (IIBA) und deren Publikation „A Guide to the Business Analysis Body of Knowledge“ (BABOK) geprägt ^[6]. Der BABOK unterteilt die Tätigkeiten eines Business Analysten in sechs so genannte Knowledge Areas:

1. Business Analysis Planning and Monitoring
2. Elicitation and Collaboration
3. Requirements Life Cycle Management
4. Strategy Analysis
5. Requirements Analysis and Design Definition
6. Solution Evaluation.

Business Analyse ist nicht auf den Bereich der IT beschränkt. Der BABOK definiert Business Analyse als „the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders“. Diese Definition ist sehr allgemein und ermöglicht so ein sehr weites Anwendungsfeld. Der Nachteil ist aber, dass die beschriebenen Vorgangsweisen und Methoden nicht auf die IT-Analyse zugeschnitten sind und so die Aussagen im BABOK häufig schwammig – „nicht Fisch und nicht Fleisch“ – sind.

Ähnlich wie das Requirements Engineering hat auch die Business Analyse die Anforderungen im Fokus. Die Tätigkeit des Entwerfens wird auch hier kaum beschrieben, auch wenn mit der Version 3 des BABOK erstmals der Begriff des Designs eingeführt wurde.

Digital Design
Digital Design ist ein Ansatz, der – wie das Requirements Engineering (RE) – im Umfeld des IREB entstanden ist – gewissermaßen als Reaktion auf die Anforderungs-Zentrierung im Requirements Engineering. Als Begründung dafür werden die neuen Herausforderungen der Digitalisierung angegeben. Tatsächlich ist es aber gleichsam eine Rückkehr zu den Anfängen der IT-Analyse, als auch schon der Entwurf (das Design) im Zentrum der Tätigkeit stand.

Der Inhalt des Digital Design ist ebenso wie das Requirements Engineering in einem Handbuch und einem Lehrplan zu einer Zertifizierungsprüfung festgelegt.^[7]

Digital Design sieht die erforderlichen Kompetenzen für einen Digital Designer in zwei Bereichen:

• Material-Kompetenz: Analog zum Bauwesen wird die zur Verfügung stehende digitale Technologie als „Material“ angesehen, das im Design gestaltet wird. Zu diesem Zweck muss der Designer dieses Material kennen.
• Design-Kompetenz: Um das digitale Material gestalten zu können, muss Know-How über den Design-Prozess vorhanden sein. Der Designer muss die Methoden und Techniken kennen, um ein Design erstellen zu können.

Es sind drei Schritte im Design-Prozess vorgesehen:

• Auftragsklärung: es soll beim Auftraggeber und unter allen relevanten Stakeholdern ein klares und gemeinsames Verständnis über den Auftrag erzielt werden.
• Konzeptarbeit: Ziel ist, unter allen relevanten Stakeholdern ein ausreichendes Verständnis der Lösung und des zugrundeliegenden technischen Systems zu erarbeiten. Auf Grundlage dieses Verständnisses kann entschieden werden, ob das Risiko einer Realisierung der Lösung eingegangen werden soll oder nicht.
• Entwicklung und Betrieb: Entwicklung und Betrieb werden im Digital Design als Einheit betrachtet, weil die Lösung laufend weiterentwickelt wird. Hier erfolgt der eigentliche Entwurf. Erst hier werden die Konzepte in einem Detailgrad ausgearbeitet, der die Realisierung der digitalen Lösung ermöglicht.

IT-Analyse – Grundsätze

Jeder der genannten Ansätze hat einen speziellen Fokus. Im Folgenden sollen die wesentlichen Punkte zusammengefasst werden:

• Die Basis jeder Software-Entwicklung sind Anforderungen
• Anforderungen können nicht unmittelbar in Software umgesetzt werden
• Im Entwurfsprozess werden die Anforderungen transformiert
• Ziel dieses Prozesses ist ein Entwurf, in dem die Anforderungen konsolidiert und Widersprüche aufgelöst werden und der in Software umgesetzt werden kann
• Ein Entwurf beschreibt Aufbau, Prozesse und Schnittstellen des IT-Systems
• Technische Entscheidungen, wie Auswahl der Programmiersprache, anderer Entwicklungswerkzeuge und deren Anwendung fallen nicht in den Kompetenzbereich der IT-Analyse.

Ausblick
In dieser Folge wurden verschiedene Ansätze zu Beschreibung des Berufsbildes IT-Analyse aus Gegenwart und Vergangenheit betrachtet. Auf dieser Basis und ergänzt um eigene langjährige Erfahrung wird im nächsten Artikel das Profil eines praxisnahen Berufsbilds der IT-Analyse beschrieben.

Quellen:
_[1]  Wedekind, Hartmut, Systemanalyse – Die Entwicklung von Anwendungssystemen für Datenverarbeitungsanlagen, München, Wien, 1976

^[2] Wedekind, Hartmut, a.a.O., S 265

^[3] Wedekind, Hartmut, a.a.O, S 17

^[4] Hansen, H.R., Wirtschaftsinformatik I, Stuttgart, 1983, S 277 f.

^[5] https://www.ireb.org/…

^[6] International Institute of Business Analysis, BABOK – A Guide to the Business Analysis Body of Knowledge, Toronto 2015

^[7] https://www.digitaldesign.org/…

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

IT-Analyse III – das Modell im Überblick