Wie findet eine Bedarfsanalyse bei Informationssystemen statt?

Betrachtet man obige Ausführungen, so wird rasch deutlich, dass Software-Entwicklung bei größerem Umfang ein Projekt ist. Es handelt sich meist um etwas Neuartiges, die Entwicklung (einer bestimmten Version) ist mit Zeit und Kosten begrenzt, die Ressourcen sind eingeschränkt verfügbar – typische Faktoren für ein Projekt. Somit ist es auch nur logisch, dass Software-Entwicklung neben anderen Tätigkeiten wie Testmanagement oder Qualitätsmanagement auch ein angemessenes und begleitendes Projektmanagement benötigt.

Die genaue Abgrenzung des Projektbegriffs ist nicht immer eindeutig. Wir definieren hier das eigentliche Projekt vom Erhalt eines Auftrags zur Projektdurchführung bis hin zur Abnahme und Übergabe eines fertigen Produkts:

Dem eigentlichen Projekt geht immer voraus, dass von einem Auftraggeber eine Entscheidung getroffen wird, ein Projekt durchzuführen. Ist der Auftraggeber extern, so gibt es meist eine Anfrage (z.B. in Form einer Ausschreibung). Daraufhin legen potentielle (und eingeladene) Bieter entsprechende Angebote, von denen eines (in Sonderfällen auch keines) einen Zuschlag erhält, was zu einer Auftragserteilung und damit in Folge zu einem (externen) Projekt führt.

Ist der Auftraggeber intern, so kann es zu einem Projekt kommen, wenn es eine Projektidee oder eine Notwendigkeit, z.B. aus einer strategischen Planung oder durch eine Gesetzesänderung, gibt. Oft folgt darauf eine Vorprojektphase, in der – speziell bei unbekannten Technologien etc. – die Machbarkeit der Projektidee überprüft und ein Kostenrahmen geschätzt wird. Fällt die Entscheidung positiv aus, kommt es zum (internen) Projekt.

Ab diesem Punkt – nämlich dem Erhalt des Auftrags zur Durchführung des Projekts – beginnt das Projekt offiziell zu laufen. Das bedeutet nicht zwangsläufig, dass nicht Teile der (künftig geplanten) Projektorganisation nicht auch schon in Vorphasen involviert waren – beispielsweise wird ein Projektmanager seine Expertise in die Planung und Kalkulation bei der Angebotslegung oder bei der Vorprojektphase einbringen. Ebenso ist es möglich, dass bei komplexen Vorstudien oder bei umfangreichen Angeboten diese selbst als eigenes Projekt aufgesetzt und durchgeführt werden.

Die Bedarfsanalyse und der sich daraus ergebende Projektauftrag sind wesentliche Voraussetzungen für die Abwicklung der Planung und der Entwicklung von Informationssystemen. Schließlich münden die Ergebnisse der Bedarfsanalyse in konkrete, umzusetzende Ziele und geben einen Zeit- und Kostenrahmen für die Projektumsetzung vor.

In obiger Abbildung des Software-Lebenszyklus stehen die Themen Problemanalyse, Ideen und Vorstudien zu Beginn jeglicher Entwicklung. Diese Themen werden jedoch nicht nur einmalig zu Beginn eines neuen Projekts relevant sein, sondern auch dann, wenn sich „von außen“ neue Herausforderungen ergeben und diese beispielsweise wieder in einer Durchführbarkeitsstudie auf Umsetzungsmöglichkeit überprüft werden. Gleichzeitig werden in den meisten Fällen laufend neue Anforderungen durch zusätzliche Ideen und Wünsche von Benutzern sowie Rückmeldungen für Fehlerbehebungen eintreffen.

Die Bedarfsanalyse ist somit auch eng mit dem Change Management verbunden – auch bei Änderungswünschen müssen Machbarkeit, Zeit und Kosten definiert werden und es muss eine Entscheidung zur Umsetzung getroffen werden. 

Welche Phasen hat eine Business Analyse?

Betrachtet man die Phase der Bedarfsanalyse aus Sicht der Business Analyse, so sind mehrere Schritte zu durchlaufen:

Ergebnis einer Business Analyse sind somit ein oder mehrere Lösungsvorschläge, welche stark am Unternehmensnutzen ausgerichtet sind, die Anforderungen der Unternehmensvorgaben und der betroffenen Stakeholder berücksichtigen und unter anderem auch einen Zeit- und Kostenrahmen beinhalten.

Wichtig bei der Bedarfsanalyse ist es auch, möglichst alle Stakeholder (also alle vom Projekt betroffenen Personen und Organisationen) in die Analyse einzubinden, da nur dann ein Erfolg eines Projekts sichergestellt werden kann. Werden wichtige Stakeholder und deren Wünsche und Anforderungen nicht berücksichtigt, ist wahrscheinlich die Akzeptanz einer Lösung gering oder wird nicht selten sogar boykottiert. Das richtige und angemessene Stakeholder-Management ist somit auch ein wesentlicher Aspekt jedes Projekts.

Was ist der Systemkontext in der Anforderungsanalyse?

Eine der ersten und wesentlichen Aufgaben innerhalb der Bedarfs- und Anforderungsanalyse ist die Abgrenzung bzw. Festlegung des Systemkontexts. Dieser wird definiert als „jener Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen an das betrachtete System relevant ist“. 

Das ist insofern einleuchtend, weil ja der Ursprung aller Anforderungen an ein System in dessen Umgebung liegt. In diesem Sinne zählen sowohl Personen (Stakeholder oder Stakeholdergruppen), fremde Systeme (andere technische Systeme), Prozesse (technische und physikalische Prozesse) als auch Dokumente (Gesetze, Standards etc.) dazu.

Wird der Systemkontext im Rahmen der Bedarfsanalyse inkorrekt oder unvollständig berücksichtigt, hat dies unvollständige oder fehlerhafte Anforderungen zur Folge. Dies führt dazu, dass das entwickelte System auf der Grundlage unvollständiger oder fehlerhafter Annahmen arbeitet, was eine häufige Ursache für Systemversagen im Betrieb ist. Solche Fehler bleiben bei der Überprüfung, ob das entwickelte System den spezifizierten Anforderungen genügt, häufig unentdeckt und treten erst später im Betrieb des Systems auf, und das mit teilweise katastrophalen Konsequenzen (nach (Pohl & Rupp, 2011)).

Die Systemabgrenzung dient zur Festlegen der Systemgrenze. Sie legt die Aspekte fest, welche durch das (zu entwickelnde) System bzw. durch die Umgebung erbracht werden. Die Systemgrenze „separiert das geplante System von seiner Umgebung. Sie grenzt den im Rahmen des Entwicklungsprozesses gestaltbaren und veränderbaren Teil der Realität von Aspekten in der Umgebung ab, die durch den Entwicklungsprozess nicht verändert werden können“ (Pohl & Rupp, 2011).

Die Kontextabgrenzung stellt die Abgrenzung des Systemkontexts von der irrelevanten Umgebung dar. Die Kontextgrenze „separiert den relevanten Teil der Umgebung eines geplanten Systems vom irrelevanten Teil, d.h. dem Teil der Umgebung, der keinen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen des Systems hat“ (Pohl & Rupp, 2011).

Die Anforderungsphase ist besonders wichtig in der Entwicklung von Software

Ein wesentlicher Teil der Zeit wird – besser gesagt sollte – für die Analysephase aufgewendet (werden). In dieser Phase werden die meisten Fehler mit teils immenser Auswirkung auf Qualität, Zeit und Kosten verursacht, während Fehler in der Testphase „nur mehr“ gefunden werden können. Folgende Bilder sollen das verdeutlichen:

Die Entwicklungsphase lässt sich in vier grobe Teile unterteilen – Analyse/Anforderungen, Entwurf/Design, Implementierung und Test. In jeder dieser Phasen kann alles richtig gemacht werden oder es entstehen Fehler durch Missverständnisse, fehlerhafte Umsetzung oder durch Unvollständigkeit etc.

Die einzige Möglichkeit, zu einem „fehlerfreien“ Produkt zu kommen ist es, in allen Phasen alles richtig zu machen:

Anmerkung: Es ist nach derzeitigem Stand der Technik nicht möglich, ein zu 100% fehlerfreies Software-Produkt zu entwickeln, deshalb oben „fehlerfrei“ unter Anführungszeichen.

Werden nun Fehler nur in der Testphase gemacht, führt dies zu einem zumindest scheinbar fehlerhaften Produkt:

