Haben Sie sich eigentlich schon mal gefragt, ob der Blog der SOPHISTen auch noch da ist, wenn keiner, also wirklich gar keiner gerade in unserem Blogeinträgen stöbert? Nachts 3:45 Uhr zum Beispiel (falls Sie uns jetzt widersprechen möchten und zugeben, dass Sie auch zu etwas ungewöhnlichen Zeiten in unseren Blogeinträgen schmökern – geben Sie es gern zu).

Ein Konstruktivist würde diese Frage stellen: Was passiert mit Dingen, wenn sie unbeobachtet sind? Es handelt sich ja nur um Konstruktionen. Eine Antwort darauf kann der Konstruktivist nicht geben, denn sobald er etwas Unbeobachtetes beobachten will… Sie merken es – die Spielregeln wären verletzt. Beobachten geht nicht ohne einen Beobachter[1].

Ich sehe was, was du nicht siehst, oder doch?[2]

Im ersten Teil der Blogserie über Requirements-Engineering und Konstruktivismus haben wir ausgewählte Beispiele aus dem Arbeitsalltag eines Requirements-Engineers unter Berücksichtigung des Konstruktivismus vorgestellt. Der zweite Blogeintrag wird konkreter: Hat der Konstruktivismus Einfluss auf die Ermittlungstechniken im Requirements-Engineering? Ja, hat er wie Sie in den folgenden Zeilen erfahren werden.

Ein REler – Ein Stakeholder
Verschiedene Ermittlungstechniken bieten dem Requirements-Engineer verschiedene Möglichkeiten, mit der Tatsache umzugehen, dass ein Stakeholder Anforderungen konstruiert.

Konstruktion abholen: Will der Requirements-Engineer möglichst die „ursprüngliche“ Konstruktion eines Stakeholders bekommen, kann der den Stakeholder einfach erzählen lassen. Nachfragen oder die eigene Meinung muss der Requirements-Engineer zurückhalten, da er sonst die Konstruktion des Stakeholders beeinflussen würde. Ähnlich verhält es sich mit einem Interview mit offenen Fragen. Auch so bekommt der Stakeholder die Möglichkeit, ohne weiteren Einfluss dem Requirements-Engineer seine Anforderungen mitzuteilen.

Eigene Konstruktion reflektieren lassen: Ist ein Requirements-Engineer schon länger an einem Projekt beteiligt oder kann auf eine umfangreiche Dokumentation des Vorgängerprojektes zugreifen, bietet es sich an, einen Prototypen zu erstellen. Diesen Prototypen kann der Stakeholder bewerten und seine eigene Konstruktion mit der des Requirements-Engineers vergleichen. Eine andere Möglichkeit ist es, dem Stakeholder in einem Interview geschlossene Fragen zu stellen. Auf diese Art und Weise informiert der Requirements-Engineer den Stakeholder über seine Sicht des Projektes. Der Stakeholder kann entsprechend reagieren: zustimmen oder ablehnen und seine eigene Konstruktion vorstellen.

Konstruktion abholen und beeinflussen: Das 6-Hut-Denken und die Osborne-Checkliste sind Möglichkeiten, die dem Stakeholder zwar eine Richtung vorgeben, ihm aber gleichzeitig genügend Spielraum lassen, um seine eigenen Ideen zu entfalten. Die Beeinflussung geschieht durch die Vorgabe verschiedener Sichten, die der Stakeholder einnehmen muss.

Ein REler – Viele Stakeholder
Was haben viele Köche und viele Stakeholder gemeinsam? Richtig, sie verderben den Brei. Damit genau das dem Requirements-Engineer nicht passiert, sollte er sich der folgenden Punkte bewusst sein:

Konstruktion unvermischt abholen: In der Praxis werden wir häufig nicht mit lediglich nur einem Stakeholder arbeiten. Bei der Arbeit mit vielen Stakeholdern kann es das Ziel des Requirements-Engineers sein, zunächst unvermischte Konstruktionen der einzelnen Stakeholder zu sammeln. Ein Fragebogen mit offenen Fragen oder das Apprenticing oder eine Beobachten des Stakeholders sind dafür mögliche Ermittlungsmethoden[3].

