Zusammenfassung
Zusammenfassung
Strukturierung der Anforderungen in Kategorien
In der modernen Geschäftswelt ist die Ablösung und Integration von IT-Systemen ein kritischer Prozess. Bei einer Systemablösung ist eine gut durchdachte Schnittstellenanalyse unerlässlich, um sicherzustellen, dass alle Anforderungen erfüllt werden. Der folgende Artikel bietet eine Übersicht über den Prozess der Schnittstellenanalyse für eine Systemablösung.
Der erste Schritt besteht meist darin, eine vom Kunden bereitgestellte Anforderungsliste zu sichten. Diese Liste enthält eine grobe Zusammenfassung der Wünsche des Kunden bezüglich der neuen Software und muss deshalb sorgfältig nach ihrer Bedeutung eingeordnet werden. Die Anforderungsliste bildet die Grundlage für den anschließenden Analyseprozess.
Sobald die Liste vorliegt (1), werden alle Anforderungen in verschiedene Kategorien geordnet (2). Diese Kategorisierung hilft, den Überblick zu behalten und die Anforderungen systematisch zu bearbeiten. Anschließend werden die Anforderungen sortiert, sodass alle Elemente derselben Kategorie zusammenstehen (3). Dies erleichtert es, ähnliche oder doppelte Anforderungen zu erkennen und diese zu konsolidieren oder zu entfernen.
Abbildung 1
Abbildung 2
Abbildung 3
Strukturierung der Anforderungen in Kategorien
In der modernen Geschäftswelt ist die Ablösung und Integration von IT-Systemen ein kritischer Prozess. Bei einer Systemablösung ist eine gut durchdachte Schnittstellenanalyse unerlässlich, um sicherzustellen, dass alle Anforderungen erfüllt werden. Der folgende Artikel bietet eine Übersicht über den Prozess der Schnittstellenanalyse für eine Systemablösung.
Der erste Schritt besteht meist darin, eine vom Kunden bereitgestellte Anforderungsliste zu sichten. Diese Liste enthält eine grobe Zusammenfassung der Wünsche des Kunden bezüglich der neuen Software und muss deshalb sorgfältig nach ihrer Bedeutung eingeordnet werden. Die Anforderungsliste bildet die Grundlage für den anschließenden Analyseprozess.
Sobald die Liste vorliegt (1), werden alle Anforderungen in verschiedene Kategorien geordnet (2). Diese Kategorisierung hilft, den Überblick zu behalten und die Anforderungen systematisch zu bearbeiten. Anschließend werden die Anforderungen sortiert, sodass alle Elemente derselben Kategorie zusammenstehen (3). Dies erleichtert es, ähnliche oder doppelte Anforderungen zu erkennen und diese zu konsolidieren oder zu entfernen.
Abbildung 1
Abbildung 2
Abbildung 3
Entwicklung der Use Cases anhand der Anforderungen
Sobald die Kategorisierung abgeschlossen ist, können auf dieser Basis mithilfe der Anforderungen spezifische Use Cases geschrieben und definiert werden (4). Diese Use Cases beschreiben im Detail, wie das neue System funktionieren soll und welche Anforderungen es erfüllen muss. In diesem Schritt werden die jeweiligen Use Cases gründlich mit den Fachbereichen analysiert, um die Anforderungen auf Vollständigkeit zu prüfen und mit Akzeptanzkriterien zu ergänzen. Dabei werden auch Überschneidungen, logische Lücken und andere kritische Punkte identifiziert.
Abbildung 4
Damit gewährleistet ist, dass die Use Cases realistisch und durchführbar sind, können abschließend Plausibilisierungsworkshops durchgeführt werden. In diesen Workshops werden die Anforderungen und Akzeptanzkriterien überprüft, gegebenenfalls angepasst oder, wenn nötig, gestrichen.
Entwicklung der Use Cases anhand der Anforderungen
Sobald die Kategorisierung abgeschlossen ist, können auf dieser Basis mithilfe der Anforderungen spezifische Use Cases geschrieben und definiert werden (4). Diese Use Cases beschreiben im Detail, wie das neue System funktionieren soll und welche Anforderungen es erfüllen muss. In diesem Schritt werden die jeweiligen Use Cases gründlich mit den Fachbereichen analysiert, um die Anforderungen auf Vollständigkeit zu prüfen und mit Akzeptanzkriterien zu ergänzen. Dabei werden auch Überschneidungen, logische Lücken und andere kritische Punkte identifiziert.
Abbildung 4
Damit gewährleistet ist, dass die Use Cases realistisch und durchführbar sind, können abschließend Plausibilisierungsworkshops durchgeführt werden. In diesen Workshops werden die Anforderungen und Akzeptanzkriterien überprüft, gegebenenfalls angepasst oder, wenn nötig, gestrichen.
Ableitung der Geschäftsobjekte aus den Use Cases
Nach der Plausibilisierung werden die Use Cases hinsichtlich der dazugehörigen Geschäftsobjekte (d.h. der für den Use Case benötigten Daten) analysiert. Diese Geschäftsobjekte werden dokumentiert und den jeweiligen Use Cases zugeordnet (5)
Abbildung 5
In Schnittstellenworkshops werden die identifizierten Geschäftsobjekte weiter beschrieben und deren Herkunft zugewiesen. Dabei spielt beispielsweise die „Golden Source“ – also das System, das die Daten bereitstellt – eine wichtige Rolle. Es muss klar definiert werden, ob die Geschäftsobjekte von anderen Systemen oder Applikationen bereitgestellt werden und welche Geschäftsobjekte vom neuen System abgebildet werden. Sobald alle Geschäftsobjekte einem systemischen Ursprung oder einem Quellsystem zugewiesen sind, können die Schnittstellen und deren Architektur besprochen werden (6). Dabei werden Fragen wie: „Wann werden welche Daten, wie oft, in welchem Format und über welches Protokoll von der Applikation A in meine neue Software geladen?“ gestellt und beantwortet.
Abbildung 6
Da es viele Punkte zu berücksichtigen gibt, habe ich die wichtigsten in der folgenden Übersicht dargestellt:
Die oben beschriebene Vorgehensweise wird auf alle relevanten Use Cases angewendet und in ein Abschlussdokument überführt. Dieses Dokument wird kontinuierlich mit den Stakeholdern abgestimmt, vervollständigt und schließlich übergeben.
Ich hoffe, dieser Einblick in die Schnittstellenanalyse bei einer Systemablösung war hilfreich für euch. Wenn ihr Fragen habt oder mehr über konkrete Inhalte erfahren möchtet, lasst es mich bitte wissen! Nutzt dafür den unten angegebenen Kontaktbereich.
Ableitung der Geschäftsobjekte aus den Use Cases
Nach der Plausibilisierung werden die Use Cases hinsichtlich der dazugehörigen Geschäftsobjekte (d.h. der für den Use Case benötigten Daten) analysiert. Diese Geschäftsobjekte werden dokumentiert und den jeweiligen Use Cases zugeordnet (5)
Abbildung 5
In Schnittstellenworkshops werden die identifizierten Geschäftsobjekte weiter beschrieben und deren Herkunft zugewiesen. Dabei spielt beispielsweise die „Golden Source“ – also das System, das die Daten bereitstellt – eine wichtige Rolle. Es muss klar definiert werden, ob die Geschäftsobjekte von anderen Systemen oder Applikationen bereitgestellt werden und welche Geschäftsobjekte vom neuen System abgebildet werden. Sobald alle Geschäftsobjekte einem systemischen Ursprung oder einem Quellsystem zugewiesen sind, können die Schnittstellen und deren Architektur besprochen werden (6). Dabei werden Fragen wie: „Wann werden welche Daten, wie oft, in welchem Format und über welches Protokoll von der Applikation A in meine neue Software geladen?“ gestellt und beantwortet.
Abbildung 6
Da es viele Punkte zu berücksichtigen gibt, habe ich die wichtigsten in der folgenden Übersicht dargestellt:
Die oben beschriebene Vorgehensweise wird auf alle relevanten Use Cases angewendet und in ein Abschlussdokument überführt. Dieses Dokument wird kontinuierlich mit den Stakeholdern abgestimmt, vervollständigt und schließlich übergeben.
Ich hoffe, dieser Einblick in die Schnittstellenanalyse bei einer Systemablösung war hilfreich für euch. Wenn ihr Fragen habt oder mehr über konkrete Inhalte erfahren möchtet, lasst es mich bitte wissen! Nutzt dafür den unten angegebenen Kontaktbereich.
