Wenn wir neu in ein Projekt kommen, dessen Ziel es ist, ein System zu entwickeln, ist eine unserer ersten Fragen: „Wer sind die Stakeholder des Systems?“. Da wird dann meist der Kunde oder Auftraggeber genannt und mit viel Glück auch noch die späteren Anwender. Das ist dann meist schon das Ende der Fahnenstange.
Stellen wir dann auch noch die seltsame Frage, wie sie denn diese Stakeholder ermittelt haben, dann werden wir meist mit großen Augen angesehen, in denen zu lesen steht: „Wie… die kann man ermitteln!?“
Ja. Kann man. Und sollte man auch.
Da Stakeholder neben Dokumenten und Systemen unsere Hauptquelle für Anforderungen sind, müssen wir sie [1] identifiziert haben, bevor wir Anforderungen ermitteln können. In dieser kleinen Blogserie wollen wir das Geheimnis lüften, wie man Stakeholder findet, indem man zielgerichtet nach ihnen sucht.
Heute befassen wir uns mit den drei Säulen [2], auf denen die Stakeholder-Ermittlung steht: Person, Rolle und Wissensgebiet.
Für jeden Stakeholder müssen wir wissen, wer er ist (also seinen Namen und seine Kontaktdaten), in welcher Rolle er für unser Projekt relevant ist (eine Person kann auch mehrere Rollen haben) und welches Wissen wir uns von dieser Person erwarten.
Über diese drei Säulen können wir uns systematisch der Ermittlung der Stakeholder und somit dem Befüllen der Stakeholdertabelle nähern. In den folgenden Teilen dieser Blogserie werden wir ein konkretes Vorgehen dafür vorstellen.
Teil 2: Am Anfang war der Stakeholder (Teil 2): Von bewussten, unbewussten und unterbewussten Stakeholdern
Teil 3: Am Anfang war der Stakeholder (Teil 3): Techniken zur Ermittlung bewusster Stakeholder
[1] Das soll allerdings nicht heißen, dass man *alle* Stakeholder ermittelt haben muss, um mit der Ermittlung von Anforderungen beginnen zu können.
[2] Angelehnt an Volere Stakeholder Template (http://www.volere.co.uk/templates.htm)
Liebe Frau Schwarz,
obwohl ich eigentlich gerne ihre Blogbeiträge lese, entnehme ich doch gleich mehrere Fehler in ihrem Diagramm. Überprüfen Sie doch bitte noch einmal ihre Multiplizitäten. Ein Detail….
Hallo Herr Gerke,
Sie haben Recht, die Wahl meiner Multiplizitäten bedarf einer Erklärung.
Ich vermute, Sie sehen die „Fehler“ bei den 0en und würden dort eher 1en erwarten?
Über die Richtigkeit von Multiplizitäten in Klassendiagrammen entscheidet vor allem die Perspektive. Aber genau die sollte klar sein. Und da gebe ich Ihnen Recht, dass die hier eingenommene Perspektive aus dem ersten Teil des Blogbeitrags noch nicht hervor geht.
Das hier gezeigte Begriffsmodell (Notation: Klassendiagramm der UML) zeigt die drei Säulen der Stakeholder-Ermittlung. Also quasi die Wissenslage während der Ermittlung der Stakeholder. Es zeigt NICHT die ermittelten Stakeholder. Deshalb ist die mittlere Klasse auch mit „Person“ und nicht mit „Stakeholder“ benannt.
Im Laufe der Stakeholder-Ermittlung können Personen „auftauchen“ (sie werden genannt, stehen in einem Dokument, etc.), denen zunächst oder auch im weiteren Verlauf keine Rolle und/oder kein Wissensgebiet zugeordnet werden kann.
Würde ich das Zielbild der ermittelten Stakeholder modellieren, so würde ich bei Rolle und Wissensgebiet die 0 jeweils durch eine 1 ersetzen. Gehen wir weiterhin davon aus, dass wir dann nur die für das betrachtete System relevanten Rollen und Wissensgebiete betrachten, würde ich auch die 0en bei Person durch 1en ersetzen. Und in diesem Fall würde ich auch die Klasse „Person“ durch die Klasse „Stakeholder“ ersetzen. Das wäre das favorisierte Ergebnis der Stakeholderermittlung, nämlich mindestens ein Stakeholer pro Rolle und Wissensgebiet und keine Rolle und kein Wissensgebiet ohne einen Stakeholder, der sie/es vertritt*.
Mit den weiteren Teilen dieser Blogserie wird die in diesem Beitrag gezeigte Perspektive sicherlich noch klarer.
Vielen Dank für Ihr Feedback und weiterhin viel Spaß beim Lesen!
Anja Schwarz
*Und wollte man ein Datenmodell erstellen, müsste man sich auch noch Gedanken darüber machen, ob und wie eine Rolle mit einem Wissensgebiet zusammen hängt. Aber hier geht es um ein fachliches Modell zur Stakeholder-Ermittlung, bei dem wir diesen Zusammenhang nicht weiter betrachten.