"Sobald der Geist auf ein Ziel gerichtet ist, kommt ihm vieles entgegen."
(Johann Wolfgang von Goethe)

Zweck und Tragweite (engl.: "Purpose & Scope")

Wenn Sie als Analytiker vom Kunden das Hauptziel bekommen haben, fragen Sie nach allen Leuten, die an der Definition dieses Hauptziels beteiligt waren. Es erscheint unglaublich, aber ich habe schon erlebt, dass acht(!) Leute aus verschiedenen Bereichen ein halbes Jahr für die Definition dieses einen Satzes gebraucht haben! Und es gab sowohl ein Altsystem als auch ein Fachkonzept! In einem solchen Fall sollten Sie auch alle Leute das gemeinsam gefundene Ziel unterschreiben lassen! Wenn Sie wissen, wer an der Suche nach dem Hauptziel beteiligt war, dann kennen Sie meistens auch schon die ersten "Interessensgruppen" und "Hauptakteure". Die Akteure (engl. "actors") des neu zu erstellenden softwareintensiven Systems sind die Unternehmensrollen (z.B. "Buchhalter"), die später direkt mit dem System arbeiten werden. Wenn Sie zu viele Akteure finden (mehr als 7), sollten Sie die Hauptakteure (die wichtigsten Akteure, engl. "main actors") bestimmen. Die Hauptakteure sind diejenigen Akteure, die das System für die wichtigsten, häufigsten und kritischsten Fälle anwenden. Die Interessensgruppen (engl. "stakeholders") bedienen das System nicht direkt, haben aber bestimmte Interessen daran, dass die Akteure dies tun. Die Interessensgruppe sind also eher das gehobene und mittlere Management oder bei einem Online-System die Chefs der Distributionsfirmen.

Wie es abgegrenzt wurde.

Sprechen Sie als Auftragnehmer selbst mit den bis dato ermittelten Interessensgruppen, Hauptakteuren und Akteuren und nehmen deren Hauptanforderungen auf, auch wenn Sie bereits ein Fachkonzept vorliegen haben. Ihr Ansprechpartner mag zunächst beleidigt sein, aber für Sie ist es ein Test, ob Ihr Ansprechpartner beim Erstellen des Fachkonzepts wirklich mit den Akteuren gesprochen hat, oder ob er aufgeschrieben hat, wie er meint, dass die Akteure doch eigentlich handeln müssten. Sie sehen, wie früh man Software bereits testen kann! Wenn Sie diesen Testaspekt mit Ihrem Ansprechpartner diskutieren und dabei Ihre Methodik erläutern, gewöhnen sich zum einen alle Beteiligten sehr früh ans Testen und zum anderen führen Sie damit einen offenen und fairen Arbeitsstil ein. Die Hauptanforderungen werden in der späteren Analyse weiter zerlegt und mit den hinterfragten Informationen aus dem Fachkonzept weiter gefüllt. Diese Reihenfolge ist meiner Erfahrung nach die bessere, weil dabei das Fachkonzept systematisch zerlegt und beurteilt wird. Als Ergebnis entsteht während der Analysephase ein neuer, sauber gegliederter, gleichmäßig gefüllter und objektiver Prosatext als Spezifikation.

Anhand der Diskussionen zur Findung des Hauptziels und anhand einer ersten Sichtung des Fachkonzepts und nicht zuletzt durch eine Gewichtung der gefundenen Hauptanforderungen der Akteure können Sie auch die Teilziele (Download einer Vorlage) für das System ermitteln. Ist es nicht erstaunlich, dass Goethe uns bei der Analyse von Softwareanforderungen hilft (s. Spruch oben)? Hier ein Beispiel: "Ermittlung von beleihungsfähigen Bewirtschaftungseinheiten als Objektvorschlag zur grundbuchlichen Darlehensabsicherung für die Banken. Dieses Teilziel ist erreicht, wenn eine Ermittlung von Bewirtschaftungseinheiten auf Basis aller Darlehenszuordnungen softwaregestützt möglich ist." Wie alle Ziele sollten auch die Teilziele SMART sein. Zur besseren Messbarkeit kann natürlich, wie bei diesem Beispiel, ein Akzeptanzkriterium hinzugefügt werden.

Auch hier gibt es natürlich kein Patentrezept, denn wenn der Gegenstand Ihres Projekts die zentrale Abrechnungssoftware der RWE-Stromgesellschaft ist und in Form von vielen Ordnern vorliegt, müssen Sie wahrscheinlich anders vorgehen. Aber dann werden Sie die Vorgehensweise zu diesem Zeitpunkt auch nicht frei wählen können. Vielmehr ist die anzuwendende Systematik vorher mit vielen Beratern und erfahrenen Entwicklern zum Projekt passend festgelegt worden.

Beschreiben Sie mit den Hauptanforderungen was das System leisten soll, noch nicht wie es das tun soll, denn das System selbst ist in diesem Stadium noch eine Unbekannte (engl. "Black Box"). Ferner sollten Sie hier keinesfalls in Details gehen, weil Sie vieles davon später ohnehin wieder verwerfen werden. Es geht in der Pre-Analyse-Phase darum, die Hauptanforderungen als Teilziele zu identifizieren, dem Ansprechpartner sowie den Interessensgruppen und Hauptakteuren systematisch den Projektumfang und Gesamtaufwand zur Prüfung auf zeitliche und finanzielle Machbarkeit zu reflektieren. Kaufmännisch geht es für Sie als Auftragnehmer natürlich auch darum, so viel Vertrauen aufzubauen und Kompetenz zu beweisen (nicht vorzuspielen, sondern zu beweisen!), dass Sie die folgende Anforderungsanalyse beauftragt bekommen. Und nicht zuletzt ist es für beide Seiten mit nur sehr geringem finanziellen und unternehmerischen Risiko die Möglichkeit, sich gegenseitig zu beschnuppern und die Chemie zu prüfen.

Spätestens jetzt wird allen Beteiligten deutlich, wofür das zu erstellende Software-System eigentlich gut ist ("Zweck") und wen es alles betrifft ("Tragweite"). Und dies können Sie anhand eines Diagramms halt am besten diskutieren. Im weiteren Verlauf dieses Kapitels werden Sie noch sehen, wie und warum ich Prosatext ergänze und wie ich dieses Diagramm "verkaufe". Im Folgenden noch weitere Beispiele für Zweck- und Tragweiten-Diagramme aus verschiedenen Teams und mit verschiedenen Tools erstellt (teilweise auf Kundenwunsch "neutralisiert"):

Dieses Verfahren zum Aufnehmen von Hauptanforderungen kann natürlich nicht nur für die Erstellung von softwareintensiven Systemen genutzt werden: wer sind wohl die Hauptakteure von folgendem kleinen Netzwerk und welche Hauptanforderungen wurden bzw. werden wohl an dieses Netzwerk gestellt?