Die Korrektur ist vergleichsweise einfach – es müssen nur jene Tests wiederholt werden, die fehlerhaft durchgeführt wurden oder fehlerhafte Ergebnisse geliefert haben.

Fehler in der Implementierungsphase führen hingegen bereits unweigerlich zu einem fehlerhaften Produkt, unabhängig davon, ob in der nachfolgenden Testphase alles richtig gemacht wird oder vielleicht dort auch Fehler entstehen:

Konsequenz ist: Wiederholung der fehlerhaften Entwicklungsschritte plus notwendiger, unter Umständen aller zugehörigen, Tests.

Dramatisch werden Fehler in der Anforderungsphase. Wird hier etwas falsch verstanden oder sind nicht alle Anforderungen bekannt führt dies mit Sicherheit zu einem unbrauchbaren Produkt:

Konsequenz ist: Zurück an den Start und nochmaliges Durchlaufen des teilweisen oder vollständigen Entwicklungszyklusses – beispielsweise können übersehene Anforderungen Einfluss auf das Design des Systems haben, wodurch sich umfangreiche Änderungen ergeben können.

Die obige Darstellung zeigt zwei Dinge:

• Es ist essentiell wichtig, von Beginn an alles möglichst richtig zu machen. Auch in der heutigen Zeit hat sich diese Erkenntnis noch nicht vollständig durchgesetzt und führt dazu, dass die Phasen der Analyse, der Anforderungen und des Designs mit den daraus resultierenden Konsequenzen oft vernachlässigt werden. Requirements Engineering und Business Analyse sind in den letzten Jahren zu zwei eigenständigen Disziplinen herangewachsen, um diesen Problemen zu begegnen
• Die Kosten für Fehlerbehebungen steigen exponentiell an – je später ein Fehler entdeckt wird, desto teurer wird dessen Behebung. Man spricht von 100- bis 1000-fachen Kosten, wenn beispielsweise Fehler erst nach der Auslieferung anstelle in der Analysephase entdeckt werden

Gleichzeitig ist es nicht wirtschaftlich, beliebig viel Aufwand in die Analyse- und Anforderungsphase zu stecken, da – ähnlich wie in der Testphase – ab einem gewissen Punkt der Nutzen nur mehr marginal im Vergleich zum Aufwand steigt:

Software Engineering strebt daher nach dem Kostenminimum. Dabei müssen auch Folgekosten und Risiken berücksichtigt werden, was beispielsweise wie folgt aussehen kann:

Die Wartung – Korrektur, Anpassung und Erweiterung eines Systems – kostet über die gesamte Lebensdauer betrachtet oft mehr als die Entwicklung; es können durchaus mehr als zwei Drittel des Gesamtaufwands in die Wartung gehen.

Pflege (auch Wartung, engl.: Maintenance) kann definiert werden als Modifikation und/oder Ergänzung bestehender Software durch neue Software mit dem Ziel, Fehler zu beheben, die bestehende Software an veränderte Bedürfnisse oder Umweltbedingungen anzupassen oder die bestehende Software um neue Fähigkeiten zu erweitern.

Es handelt sich somit um eine systematische Erhaltung der Gebrauchstauglichkeit von Programmen nicht nur zur Fehlerbehebung und somit um einen kontinuierlichen Prozess mit folgenden Teilaufgaben:

• Erfassung der Kundenbedürfnisse:
  • reaktiv: als Problemmeldewesen
  • pro aktiv: wohin geht die Reise (Märkte, Umwelt, Konkurrenz,…)
• Analyse der Kundenbedürfnisse
• Planung der Pflegearbeiten, Bildung von Arbeitspaketen (Releases)
• Durchführung der anstehenden Arbeitspakete
• Auslieferung der Ergebnisse
• Verwaltung der Artefakte (Problemmeldungen, Arbeitspakete, Lieferungen usw. mittels Konfigurationsverwaltung)

Besonders sei darauf hingewiesen, dass die Phasen der Analyse und Zielbestimmung, der Erhebung und Verwaltung von Anforderungen, des Projekt- und Qualitätsmanagements sowie der Tests und der Installation und Schulungen auch dann notwendig sind, wenn Software gekauft wird, also keine eigene Entwicklung durchgeführt wird.