Kapitel 1: Systemanalyse, gestern – heute – morgen

Systemanalyse - gestern, heute, morgen

(in dem wir die Entwicklung der Systemanalyse in den letzten Jahren und Jahrzehnten besprechen und andeuten, wie der nächste Entwicklungsschritt aussehen könnte)

Business Architect, Projektmanager, Systemanalytiker, Systems-Engineer, Tester, Business Analyst, Software Architect, Requirements Engineer, Software-Entwickler, ...

Groß ist die Zahl der Berufsbezeichnungen und der Job-Titles in der IT. Und es ist nicht immer klar, welche Aufgabe mit der jeweiligen Bezeichnung verbunden ist. Übersichtlicher wird die Lage, wenn man die Tätigkeitsbereiche in drei Gruppen einteilt [HRUSCHKA2014]:

1. Das Team zum Ziel führen: das ist das Gebiet des Projektmanagements. Die Aufgabe in diesem Bereich liegt in der Zeit-, Kosten- und Terminplanung und im Setzen von geeigneten Maßnahmen zur Zielerreichung.
2. Das Problem verstehen und Lösungen entwerfen: in diesem Tätigkeitsbereich wird die Aufgabenstellung analysiert und auf Basis dieser Analyse werden Lösungen vorgeschlagen und konzipiert.
3. Lösungen mit einer gewählten Technologie implementieren: dabei handelt es sich um das weite Feld der Software-Entwicklung, das auch die Auswahl und die Integration der Technologien beinhaltet.

Jedes der oben genannten Berufsbilder lässt sich einem dieser Bereiche zuordnen, im einen oder anderen Fall gibt es vielleicht auch Überschneidungen.

In dieser Blog-Serie soll der zweite der genannten Bereiche behandelt werden, dessen Aufgabe es ist, die Aufgabenstellung unabhängig von den technischen Implementierungsdetails zu analysieren, die Anforderungen an eine Lösung zu erheben und auf dieser Grundlage eine oder auch mehrere Lösungen zu entwerfen und zur Umsetzung zu bringen.

Gerade dieses Gebiet hat in den letzten Jahren und Jahrzehnten eine gewaltige Entwicklung erlebt. Es handelt sich keineswegs um eine neue Disziplin. Auch der grundsätzliche Inhalt - das Konzipieren von Lösungen - hat sich seit den 60er-Jahren kaum geändert. Was sich jedoch geändert hat, sind die zur Verfügung stehenden Methoden und Techniken. Darüber hinaus haben auch verschiedene Standardisierungsbestrebungen zur Entwicklung dieses Fachbereiches beigetragen.

Lange Zeit war die Tätigkeit der Analyse und der Konzeption von Software-Lösungen als Systemanalyse bekannt. Dieser Begriff wurde in den letzten Jahren von zwei anderen Bezeichnungen weitgehend abgelöst: Requirements Engineering und Business Analyse. Dabei geht es aber nicht nur um eine neue Bezeichnung für den gleichen Inhalt, sondern es kam auch zu einer Verschiebung der Schwerpunkte innerhalb des Berufsbildes des Systemanalytikers.

Die Aufspaltung der ursprünglichen "Systemanalyse" geht zurück auf die frühen 2000er-Jahre. Damals erlebten die Standardisierungsbestrebungen auf dem Gebiet des Projektmanagements einen Boom. Organisationen wie das PMI (Project Management Institute) schufen Standards und boten den Projektmanagern die Möglichkeit, sich auf diese Standards zertifizieren zu lassen. Diese Zertifikate wurden auch zunehmend von Arbeitgebern und im Rahmen von Ausschreibungen nachgefragt. Auf dem Gebiet der Systemanalyse gab es Derartiges nicht.

Diese Situation wurde von vielen Systemanalytikern als unbefriedigend empfunden. So taten sich nahezu gleichzeitig an verschiedenen Orten der Welt Menschen zusammen, um dem Abhilfe zu verschaffen. Im Jahr 2003 wurde in Toronto, Kanada, das International Institute of Business Analysis (IIBA) gegründet. Diese Organisation setzte es sich zur Aufgabe, das Berufsbild der Business Analyse - so nannte man dort die bisherige Systemanalyse - zu etablieren und einen Standard dafür zu schaffen. Das Instrument für Letzteres ist die Herausgabe des so genannten "Business Analysis Body of Knowledge" (BABOK-Guide), der sich mittlerweile zu einem Standardwerk der Business Analyse entwickelt hat und im April 2015 in seiner dritten Version erschienen ist.

In etwa zeitgleich mit dem IIBA wurde in Deutschland das International Requirements Engineering Board (IREB) gegründet, das eine ähnliche Zielsetzung wie das IIBA erfolgt. Wie das IIBA bietet auch das IREB Zertifizierungen für Systemanalytiker an. Hier wird die Disziplin der Systemanalyse nun Requirements Engineering genannt.

Obwohl also sowohl die Business Analyse als auch das Requirements Engineering ähnliche Wurzeln haben, gibt es doch auch Unterschiede in den Schwerpunktsetzungen, die sich auch in den (neuen) Namen ausdrücken: Während Business Analyse den Fokus auf die fachliche ("Business") Analyse legt und auch über den Bereich der IT hinausgeht, liegt ein deutlicher Schwerpunkt des Requirements Engineering in der System-Modellierung. Dadurch hab das Requirements Engineering einen viel deutlicheren IT-Bezug als Business Analyse.

Eine besondere Herausforderung für die Disziplin der Systemanalyse ist der aktuelle Mega-Trend auf dem Gebiet der Software-Entwicklung: die agile Vorgehensweise. Die ursprüngliche Idee dieser Methoden sollte Analyse-Tätigkeit überhaupt weitgehend überflüssig machen. Mittlerweile hat man erkannt, dass es ganz ohne diese doch nicht geht. Aber dennoch hat dieses geänderte Paradigma wesentliche Auswirkungen auf die Tätigkeit des Systemanalytikers.

Ein weiterer Aspekt, der hier besondere Berücksichtigung finden soll, ist jener der Kreativität. Sehr oft wird der Prozess der Systemanalyse als ein fast mechanischer betrachtet, wo kein Raum für Kreativität vorhanden ist - ja auch gar nicht benötigt wird. Tatsächlich ist jedoch das Finden der Lösung im Rahmen der Systemanalyse ein bedeutender Schritt, ja das eigentliche Ziel der Arbeit des Analytikers, und ist keineswegs mit der Erhebung und Dokumentation der Anforderungen erledigt.

Das ist nun der Hintergrund hinter dem Konzept der Systemanalyse 3.0.

Es soll ein Ansatz dargestellt werden, der folgende Aspekte in sich vereinigt:

• Die klassische Systemanalyse
• Business Analyse
• Requirements Engineering
• Agile Software-Entwicklung
• Kreativität.

Wir nennen diesen Ansatz "Systemanalyse 3.0". Warum sprechen wir gerade von der dritten Version der Systemanalyse?

Die Version 1 war das Vorgehen der klassischen Systemanalyse. Diese wurde von den Konzepten der Business Analyse und des Requirements Engineering abgelöst.

Mit der hier vorgestellten Version 3 sollen die verschiedenen Richtungen wieder zu einem einheitlichen Konzept zusammengeführt werden. Dieses einheitliche Konzept soll zusätzlich um die Ideen der agilen Software-Entwicklung und der Kreativitätstheorien erweitert werden.

Der nächste Artikel wird beschreiben, was Systemanalyse 3.0 ist und wie wir sie definieren wollen.

Zum folgenden Artikel der Reihe