Begriffsklärung durch Moderation auf vier Ebenen

Die 4-Ebenen-Moderation wird hier als die Methode zur Begriffsklärung eingesetzt. Vorhandene Prototypen können dabei als Gesprächshypothesen im Sinne von Valk (vgl. Valk 1996) eingesetzt werden. Ziel ist die sprachliche Validierung der Nutzungsanforderungen und damit auch eine Be-griffsklärung.

Neben Einzelinterviews spielen Gruppendiskussionen bzw. Workshops im Usability oder auch Requirements Engineering eine bedeutende Rolle. Unter der Bezeichnung Workshop, Focus Group, Meeting o.ä. werden in Projekten Abstimmungstreffen mit einer Auswahl von Beteiligten (Stake-holder) zur Klärung einzelner Fragen hinsichtlich des Systementwurfs durchgeführt. Oft werden diese Sitzungen von Personen geleitet, die tief in das Thema involviert sind, und die deshalb dem zu diskutierenden Thema nicht (ausreichend) neutral gegenüberstehen, im extremen Fall sind sie sogar von den dort gefassten Beschlüssen direkt oder indirekt selbst betroffen. Personen, die schon viele Jahre im Unternehmen tätig sind, mangelt es oft an der notwendigen Distanz; sie sind betriebsblind.

Dies wirkt sich eher hinderlich für die sachgerechte Lösung von Problemen des Systementwurfs aus.

Derartige Workshops sollten daher von einer in Moderationstechnik erfahrenen, am Ergebnis jedoch unbeteiligten Person moderiert werden, wie es ein Usability Engineer ist.

Moderation wird definiert als die „nicht-direktive Leitung eines Gesprächs oder einer Verhandlung mit dem Ziel, den Meinungs- und Willensbildungsprozess zu ermöglichen und zu fördern, ohne inhaltlich zu steuern“ (Krems 2007). In gewisser Weise muss jedoch gesteuert werden, nur eben nicht aus Sicht spezieller Interessen. Die Workshop-Moderation im Kontext der Anforderungsermittlung hat darüber hinaus zwei weitere Funktionen: Zum einen die der Übersetzung zwischen fach- und IT-spezifischen Begriffen und Benennungen. Zum anderen müssen die unterschiedlichen Ebenen, auf denen diskutiert wird, erkannt und das von Teilnehmern Gesagte entsprechend strukturiert werden.

Die vier in Tabelle 9 oben aufgeführten Ebenen sind wie folgt zu unterscheiden: Ebene 1 ist der Nutzungskontext: Was tun die Nutzer bzw. wollen/müssen sie tun, um eine Aufgabe zu erledigen?

Ebene 2 sind die Erfordernisse, also die Frage: Was ist dafür unbestreitbar notwendig? Ebene 3 sind die Nutzungsanforderungen, also: Welche Möglichkeiten gibt es, diese Erfordernisse hardware- oder software-technisch zu realisieren? Ebene 4 schließlich sind die konkreten Lösungsvorschläge, auch Produktmerkmale genannt.

Ebene 1 ableiten Æ Ebene 2 ableiten Æ Ebene 3 ableiten Æ Ebene 4 Kontext der Nutzer

(Quelle:

Kontextszenario)

Erfordernis Nutzungsanforderung Lösung/

Realisierungs-möglichkeit

Definition „Eine notwendige

Voraussetzung, die es ermöglicht, den in einem Sachverhalt des Nutzungs-kontexts enthaltenen Zweck effizient zu erfüllen.“ (DATech 2007, Glossar).

„Eine erforderliche Benutzer-aktion an einem interaktiven System, in einer die Tätigkeit beschreibenden Weise – nicht in technisch realisierter Weise.

Beispiel: Der Benutzer muss lesen können. Nicht: Die Beleuchtungsstärke muss einstellbar sein.“ (DATech 2007, Glossar).

Authentische Beschreibung des Sachverhalts

Was ist hier selbstverständlich, unstrittig erforderlich?

Selbstverständlicher, unstreitiger Beweggrund des Handelns

Tätigkeitsanforderung Welche Nutzungsanforderung folgt aus dem Erfordernis und dem Dialogprinzip?

Merkmalsanforderun g/Produktmerkmal

