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:
- Istanalyse
- Zielsetzung, Sollkonzept und Rechtfertigung eines neuen Anwendungssystems
- Systementwurf
- Systemimplementierung
- Systembetrieb.
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.
- Analyse zu programmierender, vorgegebener, anwendungsbezogener Aufgaben
- Entwicklung einer programmiertechnischen Lösung mit Leistungsspezifikationen wie Speicherbedarf, Maschinenzeit, usw.
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.
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.
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:
- Business Analysis Planning and Monitoring
- Elicitation and Collaboration
- Requirements Life Cycle Management
- Strategy Analysis
- Requirements Analysis and Design Definition
- Solution Evaluation.
Ä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.
- 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.
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.
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