Konstruktion abgeglichen abholen: Mit unzähligen Stakeholder arbeiten ist jedoch zeit- und damit kostenintensiv. Mit einem Gruppeninterview kann der Requirements-Engineer beides zumindest etwas eindämmen. Hier ist das Entscheidende, dass er den Prozess der Anforderungsermittlung begleitet, in dem die Befragten ihre Konstruktionen untereinander abstimmen und sich auch von ungewünschten Konstruktionen verabschieden. Ähnliche Vorteile bietet auch die Ermittlungsmethode 6-3-5. Ein Stakeholder kann seine Ideen notieren, doch ist nicht sicher, ob andere Stakeholder sich auch für diese Idee erwärmen. Die Stakeholder entscheiden sich miteinander für eine Konstruktion. Dieses Vorgehen bietet einen weiteren Vorteil: Es eignet sich auch, um Konflikte[4], bei denen die Teammitglieder an kommunikative Grenzen stoßen, schriftlich zu lösen.

Eigene Konstruktion reflektieren lassen: Nehmen wir an, ein Requirements-Engineer hat viele viele Anforderungen ermittelt und versucht nun, der Anforderungsflut Herr zu werden. Er kann – wie schon bei der Arbeit mit lediglich einem Stakeholder – die Anforderungen in einen Prototyp verwandeln. Während einer Gruppenpräsentation diskutieren die Stakeholder über diesen und kommen am Ende auf gemeinsame Anforderungen. Demselben Prinzip folgt das Reflektieren von Anforderungen in der Gruppe. Gemeinsam wertet die Gruppe die ihr vorgestellten Anforderungen aus und kommt so auf eine eigene, abgestimmte Konstruktion bzw. Anforderungen.

Die Entscheidung für eine Ermittlungstechnik wird also nicht nur von unter anderem menschlichen und fachlichen Faktoren beeinflusst[5]. Auch der Kostruktivismus hat entscheidenden Einfluss auf die Auswahl einer Ermittlungstechnik und der Requirements-Engineer sollte sich bei der Auswahl einer Technik bewusst sein, dass er den Stakeholder unterschiedlich stark beeinflussen kann. Ihm kommt die Verantwortung zu, mit verschiedensten Projektbeteiligten zahlreiche Konstruktionen zu ermitteln und sie anschließend zu dokumentieren, zu prüfen und zu verwalten. So ist der Konstruktivismus ein weiteres Argument für Requirements-Engineering in Projekten. Für einen sinnvollen Umgang mit Konstuktivismus fördert der Requirements-Engineer Kommunikation und Toleranz unter allen Stakeholder und macht deren Konstruktionen sichtbar.

Im dritten und letzten Teil der Blogserie „Requirements-Engineering und Konstruktivismus“ soll gezeigt werden, wie groß der Einfluss des Konstruktivismus auf eine so gängige Ermittlungstechnik wie das Interview ist.

Konstruktivismus im Requirements-Engineering: Gut ermittelt und doch konstruiert (Teil 1)
Konstruktivismus im Requirements-Engineering: Interview und Konstruktivismus (Teil 3)

——————————————–

Quellenangaben:

[1] Vgl. Foerster, Heinz et al.: Entdecken oder Erfinden. Wie läßt sich Verstehen verstehen? In: In: Foerster, Heinz von (2010): Einführung in den Konstruktivimus. München, Zürich: Piper.
[2] Ruland, Christoph: Zwerglein. Quelle: aboutpixel.de.
[3] Ein ganzes Kapitel widmen wir Ermittlungsmethoden in: Rupp, Chris und SOPHISTen, die: Requirements- Engineering und -Management – Aus der Praxis von klassisch bis agil. Hanser: München 2014. 6., aktualisierte und erweiterte Auflage.
[4] Eine konstruktivistische Sicht auf Konflikte finden Sie im ersten Teil dieser Serie.
[5] Rupp, Chris und SOPHISTen, die: Requirements- Engineering und -Management – Aus der Praxis von klassisch bis agil. Hanser: München 2014. 6., aktualisierte und erweiterte Auflage.