Was tun die Nutzer und wie tun sie es?

Zu welchem Zweck tun sie es und welche Voraussetzungen müssen erfüllt sein, damit sie es tun können?

Was müssen Nutzer am System wie tun können?

Wie muss/kann das im User Interface aussehen?

Wie kann man das realisieren?

Beispiel Autoradio Kontext: Während der Fahrt das Radio einstellen

Fokus auf Verkehr behalten können

ohne Blickwechsel Drehregler mit Schnittstelle

Tabelle 9: Moderationsebenen in der Anforderungsentwicklung In Anlehnung an (Geis 2005)

Gerade wenn es nicht darum geht herauszufinden, ob eine bestimmte Funktionalität implementiert werden soll, sondern darum, wie diese Funktion innerhalb des Arbeitsablaufs realisiert werden soll, ist diese Strukturierung der Diskussionen hilfreich. Das Ziel einer Moderation in diesem Kontext ist es, transparent zu machen, was der Nutzer benötigt und nicht, was er wünscht. Hier muss die Diskussion so moderiert werden, dass die vier Ebenen, die sich aus der Systematik der Anfor-derungsermittlung ergeben, strikt auseinander gehalten werden. Wenn der Kontext, wie hier das Bedienen eines Autoradios während einer Autobahnfahrt ist, also bei hoher Geschwindigkeit, so ist das unstrittige Erfordernis, dass der Fahrer den Blick auf den Verkehr halten kann, während er das Radio bedient. Die abzuleitende Nutzungsanforderung lautet, dass das Bedienelement ohne

Blick-wechsel nutzbar sein muss. Die Realisierungsmöglichkeiten hierfür, die Produktmerkmale also, sind ein Dreh- oder ein Schieberegler. Dabei kann der Fahrer haptisch erfassen, wie weit er den Regler bewegen muss. Durch die genaue Formulierung von Erfordernissen und daraus abgeleitete Nutzungs-anforderungen wird die Spezifizierung von Design-Vorschlägen unterstützt, nicht brauchbare Alter-nativen werden ausgeschlossen.

Durch eine derart moderierte Diskussion kommt es zu einem dialektischen Lösungsprozess. Diese Form der Diskussionslenkung korrespondiert mit der Idee der dialektischen Problemlösung (Abb.

38). Darunter versteht man die Entwicklung von Nutzungsanforderungen als Prozess der Lösung zweier Probleme. Zum einen müssen Anforderungen präzisiert werden. Zum anderen müssen Anfor-derungen veranschaulicht und in einen Lösungsvorschlag transformiert werden (vgl. Dzida/ Freitag 1998). Dabei ist das Erzeugen und Überwinden von Widersprüchen durchaus gewollt.

Abbildung 38: Dialektisches Problemlösen (DATech 2008, S. 12)

In moderierten Workshops sollte damit der Kontextanalyse eine Kontextsynthese folgen. Bei der Gegenüberstellung von Arbeitsaufgaben und Produktidee bzw. dem jeweiligen Vokabular dazu, wird vor allem auf Widersprüche geachtet, deren Klärung zur Präzisierung von Nutzungsanforderungen führt. Dieser als dialektisch bezeichnete Prozess verhindert subjektive Verzerrungen in der Dar-stellung des Nutzungskontextes. Diese Verzerrungen werden bei der Validierung der Anforderungen oder bei der Evaluierung von Prototypen deutlich. Der Prozess der Anforderungsentwicklung und des Prototyping ist explizit darauf angelegt, solche Einschränkungen im Verstehen der Entwurfs-grundlagen aufzudecken.

Die Umsetzung der Nutzungsanforderungen in technische Dialogmerkmale findet im nächsten Schritt statt. Die Erarbeitung konstruktiver Lösungsvorschläge, inklusive Begriffsfindung für die als valide erkannten Nutzungsanforderungen, wird auch als dialektisches Problemlösen bezeichnet (vgl. Dörner 1979).

8 Evaluation des Verfahrens

In diesem Kapitel wird die Auswahl der Forschungsmethode begründet, das Vorgehen beschrieben und es werden Ergebnisse dargestellt. Das Vorgehen erfolgte in Form einer Fallstudie.