Gottfried Wilhelm Leibniz Universität HannoverFakultät für Elektrotechnik und Informatik

Institut für Praktische InformatikFachgebiet Software Engineering

Ableitung von Anforderungen durch Benutzerbeobachtung in adaptiven Systemen

Masterarbeit

im Studiengang Informatik

von

Christian El Boustani

Prüfer: Prof. Dr. Kurt SchneiderZweitprüfer: Prof. Dr. Jörg HähnerBetreuer: Dipl.-Math. Olesia Brill

Hannover, 01.11.2010

Erklärung

Hiermit versichere ich, dass ich die vorliegende Masterarbeit selbstständig und ohne fremde Hilfe verfasst habe und keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel verwendet habe.

Hannover, 01.11.2010Christian El Boustani

2

Danksagung

Hiermit möchte ich mich bei allen Personen bedanken, die mich bei der Erstellung dieser Arbeit unterstützt haben.

Mein besonderer Dank gilt meiner Betreuerin Olesia Brill sowie Eric Knauss für die jederzeit vorbildliche Unterstützung und die vielen konstruktiven Anregungen und Ratschläge, meinen Kommilitonen, die mich bei der Durchführung des Feldversuchs tatkräftig unterstützt haben sowie allen Personen, die sich die Zeit genommen haben, diese Arbeit Korrektur zu lesen.

3

Zusammenfassung

IT-Ökosysteme sind extrem große und dynamische Softwaresysteme, die sich durch eine Vielzahl von unterschiedlichen Benutzern und verschiedenen Subsystemen auszeichnen. Die hohe Änderungsdynamik, die sich vor allem in der sich ständig ändernden Anzahl von Subsystemen und der Anzahl der Benutzer des Gesamtsystems zeigt, stellt eine besondere Herausforderung für die Erhebung von Anforderungen dar. Die etablierten Erhebungstechniken für Anforderungen, die oft auf das explizite Feedback von Benutzern setzen, scheinen für den Einsatz in einem derart komplexen und dynamischen Umfeld nur unzureichend geeignet, da nicht erwartet werden kann, dass die Benutzer des Systems über ausreichend Zeit und Motivation verfügen, um z.B. im Rahmen von Interviews ihre Anforderungen zu formulieren.

In dieser Arbeit wird ein Konzept entwickelt und implementiert, um neue Anforderungen bzw. Indikatoren für neue Anforderungen ohne Interaktion mit den Benutzern zu erheben. Hierbei kommt vor allem dem Umfeld bzw. dem Kontext des Benutzers eine zentrale Rolle zu. Die Anwendung des Konzepts wird an einem fiktiven Beispiel aus der Domäne „Flughafen“ veranschaulicht und in einem realen Feldversuch an verschiedenen Orten einer Großstadt in Deutschland angewendet. Eine Literaturrecherche gibt einen Überblick über den Stand der Forschung auf dem Gebiet der Anforderungserhebung durch Benutzerbeobachtung, den kontextsensitiven Systemen sowie über den Begriff des Kontextes im Requirements Engineering.

Das in dieser Arbeit entwickelte Konzept erlaubt die Durchführung gezielter kontextbezogener Benutzerbeobachtungen und verknüpft Benutzerverhalten, Kontexteinflüsse und Ziele der Benutzer. Aus den gewonnenen Daten können Indikatoren für neue bzw. geänderte Anforderungen gewonnen werden.

4

Inhalt

1 Einleitung 71.1 Motivation.....................................................................................................................71.2 Ziele dieser Arbeit.........................................................................................................71.3 Grundbegriffe................................................................................................................81.4 Aufbau dieser Arbeit......................................................................................................9

2 Literaturrecherche 102.1 Anforderungserhebung durch Beobachtung von Benutzern........................................102.2 Der Begriff des Kontextes im Requirements Engineering............................................112.3 Kontextadaptive Systeme...........................................................................................13

3 Konzept zur Ableitung von Anforderungen durch Benutzerbeobachtung 163.1 Vorüberlegungen........................................................................................................163.2 Definitionen.................................................................................................................17

3.2.1 Kontext- und Verhaltensmodell............................................................................173.2.2 Aufenthaltsort und Umgebung eines Benutzers..................................................193.2.3 Erwartetes Benutzerverhalten.............................................................................203.2.4 Regeln für adaptive Systeme..............................................................................21

3.3 Anwendung des Konzepts..........................................................................................223.4 ER-Modell des Konzepts............................................................................................273.5 Ablauf der Anwendung des Konzepts.........................................................................28

4 Exemplarische Anwendung des Konzepts 314.1 Definition der Action Areas und Identifikation der adaptiven Systeme.........................324.2 Definition der Ziele der Benutzer................................................................................324.3 Set of expected Actions für Action Areas definieren....................................................344.4 Regeln und erwartetes Benutzerverhalten aufstellen..................................................344.5 Benutzerbeobachtung durchführen.............................................................................364.6 Auswertung des Benutzerverhaltens...........................................................................394.7 Konsequenzen für adaptive Systeme ableiten............................................................404.8 Neue Anforderungen ableiten und Regeln überarbeiten.............................................414.9 Einsatzmöglichkeiten und Grenzen des Konzepts......................................................43

5 Implementierung des Konzepts 455.1 Vorüberlegungen........................................................................................................455.2 Eingesetzte Technologien...........................................................................................455.3 Beschreibung des Programms....................................................................................46

5.3.1 Vorbereitung einer Benutzerbeobachtung...........................................................475.3.2 Durchführung einer Benutzerbeobachtung..........................................................535.3.3 Auswertung einer Benutzerbeobachtung.............................................................55

5

6 Praktischer Einsatz des Konzepts im Feldversuch 576.1 Einsatzort 1: Tiefgarage..............................................................................................58

6.1.1 Action Area: Tiefgarage.......................................................................................596.1.2 Action Area: Erstes Untergeschoss der Tiefgarage.............................................60

6.2 Einsatzort 2: Bushaltestelle.........................................................................................616.3 Ergebnisse und Auswertung.......................................................................................626.4 Erfahrungen des Feldversuchs...................................................................................636.5 Analyse der Schwachstellen.......................................................................................64

7 Fazit und Ausblick 677.1 Fazit............................................................................................................................677.2 Ausblick......................................................................................................................68

8 Literaturverzeichnis 70

6

1 Einleitung

1.1 MotivationIT-Ökosysteme (s. Kapitel 1.3) sind extrem große Softwaresysteme, deren Komplexität kontinuierlich zunimmt: Zahlreiche Subsysteme (z.B. adaptive Systeme, vgl. Kapitel 1.3) kommen im Laufe der Zeit zu dem Gesamtsystem hinzu, andere verschwinden wiederum. Auch die Anzahl und Art der Benutzer des Systems und ihr Verhalten ändern sich über die Zeit. Damit unterliegen auch die Anforderungen, die die Benutzer an die Subsysteme stellen, einer ständigen Veränderung. Die Dynamik, mit der sich die Anforderungen ändern, stellt eine besondere Herausforderung für das Requirements Engineering dar.

Zu den etablierten Techniken der Anforderungserhebung gehören kommunikative Techniken, wie z.B. Interviews oder Workshops, mit deren Hilfe Anforderungsanalysten versuchen, Anforderungen direkt im Dialog mit den Benutzern zu ermitteln (vgl. [SWE04]). Solche Techniken der Anforderungserhebung sind jedoch zeitaufwändig und ihre Ergebnisse oft unvollständig oder fehlerhaft, da die Benutzer sich häufig gar nicht ihrer Anforderungen bewusst sind oder Schwierigkeiten haben, diese zu formulieren. Als weitere Fehlerquelle sind außerdem Kommunikationsschwierigkeiten und Missverständnisse zwischen Anforderungsanalysten und Benutzern zu nennen. In [Sin+09] wird außerdem erwähnt, dass die Benutzer eines IT-Ökosystems eine heterogene Gruppe bilden: Während manche Benutzer sehr eng mit dem System verbunden sind (z.B. wenn sie selbst für Dienste oder Subsysteme des IT-Ökosystems verantwortlich sind), sind sich andere Benutzer (insbesondere ein Teil der Endbenutzer) überhaupt nicht des Systems, welches sie umgibt, bewusst. Vor allem von der letzteren Gruppe kann kaum erwartet werden, dass sie die Motivation haben, aktiv bei der Erhebung von Anforderungen mitzuwirken. Man nimmt an, dass klassische Erhebungstechniken, wie z.B. Interviews, vermutlich nicht zum Erfolg führen würden (vgl. [Sin+09]).

Aus den oben genannten Gründen erscheint es sinnvoll, eine Methodik für die Anforderungserhebung in IT-Ökosystemen zu wählen, bei der die aktive Mitarbeit der Benutzer nicht erforderlich ist. Diese Methodik kann unterstützend zu den klassischen Erhebungstechniken für Anforderungen eingesetzt werden.

1.2 Ziele dieser ArbeitIn dieser Arbeit soll ein Konzept für eine Methodik der Anforderungserhebung, die auf der Beobachtung des Benutzers basiert und bei der seine aktive Mitarbeit nicht erforderlich ist, entwickelt und implementiert werden. Es sollen Indikatoren für neue bzw. veränderte Anforderungen der Benutzer von adaptiven IT-Systemen (die Teil von IT-Ökosystemen sind) ermittelt werden. Dabei soll untersucht werden, welche Rückschlüsse sich aus dem Kontext und aus dem Verhalten des Benutzers bezüglich neuer oder geänderter Anforderungen ziehen lassen.

Das entwickelte Konzept soll an einem adäquaten Beispiel aus der Domäne „Flughafen“ demonstriert werden. Zudem ist eine rudimentäre Implementierung des Konzepts vorgesehen. Eine Literaturrecherche soll einen Überblick über den aktuellen Stand der Forschung auf dem Gebiet der Anforderungserhebung durch Beobachtung von Benutzern, kontextbezogener Anforderungserhebung und kontextsensitiver Systeme geben.

7

1.3 GrundbegriffeEin IT-Ökosystem ist ein IT-System, das aus einer Vielzahl unterschiedlicher autonom agierender Akteure (sogenannter Agenten) besteht. Diese Agenten können sowohl Menschen, aber auch technische Geräte oder Software-basierte Dienste sein und benutzen die Infrastruktur des IT-Ökosystems, um miteinander zu kommunizieren und zu interagieren. Zu den Agenten eines IT-Ökosystems gehören auch adaptive Systeme, die in dieser Arbeit folgendermaßen definiert werden:

Definition: Adaptives System

Definition 1

Adaptive Systeme sind sowohl Systeme, die der Benutzer jederzeit bei sich trägt (z.B. Smartphones), aber auch ortsgebundene Systeme, wie z.B. ein Verkehrsleitsystem, das sich auf einer bestimmten Straße befindet und einem Benutzer z.B. Empfehlungen bezüglich der Wahl eines Parkplatzes geben kann.

Der Begriff Kontext hat nach [Bro10] einen lateinischen Ursprung und steht für „Zusammenhang, Umfeld“. Verschiedene wissenschaftliche Veröffentlichungen aus dem Requirements Engineering verwenden jedoch unterschiedliche Definitionen des Begriffs, die in Kapitel 2.2 vorgestellt werden. Die Kontextdefinition, die im Rahmen des Konzepts in dieser Arbeit verwendet wird, wird in Kapitel 3.2.1 vorgestellt.

Ein zentrales Element des in dieser Arbeit entwickelten Konzepts, das Anforderungen, adaptive Systeme und das Verhalten des Benutzers miteinander verbindet, sind die Ziele, die ein Benutzer verfolgt (s. Abbildung 6). Zur besseren Darstellung der Einflüsse, die zur Erreichung eines Ziels beitragen, wird in dieser Arbeit an einigen Stellen das i*-Framework (s. Abbildung 1) verwendet.

8

Abbildung 1: Elemente des i*-Frameworks nach [Poh08]

1.4 Aufbau dieser ArbeitDiese Arbeit gliedert sich in sieben Kapitel: Nachdem in Kapitel 1 die Einleitung, die Motivation sowie Zielsetzungen und grundlegende Begriffe behandelt worden sind, folgt in Kapitel 2 die Literaturrecherche. In Kapitel 3 wird das Konzept zur Ableitung von Anforderungen durch Benutzerbeobachtung vorgestellt. In Kapitel 4 wird das Konzept exemplarisch an einem Beispiel aus der Domäne „Flughafen“ demonstriert. Kapitel 5 stellt die Implementierung des Konzepts in Form eines Prototyps vor. Kapitel 6 beschreibt die Anwendung des Konzepts in einem Feldversuch und stellt die Ergebnisse und Erfahrungen vor, die dabei gewonnen worden sind. In Kapitel 7 wird ein Fazit über die Ergebnisse dieser Arbeit gezogen und im Ausblick eingeschätzt, welche Aspekte in zukünftigen Arbeiten weiter vertieft werden könnten.

9

2 LiteraturrechercheDie Literaturrecherche in dieser Arbeit soll zunächst einen Überblick über den Stand der Forschung auf dem Gebiet der Anforderungserhebung durch Benutzerbeobachtung, der kontextsensitiven Anwendungen und der kontextbezogener Anforderungserhebung geben und die bereits existierenden Ansätze zu dem Konzept in dieser Arbeit abgrenzen.

Die Literaturrecherche gliedert sich in mehrere Abschnitte: Da in dieser Arbeit der Fokus auf der Ableitung von Anforderungen durch Benutzerbeobachtung liegt, werden zunächst in Kapitel 2.1 bereits etablierte Ansätze und Vorgehensweisen auf diesem Gebiet vorgestellt. Ein weiteres wichtiges Element in dieser Arbeit ist der Begriff des Kontextes. Da dieser Begriff in der Literatur jedoch nicht eindeutig definiert ist, wird in Kapitel 2.2 vorgestellt, welche Bedeutungen dieser Begriff in verschiedenen Vorgehensweisen des Requirements Engineerings haben kann und wie sich dies auf die jeweilige Methodik auswirkt. Abschließend wird in Kapitel 2.3 vorgestellt, welche Methoden kontextsensitive Systeme verwenden, um sich an unterschiedliche Rahmenbedingungen bzw. an geänderte Anforderungen anzupassen, und welche Übereinstimmungen und Unterschiede es mit dem Konzept, das in dieser Arbeit entwickelt wird, gibt.

Als Basis für die Literaturrecherche wurden folgende Konferenzen mit Schwerpunkt Requirements Engineering betrachtet: „IEEE International Requirements Engineering Conference“ (2007 – 2009) und „REFSQ“ (2007 – 2010). Außerdem wurden die Quellen [Rup07] und [Poh08], die zu den Standardwerken im Bereich Requirements Engineering gehören, untersucht sowie in den Suchmaschinen „Google“ (http://www.google.de/) und „Google Scholar“ (http://scholar.google.de) nach wissenschaftlichen Veröffentlichungen zu den Themen der Kapitel 2.1, 2.2 und 2.3 gesucht. Zusätzlich wurde in den angegebenen Referenzen von den in dieser Arbeit zitierten Veröffentlichungen nach weiteren relevanten Veröffentlichungen gesucht.

2.1 Anforderungserhebung durch Beobachtung von BenutzernDie Beobachtung von Benutzerverhalten ist im Requirements Engineering ein bekannter Ansatz und gehört laut [SWE04] zu den etablierten Erhebungstechniken für Anforderungen. In [Rup07] werden Techniken zur Feldbeobachtung vorgestellt, in denen ein Anforderungsanalyst Benutzer bei ihrer Arbeit beobachtet und das Benutzerverhalten dokumentiert. Allerdings wird explizit auch erwähnt, dass der Anforderungsanalyst während der Beobachtung den Benutzern Fragen stellen kann. Die Kombination von Feldbeobachtung und Benutzerbefragung ist auch ein zentrales Element von Contextual Inquiry ([Bey+98]). Bei dieser Methodik wird ein Benutzer während der Verrichtung einer Tätigkeit in seiner Domäne von einem Anforderungsanalysten beobachtet. Ab und zu unterbricht der Analyst den Benutzer in seiner Tätigkeit und bespricht mit dem Benutzer die zuvor ausgeübte Tätigkeit. Abschließend werden die Ergebnisse des Interviews in einer Gruppe besprochen und interpretiert, die sich aus dem Benutzer, dem Analysten sowie weiteren am Projekt beteiligten Stakeholdern zusammensetzt.

Eine weitergehende Interaktion bei der Beobachtung von Benutzern wird in [Rup07] und [Poh08] beschrieben: So könnte ein Anforderungsanalyst nicht nur die Benutzer beobachten, sondern die Arbeitsabläufe der Benutzer selbst erlernen, indem er sie (soweit möglich) aktiv durchführt (in [Rup07] wird diese Technik als Apprenticing bezeichnet).

10

Eine Variante der Feldbeobachtung ist der Einsatz von Videoaufzeichnungen, wie sie in [Rup07] beschrieben werden. Dieser Ansatz bietet den Vorteil, dass komplexe und schnell ablaufende Vorgänge und deren Zeitverhalten korrekt festgehalten werden können, die bei einer gewöhnlichen Beobachtung übersehen oder verfälscht dokumentiert werden würden.

Neben allgemeinen Methoden zur Feldbeobachtung können unter Umständen auch domänenspezifische Vorgehensweisen entwickelt werden. So wird in [Sø+07] ein Framework zur strukturierten Durchführung von Feldbeobachtungen in einem Krankenhaus vorgestellt, was auf den Erfahrungen und Ergebnissen mehrerer durchgeführter Feldbeobachtungsstudien basiert: Das Framework schlägt ein mehrstufiges Vorgehen vor, das sich von der Auswahl der Dokumentationstechniken über die eigentliche Feldbeobachtung, Transformation der erhobenen Rohdaten bis hin zur Analyse und Auswertung der Daten erstreckt. Obwohl das in dieser Arbeit entwickelte Konzept an einem Beispiel aus der Domäne Flughafen exemplarisch demonstriert wird, bestehen bezüglich der Einsatzmöglichkeiten des Konzepts keinerlei domänenspezifische Einschränkungen.

Auch bei der Analyse der Bedienbarkeit (Usability) von technischen Systemen spielt die Beobachtung des Benutzerverhaltens eine entscheidende Rolle und kann dazu dienen, Schwächen in der Ergonomie eines technischen Geräts oder einer Software aufzuzeigen. Die Art der Benutzerbeobachtung kann dabei von reiner Beobachtung des Benutzers über Beobachtung und Aufnahme von Erläuterungen, die der Benutzer bei der Bedienung von sich gibt („Think Aloud“) bis hin zu dialogbasierten Verfahren, bei denen ein Analyst Zwischenfragen stellt, variieren. Verschiedene Varianten, um die Usability eines System zu testen, werden in [Nie93] vorgestellt.

Detailliertere Formen der Benutzerbeobachtung werden unter anderem in [Dza08] untersucht. Das Eye Tracking stellt hierbei eine wichtige Technik dar, mit der das Blickverhalten von Benutzern des Systems analysiert und ausgewertet wird. Insbesondere im Bereich Human-Computer Interaction (HCI) stellt die Erhebung und Auswertung des Blickverhaltens des Benutzers ein wichtiges Hilfsmittel dar, um Defizite in der Usability (vgl. [Poo+05]) von technischen Systemen und grafischen Benutzeroberflächen aufzudecken. Eine Übersicht über das Thema Eye Tracking und den aktuellen Stand der Forschung auf diesem Gebiet wird in [Poo+05] gegeben.

Viele Ansätze der Anforderungserhebung durch Beobachtung der Benutzer verwenden unterstützend das Feedback des Benutzers, indem entweder der Benutzer selbst befragt wird oder er selbstständig Kommentare zu seiner Tätigkeit abgeben soll. Das in dieser Arbeit erarbeitete Konzept richtet sich jedoch insbesondere an die Benutzer, die sich der technischen Systeme, die sie umgeben nicht bewusst sind und von denen keine Motivation erwartet werden kann, aktiv bei der Erhebung von Anforderungen mitzuarbeiten. Daher verzichtet das Konzept dieser Arbeit bewusst auf eine Interaktion mit den Benutzern.

2.2 Der Begriff des Kontextes im Requirements EngineeringIn Kapitel 1.3 wurde bereits erwähnt, dass es keine einheitliche Definition des Begriffs „Kontext“ gibt. In Veröffentlichungen zum Thema Requirements Engineering finden sich unterschiedliche Definitionen, die an dieser Stelle vorgestellt werden sollen.

11

In [Poh08] wird z.B. der Begriff Systemkontext eingeführt, der als „Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen an das System relevant ist.“ definiert wird. Die Kontextgrenze dagegen „separiert den relevanten Teil der Umgebung eines Systems von dem irrelevanten Teil, d.h. dem Teil, der (…) im Requirements Engineering nicht betrachtet wird.“ Es wird außerdem darauf hingewiesen, dass Anforderungen immer für „einen Kontext definiert und interpretiert“ werden.

Die Abhängigkeit einer Anforderung von der aktuellen Situation, in der sich ein Benutzer befindet, wird auch in der RE-CAWAR Methodik (vgl. [Sit09]) berücksichtigt, welche ein „modellbasierter Ansatz des RE kontextsensitiver Anwendungen“ darstellt. Hierbei wird neben der Verwendung unterschiedlicher Modelle (z.B. Nutzermodell, Aufgabenmodell, etc.) auch explizit eine Kontext-Analyse durchgeführt, die die Rahmenbedingungen der späteren Nutzung des Systems berücksichtigt.

Auch [Sut+05] stellt ein Framework vor, das den Einfluss des Kontextes auf Anforderungen betrachtet: So werden Anforderungen in unterschiedliche Kategorien unterteilt, wie z.B. allgemeine Anforderungen der Stakeholder oder persönliche Ziele eines Benutzers. Diese Kategorien von Anforderungen spiegeln sich in unterschiedlichen Aspekten des Systemdesigns wider, wie z.B. der funktionalen Spezifikation oder der Entwicklung von personalisierbaren Systemeigenschaften. Es wird außerdem berücksichtigt, dass sich Anforderungen durch Änderungen in Raum und Zeit verändern können. Dieser Ansatz wird in ähnlicher Weise auch in [Poh08] aufgegriffen: „Eine dokumentierte Anforderung erhält je nach Kontext eine andere Bedeutung“.

[Sch+98] betont, dass der Standort häufig als zentraler Faktor des Kontextes gesehen wird, es jedoch sinnvoll sei, den Kontextbegriff um weitere Faktoren zu erweitern. Hierzu wird ein hierarchisches Modell von Kontextattributen vorgestellt und diskutiert, welche Informationen über den Kontext mittels Sensoren von mobilen Geräten aufgenommen werden und zur Anpassung des Systemverhaltens des Geräts genutzt werden könnten.

In [Sey+08] wird ein Ansatz vorgestellt, der einen Anforderungsanalysten bei der Erhebung von Anforderungen unterstützt, indem er über ein mobiles Gerät kontextabhängig Hilfestellungen bereitstellt. [Sey+08] greift auf eine Definition von „Kontext“ zurück, die von Anind K. Dey et al. (vgl. [Dey+99]) vorgeschlagen wurde: „Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves.“ . Diese Definition wird in diversen Veröffentlichungen zum Thema kontextadaptive Systeme zitiert (vgl. [Sit09], [Wei09]).

Der Kontextbegriff in dieser Arbeit wird – ähnlich wie [Dey+99] und [Sch+98] - verschiedene Faktoren der Umgebung berücksichtigen, aber im Gegensatz zu den vorgestellten Definitionen explizit den möglichen Einfluss von Kontextfaktoren auf das Verhalten eines Benutzers berücksichtigen (s. Definition 2). Analog zu [Sch+98] wird in dieser Arbeit ebenfalls ein hierarchisches Modell von Kontextattributen verwendet (s. Abbildung 3). Die zeitliche und räumliche Variabilität von Anforderungen wird durch das Konzept dieser Arbeit unterstützt, indem der räumliche Bereich, in dem sich ein Benutzer befindet, explizit für die Anwendung des Konzepts festgelegt werden muss und die wiederholbare Anwendung des Konzepts Veränderungen im Umfeld des Benutzers berücksichtigt.

12

2.3 Kontextadaptive SystemeEin Gebiet, in dem der „Kontext“ (eines Systems bzw. eines Geräts, das seinen Standort zusammen mit einem Benutzer wechselt) von großer Bedeutung ist, sind kontextsensitive – bzw. kontextadaptive Systeme, wie sie z.B. in [Sit09] vorgestellt werden. Ein System heißt (nach der Definition in [Sit09]) kontextadaptiv oder auch kontextsensitiv, „wenn es über Sensorik relevante Informationen über die Einsatzumgebung aufnimmt, und diese zur Adaption seiner Interaktionen mit dem Nutzer verwendet.“ In [Che+09] werden adaptive Systeme beschrieben als „Systeme, die in der Lage sind, ihr Verhalten als Reaktion auf ihre Wahrnehmung der Umwelt und des Systems selbst anzupassen“.

Eine ausführliche Übersicht über den Stand der Forschung des Software Engineerings auf dem Gebiet der adaptiven Systeme bietet [Che+09]. Es werden verschiedene Themengebiete, wie z.B. die Modellierung der Adaptivität oder der Bereich Requirements von adaptiven Systemen, angesprochen. Im Folgenden sollen einige zentrale Inhalte dieser Veröffentlichung erläutert werden.

Im Bereich Modellierung werden verschiedene Aspekte erwähnt, die für die Modellierung eines adaptiven Systems entscheidend sind: Der erste Aspekt sind die Ziele (Goals), die ein adaptives System erreichen soll. Diesem Aspekt sind weitere Attribute zugeordnet: Die Frage, in welcher Form sich die Ziele des Systems in Anzahl und Art zur Laufzeit des Systems ändern können, wie flexibel einzelne Ziele an sich definiert sind, wie lange die Ziele gültig bleiben, ob ein System ein einzelnes Ziel verfolgt oder mehrere Ziele, und falls das System mehrere Ziele verfolgt, in welcher Beziehung diese Ziele zueinander stehen.

Der zweite Aspekte sind die Änderungen (Change), auf die ein adaptives System reagieren muss. Hierbei werden folgende Attribute betrachtet: Die Frage, ob die Veränderung, auf die das adaptive System reagieren soll, eine systeminterne Veränderung ist oder es sich um einen äußeren Einfluss handelt, die Art der Änderung (funktionale -, nicht-funktionale - oder technologische Änderung), die Frequenz der Änderungen und inwiefern eine Änderung vorhersehbar ist.

Der dritte Aspekt bezieht sich auf die Reaktionsweisen (Mechanism) eines adaptiven Systems bezüglich einer Änderung (z.B. in der Umgebung des Systems). Die Attribute, die diesem Aspekt zugeordnet sind, der Typ der Adaption (Adaption der Parameter oder der Struktur des Systems), der Grad der Autonomie, mit der die Adaption geschieht, die Frage, wie die Adaption innerhalb des System durch Systemkomponenten organisiert ist, die Frage, ob eine Adaption nur Teile des Systems oder das Gesamtsystem betrifft, wie lange die Adaption dauert, ob es Zeitschranken gibt, bis die Adaption abgeschlossen ist, und die Frage, ob der Auslöser für die Adaption event- oder zeit-basierend ist. Unterschiedliche Adaptionsstrategien werden auch in [Gei08] vorgestellt.

Der vierte und letzte Aspekt betrifft die Auswirkungen der Adaption (Effects) auf das System selbst. Die Attribute, die diesem Aspekt zugeordnet sind, sind die Kritikalität einer (erfolgreichen) Selbst-Adaption (d.h. wie kritisch sind die Konsequenzen, falls die Adaption des Systems scheitert?), inwiefern die Adaption zeitlich und inhaltlich vorhergesehen werden kann, welche Auswirkungen die Adaption auf die Leistungsfähigkeit des Systems hat und die Robustheit des Systems, wenn Änderungen auftreten.

13

Im Bereich Requirements steht die Frage nach dem Grad der Anpassungsfähigkeit und deren Grenzen im Vordergrund (s. [Che+09]). Trotz der erforderlichen Flexibilität, die ein adaptives System aufweisen müsse, könne es jedoch nicht in jeder Hinsicht flexibel sein. Die Tatsache, dass jedes adaptive System zwangsläufig auch invariante Anteile (z.B. Hardware) enthalten muss, wird auch in [Wel+09] erwähnt. Zentrale Aufgabe des Requirements Engineerings für adaptive Systeme sei es, Aspekte der Umgebung, die für die Adaptivität des Systems relevant sind, zu identifizieren und einzuschätzen, welche Anforderungen sich zur Laufzeit des Systems ändern könnten. Da es aber in der Regel nicht möglich sein wird, alle möglichen Umgebungseinflüsse, auf die ein adaptives System reagieren muss, bereits bei der Entwicklung zu definieren und zu berücksichtigen, folge nach [Che+09] daraus, dass die Menge der erhobenen Anforderungen zwangsläufig unvollständig sein würde. Diese Form der Unsicherheit würde auch neue Notationsformen für Anforderungen erfordern, da etablierte Notationsformen für Anforderungen noch keine explizite Unterstützung für Unsicherheiten, die bei der Entwicklung adaptiver Systeme auftauchen, anbieten würden.

In [Sal09] wird eine Übersicht über den Stand der Forschung auf dem Gebiet der Selbst-adaptiven Software gegeben: Zunächst werden unterschiedliche Definitionen von Selbst-adaptiver Software vorgestellt, wobei insbesondere die häufig zitierte Definition (s. auch [Lad01]) des DARPA Broad Agency Announcement (BAA) von 1997 ([Lad06]) zu erwähnen ist: „Self Adaptive Software evaluates its own behavior and changes behavior when the evaluation indicates that it is not accomplishing what the software is intended to do, or when better functionality or performance is possible.“ . Es werden Eigenschaften von Selbst-adaptiver Software vorgestellt (Self-* Properties, [Hor01]) und der Zusammenhang zwischen diesen Eigenschaften und Qualitätseigenschaften und Nicht-funktionalen Anforderungen diskutiert. Ferner werden Strategien zur Anforderungserhebung für Selbst-adaptive Software vorgestellt: Einerseits müsse geklärt werden, welche Teile des Systems die Anforderung nach einer Änderung begründen (Aspekt: „Where“), der Zeitpunkt, zu dem eine Änderung des Systems notwendig wäre (Aspekt: „When“) müsse festgelegt werden, welche Teile des Systems geändert werden sollten (Aspekt: „What“) müsste bestimmt werden, die Frage warum eine adaptive Software entwickelt werden sollte (Aspekt: „Why“) müsste beantwortet werden sowie wie groß der Anteil der Autonomie der Software ist und welche Rolle ein menschlicher Benutzer in der Interaktion mit der Software spielt (Aspekt: „Who“) und in welcher Weise die adaptiven Teile des Systems geändert werden sollten (Aspekt: „How“). Es wird ferner ein Adaptions-Prozess vorgestellt, der sich, ausgehend von Sammlung von Sensordaten über das Treffen der Entscheidung, wann eine Adaption des Systems notwendig ist bis hin zu der Entscheidung, welcher Teil des Systems in welcher Weise im Hinblick auf die Adaption geändert werden muss, erstreckt.

Außerdem werden in [Sal09] verschiedene Aspekte in Bezug auf die Selbst-Adaptivität eines Systems vorgestellt: So muss ein System zur Anpassung seines Systemverhaltens zunächst identifizieren, welche Abstraktionsschicht (z.B. Middleware) sowie welche Komponenten innerhalb dieser Schicht angepasst werden müssen, um auf neu entstandene Anforderungen zu reagieren. Ferner muss das System auch Auswirkungen und Aufwand einer Adaption abschätzen. Bei der Art einer Adaption unterscheidet [Sal09] zwischen einer statischen Adaptivität und einem dynamischen Ansatz. Unter statischer Adaptivität wird eine Änderung des Systems verstanden, bei der programmiertechnisch in das System oder in Teile des Systems eingegriffen werden muss, um das Systemverhalten zu ändern, wobei bei einer dynamischen Adaptivität das Systemverhalten über Regeln und Richtlinien extern gesteuert wird. Ein weiterer wichtiger Punkt, der in [Sal09] erwähnt wird, ist die Frage, ob ein adaptives System auf eine Änderung in seiner Umgebung reaktiv (d.h. wenn die Änderung bereits stattgefunden hat) oder proaktiv (d.h. vorausschauend)

14

reagieren soll. In dieser Arbeit wird grundsätzlich von reaktiven Systemen ausgegangen, da eine Anpassung des Systemverhaltens gemäß einer Regel stets im Anschluss an die Beobachtung einer Änderung im Kontext des Systems stattfindet und damit reaktiver Natur ist.

Weitergehender Forschungsbedarf besteht nach [Sal09] insbesondere in den Bereichen der Anforderungsanalyse, in der die Herausforderung vor allem darin besteht, die Erwartungen der Benutzer im Hinblick auf die Adaptivität des Systems zur Laufzeit angemessen zu modellieren. In [Sal09] wird zielorientiertes Requirements Engineering als vielversprechender Ansatz angesehen, um den Herausforderungen bei der Anforderungsanalyse bei der Entwicklung adaptiver Software zu begegnen. In [Mei+07] wird ein Framework vorgestellt, um Ziel-Modelle eines Systems mit den Ziel-Vorstellungen von Benutzern zu vergleichen. Als Basis für das Ziel-Modell des Benutzers werden unter anderem Anforderungsdokumentationen, wie z.B. Use-Cases, vorgeschlagen. Der Ansatz, Ziele aus Use-Cases und anderen Anforderungsdokumenten abzuleiten, wird auch in dieser Arbeit verfolgt. Weitere Herausforderungen bei der Entwicklung adaptiver Software bestehen nach [Sal09] vor allem in dem Aufbau einer adäquaten Architektur und der Wahl von geeigneten Programmiersprachen und Frameworks, die die erforderliche Adaptivität bestmöglich unterstützen. Auch im Bereich des Testens und der Qualitätssicherung von adaptiver Software bestehe noch signifikanter Forschungsbedarf. Insbesondere die hohe Variabilität einer adaptiven Software wirke hierbei erschwerend. Als Ansatz zur Qualitätssicherung werden z.B. Selbst-Test-Verfahren und Evaluation von durch Adaptivität entstandenen Änderungen zur Laufzeit genannt. Bei der Umsetzung der Self-* Properties bestehe insbesondere noch bei der Koordination dieser Eigenschaften und sich daraus ableitbaren Zielen auf unterschiedlichen Ebenen weiterer Forschungsbedarf. Auf technischer Seite steht die Frage nach der Quantität der notwendigen Informationen, die der Software über Sensoren zur Verfügung gestellt werden müssen, weiterhin im Fokus des Interesses. Auch die Fragen, nach welchen Kriterien eine adaptive Software quasi-intelligente Entscheidungen treffen soll, wie diese Entscheidungsmechanismen realisiert werden müssen und wie dabei Interessenkonflikte vermieden und die Integrität des Gesamtsystems gewährleistet werden kann, können bisher nicht abschließend beantwortet werden.

In dieser Arbeit wird von adaptiven Systemen (s. Definition 1) ausgegangen, deren Adaptivität ausschließlich über systemspezifische Regeln definiert wird und keine systemautonome Adaption erfolgen soll. Die Änderung der Regeln muss manuell (d.h. durch einen Anforderungsanalysten) erfolgen.

15

3 Konzept zur Ableitung von Anforderungen durch Benutzerbeobachtung

3.1 VorüberlegungenWie in Kapitel 1.3 beschrieben, bestehen IT-Ökosysteme aus einer Vielzahl autonomer Agenten. Aufgrund der Autonomie der Agenten und der unterschiedlichen Zielen, die diese Agenten verfolgen, können dynamische und unvorhergesehene Effekte eintreten (sogenannte emergente Effekte). Trotz dieser Effekte muss in einem IT-Ökosystem dennoch ein Gleichgewicht herrschen, um die Funktionalität des Gesamtsystems zu gewährleisten. Hierzu ist es erforderlich, dass das IT-Ökosystem emergente Effekte, die durch die Autonomie von Agenten entstehen, einschränkt. [Her+08] schlägt zu diesem Zweck den Einsatz eines Regelsystems vor.

In [Sin+09] wird die Idee eines Regelsystems aufgegriffen und um weitere Aspekte erweitert: So wird vorgeschlagen, bestimmte Anforderungen in Form von Regeln zu formalisieren. Verschiedene Regel könnten außerdem unterschiedlich wichtig sein: Die Einhaltung von Regeln, die Leib und Leben der Benutzer des IT-Ökosystems schützen sollen, hätte eine höhere Priorität als Beachtung von Regeln, die z.B. lediglich der Prozessoptimierung oder der Steigerung des individuellen Komforts der Benutzer dienen. In [Sin+09] werden daher Ansätze, wie z.B. die Einführung einer Regelhierarchie und die Kategorisierung von Regeln, in Regeln, die zwingend eingehalten werden müssen (sogenannte Hard Rules), und Regeln, deren Einhaltung wünschenswert, aber nicht zwingend erforderlich wäre, diskutiert. Ein weiterer wesentlicher Aspekt bezieht sich auf die Gültigkeit von Regeln: [Sin+09] erwähnt, dass sich die Gültigkeit einer Regel durch lokale -, saisonale - und kontextuelle Faktoren verändern könnte, so dass bestimmte Regeln z.B. nur zu einer bestimmten Jahreszeit gelten würden.

Ein Agent des IT-Ökosystems könnte aufgrund seiner Autonomie theoretisch jederzeit gegen eine Regel des Systems verstoßen, wenn diese im Widerspruch zu seinen individuellen Zielen steht. Dies könnte z.B. auch bedeuten, dass sich die Anforderungen des Agenten an das IT-Ökosystem bzw. an ein adaptives Teilsystem geändert haben (vgl. [Sin+09]).

In [Sin+09] wird als Beispiel ein System (SmartFair) vorgestellt, das Besuchern einer Messe einen Parkplatz vorschlägt. Dabei stützt sich das System auf eine Regel, die besagt, dass der Parkplatz, der dem Benutzer vorgeschlagen wird, sich möglichst nahe am Eingang befinden soll, um den Weg, den der Benutzer zu Fuß zurücklegen muss, zu verkürzen. Bei der Beobachtung der Benutzer fällt jedoch auf, dass diese unter bestimmen Rahmenbedingungen nicht den vorgeschlagenen Parkplatz wählen. Bei näherer Analyse der Situation fiel auf, dass die Autofahrer an sonnigen und warmen Tagen einen Parkplatz im Schatten bevorzugten, der nicht zwangsläufig dem Parkplatz entsprach, den das System vorgeschlagen hatte. Vermutlich hatten die Umgebungsbedingungen (Sonne, hohe Temperatur) dazu geführt, dass sich die Prioritäten des Benutzers bei der Wahl eines Parkplatzes geändert hatten. Der Ansatz zur Anforderungserhebung, der in [Sin+09] vorgestellt wird, geht von der Prämisse aus, dass derartige Abweichungen von dem erwarteten Verhalten gute potenzielle Ansatzpunkte für neue bzw. geänderte Anforderungen darstellen könnten. Das Konzept in dieser Arbeit baut auf dieser Idee auf.

16

Der durchgängige Anwendungsfall für das in dieser Arbeit entwickelte Konzept und die Basis für die folgenden Überlegungen ist ein IT-Ökosystem in der Domäne „Flughafen“. Eine Grundannahme besteht darin, dass ein (menschlicher) Teilnehmer des Systems mit grundlegenden Abläufen auf einem Flughafen vertraut ist (z.B. Anreisen, Check-In, usw.). Sollte dies nicht der Fall sein, könnte die Aushändigung von Informationsmaterial oder eine ortsabhängige Hilfe über das Smartphone des Benutzers Abhilfe schaffen. Diese Ansätze sollen jedoch in dieser Arbeit nicht vertieft werden.

Die Vorschriften, die aufgrund von festgelegten Prozessen (z.B. Check-In) oder gesetzlichen Rahmenbedingungen (z.B. das Verbot, bestimmte Gegenstände mit an Bord eines Flugzeugs zu nehmen) festgelegt sind, müssen von allen Agenten des IT-Ökosystems (also von [menschlichen] Besuchern und von allen adaptiven technischen Systemen) eingehalten werden. Im Sinne von Regeln nach [Sin+09] könnten solche Vorschriften als Hard Rules modelliert werden und damit verhindern, dass sich adaptive technische Systeme in ihrer Autonomie gesetzwidrig verhalten oder einen (menschlichen) Benutzer bei der Erreichung eines offenkundig verbotenen Vorhabens unterstützen. Nach [Sin+09] würden Verstöße gegen (obligatorische) Vorschriften im Normalfall nicht als Indikator für geänderte Anforderungen gewertet werden. In dieser Arbeit wird ebenfalls davon ausgegangen, dass nur Verstöße gegen optionale Regeln bzw. Richtlinien als Indikatoren für geänderte Anforderungen betrachtet werden sollen.

3.2 DefinitionenDie Herausforderung bei der Anforderungserhebung in IT-Ökosystemen besteht unter anderem in der heterogenen Gruppe von Benutzern des Systems: Manche Benutzer sind sich nicht der Tatsache bewusst, dass sie sich in einem komplexen IT-System befinden und haben daher keinerlei Verbindung zu diesem System. Es ist anzunehmen, dass diese Benutzer daher wenig bereit wären, aktiv bei der Erhebung von Anforderungen mitzuarbeiten und sich vermutlich ihrer Anforderungen auch gar nicht bewusst wären (vgl. [Sin+09], Kapitel 1.1).

Diese Rahmenbedingungen legen den Einsatz einer Feldbeobachtung als Technik zur Anforderungserhebung nahe. Nach [Rup07] stellen Feldbeobachtungen, wie sie in der Literatur ausführlich beschrieben sind (vgl. Kapitel 2.1), unter den Rahmenbedingungen der geringen Motivation der Benutzer und bei implizitem Benutzerwissen eine geeignete Methode zur Anforderungserhebung dar.

In diesem Kapitel sollen zunächst die grundlegenden Begriffe definiert werden, die die Basis des Konzepts bilden. Eine Übersicht über die Begriffe und ihre Relationen untereinander ist in Kapitel 3.4 dargestellt.

3.2.1 Kontext- und VerhaltensmodellUm das Verhalten der Benutzer zielgerichteter zu beobachten, erscheint es sinnvoll, eine Menge von Attributen zu definieren, mit denen das Benutzerverhalten beschrieben werden kann (s. Abbildung 2). Hierbei ist zu betonen, dass es in Einzelfällen notwendig sein kann, die Menge an Verhaltensattributen noch um weitere Attribute zu erweitern, um das Verhalten eines Benutzers noch differenzierter zu beschreiben. Dies kann jedoch erst im praktischen Einsatz des Konzepts erkannt werden. Die Implementierung wird daher eine Erweiterung der Verhaltensattribute zur Laufzeit zulassen (s. Kapitel 5.1).

17

Für die Ausarbeitung des Konzepts wird idealerweise angenommen, dass die Beobachtung des Benutzers jederzeit problemlos möglich ist. Ob dies auch praktisch umsetzbar ist, wird in Kapitel 4.9 diskutiert.

Das Beispiel aus [Sin+09], bei dem ein Benutzer eine Parkplatzempfehlung, die ihm von dem adaptiven System SmartFair gegeben wird, ignoriert (vgl. auch Kapitel 3.1), lässt den Schluss zu, dass gewisse Umgebungseinflüsse das Verhalten des Benutzers beeinflussen können. Die Menge dieser Umgebungseinflüsse wird in dieser Arbeit als Kontext eines Benutzers definiert:

Definition: Kontext eines Benutzers

Definition 2

Ähnlich wie bei den Attributen des Benutzerverhaltens wird auch für den Kontext eines Benutzers eine Menge von Attributen definiert, um den Kontext besser beschreiben zu können. Das Kontextmodell in dieser Arbeit (s. Abbildung 3) nimmt Aspekte auf, die in [Sit09] erwähnt werden: So werden Beteiligte, „Aktivitäten und die (Einsatz-)Umgebung“ als drei zentrale Aspekte des Kontextes erwähnt. „Beteiligte“ können nach dem Kontextmodell dieser Arbeit sowohl Personen wie auch technische Systeme sein (s. Zweig „Objekte“ in Abbildung 3) , aus der „Umgebung“ werden relevante Einflüsse gemäß der Kontextdefinition (s. Definition 2) mit in das Modell aufgenommen. Der Aspekt „Aktivitäten“ wird an späterer Stelle (s. Definitionen 3 und 4) separat behandelt.

18

Abbildung 3: Modell für den Kontext des Benutzers

Abbildung 2: Attribute des Benutzerverhaltens (Verhaltensmodell)

Der Ort, an dem sich ein Benutzer oder ein technisches System befindet, ist in verschiedenen Veröffentlichungen Teil (vgl. [Dey+99]) der Definition von Kontext. In dieser Arbeit ist der Aufenthaltsort nicht in der Grundmenge der Attribute des Kontextmodells enthalten, wird jedoch als ein separates Element (s. Definition 3) im Konzept berücksichtigt. Die genaue Position und die Positionsveränderungen eines Benutzers sind außerdem im Verhaltensmodell enthalten. Falls während der Anwendung des Konzepts es dennoch notwendig sein sollte, den Standort eines Benutzers als Kontextattribut zu werten, kann das Kontextmodell (analog zum Verhaltensmodell) während der Feldbeobachtung erweitert werden (vgl. Kapitel 5.1).

3.2.2 Aufenthaltsort und Umgebung eines BenutzersEin Benutzer, der sich an einem bestimmten Ort befindet, kann unterschiedliche Arten von Zielen haben: Einerseits können bestimmte Ziele unabhängig vom Aufenthaltsort des Benutzers sein, während andere Ziele ortsabhängig sind. Als Beispiel für ein ortsabhängiges Ziel ist etwa das Ziel „Gepäck einchecken“ zu nennen, das nur am Check-In Schalter eines Terminals des Flughafens erreicht werden kann. Auch das Beispiel des Parkplatzes aus [Sin+09] zeigt, dass der Benutzer grundsätzlich über bestimmte Vorkenntnisse über die Domäne, in der er sich befindet, verfügt und weiß, wie er sie zur Erreichung seiner Ziele verwenden kann (in diesem Beispiel: Der Benutzer weiß, dass er sein Ziel, sein Auto zu parken, in einem Parkhaus erreichen kann). Im Folgenden werden grundsätzlich nur ortsabhängige Ziele des Benutzers betrachtet, da davon ausgegangen wird, dass die adaptiven Systeme in der Domäne, in der das Konzept angewendet wird, ebenfalls stationär sind und der Zusammenhang zwischen (ortsabhängigen) Zielen und Anforderungen zur Anforderungserhebung und Optimierung der adaptiven Systeme ausgenutzt werden kann.

Um ein (ortsabhängiges) Ziel zu erreichen, ist anzunehmen, dass ein Benutzer bestimmte Handlungen vornehmen wird. Diese Handlungen können sich z.B. aus Use-Cases ergeben. In Anbetracht der ortsabhängigen Ziele eines Benutzers, bedeutet dies, dass in bestimmten Teilen der Umgebung eines Benutzers bestimmte Handlungen zu erwarten sind (z.B. Handlung „Parkplatz wählen“ für den Bereich „Parkdeck eines Parkhauses“). Diese Teile der Umgebung sind in dieser Arbeit folgendermaßen definiert:

Definition: Action Area

Definition 3

Bezüglich des Beispiels aus [Sin+09] könnte nach der Definition in dieser Arbeit sowohl das gesamte Parkdeck als auch jeder einzelne Parkplatz als Action Area aufgefasst werden.

19

3.2.3 Erwartetes BenutzerverhaltenErgänzend zu Definition 3 wird die Menge der möglichen Handlungen, die von einem Benutzer in einer Action Area erwartet werden, folgendermaßen definiert:

Definition: Set of expected Actions

Definition 4

Für die Entwicklung und Optimierung eines ortsgebundenen adaptiven Systems ist die Kenntnis der Ziele eines Benutzers von entscheidender Bedeutung. Nach [Poh08] können Ziele sowohl bei der Gewinnung von Anforderungen helfen als auch zur Rechtfertigung von Anforderungen dienen („Trägt eine Anforderung zur Erfüllung eines Ziels bei, so dokumentiert das Ziel die Notwendigkeit dieser Anforderung“). Das Ziel, das ein Benutzer hat, rechtfertigt die Anforderungen, die an das adaptive System gestellt werden. Das adaptive System wiederum befindet sich in derselben Action Area wie der Benutzer und hilft ihm, sein Ziel zu erreichen (s. Abbildung 6).

Das Set of expected Actions (s. Definition 4) umfasst die Gesamtmenge der Handlungen, die in einer Action Area von dem Benutzer erwartet werden. Wie das Parkplatz-Beispiel aus [Sin+09] jedoch zeigt, können die Ziele des Benutzers (und damit auch die Handlungen, die vom Benutzer erwartet werden können) je nach Kontexteinfluss variieren: So führte in dem Parkplatz-Beispiel die hohe Außentemperatur sowie die Sonneneinstrahlung dazu, dass das (ursprüngliche) Ziel des Benutzers, einen geringen Fußweg zum Ausgang zurückzulegen, in den Hintergrund trat und durch das neue Ziel, sein Auto auf einem schattigen Parkplatz abzustellen, ersetzt wurde. Es ist also erforderlich zu definieren, unter welchen Rahmenbedingungen eine bestimmte Handlung von einem Benutzer in einer Action Area erwartet werden kann. Dies führt zu folgender Definition:

Definition: Erwartetes Benutzerverhalten

Definition 5

Die Rahmenbedingungen, unter denen eine bestimmte Handlung von einem Benutzer bzw. einer bestimmten Gruppe von Benutzern erwartet werden kann, findet sich in der Definition des erwarteten Benutzerverhaltens in Form der sogenannten Anwendungsbedingung (s. Definition 6) wieder. Die Anwendungsbedingung verwendet eine Menge von 2-Tupeln, die sich jeweils aus einem Attribut aus dem Kontextmodell (s. Abbildung 3) und einem zugehörigen Wert zusammensetzen.

20

Zusätzlich ist noch ein Feld für eine (beliebige) Bedingung vorgesehen für den Fall, dass es noch weitere relevante Rahmenbedingungen gibt, die in die Anwendungsbedingung einfließen sollten, die sich aber nicht mit Hilfe von Kontextattributen formalisieren lassen. Als Beispiel könnte etwa eine bestimmte Uhrzeit genannt werden, die (nach Definition 2) nicht Teil des Kontextmodells ist.

Definition: Anwendungsbedingung

Definition 6

Die Anwendungsbedingung legt fest, unter welchen Rahmenbedingungen ein bestimmtes Systemverhalten von einem adaptiven System zu erwarten ist (ausgedrückt durch eine Regel [s. Definition 7]) und welches Verhalten von einem Benutzer unter denselben Rahmenbedingungen erwartet wird (ausgedrückt durch das erwartete Benutzerverhalten).

3.2.4 Regeln für adaptive SystemeAnalog zur Definition des erwarteten Benutzerverhaltens, das unter einer bestimmten Anwendungsbedingung gilt, ist es noch erforderlich zu definieren, wie sich ein adaptives System in der Nähe des Benutzers verhalten soll. Dies führt zu folgender Definition:

Definition: Regel

Definition 7

Die Definition der Regel beinhaltet die konkrete Anforderung und das adaptive System, für das diese Anforderung gilt. In Anlehnung an die Vorschläge aus [Sin+09] (vgl. auch Kapitel 3.1) enthält die Regeldefinition eine Prioritätsangabe, die für die Ausführung der Regel gilt. Analog zu dem erwarteten Benutzerverhalten (s. Definition 5) gilt auch für die Regel eine Anwendungsbedingung (s. Definition 6). In dieser Arbeit wird davon ausgegangen, dass es für jedes adaptive System schon eine bestimmte Menge an Basis-Anforderungen gibt, die mit Hilfe der Regeldefinition formalisiert werden. Nicht alle Anforderungen, die an ein adaptives System gestellt werden, müssen als Regeln dargestellt werden. Eine Anforderung, wie z.B. „Das System soll die Benutzerdaten in verschlüsselter Form speichern“, wäre für die Interaktion des Benutzers mit dem System wenig relevant. Vorzugsweise würden jene Anforderungen als Regeln formuliert werden, die sich auf die Interaktion zwischen Benutzer und System auswirken.

Es ist zu betonen, dass es sich bei Regeln nach Definition 7 nicht um globale Regeln handelt (vgl. [Her+08]), sondern dass sich jede Regel konkret auf das Systemverhalten eines speziellen adaptiven Systems bezieht. Bei der Erstellung der Regeln (basierend auf den Anforderungen eines adaptiven Systems) sind jedoch Grenzen und Einschränkungen zu beachten, die von globalen Regeln vorgegeben werden.

21

3.3 Anwendung des KonzeptsDie Anwendung der bisher vorgestellten Definitionen auf das Parkplatz-Beispiel aus [Sin+09] wird in Formalisierung 1 gezeigt. Es wird davon ausgegangen, dass es ein adaptives System („Parkleitsystem“) in der Action Area „Parkdeck eines Parkhauses“ gibt, das gemäß der formulierten Regeln dem Benutzer einen Parkplatz nahe am Fußgängereingang zuweisen soll. Analog zu den Regeln wird durch das erwartete Benutzerverhalten von dem Benutzer vermutet, dass er einen Parkplatz nahe am Eingang (der gleichzeitig auch der Ausgang des Parkdecks ist) wählt. Dieses Verhalten wird nur von einer bestimmten Benutzergruppe erwartet – nämlich von den Benutzern, die das Parkdeck mit ihrem PKW befahren. Für andere Benutzergruppen, wie z.B. für Benutzer, die mit ihrem PKW das Parkdeck verlassen möchten, gilt das erwartete Benutzerverhalten nicht. Demzufolge gelten auch die Regeln für das adaptive System nur in Bezug auf die festgelegte Benutzergruppe. Schließlich ist noch die Anwendungsbedingung zu erwähnen, die bestimmt, unter welchen (kontextuellen) Rahmenbedingungen die Regel für das adaptive System gilt und das erwartete Benutzerverhalten zu erwarten ist. Die Anwendungsbedingung (s. Formalisierung 1) berücksichtigt bereits den Spezialfall aus [Sin+09], dass ein Benutzer nur unter bestimmten Rahmenbedingungen einen Parkplatz nahe am Eingang zugewiesen bekommen möchte. Bei hoher Außentemperatur und Sonne bevorzugt der Benutzer einen Parkplatz im Schatten (der unter Umständen weiter entfernt vom Ausgang liegt).

Action Area = „Parkdeck eines Parkhauses“

Set of expected Actions = {„Parkplatz suchen“, „Parkplatz wählen“, „Parkplatz verlassen“}

Regel = („Benutzer soll Parkplatz nahe Ausgang zugewiesen werden“, 3, Anwendungsbedingung, „Autofahrer, die das Parkdeck mit ihrem PKW befahren“, „Parkleitsystem“)

Erwartetes Benutzerverhalten = („Parkplatz wählen“, „Benutzer wählt Parkplatz nahe am Ausgang“, {(Abstand zu Ausgang, minimal)}, Anwendungsbedingung, „Autofahrer, die das Parkdeck mit ihrem PKW befahren“)

Anwendungsbedingung = ( {(Temperatur, < 25 °C), (Sonne, Nein)}, -)

Formalisierung 1: Parkplatz-Beispiel nach [Sin+09]

Eine entscheidende Frage ist, unter welchen Rahmenbedingungen das Verhalten des Benutzers von dem erwarteten Benutzerverhalten abweicht und ob diese Verhaltensabweichung überhaupt in einem Zusammenhang zu einem äußeren Einfluss steht. Wie der Zusammenhang zwischen Benutzerverhalten und Kontexteinflüssen hergestellt werden kann, wird an späterer Stelle im Konzept vorgestellt.

Um zu analysieren, ob eine Verhaltensabweichung vom erwarteten Benutzerverhalten mit äußeren Einflüssen zusammenhängen könnte, wird bei der Beobachtung des Benutzers zunächst eine Menge von Kontextattributen aufgezeichnet. So könnten z.B. im Parkplatz-Beispiel aus

22

[Sin+09] die Außentemperatur und die Lichtverhältnisse relevante Kontextparameter sein, da der Benutzer bei Sonne und warmer Außentemperatur einen schattigen Parkplatz bevorzugt, der nicht zwangsläufig nahe am Ausgang liegt.

Von zentraler Bedeutung ist die Frage, welche Kontextattribute bei der Benutzerbeobachtung aufgezeichnet werden sollten. Tendenziell ist es zu empfehlen, im Zweifelsfall eher mehr Parameter zu berücksichtigen als zu wenige, um das Risiko zu reduzieren, dass relevante Informationen zum Zeitpunkt der Auswertung fehlen. Um die Menge der relevanten Kontextattribute abzuschätzen, muss (vor jeder einzelnen Beobachtung eines Benutzers) eine Einschätzung getroffen werden, welche Parameter von dem Benutzer am stärksten wahrgenommen werden würden. Als Heuristik könnte z.B. der räumliche Abstand des Kontextattributs zum Benutzer verwendet werden oder der Beobachter könnte (sofern er sich nahe dem zu beobachtenden Benutzer aufhält) subjektiv einschätzen, welche Kontexteinflüsse in der aktuellen Situation besonders stark wahrnehmbar sind. Eine solche Abschätzung könnte zusätzlich noch durch mehrere andere Beobachter abgesichert werden. Um den Aufwand einer einzelnen Benutzerbeobachtung zu reduzieren, kann die Einschätzung, welche Kontextattribute vom Benutzer am stärksten wahrgenommen werden, auch aus einer vorherigen Beobachtung übernommen werden. In welchem Fall die Kontextparameter neu bestimmt werden müssen, muss von den Beobachtern abgeschätzt werden.

Nachdem verschiedene Benutzer beobachtet worden sind, können nun Abweichungen vom erwarteten Benutzerverhalten und die Kontexteinflüsse, die zur Zeit der beobachteten Abweichung vorlagen, tabellarisch gegenübergestellt werden (s. Tabelle 1). Die prozentuale Verhaltensabweichung für einen Benutzer ergibt sich aus der Anzahl der 2-Tupel (Verhaltensattribut, Wert) des erwarteten Benutzerverhaltens, die vom Benutzer nicht eingehalten worden sind (z.B. (Abstand zum Ausgang, minimal) wurde nicht eingehalten → Verstoß gegen das einzige 2-Tupel in der Regel → 100 % Abweichung vom erwarteten Verhalten).

Kontextattribut 1 ... Kontextattribut n

Benutzer 1: x % [Wert Kontextattribut 1] ... [Wert Kontextattribut n]

Benutzer 2: y % [Wert Kontextattribut 1] ... [Wert Kontextattribut n]

... ... ... [Wert Kontextattribut n]

Benutzer n: z % [Wert Kontextattribut 1] ... [Wert Kontextattribut n]

Tabelle 1: Abweichung vom erwarteten Verhalten und Werte der gemessenen Kontextattribute

Weicht das Verhalten eines Benutzers von dem erwarteten Verhalten ab, so ist es wahrscheinlich, dass sich die Ziele eines Benutzers geändert haben. Im Parkplatz-Beispiel aus [Sin+09] hatte sich das ursprüngliche Ziel des Benutzers, einen Parkplatz nahe am Ausgang zu wählen (s. Abbildung 4), an sonnigen und warmen Tagen dahingehend geändert, dass der Benutzer mehr Wert auf einen schattigen Parkplatz gelegt hatte (Abbildung 5).

23

Verhaltens-abweichung bei Benutzer

Kontext-attribute

24

Abbildung 4: Ziel des Autofahrers bei der Wahl des Parkplatzes (i*-Notation)

Abbildung 5: Ziel des Autofahrers bei der Wahl des Parkplatzes an einem sonnigen und warmen Tag (i*-Notation)

Parkplatz nahe am Ausgang wählen

ParkleitsystemAusgang schnell zu Fuß erreichen Parkplatz wählen

Autofahrer

Auto im Schatten abstellen

ParkleitsystemErhitzung des Fahrzeug verhindern Parkplatz wählen

Autofahrer

Denkbar sind aber auch Situationen, in der sich das Ziel eines Benutzers nicht geändert hat, ihn aber ein Kontexteinfluss an der Erreichung dieses Ziels hindert: So könnte z.B. eine nicht-funktionierende Beleuchtung in einer Tiefgarage dazu führen, dass der Benutzer Probleme hat, zu Fuß den Ausgang zu finden. Wichtig ist außerdem zu ermitteln, ob der Benutzer nur eine längere Zeit braucht, um den Ausgang zu finden (die Erreichung des Softgoals „Ausgang des Parkdecks schnell zu Fuß erreichen“ wird verhindert) oder ob er den Ausgang überhaupt nicht mehr erreichen kann.

Ein Benutzer kann jedoch auch Ziele haben, die in keinerlei Zusammenhang mit seinem Aufenthaltsort oder einem Kontexteinfluss stehen. So könnte ein Benutzer z.B. zu jeder Zeit eine ihm bekannte Person anrufen wollen.

Insgesamt ergeben sich, was die Zielanalyse eines Benutzers betrifft, folgende Fragen:

1. Wird das Ziel des Benutzers von seinem Aufenthaltsort (Action Area) bestimmt?2. Wird das Ziel des Benutzers von einem Kontexteinfluss bestimmt?3. Behindert ein Kontexteinfluss den Benutzer bei der Erreichung des Ziels?

Tabelle 2 zeigt eine Übersicht über die relevanten Kombinationsmöglichkeiten:

Fall

Wird das Ziel des Benutzers von seinem Aufenthaltsort (Action Area) bestimmt?

Wird das Ziel des Benutzers von einem Kontexteinfluss

bestimmt?

Behindert ein Kontexteinfluss den Benutzer bei der Erreichung des Ziels?

1 Ja - -

2 - Ja -

3 Ja Ja -

4 Ja - Ja

Tabelle 2: Übersicht über die relevanten Fälle bei der Zielanalyse der Benutzer

Die Fälle, in denen ein Benutzer ein Ziel verfolgt, das weder mit seinem Aufenthaltsort noch einem Kontexteinfluss in Verbindung steht, werden als irrelevant eingestuft, da diese Fälle zu individuell sind, als dass eine Anpassung der ortsabhängigen adaptiven Systeme an diese Ziele für die Allgemeinheit hilfreich wäre.

Jede Beobachtung eines Benutzers muss einem der Fälle aus Tabelle 2 zugeordnet werden. Diese Zuordnung sollte durch einen Beobachter gemäß seiner subjektiven Einschätzung vorgenommen werden, der sich zum Zeitpunkt der Beobachtung in derselben Action Area befindet wie der zu beobachtende Benutzer. Die möglichen Reaktionen auf die in Tabelle 2 vorgestellten Fälle sind in Tabelle 3 dargestellt.

25

Fall aus Tabelle 2 Mögliche Konsequenz für adaptives System

1 Dem Benutzer helfen, sein Ziel effizienter zu erreichen (z.B. bessere Usability)

2 Smartphone des Benutzers: Kontextspezifische Tipps anzeigen

3 Kontexteinfluss als Sonderfall berücksichtigen

4 Störeinfluss ausgleichen

Tabelle 3: Mögliche Konsequenzen für adaptive Systeme bezüglich der Fälle in Tabelle 2

Die Konsequenzen für die adaptiven Systeme könnten gemäß Tabelle 3 wie folgt aussehen:

• Im Fall 1 könnte eine Reaktionsweise eines adaptiven System darin bestehen, den Benutzer dabei zu unterstützen, sein Ziel noch effizienter zu erreichen, indem das System z.B. unter Usability-Aspekten noch weiter optimiert wird.

• Im Fall 2 könnte das Smartphone eines Benutzers ihm kontextabhängige Hilfestellungen geben. Die adaptiven Systeme in den einzelnen Action Areas wären hierfür wenig geeignet, da das Ziel des Benutzers in diesem Fall nicht von dem Aufenthaltsort (Action Area) abhängt. Beispielsweise könnte ein Smartphone einem Benutzer an einem warmen und sonnigen Tag Empfehlungen geben, wo er Getränke erwerben kann.

• Fall 3 tritt z.B. in dem Parkplatzbeispiel (vgl. [Sin+09]) ein, wo das Ziel des Benutzers (einen bestimmten Parkplatz zu wählen) zum einen von der Action Area (Parkdeck) abhängt, zum anderen auch von Kontexteinflüssen, wie z.B. der Umgebungstemperatur. In diesem Fall ist der Kontexteinfluss bzw. die Kontexteinflüsse als Sonderfall zu berücksichtigen, so dass die Regel (und v.a. die Anwendungsbedingung der Regel) für das adaptive System (Parkleitsystem) zu verändern ist.

• Im Fall 4 könnte ein adaptives System versuchen, den Störeinfluss, der den Benutzer an der Erreichung seines Ziels hindert, auszugleichen (sofern das adaptive System dazu in der Lage ist). Ein Beispiel wäre etwa eine adaptive digitale Infotafel (s. Kapitel 4.7), die abhängig von den Lichtverhältnissen ihre Helligkeits- und Kontrastwerte verändert, um weiterhin eine gute Lesbarkeit der dargestellten Informationen für den Benutzer zu gewährleisten.

Bezogen auf die Regeln, die für das adaptive System gelten, würden in den Fällen 1 und 4 unter Umständen neue Regeln entstehen, die auf neuen Anforderungen basieren. Es wäre aber auch denkbar, dass z.B. in Fall 1 kein Optimierungsbedarf für ein adaptives System erkennbar wäre, was wiederum auch keine neuen Anforderungen nach sich ziehen würde. Auch in Fall 4 müsste überprüft werden, inwiefern das adaptive System den Störeinfluss überhaupt ausgleichen könnte oder ob Optimierungsmaßnahmen an Infrastruktur, Gebäude etc. hierfür nicht geeigneter wären. In Fall 3 würde sich vor allem die Anwendungsbedingung für eine Regel verändern, so dass unter bestimmten Kontexteinflüssen Ausnahmen von der (zunächst allgemeingültigen) Regel erstellt werden müssten.

26

3.4 ER-Modell des KonzeptsAbbildung 6 gibt eine Übersicht über die Entitäten des Konzepts und deren Relationen zueinander. Ausgehend von Zielen, die ein Benutzer, der sich in einer Action Area befindet, hat, existieren in einer Action Area adaptive Systeme, die ihn bei der Erreichung dieser Ziele unterstützen. Hieraus ergeben sich Anforderungen an die adaptiven Systeme, deren Existenz durch die Ziele des Benutzer gerechtfertigt werden. Die Kontexteinflüsse können das Verhalten des Benutzers (und unter Umständen indirekt auch die Ziele) beeinflussen. Die einzelnen Handlungen des Benutzers bilden das Set of expected Actions, was zu einer Action Area gehört.

27

Abbildung 6: ER-Modell des Konzepts

Benutzerbefindet sich in

hat

befindet sich in

Anforderung

hilft bei derErfüllung von

rechtfertigt

wird ausgedrücktdurch

gilt für

gehört zu

gilt für

AdaptivesSystem

1

1 1:n

1:n

Action Area

1

11

dient zur Erreichung

von

gilt beibestimmten

beeinflusst

ist Teil vonSet of expected Actions1 1

1:n1:n

Regel 11:n1:n

Kontexteinflüsse1:n *

1:n

11:n

ErwartetesBenutzerverhalten

1:n

1:n

1:n

Ziel

1

1:n

11:n

3.5 Ablauf der Anwendung des KonzeptsIm Folgenden wird der Prozess der Anwendung (s. auch Kapitel 4) des Konzepts erläutert (s. Abbildung 7):

1. Im ersten Schritt wird die Action Area festgelegt. Die Festlegung der Action Area kann zunächst relativ großzügig vorgenommen werden (z.B. eine ganze Halle in einem Gebäude). Im Laufe der Zeit können weitere kleinere Action Areas definiert werden.

2. Es werden die relevanten adaptiven Systeme in der Action Area identifiziert. Hierzu zählen nach Definition 1 nur Systeme, die einen Softwareanteil enthalten.

3. Um die Ziele des Benutzers zu ermitteln, können bereits existierende Anforderungsdokumente als Quellen herangezogen werden. Insbesondere Use-Cases könnten hierbei aufgrund ihres zielbezogenen Charakters wertvolle Hinweise enthalten.

4. Als nächstes wird das Set of expected Actions erstellt. Auch hierbei können wieder Use-Cases sowie andere bereits existierende Anforderungsdokumente als Quellen dienen.

5. In diesem Schritt müssen nun die bereits bekannten Anforderungen für die adaptiven Systeme als Regeln formalisiert werden. Um quasi die Grundmenge an Regeln für ein System zu erstellen, können abermals Anforderungsdokumente als Quelle dienen. Die Regeln (und damit auch die Anforderungen des jeweiligen adaptiven Systems) können durch Anwendung des Konzepts iterativ erweitert und verbessert werden.

6. Analog zur Regel muss nun das erwartete Benutzerverhalten definiert werden. Hierbei wird aus dem Set of expected Actions eine Handlung des Benutzers gewählt und in Form von 2-Tupeln aus den Attributen des Benutzerverhaltens (s. Abbildung 2) festgelegt, welche (beobachtbare) Eigenschaften der Benutzer während der Ausführung der Handlung zeigt.

Nachdem die Regeln und das erwartete Benutzerverhalten modelliert worden sind, besteht der nächste Schritt darin, die Anwendungsbedingung zu modellieren, die für die Regeln und das erwartete Benutzerverhalten gilt. Die Anwendungsbedingung enthält einerseits eine Menge von Attributen aus dem Kontextmodell (s. Abbildung 3) und den dazugehörigen Werten und andererseits eine beliebige andere Bedingung, die erfüllt sein muss, damit die Anwendungsbedingung gültig ist (z.B. eine bestimmte Uhrzeit). Beide Parameter der Anwendungsbedingung sind optional. Ist die Anwendungsbedingung leer, so ist sie immer erfüllt, d.h. die dazugehörigen Regeln gelten immer und das entsprechende erwartete Benutzerverhalten ist zu jeder Zeit und unter beliebigen Kontexteinflüssen zu erwarten. Durch Anwendung des Konzepts kann die Anwendungsbedingung iterativ verfeinert werden, so dass die Regeln z.B. nur unter bestimmten Kontexteinflüssen gültig sind (analog für das erwartete Benutzerverhalten). Der Vorgang der iterativen Regelverbesserung wird auch in [Sin+09] vorgestellt.

28

7. Der Subprozess der Benutzerbeobachtung wird in Abbildung 8 gezeigt: Dabei müssen zunächst die Attribute aus dem Kontextmodell, die gemessen werden sollen, festgelegt werden (Schritt 7a). Hinweise für die Wahl der relevanten Kontextattribute sind auf Seite 23 erwähnt.

Die Schritte 7b1 (Verhaltensattribute des Benutzers dokumentieren) und 7b2 (Kontextattribute dokumentieren) werden parallel und vorzugsweise von zwei unterschiedlichen Beobachtern durchgeführt. Diese beiden Schritte beginnen, sobald der Benutzer mit der Aktion, die im erwarteten Benutzerverhalten definiert worden ist, beginnt.

Der Schritt 7c (Zielanalyse) besteht darin einzuschätzen, welcher Fall aus Tabelle 2 vorliegt. Hierbei muss sich der Beobachter abermals auf seine subjektive Einschätzung verlassen.

8. Nach abgeschlossener Benutzerbeobachtung müssen nun die Verhaltensweisen des Benutzers mit dem erwarteten Benutzerverhalten verglichen werden. Hierbei sind die Fälle von besonderem Interesse, in denen die Benutzer gegen besonders viele Verhaltensattribute verstoßen haben.

9. Der nächste Schritt besteht in der Gegenüberstellung der prozentualen Verhaltensabweichung der Benutzer und den Werten der Kontextparameter (s. Tabelle 1).

Bei größeren Datenmengen sind auch Data Mining-Ansätze oder statistische Analyse der Daten denkbar, um Muster zu erkennen, die eine Korrelation zwischen Benutzerverhalten und Kontexteinflüssen nahelegen.

10. Aus den Beobachtungen und deren Auswertung müssen nun Konsequenzen für die Regeln bzw. für das Verhalten der adaptiven Systeme abgeleitet werden (s. Tabelle 3)

11. Im letzten Schritt werden nun konkrete neue Anforderungen formuliert und Regeln überarbeitet. Hierbei sind jedoch mögliche Zielkonflikte zwischen verschiedenen Zielen oder Anforderungen zu beachten (vgl. Kapitel 4.8). So könnten sich sowohl Ziele einzelner Benutzer gegenseitig widersprechen, aber auch das Ziel eines einzelnen Benutzers im Widerspruch zu systemweiten Zielen mit höherer Priorität stehen.

29

30

Abbildung 7: Prozess der Anwendung des Konzepts

Abbildung 8: Subprozess der Benutzerbeobachtung

2: Adaptive Systeme in Action Area identifizieren

1: Action Area definieren

3: Ziele (Goals) und Softgoals des Benutzers für Action Area definieren

4: Set of expected Actions aufstellen

5: Regeln für adaptive Systeme aufstellen

6: Erwartetes Benutzerverhalten definieren

7: Benutzerbeobachtung und Dokumentation

8: Dokumentiertes Benutzerverhalten mit erwartetem Benutzerverhalten vergleichen

9: Abweichung von erwartetem Benutzerverhalten mit gemessenen Kontextattributen in Zusammenhang bringen

10: Konsequenzen für adaptive Systeme ableiten

11: Neue Anforderungen ableiten und Regel überarbeiten

7a: Kontextattribute, die gemessen werden sollen, festlegen

7c: Zielanalyse

[Messung beenden]

7b1: Verhaltensattribute des Benutzers dokumentieren 7b2: Kontextattribute dokumentieren

[Messung fortsetzen]

4 Exemplarische Anwendung des KonzeptsUm die Anwendung des Konzepts zu demonstrieren, wird in diesem Kapitel ein Beispiel aus der Domäne „Flughafen“ vorgestellt.

Abbildung 9 zeigt eine (fiktive) Flughafenhalle, in der sich verschiedene Besucher aufhalten. Zwecks Vereinfachung wurden nur einige zentrale Elemente in die Skizze integriert, wie z.B. die Check-In Schalter, ein Wartebereich sowie ein Bereich mit einem Gepäckband, in dem Anreisende ihre Gepäckstücke entgegen nehmen können. Die Flughafenhalle verfügt zudem über zwei Eingänge: Zum einen existiert ein Haupteingang, der gleichermaßen auch der Ausgang der Halle ist und zum anderen existiert im oberen Bereich der Skizze ein Eingang für Anreisende.

Die folgenden Unterkapitel demonstrieren die Anwendung des Konzepts in der Flughafenhalle gemäß Abbildung 7.

31

Abbildung 9: Flughafenhalle mit verschiedenen Action Areas

HaupteingangGepäckwagen

Check-In Schalter

WartebereichBenutzer A

InfotafelnAction Area

a1

Benutzer B

Gepäckband

a2.1

a2.2

a2.3

Eingang (für Anreisende)

Benutzer D Benutzer C

4.1 Definition der Action Areas und Identifikation der adaptiven SystemeDer erste Schritt (vgl. Abbildung 7) besteht in der Definition der Action Areas. Nach der Beschreibung des Ablaufs des Konzepts (s. Seite 28) kann die Definition der Action Areas zunächst relativ großzügig erfolgen (z.B. wenn noch keine Anhaltspunkte für ortsabhängiges Benutzerverhalten vorliegen und dies erst durch eine Feldbeobachtung ermittelt werden muss). Im Beispiel der in Abbildung 9 vorgestellten Flughafenhalle existieren jedoch schon bestimmte Bereiche, in denen ein bestimmtes Benutzerverhalten wahrscheinlich ist. Diese Bereiche stellen gute Kandidaten für Action Areas dar. Im Folgenden werden zwei Action Areas definiert: Der Bereich vor den Infotafeln (a1) und der Bereich um das Gepäckband (a2.1 + a2.2 + a2.3 = a2). Im Fall von a2 wurde außerdem von der Möglichkeit Gebrauch gemacht, eine Action Area aus verschiedenen kleineren Action Areas zusammenzusetzen (vgl. Definition 3). Warum dies in diesem Fall sinnvoll sein könnte, wird an späterer Stelle verdeutlicht.

Die Identifizierung der adaptiven Systeme stellt den zweiten Schritt (vgl. Abbildung 7) dar. Die technischen Systeme in den beiden definierten Action Areas sind die Infotafeln in a1 und das Gepäckband in a2. Um Definition 1 Rechnung zu tragen, wird im Folgenden davon ausgegangen, dass sowohl die Infotafeln sowie das Gepäckband einen Softwareanteil enthalten und ihr adaptives Systemverhalten sich über die Software verändern lässt. Die Infotafeln sollen demnach ein adaptives Benutzerinformationssystem sein, das einen Besucher des Flughafens über Details zu Flügen informiert und das Gepäckband soll ein adaptives Gepäckverteilungssystem sein. In Anlehnung an das adaptive System SmartFair aus [Sin+09], das Messebesuchern einen Parkplatz auf einem Parkdeck zuweist, wird das System der Infotafeln im Folgenden SmartInfo und das Gepäckverteilungssystem, zu dem das Gepäckband gehört, SmartBaggage genannt.

4.2 Definition der Ziele der BenutzerIm nächsten Schritt werden die Ziele der Benutzer definiert. Ausgehend von den Anforderungsspezifikationen von SmartInfo und SmartBaggage können die Ziele der Benutzer ermittelt werden. Hierbei sind jedoch nicht nur die gewöhnlichen Ziele (Goals), sondern auch die Softgoals zu berücksichtigen (vgl. Abbildung 1).

Abbildung 10 und Abbildung 11 stellen die Ziele für die Benutzer in den Action Areas a1 und a2

in i*-Notation (vgl. Abbildung 1) dar. Es ist zu betonen, dass ein Benutzer durchaus mehrere (ortsabhängige) Ziele in einer Action Area haben kann. In diesem Fall wird jedoch nur von einem Ziel je Action Area ausgegangen.

Das in Abbildung 10 dargestellte Ziel besteht darin, dass ein Flughafenbesucher die Abflugs- bzw. Ankunftszeit eines relevanten Flugs erfahren möchte. Zur Erreichung dieses Ziels trägt sowohl das Softgoal „Schnelles Ablesen“ sowie das (adaptive) System „Infotafel“ und der Task „Infotafel lesen“ bei. Analog ist in Abbildung 11 das Ziel eines Anreisenden („Eigenes Gepäckstück erhalten“) mit den Faktoren, die zur Erreichung dieses Ziels dienen, dargestellt.

32

33

Abbildung 10: Modellierung der Ziele des Benutzers für Action Area a1 (i*-Notation)

Abbildung 11: Modellierung der Ziele des Benutzers für Action Area a2 (i*-Notation)

Abflugs- bzw. Ankunftszeit des

relevanten Flugs erfahren

Infotafel

Flughafen-besucher

InfotafellesenSchnelles

Ablesen

Eigenes Gepäckstück erhalten

Gepäckband

Anreisender

Gepäckstück aufnehmenSchnelles

Aufnehmen

4.3 Set of expected Actions für Action Areas definierenNach der Modellierung der Benutzerziele wird nun das Set of expected Actions erstellt. Hierzu können abermals vorliegende Use-Cases der adaptiven Systeme als Quelle verwendet werden, die unter Umständen Handlungsschritte des Benutzers enthalten, die für das Set of expected Actions relevant sein könnten. Die Formalisierungen 2 und 3 stellen das Set of expected Actions für die Action Areas in diesem Beispiel dar.

{„Infotafel lesen“}

Formalisierung 2: Set of expected Actions für a1

{„Sich eigenem Gepäckstück nähern“, „Gepäckstück aufnehmen“, „Sich mit Gepäckstück vom Gepäckband entfernen“}

Formalisierung 3: Set of expected Actions für a2

4.4 Regeln und erwartetes Benutzerverhalten aufstellenDer nächste Schritt besteht in der Modellierung der Regeln für die adaptiven Systeme und des erwarteten Benutzerverhaltens. Ausgangspunkt ist ein Ziel, das der Benutzer in der Action Area erreichen will (s. Abbildungen 10 und 11). Die Regel enthält eine konkrete Anforderung an ein adaptives System, die wiederum durch ein Ziel, das der Benutzer hat, gerechtfertigt wird (s. Abbildung 6). Das erwartete Benutzerverhalten stellt dar, welche beobachtbaren Verhaltensattribute (s. Abbildung 2) mit den dazugehörigen Werten ein Benutzer bei der Ausführung einer Handlung erwartungsgemäß zeigen wird (z.B. Während der Benutzer die Handlung „Infotafel lesen“ ausführt, zeigt er u.a. das Verhaltensattribut „Körperhaltung“ mit Wert „stehend“, s. Formalisierung 4).

Die Tabellen 4 und 5 geben einen Überblick über die Ziele des Benutzers in der jeweiligen Action Area, die relevanten adaptiven Systeme, die den Benutzer bei der Erreichung seiner Ziele unterstützen, und die Anforderungen, die sich daraus an die adaptiven Systeme ergeben.

Ziel des Benutzers Relevantes adaptives System zur Zielerfüllung

Anforderungen an adaptives System

Abflugs- bzw. Ankunftszeit des relevanten Flugs erfahren

SmartInfo • Infotafeln sollen dem Benutzer die Zeit des für ihn relevanten Flugs anzeigen

• Benutzer soll die Abflugzeit in einer Zeit unterhalb von 30 Sekunden ablesen können

• Informationen auf dem Display sollen aus mehr als einem Meter Entfernung für den Benutzer lesbar sein

Tabelle 4: Ziel des Benutzers, adaptives System und Anforderungen an das adaptive System für Action Area a1

34

Ziel des Benutzers Relevantes adaptives System zur Zielerfüllung

Anforderungen an adaptives System

Eigenes Gepäckstück erhalten SmartBaggage • Die Gepäckstücke auf dem Gepäckband sollen nach der Position der Benutzer, die am Gepäckband stehen, sortiert sein.

• Die Bewegungsgeschwindigkeit des Gepäckbandes soll so hoch sein, dass jedes Gepäckstück sich 1 Sekunde lang im Bereich vor einem Benutzer, der am Gepäckband steht, befindet

Tabelle 5: Ziel des Benutzers, adaptives System und Anforderungen an das adaptive System für Action Area a2

Der letzte Schritt besteht darin, die Anwendungsbedingung festzulegen. Im Fall der Action Areas a1 und a2 ist die Anwendungsbedingung leer, was bedeutet, dass die Regeln für die adaptiven Systeme jederzeit gelten und das entsprechende erwartete Benutzerverhalten ebenfalls jederzeit erwartet wird.

Ein Beispiel für Regeln, erwartetes Benutzerverhalten und Anwendungsbedingungen für die Action Areas a1 und a2 finden sich in den Formalisierungen 4 und 5.

Set of expected Actions = {„Infotafel lesen“}

Regel = („Benutzer soll es ermöglicht werden, aus einem Abstand von über 1 Meter in weniger als 30 Sekunden die relevante Abflugs- bzw. Ankunftszeit von der Infotafel abzulesen“, 3, Anwendungsbedingung, „Besucher, die vor einer Infotafel stehen und sie lesen“, „SmartInfo“)

Erwartetes Benutzerverhalten = („Infotafel lesen“, „Benutzer liest Abflugs- bzw. Ankunftszeit ab“, {(Abstand zur Infotafel, >1 Meter), (Körperhaltung, stehend), (Dauer der Betrachtung der Infotafel, < 30 Sekunden)}, Anwendungsbedingung, „Besucher, die vor einer Infotafel stehen und sie lesen“)

Anwendungsbedingung = ({}, -)

Formalisierung 4: Set of expected Actions, Regel und erwartetes Benutzerverhalten für a1

35

Set of expected Actions = {„Sich eigenem Gepäckstück nähern“, „Gepäckstück aufnehmen“, „Sich mit Gepäckstück vom Gepäckband entfernen“}

Regel = („Das Gepäckstück eines Benutzers soll sich bei laufendem Gepäckband 1 Sekunde lang im Bereich vor dem Benutzer befinden“ Anwendungsbedingung, „Besucher, die vor dem Gepäckband stehen und auf ihr Gepäckstück warten“, „SmartBaggage“)

Erwartetes Benutzerverhalten = („Sich eigenem Gepäckstück nähern“, „Benutzer nähert sich seinem Gepäckstück“, {(Körperhaltung, stehend), (Verweildauer vor eigenem Gepäckstück, 1 Sekunde)}, Anwendungsbedingung, „Besucher, die vor dem Gepäckband stehen und auf ihr Gepäckstück warten“)

Anwendungsbedingung = ({}, -)

Formalisierung 5: Set of expected Actions, Regel und erwartetes Benutzerverhalten für a2

4.5 Benutzerbeobachtung durchführen

Nachdem das erwartete Benutzerverhalten sowie die Regeln für die adaptiven Systeme in den Action Areas sowie die jeweiligen Anwendungsbedingungen festgelegt worden sind, besteht gemäß Abbildung 7 der nächste Schritt in der Durchführung der Benutzerbeobachtung.

Zunächst muss festgelegt werden, welche Kontextattribute (s. Abbildung 3) während der Benutzerbeobachtung aufgezeichnet werden sollen (s. Abbildung 8, Schritt 7a). In der Action Area a1 wird etwa das Licht als relevantes Kontextattribut gewählt. Diese Wahl ergibt sich aus der Tatsache, dass das Licht die visuelle Wahrnehmung des Benutzers während der Interaktion mit SmartInfo beeinflussen könnte. Weiterhin wird noch das Vorhandensein einer weiteren Infotafel als relevant eingestuft. In a2 dagegen wird die Anzahl der Personen in seinem Umfeld (bzw. genauer im Radius von einem Meter) und der Abstand zum Gepäckband als relevante Kontextattribute gewählt.

Gemäß dem Ablauf der Benutzerbeobachtung in Abbildung 8 sollten vor jeder einzelnen Benutzerbeobachtung die aufzuzeichnenden Kontextattribute neu bestimmt werden. Jedoch ist es auch denkbar, dass sich die Umgebungseinflüsse zwischen zwei Benutzerbeobachtungen nicht oder nur unwesentlich geändert haben. In diesem Beispiel wird davon ausgegangen, dass sich die Umgebungseinflüsse nicht geändert haben und somit die Festlegung, welche Kontextattribute aufgezeichnet werden, nur einmalig vorgenommen werden muss.

Sobald ein Benutzer mit der Handlung beginnt, die in dem erwarteten Benutzerverhalten formalisiert worden ist (s. Formalisierungen 4 und 5), wie z.B. „Infotafel lesen“, werden die Verhaltensattribute des Benutzers, die in dem erwarteten Benutzerverhalten auftauchen (s. Abbildung 8, Schritt 7b1) und parallel die relevanten Kontextattribute (s. Abbildung 8, Schritt 7b2) dokumentiert.

36

Tabelle 6 zeigt das Messergebnis für die Action Area a1. Es wurden zwei Benutzer beobachtet und die Werte der vorher als relevant eingestuften Verhaltensattribute aufgezeichnet.

Benutzer Abstand zur Infotafel Körperhaltung Dauer des Betrachtung der Infotafel

Benutzer A 1,5 m stehend 20 Sek

Benutzer B 0,5 m stehend 120 Sek

Tabelle 6: Messergebnis des Benutzerverhaltens in a1

Analog zu dem beobachteten Benutzerverhalten wurden während der Beobachtung der beiden Benutzer in Action Area a1 auch die relevanten Kontextattribute dokumentiert (s. Tabelle 7).

Benutzer Licht Technisches System

Benutzer A Deckenbeleuchtung Zweite Infotafel

Benutzer B Sonnenlicht Zweite Infotafel

Tabelle 7: Werte der aufgezeichneten Kontextattribute für a1

Auch für Action Area a2 wurde das Benutzerverhalten (s. Tabelle 8) sowie die Kontextattribute (s. Tabelle 9) dokumentiert. Der scheinbare Widerspruch zwischen dem gemessenen Verhalten von Benutzer D („in Bewegung“ und trotzdem eine „Verweildauer vor eigenem Gepäckstück“ von vier Sekunden) erklärt sich dadurch, dass der Benutzer seinem Gepäckstück (was auf dem Gepäckband in Bewegung war) gefolgt ist, es jedoch nicht erreichen konnte. Er befand sich also mehrere Sekunden lang vor seinem Gepäckstück und hatte sich aber (auf Grund der Bewegung seines Gepäckstückes) dennoch bewegt.

Benutzer Körperhaltung Verweildauer vor eigenem Gepäckstück

Benutzer C stehend 1 Sek

Benutzer D in Bewegung 4 Sek

Tabelle 8: Messergebnis des Benutzerverhaltens in a2

BenutzerAnzahl Personen im Umkreis des

Benutzers (Radius 1 Meter)Abstand zum Gepäckband

Benutzer C 0 1 m

Benutzer D 3 2 m

Tabelle 9: Werte der aufgezeichneten Kontextattribute für a2

37

Die Zielanalyse gemäß Tabelle 2 stellt den letzten Schritt (s. Abbildung 8, Schritt 7c) im Ablauf des Teilprozesses der Benutzerbeobachtung dar. Die Ergebnisse der Zielanalyse sind in den Tabellen 10 und 11 abgebildet.

In der Action Area a1 wurde im Fall des Benutzers A geschätzt, dass sein Ziel (s. Abbildung 10) von der Action Area bestimmt wird. Dies ist deswegen anzunehmen, weil seine Handlung (lesen der Infotafel) darauf hindeutet, dass er eine Information erfahren will, die ihm das adaptive System bietet. Im Fall der Infotafel sind dies die Abflugs- und Ankunftszeiten. Da sich die Infotafeln nur in der Action Area a1 befinden, kann der Benutzer sein Ziel auch nur dort erreichen. Es konnte ferner kein störender Kontexteinfluss bestimmt werden, der den Benutzer bei der Erreichung seines Ziels hätte behindern können. Das Ziel des Benutzers A wird zu hoher Wahrscheinlichkeit nicht durch einen Kontexteinfluss bestimmt, da sein Ziel durch einen gewöhnlichen Anwendungsfall erreicht wird und damit unabhängig von äußeren Einflüssen ist.

Im Fall des Benutzers B wurde geschätzt, dass sein Ziel ebenfalls von der Action Area abhängt. Jedoch wurde von den Beobachtern die Einschätzung vertreten, dass es einen Kontexteinfluss gibt, der den Benutzer bei der Erreichung seines Ziel behindert. Details hierzu finden sich in Kapitel 4.6.

Benutzer

Wird das Ziel des Benutzers von seinem Aufenthaltsort (Action

Area) bestimmt?

Wird das Ziel des Benutzers von einem Kontexteinfluss

bestimmt?

Behindert ein Kontexteinfluss den Benutzer bei der Erreichung

des Ziels?

Benutzer A Ja - -

Benutzer B Ja - Ja

Tabelle 10: Ergebnisse der Zielanalyse für a1

Tabelle 11 zeigt die Ergebnisse der Zielanalyse (Erläuterungen analog wie in Action Area a 1) für die Beobachtungen in Action Area a2.

Benutzer

Wird das Ziel des Benutzers von seinem Aufenthaltsort (Action

Area) bestimmt?

Wird das Ziel des Benutzers von einem Kontexteinfluss

bestimmt?

Behindert ein Kontexteinfluss den Benutzer bei der Erreichung

des Ziels?

Benutzer C Ja - -

Benutzer D Ja - Ja

Tabelle 11: Ergebnisse der Zielanalyse für a2

38

4.6 Auswertung des Benutzerverhaltens

Die Auswertung des Benutzerverhaltens beginnt zunächst mit dem Vergleich zwischen dem dokumentierten und dem erwarteten Benutzerverhalten. Dabei wird jedes gemessene Verhaltensattribut des Benutzers (s. Tabelle 6 und 8) mit seinem Soll-Wert (s. jeweils „Erwartetes Benutzerverhalten“ in den Formalisierungen 4 und 5) verglichen. Das Ergebnis des Vergleichs zwischen Soll- und Ist-Werten ist in den Tabellen 12 und 13 dargestellt.

Benutzer(Abstand zur Infotafel,

mehr als 1 Meter)(Körperhaltung,

stehend)(Dauer der Betrachtung der Infotafel,

weniger als 30 Sekunden)

Benutzer A Ja Ja Ja

Benutzer B Nein Ja Nein

Tabelle 12: Vergleich des Benutzerverhaltens mit dem erwarteten Benutzerverhalten für a1

Benutzer(Körperhaltung,

stehend)(Verweildauer vor eigenem Gepäckstück,

1 Sekunde)

Benutzer C Ja Ja

Benutzer D Nein Nein

Tabelle 13: Vergleich des Benutzerverhaltens mit dem erwarteten Benutzerverhalten für a2

Um einen Zusammenhang zwischen dem Benutzerverhalten und den Kontextattributen herstellen zu können, wird die prozentuale Abweichung des Benutzerverhaltens von dem erwarteten Verhalten (z.B. Tabelle 12 Benutzer B: Abweichung in 2 von 3 Verhaltensattributen d.h. ca. 66 % Abweichung) in einer Tabelle mit den Kontextattributen und deren Werten dargestellt. Diese tabellarische Darstellung wird getrennt pro Action Area erstellt (s. Tabelle 14 und 15).

Licht Technisches System

Benutzer A: 0 % Deckenbeleuchtung Zweite Infotafel

Benutzer B: 66 % Sonnenlicht Zweite Infotafel

Tabelle 14: Prozentuale Verhaltensabweichung und gemessene Kontexteinflüsse in a1

39

Verhaltens-abweichung bei Benutzer

Kontext-attribute

Anzahl Personen im Umkreis des Benutzers

(Radius 1 Meter)

Abstand zum Gepäckband

Benutzer C: 0 % 0 1 m

Benutzer D: 100 % 3 2 m

Tabelle 15: Prozentuale Verhaltensabweichung und gemessene Kontexteinflüsse in a2

In Tabelle 14 zeigt Benutzer B die größte Abweichung vom erwarteten Verhalten. Ein Blick auf die Zielanalyse (s. Tabelle 10) zeigt, dass der Beobachter, der das Verhalten von Benutzer B dokumentiert hat, eingeschätzt hat, dass das Verhalten von Benutzer B einerseits von seinem Aufenthaltsorts abhängig war und andererseits ein Kontexteinfluss ihn bei der Erreichung seines Ziels behindert haben soll. Zur genaueren Analyse können nun Tabelle 12 sowie die Ziele des Benutzers (s. Abbildung 10) herangezogen werden: Die längere Betrachtungsdauer deutet darauf hin, dass der Benutzer sein Softgoal nicht erreicht. Das Kontextattribut „Licht“ unterscheidet sich in seinem Wert zudem von dem Fall des Benutzers A (s. Tabelle 7), der keine Verhaltensabweichung gezeigt hat. Dies lässt den Schluss zu, dass das Kontextattribut „Licht“ mit dem Wert „Sonnenlicht“ einen Benutzer bei der Erreichung seines Ziels behindern könnte.

In Tabelle 15 weicht das Verhalten von Benutzer D am stärksten von dem erwarteten Verhalten ab. Auch in diesem Fall wurde in der Zielanalyse geschätzt, dass der Benutzer durch Kontexteinflüsse bei der Erreichung seines Ziels behindert wurde. Die Betrachtung der Kontextattribute und deren Werte (s. Tabelle 9) gibt erste Hinweise, warum dies der Fall sein könnte: Benutzer D hatte einen größeren Abstand zum Gepäckband als Benutzer C und es befanden sich außerdem mehr Personen im Umfeld von Benutzer D. Abbildung 9 zeigt außerdem, dass sich wenigstens eine Person direkt zwischen Benutzer D und dem Gepäckband befand und ihn bei der Erreichung des Gepäckbandes behindert haben könnte.

4.7 Konsequenzen für adaptive Systeme ableitenNach der Auswertung des Benutzerverhaltens müssen nun Konsequenzen für die adaptiven Systeme abgeleitet werden. Tabelle 3 gibt einen Überblick über die möglichen Konsequenzen, die sich basierend auf der Zielanalyse ergeben könnten. In den obigen Fällen, in denen das Verhalten der Benutzer stark von dem erwarteten Verhalten abgewichen ist, wurden die Benutzer durch einen Kontexteinfluss an der Erreichung ihrer Ziele gehindert (s. Tabelle 10 und 11); dies entspricht Fall 4 in Tabelle 3: Die adaptiven Systeme sollten also (wenn möglich) den Störeinfluss ausgleichen.

Im Fall der Infotafeln könnten eine Anpassung der Bildschirmeigenschaften (z.B. Helligkeit und Kontrast) an die Lichtverhältnisse eine Option sein, um den Störeinfluss auszugleichen. Im Fall des Gepäckbandes könnte etwa eine Veränderung der Bandgeschwindigkeit einzelnen Benutzern mehr Zeit geben, ihr Gepäckstück zu erreichen.

Wie in Abbildung 9 zu erkennen ist, sind die Personen, die auf ihre Gepäckstücke warten, nicht gleichmäßig um das Gepäckband herum verteilt. Um die Verteilung der Personen besser zu berücksichtigen, ist die Unterteilung des Bereichs um das Gepäckband in drei kleinere Action Areas hilfreich. Weitere Untersuchungen könnten unter Umständen auch die Einführung eines neuen adaptiven Systems ergeben, das die Benutzer dazu anweisen könnte, sich gleichmäßiger um das Gepäckband herum zu verteilen.

40

Verhaltens-abweichung bei Benutzer

Kontext-attribute

4.8 Neue Anforderungen ableiten und Regeln überarbeitenDer letzte Schritt besteht nun in der Aufstellung von neuen – bzw. geänderten Anforderungen, die die Basis für neue Regeln darstellen. Für SmartInfo könnte eine neue Anforderung etwa lauten „Die Infotafeln sollen ihre Einstellungen bezüglich Helligkeit und Kontrast den Lichtverhältnissen der Umgebung anpassen“ und für SmartBaggage „Die Geschwindigkeit des Gepäckbandes soll sich mit wachsender Besucherdichte verringern“.

Damit diese Anforderungen in Regeln einfließen können, ist es noch erforderlich, sie zu konkretisieren (d.h. sie müssen [möglichst objektiv] testbar sein!) und zu definieren, unter welchen Kontextbedingungen sie gelten. Eine konkrete Form der Formulierung für die oben genannten Anforderungen und die dazugehörigen Kontexteinflüsse ist in den Tabellen 16 und 17 dargestellt.

Anforderung Licht

Kontrastwert für Infotafel soll 60 % betragen Deckenbeleuchtung

Kontrastwert für Infotafel soll 100 % betragen Sonnenlicht

Tabelle 16: Geänderte Anforderung für SmartInfo in Abhängigkeit der Kontexteinflüsse

AnforderungAnzahl Personen im Umkreis des

beobachteten Benutzers (Radius 1 Meter)

Bandgeschwindigkeit soll 0,5 m pro Sekunde betragen

0

Bandgeschwindigkeit soll 0,2 m pro Sekunde betragen

3

Tabelle 17: Geänderte Anforderung für SmartBaggage in Abhängigkeit der Kontexteinflüsse

Aus Tabelle 17 geht eine Problematik hervor, die bei der Formulierung von neuen Anforderungen für die adaptiven Systeme beachtet werden sollte. So wurde die Anzahl der Personen im Umkreis eines Benutzers als relevanter Kontexteinfluss identifiziert. Das Problem ist jedoch, dass das adaptive System SmartBaggage von einer ganzen Gruppe von Benutzern gleichzeitig genutzt wird. Somit ist im Produktivbetrieb nicht klar ersichtlich, welcher Benutzer als Referenzpunkt für die Messung der Personen in seinem Umkreis verwendet werden soll. Außerdem besteht die Gefahr von Interessenkonflikten, wenn das adaptive System sein Systemverhalten nur einseitig an die Bedürfnisse einzelner Benutzer anpasst und dabei andere Benutzer außer Acht lässt. So könnte etwa eine geringe Bandgeschwindigkeit manchen Benutzern mehr Zeit verschaffen, ihr Gepäckstück zu erreichen (und ihnen damit bei der Erreichung ihres Ziels helfen, vgl. Abbildung 11), während andere Benutzer (z.B. jene, die sich am Ende des Gepäckbandes befinden) eine längere Wartezeit in Kauf nehmen müssten, um Zugang zu ihrem Gepäckstück zu bekommen (Behinderung der Zielerreichung). Durch wiederholte durchgeführte Beobachtungen verschiedener Benutzer könnte jedoch festgestellt werden, ob eine signifikante Anzahl von Benutzern in einer bestimmten Zeit durch Kontexteinflüsse behindert werden oder ihre Ziele gemäß veränderter Kontexteinflüsse variieren und ob eine Veränderung des Systemverhaltens angemessen wäre.

41

Aus Abbildung 9 geht z.B. hervor, dass sich in der Action Area a2.1 deutlich mehr Benutzer befinden als in der Action Area a2.2 oder a2.3. Vor dem Hintergrund, dass die Anzahl der Personen im Umkreis eines Benutzers ein Kontexteinfluss ist, der für die Zielerreichung eines Benutzers entscheidend ist, erscheint es sinnvoll, dass das adaptive Systeme die Benutzer in den einzelnen Teil-Action Areas unterschiedlich behandelt, was aufgrund der technischen Bauweise des Systems in diesem Fall kaum möglich ist. Als Lösungsansatz wäre es z.B. möglich, einen Kompromiss zwischen den verschiedenen Interessen der Benutzer zu finden. So könnte etwa ab einer gewissen Personendichte in der Action Area die Bandgeschwindigkeit des Gepäckbands verringert werden. Eine modifizierte Anforderung für SmartBaggage ist in Formalisierung 7 in Form einer Regel dargestellt.

Die Formalisierungen 6 und 7 zeigen, wie die neuen Regeln, die sich aus der Auswertung des Benutzerverhaltens unter bestimmten Kontexteinflüssen für ein adaptives System ergeben, aussehen könnten.

Regel1 = („Der Kontrastwert der Infotafeln soll 60 % betragen.“, 3, Anwendungsbedingung1, „Besucher, die vor einer Infotafel stehen und sie lesen“, „SmartInfo“)

Anwendungsbedingung1 = ({Licht, Deckenbeleuchtung}, -)

Regel2 = („Der Kontrastwert der Infotafeln soll 100 % betragen.“, 3, Anwendungsbedingung2, „Besucher, die vor einer Infotafel stehen und sie lesen“, „SmartInfo“)

Anwendungsbedingung2 = ({Licht, Sonnenlicht}, -)

Formalisierung 6: Neue Regeln für SmartInfo in a1

42

Regel1 = („Die Bandgeschwindigkeit des Gepäckbandes soll 0,3 m/s betragen“ Anwendungsbedingung1, „Besucher, die vor dem Gepäckband stehen und auf ihr Gepäckstück warten“, „SmartBaggage“)

Anwendungsbedingung1 = ({Personendichte in Action Area, > 3 Personen pro m²}, -)

Regel2 = („Die Bandgeschwindigkeit des Gepäckbandes soll 0,5 m/s betragen“ Anwendungsbedingung2, „Besucher, die vor dem Gepäckband stehen und auf ihr Gepäckstück warten“, „SmartBaggage“)

Anwendungsbedingung2 = ({Personendichte in Action Area, ≤ 3 Personen pro m²}, -)

Formalisierung 7: Neue Regeln für SmartBaggage in a2

4.9 Einsatzmöglichkeiten und Grenzen des KonzeptsIn diesem Kapitel soll erläutert werden, welche Voraussetzungen für den Einsatz des Konzepts notwendig sind und wo Grenzen des Einsatzes liegen.

Da das Konzept auf der Beobachtung von Benutzern basiert, ist das Vorhandensein von Benutzern offensichtlich ein notwendiges Kriterium für die Anwendung des Konzepts. Um ausreichend Daten für eine spätere Analyse zu erhalten, ist es zudem erforderlich, mehrere Benutzerbeobachtungen durchzuführen.

Weiterhin erfordert die Anwendung des Konzepts die Festlegung des Verhaltens, das von einem Benutzer erwartet wird und die Zuordnung des Benutzerverhaltens zu einem konkreten ortsabhängigen Ziel, das der Benutzer erreichen will. Szenarien, wo in einer Action Area unterschiedliche ortsabhängige Ziele existieren und wo eine konkrete Zuordnung zwischen Benutzerverhalten und Ziel nur schwer möglich ist, eignen sich nicht für den Einsatz des Konzepts. Das gleiche gilt für Orte, an denen viele Benutzer zusammenkommen, die jedoch alle unterschiedliche und ortsunabhängige Ziele haben.

Ist es jedoch wahrscheinlich, dass es an einem Ort ortsabhängige Ziele seitens der Benutzer gibt (da diese Ziele entweder durch externe Prozesse vorgegeben sind oder aber durch Beobachtung von Menschenansammlungen vermutet wird, dass solche Ziele existieren) und ist eine Zuordnung zwischen dem Benutzerverhalten und diesen Zielen möglich, kann das Konzept auch unabhängig von vorhandenen adaptiven Systemen zur reinen Prozessoptimierung eingesetzt werden, um die Auswirkungen von Kontexteinflüssen auf das Verhalten und die Ziele der Benutzer zu untersuchen (vgl. Kapitel 6.2). Eine solche Untersuchung kann dazu dienen, zielgerichteter Anforderungen an ein (möglicherweise adaptives) System zu stellen. In [Wel+08] wird die Hypothese aufgestellt, dass das Vorhandensein einer Menge nicht-funktionaler Anforderungen, deren relative Prioritäten in Abhängigkeit von der Umgebung des Systems variieren, es wahrscheinlich werden lässt, dass das zu entwickelnde System adaptive Anteile haben muss. Das in dieser Arbeit entwickelte Konzept kann in diesem Fall Hinweise auf die kontextabhängige Priorität von Zielen und Anforderungen geben und somit wichtige Hinweise für die Einführung oder Optimierung eines adaptiven Systems geben.

43

In dieser Arbeit wurde (idealerweise) davon ausgegangen, dass die Beobachtung von Benutzern im Rahmen der Anwendung des Konzepts jederzeit problemlos möglich ist. In realen Einsatzumgebungen kann davon jedoch nicht immer ausgegangen werden: Eine Anwendung des Konzepts durch Beobachter würde erfordern, dass sich die Beobachter stets in der Nähe der Benutzer befinden, was in Szenarien, in denen die jeweilige Action Area nur einem ausgewählten Personenkreis zugänglich ist, nicht gewährleistet werden kann. Insbesondere die Dokumentation des Benutzerverhaltens mittels technischer Hilfsmittel (z.B. mit Hilfe von Videokameras) erfordert die Berücksichtigung von rechtlichen Aspekten (s. § 6b [BDSG09]). Ähnliche Einschränkungen betreffen auch die Speicherung und Auswertung solcher Daten (s. § 4 [BDSG09]).

Einschränkungen und Grenzen, die generell für den Einsatz von Feldbeobachtungen gelten, behalten auch innerhalb des in dieser Arbeit erstellen Konzepts ihre Gültigkeit: So werden in [Rup07] z.B. „hohe Komplexität der Systemabläufe“ und „geringe Beobachtbarkeit“ als Fälle genannt, in denen eine Feldbeobachtung generell als Erhebungstechnik für Anforderungen ungeeignet ist. Die Schwierigkeit, komplexe -, schnelle - und zeitlich kritische Abläufe mit Hilfe des Konzepts zu analysieren, kann durch den praktischen Einsatz des Konzepts (vgl. Kapitel 6.4) bestätigt werden. Weiterhin erwies sich auch die Größe der Action Area und die Anzahl von parallel ablaufenden Aktionen für die Qualität der Beobachtung als entscheidend. In Bezug auf die Beobachtbarkeit der Benutzer ist nicht nur die Frage entscheidend, ob es prinzipiell möglich ist, die Benutzer in einer Action Area zu beobachten, sondern vor allem auch inwiefern sich die beobachtbaren Verhaltensattribute eines Benutzers in Abhängigkeit des Verhaltens eines adaptiven System verändern. Im Idealfall würde sich das beobachtbare Verhalten eines Benutzers deutlich ändern, sobald ein adaptives System die Anforderungen, die der Benutzer an das System stellt, nicht erfüllt. Im ungünstigsten Fall würde der Benutzer keine - oder nur sehr subtile nach außen hin sichtbare Verhaltensänderungen zeigen, wenn das System, mit dem er interagiert, seine Anforderungen nicht erfüllt. Im letzteren Fall wäre es sehr schwierig oder sogar unmöglich, aus dem beobachteten Verhalten des Benutzers Rückschlüsse auf seine Anforderungen zu ziehen.

Ein weiterer kritischer Punkt ist die Frage nach der genauen Relation zwischen Kontexteinflüssen und Benutzerverhalten bzw. dem Ziel, das dem Verhalten zugrunde liegt. Denkbar sind auch Situationen, in denen eine bestimmte Kombination von Kontexteinflüssen das Verhalten eines Benutzers bestimmt. Die Zielanalyse (s. Tabelle 2) stellt eine erste Analyse der Relation von Kontexteinfluss und Benutzerziel dar. Die Auswertungstabellen (s. Tabelle 1) können als Basis für statistische Analysen ebenfalls helfen, die Relation zwischen Kontexteinflüssen und Benutzerverhalten näher zu bestimmen. Die Relation zwischen Kontexteinflüssen und Benutzerverhalten kann auf diesem Wege jedoch nur heuristisch bestimmt werden.

44

5 Implementierung des Konzepts

5.1 VorüberlegungenUm die Anwendung des Konzepts zu erleichtern, wird in dieser Arbeit eine Implementierung des Konzepts vorgenommen. Hierbei sind insbesondere folgende Aspekte zu berücksichtigen:

• Der praktische Einsatz der Implementierung wird in der wiederholten Durchführung unterschiedlicher Feldbeobachtungen bestehen, in der diverse unterschiedliche Verhaltens- und Kontextattribute dokumentiert werden müssen. Dies lässt ein hohes Datenaufkommen vermuten. Die Implementierung muss in der Lage sein, effizient entsprechende Datenmengen zu verarbeiten.

• Die Daten der Benutzerbeobachtung sollen zunächst manuell erfasst werden. Jedoch wäre (s. Kapitel 7.2) eine (teil-)automatische Erfassung bestimmter Verhaltensattribute durch technische Systeme (z.B. Überwachungskameras) von Vorteil. Es soll technologisch die Möglichkeit bestehen, andere Systeme als Datenquelle mit der Implementierung zu verbinden.

• Die Implementierung soll von den Benutzern (die das Konzept anwenden) vor Ort über mobile Geräte (Smartphones) aufgerufen und bedient werden können, um für die Beobachter ein hohes Maß an Mobilität zu gewährleisten.

Die Attribute des Benutzerverhaltens (s. Abbildung 2) und das Kontextmodell des Benutzers (s. Abbildung 3) sollen zudem flexibel implementiert werden, d.h. die Beobachter sollen die Möglichkeit haben, zur Laufzeit weitere Attribute des Benutzerverhaltens hinzuzufügen bzw. das Kontextmodell um weitere Attribute erweitern zu können.

5.2 Eingesetzte TechnologienDie im vorherigen Kapitel erwähnten Aspekte (insbesondere der Aspekt der ortsunabhängigen Verfügbarkeit der Anwendung) legen den Einsatz einer internetbasierten Anwendung nahe. Um ein Höchstmaß an Kompatibilität zu gewährleisten, wird die Implementierung W3C-konformes (X)HTML verwenden und auf weitergehende Web-Technologien, wie z.B. JavaScript, Flash etc. verzichten. Um Ladezeiten und die zu übertragende Datenmenge zu reduzieren, werden außerdem keine Grafiken verwendet werden. Dies ist insbesondere deswegen wichtig, weil die Anwendung überwiegend über Smartphones bedient werden wird, die unter Umständen nicht durchgehend über eine schnelle Internetanbindung verfügen.

Um die Daten, die bei der Anwendung des Konzepts erhoben werden, zu speichern, wird als Datenbanksystem MySQL in Kombination mit PHP verwendet. Diese Kombination ist zudem aufgrund der hohen Verbreitung von Vorteil, da somit die Anwendung leichter installiert und portiert werden kann. Da auch der Zugriff auf die Datenbank über das Internet möglich ist, ist außerdem bereits eine mögliche Schnittstelle für weitere technische Systeme, die Daten über Kontext- und Verhaltensattribute liefern, vorhanden. Das Programm Doxygen wird zum Erstellen einer (technischen) Dokumentation verwendet werden.

Die Quellcode-Dateien, die technische Dokumentation sowie eine Installationsanleitung und alle relevanten Zusatzprogramme sind auf der beiliegenden CD-ROM dieser Arbeit enthalten.

45

5.3 Beschreibung des ProgrammsDie Implementierung des Konzepts bildet den Ablauf der Anwendung gemäß den Abbildungen 7 und 8 ab und dient zur Eingabe der beobachteten Kontext- und Verhaltensattribute. Außerdem bietet sie eine Übersicht über Details von einzelnen Benutzerbeobachtungen und ermöglicht die angezeigten Daten im CSV-Format als Datei zu exportieren.

Nach erfolgter Installation des Programms auf einem Webserver kann die Hauptseite des Programms aufgerufen werden (s. Abbildung 12).

Die Hauptseite bietet Zugang zu den unterschiedlichen Programmteilen, mit denen neue Benutzerbeobachtungen definiert und durchgeführt sowie Details zu den schon durchgeführten Benutzerbeobachtungen angezeigt werden können.

In den folgenden Kapiteln (5.3.1, 5.3.2 und 5.3.3) wird die Anwendung des Programms gemäß dem in Kapitel 4 beschriebenen Szenarios in der Action Area a1 und dem adaptiven System SmartInfo beschrieben.

46

Abbildung 12: Hauptseite des Programms

5.3.1 Vorbereitung einer BenutzerbeobachtungAls Vorbereitung zu einer Benutzerbeobachtung müssen zuerst die Action Area, adaptive Systeme etc. (s. Abbildung 7) festgelegt werden. Hierzu bietet das Programm verschiedene Eingabemasken an, die den Prozess, der in Abbildung 7 dargestellt ist, abbilden.

Der erste Schritt (s. Abbildung 13) besteht darin, den Namen der Action Area festzulegen, in der die Benutzerbeobachtung stattfinden soll. Obwohl es theoretisch möglich ist, zwei Action Areas mit einem identischen Namen zu belegen (jede Action Area wird intern über eine eindeutige ID identifiziert), sollte dies aus Gründen der Nachvollziehbarkeit möglichst vermieden werden.

47

Abbildung 13: Definition der Action Area

Im zweiten Schritt (s. Abbildung 14) müssen ein oder mehrere adaptive Systeme angegeben werden, die sich in der Action Area befinden. Es können bis zu fünf adaptive Systeme angegeben werden. Selbstverständlich können sich theoretisch mehr als fünf adaptive Systeme in einer Action Area befinden. Dies könnte jedoch ein Hinweis dafür sein, dass die Action Area zu großzügig gewählt worden ist und eine Unterteilung in mehrere kleinere Action Areas sinnvoll wäre (s. Definition 3). Die weitere Unterteilung einer großen Action Area wurde auch in Kapitel 6.1 vorgenommen.

48

Abbildung 14: Identifizierung der adaptiven Systeme in der Action Area

Der dritte Schritt (s. Abbildung 15) besteht darin, die Ziele festzulegen, die ein Benutzer in einer Action Area verfolgt. Hierbei ist zu bestimmen, ob es sich bei einem Ziel um ein Goal oder um ein Softgoal handelt. Es können – ähnlich wie bei den adaptiven Systemen – maximal fünf Ziele für die Action Area festgelegt werden. Eine zu hohe Anzahl von Zielen kann – wie eine zu hohe Anzahl von adaptiven Systemen – ein Indiz dafür sein, dass die Action Area zu großzügig gewählt worden ist oder, dass nicht alle Ziele ortsspezifisch sind.

49

Abbildung 15: Definition der Goals bzw. Softgoals des Benutzers für die Action Area

Im nächsten Schritt (s. Abbildung 16) werden die Handlungen angegeben, die von einem Benutzer in einer Action Area erwartet werden. Die Menge dieser Handlungen bildet das Set of expected Actions. Ähnlich wie bei den adaptiven Systemen ist die Anzahl der Handlungen, die eingetragen werden können, auf fünf begrenzt. Dies ist deshalb sinnvoll, weil der Beginn einer Handlung als Trigger für eine Feldbeobachtung dient und eine zu hohe Anzahl an Handlungen, die ein Feldbeobachter im Blick haben muss, diesen überfordern würde (vgl. Kapitel 6.4).

50

Abbildung 16: Definition des Set of expected Actions

Die Aufstellung der Regeln für die adaptiven Systeme (s. Abbildung 17) und die Definition des erwarteten Benutzerverhaltens (s. Abbildung 18) schließen den Prozess der Definition einer Benutzerbeobachtung ab.

51

Abbildung 17: Aufstellung der Regeln für die adaptiven Systeme

52

Abbildung 18: Definition des erwarteten Benutzerverhaltens

5.3.2 Durchführung einer BenutzerbeobachtungDer Ablauf einer Benutzerbeobachtung entspricht dem in Abbildung 8 dargestellten Ablauf. Die Durchführung der Benutzerbeobachtung wird vorzugsweise von einem Smartphone aus vorgenommen (s. Abbildung 19), weil dieses bezüglich der Mobilität der Beobachter Vorteile bietet. Jedoch kann das Programm grundsätzlich von jedem mobilen Gerät, das über einen (X)HTML-fähigen Browser verfügt, aufgerufen werden.

Vor Beginn der Benutzerbeobachtung muss zunächst der aktuelle Standort, an dem sich Beobachter und Benutzer befinden (Action Area), ausgewählt werden. Sobald der zu beobachtende Benutzer eine Handlung aus dem zuvor definierten Set of expected Actions (vgl. Abbildung 16) durchführt, beginnt die Beobachtung.

Zu Beginn der Benutzerbeobachtung müssen zunächst die relevanten Kontextattribute (vgl. Abbildung 8) ausgewählt werden. Das Programm bietet eine Menge an Basis-Kontextattributen an (s. Kontextmodell, Abbildung 3), kann jedoch auch um beliebige neue Kontextattribute erweitert werden.

Die Dokumentation der Verhaltens- und Kontextattribute (s. Abbildungen 20 und 21) kann gemäß dem Prozess in Abbildung 8 parallel erfolgen, in Einzelfällen (z.B. wenn nur sehr wenige Verhaltens- und Kontextattribute dokumentiert werden sollen), kann auch ein einzelner Beobachter beide Arten von Attributen dokumentieren (s. Abbildung 19). Allerdings ist hiervon prinzipiell eher abzuraten, da die gleichzeitige Beobachtung und Dokumentation von verschiedenen Attributen leicht zu einer Überforderung des Beobachters führen kann (s. auch Kapitel 6.4).

53

Abbildung 19: Dokumentation der Kontext- und Verhaltensattribute auf einem Smartphone

54

Abbildung 20: Dokumentation der Verhaltensattribute durch den ersten Beobachter

Abbildung 21: Dokumentation der Kontextattribute durch den zweiten Beobachter

5.3.3 Auswertung einer BenutzerbeobachtungNachdem eine oder mehrere Benutzerbeobachtungen durchgeführt worden sind, bietet das Programm Hilfestellungen zur Auswertung der dokumentierten Daten an und bietet auch die Möglichkeit, die dargestellten Ergebnisse im CSV-Format herunterzuladen. Die Übersicht in Abbildung 22 zeigt eine Gegenüberstellung der dokumentierten Werte der Verhaltensattribute und den erwarteten Werten aus dem erwarteten Benutzerverhalten. Die Abweichungen zwischen Soll- und Ist-Werten bei den Verhaltensattributen sind grau hinterlegt dargestellt. Die Darstellung aus Abbildung 22 zeigt den konkreten Fall der Benutzerbeobachtung von Benutzer B aus Kapitel 4 und entspricht inhaltlich den Tabellen 6 und 12.

55

Abbildung 22: Vergleich von erwartetem - und gemessenem Benutzerverhalten (vgl. Tabelle 6 und 12)

Um Hinweise in Bezug auf die Relation von Kontexteinflüssen und dem Benutzerverhalten zu erhalten, bietet das Programm eine Übersicht über die prozentuale Abweichung vom erwarteten Benutzerverhalten und den in derselben Feldbeobachtung gemessenen Kontextattributen (s. Abbildung 23). Diese Darstellung entspricht Tabelle 14.

56

Abbildung 23: Gegenüberstellung der prozentualen Verhaltensabweichung von Benutzern und den gemessenen Kontexteinflüssen (vgl. Tabelle 14)

6 Praktischer Einsatz des Konzepts im FeldversuchDas Konzept wurde mit Hilfe des entwickelten Programms unter realen Bedingungen eingesetzt. Das Ziel des Feldversuchs bestand darin, Erkenntnisse über die Anwendung des Konzepts zu gewinnen, Ansatzpunkte für mögliche Optimierungen zu erkennen und zu überprüfen, welche Schlüsse sich aus den dokumentierten Ereignissen ziehen lassen. Die Ergebnisse des Feldversuchs werden in diesem Kapitel beschrieben.

Als Einsatzorte wurden eine öffentliche Tiefgarage und eine Bushaltestelle im Zentrum einer Großstadt in Deutschland am Nachmittag eines Wochentages ausgewählt. Diese Orte boten den Vorteil, dass sie sich einerseits durch eine komplexe Umgebung mit zahlreichen Kontexteinflüssen auszeichnen und andererseits eine hohe Anzahl von Benutzern an diesen Orten zu erwarten war.

Als Vorbereitung für die Feldbeobachtung wurde für jeden Einsatzort der Prozess gemäß Abbildung 7 (bis einschließlich Schritt 6) durchlaufen, indem die für eine Feldbeobachtung erforderlichen Daten in das entwickelte Programm (s. Kapitel 5) eingegeben wurden. Das Programm selbst war zuvor auf einem Webserver installiert worden und wurde über zwei Smartphones per Webbrowser während des Versuchs bedient. Das erwartete Benutzerverhalten in den Setups der einzelnen Feldbeobachtungen wurde zunächst willkürlich festgelegt und im Rahmen der Auswertung mit dem tatsächlich beobachteten Verhalten verglichen.

Beteiligt an der Feldbeobachtung waren zwei Studenten (beide im Masterstudiengang Informatik) sowie der Autor dieser Arbeit. Die Eingabe der Daten erfolgte über Papierformulare und zwei Smartphones.

57

6.1 Einsatzort 1: TiefgarageDer erste Einsatzort war eine Tiefgarage mit zwei Untergeschossen. Hierbei wurden zwei Action Areas definiert: Die gesamte Tiefgarage und das Parkdeck im ersten Untergeschoss. Das adaptive System in beiden Action Areas war ein digitales Pfeildisplay, das aus zwei LED-Pfeilanzeigen bestand, die in grüner Farbe die Fahrtrichtung zu einem Untergeschoss mit freien Parkplätzen zeigten (s. Abbildung 24). Das Pfeildisplay befand sich an der Einfahrt zum Parkdeck des ersten Untergeschosses. Während der gesamten Feldbeobachtung waren beiden Pfeilanzeigen grün, was einem Autofahrer anzeigen sollte, dass sowohl im ersten wie auch im zweiten Untergeschoss freie Parkplätze vorhanden sein sollten. Da in der Tiefgarage die Smartphones, die zur Dokumentation genutzt werden sollten, keinen Empfang hatten, wurden ausgedruckte Formulare verwendet und die dokumentierten Daten zu einem späteren Zeitpunkt in das Programm übertragen.

58

Abbildung 24: Digitales Pfeildisplay als adaptives System in der Tiefgarage

6.1.1 Action Area: TiefgarageDie erste Action Area war die gesamte Tiefgarage, in der das Verhalten der Autofahrer bezüglich der Wahl des Untergeschosses untersucht werden sollte. Hierbei wurde das Setup aus Formalisierung 8 verwendet. Der Standpunkt während dieses Teils der Feldbeobachtung war die Einfahrt der Tiergarage am Kreuzungspunkt zum ersten Untergeschoss. Von diesem Standpunkt aus war das Pfeildisplay sichtbar (s. Abbildung 24) und die Autofahrer mussten sich entscheiden, ob sie von der Einfahrt rechts in das erste Untergeschoss abbiegen oder weiter auf der Einfahrt in das zweite Untergeschoss fahren wollen. Das relevante Kontextattribut war die digitale Pfeilanzeige, die einem Autofahrer, der das Parkdeck mit seinem Auto befuhr, anzeigte, welche Untergeschosse noch freie Parkplätze enthielten. Die Erwartung bestand darin, dass die meisten Autofahrer das erste freie Untergeschoss wählen und dort weiter nach einem geeigneten Parkplatz suchen würden.

Action Area = Tiefgarage

Adaptives System = Digitales Pfeildisplay

Set of expected Actions = {„Untergeschoss auswählen“}

Regel = („Pfeildisplay soll Benutzer freie Untergeschosse anzeigen“, 3, Anwendungsbedingung, „Autofahrer, die nach einem Parkplatz suchen“, Adaptives System)

Erwartetes Benutzerverhalten = („Untergeschoss auswählen“, „Der Benutzer wählt das oberste vorgeschlagene Untergeschoss“, {(Stockwerkauswahl, oberstes freies Untergeschoss)}, Anwendungsbedingung, „Autofahrer, die nach einem Parkplatz suchen“)

Anwendungsbedingung = ({}, -)

Formalisierung 8: Setup für Feldbeobachtung in der Tiefgarage

59

6.1.2 Action Area: Erstes Untergeschoss der TiefgarageDie zweite Action Area war das erste Untergeschoss der Tiefgarage, in dem das Verhalten der Benutzer bei der Wahl eines Parkplatzes untersucht werden sollte. Der Standort für die Beobachtung war ein Parkplatz in der Mitte des ersten Untergeschosses. Das verwendete Setup ist in Formalisierung 9 dargestellt. Die relevanten Kontextattribute waren die Anzahl der freien Parkplätze und die Anzahl der freien Parkplätze an Säulen. Die Parkplätze, die sich an einer Säule befinden, zeichnen sich durch eine deutlich geringere Breite aus als die Parkplätze, die sich an anderen Positionen befinden. Ein Autofahrer, der einen Parkplatz an einer Säule belegen will, trägt somit ein deutlich erhöhtes Risiko, sein Fahrzeug zu beschädigen. Für besonders breite Fahrzeuge sind die Säulen-Parkplätze teilweise überhaupt nicht befahrbar. Trotz dieser Einschränkungen werden diese Parkplätze als reguläre Parkplätze gezählt, so dass (theoretisch) folgende Situation eintreten kann: Das adaptive System (Pfeildisplay) zeigt an, dass z.B. im ersten Untergeschoss noch freie Parkplätze vorhanden sind. In Wirklichkeit sind jedoch nur noch Säulen-Parkplätze frei, so dass für einen Autofahrer, der ein besonders breites Fahrzeug fährt, faktisch keine Parkplätze mehr frei sind. Die Erwartung bezüglich des Benutzerverhaltens bestand darin, dass ein Autofahrer grundsätzlich einen Parkplatz wählen würde, der sich nicht an einer Säule befindet.

Action Area = 1. Untergeschoss

Adaptives System = Digitales Pfeildisplay

Set of expected Actions = {„Parkplatz suchen“}

Regel = („Pfeildisplay soll Benutzer freie Untergeschosse anzeigen“, 3, Anwendungsbedingung, „Autofahrer, die nach einem Parkplatz suchen“, Adaptives System)

Erwartetes Benutzerverhalten = („Parkplatz suchen“, „Der Benutzer wählt den Parkplatz, der breit genug für sein Fahrzeug ist“, {(Parkplatzposition, nicht an einer Säule)}, Anwendungsbedingung, „Autofahrer, die nach einem Parkplatz suchen“)

Anwendungsbedingung = ({}, -)

Formalisierung 9: Setup für Feldbeobachtung im ersten Untergeschoss der Tiefgarage

60

6.2 Einsatzort 2: BushaltestelleDer Einsatzort für den zweiten Feldversuch war eine Bushaltestelle. Hier sollte untersucht werden, wie sich die Anzahl der Fahrgäste, die aus einem Bus aussteigen und die Anzahl der Fahrgäste, die einen Bus betreten wollen, sich auf die Wartezeit einer Person, die ebenfalls den Bus betreten will, auswirken. Das Setup für diese Feldbeobachtung ist in Formalisierung 10 dargestellt.

Das „adaptive System“ in diesem Feldversuch ist die Tür eines Busses (vgl. Formalisierung 10). Es ist zu betonen, dass es sich dabei nicht um ein adaptives System nach Definition 1 handelt. Jedoch sollte in diesem Feldversuch der Versuch unternommen werden, das Konzept dennoch anzuwenden, um Hinweise zu gewinnen, ob es sinnvoll sein könnte, ein adaptives System in der Action Area einzuführen.

Die Erwartung an das Benutzerverhalten war, dass ein Benutzer zehn Sekunden brauchen wird, um einen Bus zu betreten und er dabei durch aussteigende Fahrgäste sowie weitere Benutzer, die vor ihm den Bus betreten wollen, behindert werden wird.

Action Area = Bushaltestelle

Adaptives System = Tür des Busses

Set of expected Actions = {„Sich Bus nähern“}

Regel = („Tür des Busses soll sich öffnen und dem Benutzer ermöglichen, in 10 Sekunden den Bus zu betreten“, 3, Anwendungsbedingung, „Personen, die mit dem Bus fahren wollen“, Adaptives System)

Erwartetes Benutzerverhalten = („Sich Bus nähern“, „Der Benutzer nähert sich der Tür des Busses und betritt den Bus durch dieselbe“, {(Zeit (bis zum Betreten des Busses), 10 Sekunden)}, Anwendungsbedingung, „Personen, die mit dem Bus fahren wollen“)

Anwendungsbedingung = ({(Automatische Tür (von Bus),ist geöffnet)}, -)

Formalisierung 10: Setup für Feldbeobachtung an einer Bushaltestelle

61

6.3 Ergebnisse und AuswertungIn diesem Kapitel sollen die Ergebnisse des Feldversuchs vorgestellt werden. Details zu den erhobenen Daten sind auf der beiliegenden CD-ROM zu dieser Arbeit enthalten.

In der Tiefgarage wählten 83,3 % der Autofahrer das erste Untergeschoss und entsprachen damit dem erwarteten Verhalten. Die Beobachtung ergab außerdem, dass die Autofahrer innerhalb kürzester Zeit ein Untergeschoss ausgewählt hatten und keine äußeren Störeinflüsse erkennbar waren, die die Benutzer beim Erreichen ihres Ziels behinderten. Bezüglich des adaptiven Systems (Pfeildisplay) kann festgestellt werden, dass es den Benutzer bei der Wahl eines Untergeschosses in adäquater Weise unterstützt, so dass eine Anpassung des Systemverhaltens (Regel) nicht zwingend notwendig wäre.

Im ersten Untergeschoss wählten 66,6 % der Autofahrer einen Parkplatz, der nicht an einer Säule lag und entsprachen dabei dem erwarteten Verhalten. Die Wahl des Parkplatzes war einerseits (trivialerweise) von den freien Parkplätzen abhängig. Andererseits war zu erkennen, dass für einen Großteil der Benutzer die Tatsache, dass sich ein Parkplatz nicht an einer Säule befand, ein notwendiges Kriterium für die Wahl des Parkplatzes darstellte. Das adaptive System (Pfeildisplay) erfüllte diesbezüglich nur bedingt seine Funktion: Ausgehend von der Annahme, dass die meisten Besucher das Ziel verfolgen, in kurzer Zeit einen Parkplatz zu finden, der ausreichend Platz für ihr Fahrzeug bietet (und damit nicht an einer Säule liegt), ist die Empfehlung des Pfeildisplays, dass beide Untergeschosse für einen Autofahrer gleich gut geeignet sind, dieses Ziel effizient zu erreichen, kritisch zu sehen. Da die meisten Autofahrer (66,6 %) von sich aus die Parkplätze wählen, die nicht an einer Säule liegen aber gleichzeitig 83,3 % der Autofahrer das erste Untergeschoss wählen, wenn das Pfeildisplay anzeigt, dass sich in beiden Untergeschossen noch freie Parkplätze befinden, führt dies mit hoher Wahrscheinlichkeit zu folgender Situation: Es werden mehr Parkplätze im ersten Untergeschoss besetzt sein als im zweiten Untergeschoss und die freien Parkplätze im ersten Untergeschoss werden zum Großteil Parkplätze an Säulen sein. Dies geht auch aus der Zählung der freien Parkplätze während der Feldbeobachtung hervor (Ausgangssituation im ersten Untergeschoss: 30 freie Parkplätze, davon 83,3 % Säulenparkplätze).Zudem befanden sich fast alle freien Parkplätze, die nicht an einer Säule lagen, im hinteren Bereichs des Untergeschosses, was dazu führte, dass die Autofahrer, die diese Parkplätze belegen wollten, eine größere Strecke mit ihrem Auto zurücklegen und oft auch einen längeren Fußweg zum Fußgängerausgang des Parkdecks (und später zurück zu ihrem Auto) zurücklegen mussten. Die Gruppe von Autofahrern, die im ersten Untergeschoss einen Parkplatz, der nicht an einer Säule liegt, suchen (55,5 % der Autofahrer, die die Tiefgarage befahren [83,3 % wählen das erste Untergeschoss, davon wählen 66,6 % einen Parkplatz, der nicht an einer Säule liegt, insgesamt: 55,5 %]), würden also mehr Zeit bei der Erreichung ihres Ziels, einen geeigneten Parkplatz zu finden, benötigen und außerdem häufig einen längeren Fußweg zwischen ihrem Fahrzeug und dem Fußgängerausgang zurücklegen müssen. Um dieses Problem besser zu lösen, könnte eine mögliche Anpassung des Systemverhaltens im ersten Schritt darin bestehen, generell eine gleichmäßigere Verteilung der Autofahrer auf die beiden Untergeschosse zu erreichen. Hierfür könnte das Pfeildisplay so modifiziert werden, dass es einem Autofahrer automatisch das Untergeschoss zuweist, auf dem die meisten freien Parkplätze vorhanden sind und das andere Untergeschoss als „besetzt“ anzeigt. Unter der Annahme, dass die meisten Autofahrer innerhalb eines Untergeschosses einen Parkplatz wählen, der nicht an einer Säule liegt, ist es statistisch wahrscheinlicher, dass in einem Untergeschoss, in dem es generell mehr freie Parkplätze gibt, es auch mehr Parkplätze gibt, die nicht an Säulen liegen und damit für die meisten Autofahrer attraktiv sind. Eine Anpassung des Systemverhaltens ist in jedem Fall dringend zu empfehlen, da

62

die Tiefgarage konstruktionsbedingt noch einen weiteren Nachteil bietet: Es besteht für einen Autofahrer keine Möglichkeit, innerhalb der Tiefgarage das Untergeschoss zu wechseln. Hat sich ein Autofahrer also für ein Untergeschoss entschieden und findet er dort keinen passenden Parkplatz, so muss er die Tiefgarage über die Ausfahrt verlassen und durch die Haupteinfahrt neu befahren. Dies ist jedoch auch nicht ohne weiteres möglich, da sich der Standort der Tiefgarage in einer Einbahnstraße befindet, die Ausfahrt nicht direkt neben der Einfahrt liegt und der Autofahrer daher keine direkte Möglichkeit hat, von der Ausfahrt die Einfahrt zu erreichen. Er müsste hierzu einen Umweg von ca. 500 m (und damit auch einen signifikanten Zeitverlust) in Kauf nehmen.

An der Bushaltestelle betraten lediglich 10 % Prozent der Benutzer den Bus in genau 10 Sekunden, 30 % benötigten mehr und 60 % weniger als 10 Sekunden. Es kann bestätigt werden, dass die Wartezeit, die ein Benutzer warten musste, bis er in den Bus einsteigen konnte, mit steigender Anzahl der Fahrgäste, die vor ihm den Bus betreten oder den Bus verlassen (diese bilden den relevanten Kontexteinfluss), ebenfalls ansteigt. Ein adaptives System könnte z.B. versuchen, die Fahrgäste gleichmäßiger auf verschiedene Türen des Busses zu verteilen, um den Vorgang des Ein- und Aussteigens zu beschleunigen.

6.4 Erfahrungen des FeldversuchsDie Anwendung des Konzepts im Feldversuch zeigte die Stärken und Schwächen des Konzepts und des entwickelten Programms auf. Die gewonnenen Erfahrungen sollen in diesem Kapitel diskutiert werden.

In der Tiefgarage konnte das Konzept nur eingeschränkt angewendet werden, da die Smartphones, die zur Dokumentation der beobachteten Ereignisse benutzt werden sollten, keinen Empfang hatten. Die Dokumentation der Ereignisse auf Papier erwies sich jedoch als praktikable Alternative.

Bei der Dokumentation der Wahl des Untergeschosses konnte sowohl das Benutzerverhalten (Auswahl des Untergeschosses) wie auch die relevanten Kontextparameter (Anzeige der freien Stockwerke auf dem Pfeildisplay) ohne Probleme beobachtet und dokumentiert werden. Die hohe Frequenz der einfahrenden Autos führten zudem dazu, dass bereits nach kurzer Zeit eine aussagekräftige Menge an Datensätzen vorhanden war. Insbesondere die schnelle Beobachtung von Benutzerverhalten und Kontextattributen vereinfachten die Messung.

Bei der Dokumentation der Wahl des Parkplatzes innerhalb des ersten Untergeschosses, tauchten jedoch mehrere Schwierigkeiten auf: Einerseits war es aufwändig, die Werte der relevanten Kontextattribute zu Beginn der Beobachtung zu ermitteln (konkret: Alle freien Parkplätze sowie die freien Parkplätze an Säulen im Untergeschoss zählen) und andererseits war es auf Grund der hohen Änderungsdynamik (pro Minute mehrere neue Fahrzeuge, die das Untergeschoss befahren und verlassen) kaum möglich, die Veränderung der Anzahl der freien und belegten Parkplätze über die Beobachtungszeit zu überblicken und zu dokumentieren. Zusätzlich erschwert wurde die Dokumentation dadurch, dass viele Vorgänge (z.B. Parkplatz belegen, Parkplatz verlassen) parallel und zudem an verschiedenen Stellen des Untergeschosses abliefen und nicht alle Stellen vom Beobachtungsstandort ersichtlich waren.

Bei der Feldbeobachtung an der Bushaltestelle konnten das Benutzerverhalten sowie die Kontextattribute auf Grund der überschaubaren Action Area problemlos beobachtet werden. Die Dokumentation erwies sich dahingehend als schwierig, als dass die Dauer des Vorgangs, der

63

beobachtet werden sollte, unterhalb einer Minute lag und die Eingabe der Daten per Smartphones deutlich länger dauerte als zunächst angenommen. Zudem verzögerten Latenzzeiten bei der Internetverbindung die Anwendung des Programms (s. Details hierzu in Kapitel 6.5). Durch die hohe Frequenz der eintreffenden und abfahrenden Busse an der Haltestelle, konnten jedoch – wie in der Tiefgarage – in kurzer Zeit zahlreiche Benutzerbeobachtungen abgeschlossen werden.

6.5 Analyse der SchwachstellenIn diesem Kapitel sollen die in Kapitel 6.4 erwähnten Schwachstellen beim praktischen Einsatz des Konzepts aufgegriffen und mögliche Lösungsstrategien diskutiert werden.

Während der Dateneingabe über die Smartphones erwiesen sich insbesondere die Ladezeiten einzelner Seiten des Programms sowie die Eingabe der Daten über die Touchscreens als besonders zeitintensiv. Im Folgenden soll untersucht werden, inwiefern eine andere Form der Internetanbindung und der Einsatz anderer Eingabegeräte die Eingabe von Daten beschleunigen können.

Zunächst wurden die Zeiten für die Datenübertragung verglichen. Hierzu wurden mit unterschiedlichen Verbindungsarten jeweils zehn Feldbeobachtungen mit dem Programm simuliert und pro aufgerufene Seite die durchschnittliche Ladezeit (in Sekunden) ermittelt (s. Tabelle 18). Der Vergleich der Ladezeiten der einzelnen Seiten zeigte keine signifikanten Unterschiede, was bedeutet, dass die Übertragungsgeschwindigkeit der Internetverbindung der Smartphones genauso hoch war wie bei anderen Arten der Internetverbindung.

Jedoch zeigte eine detaillierte Analyse, dass die Latenzzeiten für einen Seitenaufruf bei einer Internetverbindung über ein Smartphone deutlich höher lagen (ca. 2 – 5 Sekunden bei UMTS- oder GPRS-Verbindung, ca. 2 – 3 Sekunden bei WLAN-Verbindung [DSL]) als bei einer Internetverbindung über ein Laptop (ca. 0,5 – 1 Sekunden bei WLAN-Verbindung [DSL]). Konkret bedeutet dies: Sobald eine Verbindung zu einer URL besteht, bestehen nur sehr geringe Unterschiede bei der Dauer der Datenübertragung, aber um eine Verbindung zu einer URL herzustellen können, erwies sich eine Verbindung über ein Laptop als deutlich schneller.

Die zweite Untersuchung bestand darin, die Dauer der Dateneingabe bei Benutzung unterschiedlicher Eingabegeräte zu vergleichen. Hierzu wurde der Prozess der Benutzerbeobachtung je zehn Mal mit zwei Laptops und zum Vergleich ebenfalls zehn Mal mit zwei Smartphones durchgeführt. Da ausschließlich die Dauer der Dateneingabe von Interesse war, wurden willkürlich gewählte Werte für Verhaltens- und Kontextattribute eingegeben. Die Erwartung, dass die Durchführung des Prozesses zur Benutzerbeobachtung auf einem Smartphone deutlich langsamer ablaufen würde als über ein Laptop, konnte bestätigt werden (s. Tabelle 19): Einerseits traten bei einem Seitenaufruf höhere Latenzzeiten bis zum erfolgreichen Herstellen einer Verbindung auf, andererseits nahm die Dateneingabe über die Touchscreens der Smartphones deutlich mehr Zeit in Anspruch. Ferner waren aufgrund der beschränkten Displaygröße mehr Scrollvorgänge notwendig als bei der Dateneingabe über Laptop. Dies zeigte sich insbesondere beim Vergleich der Dauer der Dokumentation der Verhaltens- bzw. Kontextattribute (6,2 sek. [Laptop], 21 sek. [Smartphone], s. Tabelle 19).

64

Aufgerufene Seite Ladezeit der Seite (Direktverbindung mit Laptop [localhost])

Ladezeit der Seite(Internetverbindung mit Laptop [DSL 2000 über WLAN])

Ladezeit der Seite (Internetverbindung über Smartphone [UMTS oder GPRS])

Auswahl Action Area (observe01.php) 0,01 sek. 0,03 sek. 0,03 sek.

Benutzerbeobachtung starten (observe02.php)

0,05 sek. 0,03 sek. 0,03 sek.

Auswahl relevanter Kontextattribute (observe03.php)

0,34 sek. 0,28 sek. 0,29 sek.

Auswahl, ob Verhaltens- oder Kontextattribute dokumentiert werden sollen (observe04.php)

0,04 sek. 0,04 sek. 0,04 sek.

Dokumentation der gewählten Attribute (observe05.php)

0,27 sek. 0,21 sek. 0,21 sek.

Zielanalyse (observe06.php) 0,03 sek. 0,03 sek. 0,07 sek.

Beenden der Beobachtung (observe07.php) 0,01 sek. 0,03 sek. 0,02 sek.

Summe der durchschnittlichen Ladezeiten:

0,75 sek. 0,65 sek. 0,70 sek.

Tabelle 18: Vergleich der durchschnittlichen Ladezeiten für einzelne Seiten des Programms während der Feldbeobachtung mit verschiedenen Verbindungsarten

Aufgerufene Seite Durchschnittliche Anzeigedauer der Seite bei Dateneingabe mit Laptop

Durchschnittliche Anzeigedauer der Seite bei Dateneingabe mit Smartphone

Auswahl Action Area (observe01.php) 3,4 sek. 5,8 sek.

Benutzerbeobachtung starten (observe02.php)

4 sek. 10,9 sek.

Auswahl relevanter Kontextattribute (observe03.php)

5,2 sek. 16,6 sek.

Auswahl, ob Verhaltens- oder Kontextattribute dokumentiert werden sollen (observe04.php)

9,1 sek. 19,5 sek.

Dokumentation der gewählten Attribute (observe05.php)

6,2 sek. 21 sek.

Zielanalyse (observe06.php) 4,9 sek. 7,6 sek.

Summe der durchschnittlichen Übertragungszeiten:

32,8 sek. 81,4 sek.

Tabelle 19: Vergleich der durchschnittlichen Anzeigedauern (inklusive der Zeit für die Eingabe der Daten) für einzelne Seiten des Programms während der Feldbeobachtung bei Benutzung unterschiedlicher Eingabegeräte

Mögliche Lösungsansätze für die oben genannten Probleme könnten etwa der Einsatz von alternativen Eingabegeräten, wie z.B. Tablet-PCs sowie die Nutzung von WLAN-Verbindungen sein. Dabei ist zu beachten, dass nicht in jeder Action Area eine Verbindung zum Internet möglich sein wird (s. Tiefgarage). Die (temporäre) Dokumentation von Verhaltens- und Kontextattributen mit Papierformularen könnte in diesen Fällen teilweise eine Alternative darstellen (s. auch Kapitel 6.1).

65

Andere Schwierigkeiten bestanden (s. Kapitel 6.4) in einer großen und unübersichtlichen Action Area (z.B. gesamtes Untergeschoss einer Tiefgarage, vgl. Kapitel 6.1.2), aufwändig messbaren Verhaltens- oder Kontextattributen (z.B. Anzahl der Parkplätze) und in Situationen, in denen mehrere Aspekte von einem Beobachter gleichzeitig beobachtet werden mussten (z.B. Anzahl der Personen, die aus einem Bus aussteigen und Anzahl der Personen, die in den Bus einsteigen, vgl. Kapitel 6.2).

Im Fall einer großen und unübersichtlichen Action Area könnte eine höhere Anzahl von Beobachtern (die untereinander per Funk verbunden sind) zu einem vollständigeren Bild bezüglich der Vorgänge in der Action Area führen. Auch die ergänzende Auswertung von Videoaufzeichnungen könnte hierbei hilfreich sein. Videoaufnahmen könnten ebenfalls dabei helfen, Vorgänge besser zu analysieren, die zeitlich schnell oder parallel ablaufen (vgl. [Rup07]).

Um den Aufwand für einen Feldversuch zu reduzieren, könnte ein Optimierungsansatz in der automatisierten Dokumentation von Verhaltens- und Kontextattributen mittels technischer Hilfsmittel und Sensoren bestehen: Eine Datenfusion aus GPS-Daten, Video- und Tonmaterial sowie weiteren Sensorwerten könnte ein adäquates Mittel darstellen, um ein ausreichend vollständiges Bild des Benutzers und seiner Umgebung zu erhalten.

66

7 Fazit und Ausblick

7.1 FazitIn dieser Arbeit sollte ein Konzept zur Ableitung von Anforderungen entwickelt werden, bei dem die aktive Mitarbeit eines Benutzers eines Systems nicht erforderlich ist. Hierbei sollte vor allem der Kontext eines Benutzers berücksichtigt werden und untersucht werden, welche Rückschlüsse aus dem Kontext und dem Verhalten eines Benutzers bezüglich neuer – oder geänderter Anforderungen abgeleitet werden können. Ferner sollte das Konzept an einem Beispiel aus der Domäne „Flughafen“ demonstriert und rudimentär implementiert werden. Eine Literaturrecherche, die einen Überblick über den aktuellen Stand der Forschung auf den Gebieten der Anforderungserhebung durch Benutzerbeobachtung, der kontextbezogenen Anforderungserhebung und der kontextsensitiven Systeme geben sollte, ist ebenfalls Bestandteil dieser Arbeit.

Die in dieser Arbeit durchgeführte Literaturrecherche ergab, dass die etablierten Techniken zur Anforderungserhebung mittels Feldbeobachtungen in den meisten Fällen den Dialog mit Stakeholdern suchen, um Hintergründe über die beobachteten Handlungen zu gewinnen. Der bewusste Verzicht auf jede Form der Interaktion mit dem Benutzer unterscheidet das in dieser Arbeit entwickelte Konzept von den etablierten Techniken. Die Literaturrecherche ergab weiterhin, dass der Begriff des Kontextes in der Literatur nicht einheitlich definiert ist, weswegen der Begriff für diese Arbeit neu definiert wurde (s. Definition 2) und dabei insbesondere der mögliche Einfluss des Kontextes auf das Verhalten des Benutzers berücksichtigt worden ist. Im Bereich der kontextadaptiven Systeme ergab die Literaturrecherche, dass insbesondere die erwünschte Fähigkeit eines kontextadaptiven Systems, adäquat auf äußere Einflüsse zu reagieren, eine besondere Herausforderung darstellt. Auch der mit der Adaptivität zusammenhängende Aufbau der Architektur eines adaptiven Systems und insbesondere die zwingend erforderliche Festlegung von invarianten Systemteilen erweisen sich bis heute als besonders schwierige Aspekte. Für die Entwicklung von adaptiven Systemen seien nach den Ergebnissen der Literaturrecherche auch neue Formen des Requirements Engineerings und der Qualitätssicherung erforderlich.

Das in dieser Arbeit entwickelte Konzept erlaubt es, kontextbezogene Benutzerbeobachtungen durchzuführen und dabei Indikatoren für geänderte bzw. neue Anforderungen zu gewinnen. Ausgehend von ortsspezifischen Zielen werden typische Handlungen betrachtet, die ein Benutzer zur Erreichung dieser Ziele durchführen wird. Für jede Handlung wird definiert, welche beobachtbaren Verhaltensattribute ein Benutzer gewöhnlicherweise hierbei zeigen wird. Während einer Benutzerbeobachtung werden die relevanten Verhaltensattribute des Benutzers sowie auffällige Kontextparameter dokumentiert und eine Einschätzung getroffen, welche Auswirkungen der Kontext auf die Ziele des Benutzer haben könnte. In der Auswertung der Benutzerbeobachtung können die Auswirkungen des Kontextes auf die Ziele des Benutzers näher untersucht werden und anhand der dokumentierten Daten konkrete Ansatzpunkte für die Anpassung der Regeln und damit des Systemverhaltens der adaptiven Systeme im Umfeld des Benutzers gewonnen werden.

Die Beobachtung des Kontextes eines Benutzers kann in vielen Situationen Hinweise auf geänderte Ziele des Benutzers geben, aus denen sich häufig auch neue oder geänderte Anforderungen ergeben. Jedoch sind die Erkenntnisse, die aus einer reinen Benutzerbeobachtung

67

(ohne eine Interaktion mit dem Benutzer) gezogen werden können, begrenzt und grundsätzlich nur heuristischer Natur: Wie ein Benutzer seine Umwelt wahrnimmt und welche Faktoren sein Verhalten beeinflussen, kann ohne einen Dialog mit dem Benutzer nicht sicher beantwortet werden. Insbesondere die Herleitung von kausalen Zusammenhängen zwischen Kontexteinflüssen und dem Benutzerverhalten scheint alleine durch die Beobachtung eines Benutzers nicht sicher möglich zu sein. Es ist jedoch auch zu bedenken, dass es Kontexteinflüsse geben könnte, die auf unbewusster Ebene Einfluss auf das Verhalten eines Benutzer haben könnten, so dass selbst ein Dialog mit dem Benutzer nicht zwingend alle für sein Verhalten relevanten externen Einflussfaktoren zu Tage fördern würde.

Das Konzept wurde im Rahmen dieser Arbeit anhand eines Beispiels aus der Domäne Flughafen demonstriert sowie im praktischen Einsatz unter realen Bedingungen angewendet. Im Feldversuch erwies sich die in dieser Arbeit durchgeführte Implementierung des Konzepts als hilfreiches Instrument zur Dokumentation des Benutzerverhaltens und des Kontextes des Benutzers. Die Grenzen im praktischen Einsatz des Konzepts lagen insbesondere in der Beobachtung von komplexen und schnell ablaufenden Prozessen sowie in der Dokumentation von aufwändig messbaren Kontext- und Verhaltensattributen.

Das in dieser Arbeit entwickelte Konzept soll und kann Erhebungstechniken für Anforderungen, die auf Interaktion und Kommunikation mit Stakeholdern basieren, nicht ersetzen, kann jedoch ergänzend zu etablierten Erhebungstechniken eingesetzt werden – insbesondere um die Teilmenge der Benutzer, bei denen keine kommunikativen Erhebungstechniken eingesetzt werden können, in die Anforderungserhebung zu integrieren.

7.2 AusblickIm praktischen Einsatz des Konzepts besteht vor allem bei der Datenerhebung Optimierungspotenzial. So könnte eine automatische Erhebung von bestimmten Kontexteinflüssen mittels Sensoren den Aufwand der Dokumentation verringern. Zeitkritische Abläufe könnten zudem mittels Videoaufzeichnungen dokumentiert und anschließend analysiert werden. Technische Hilfsmittel könnten zudem helfen, auf unauffällige Art und Weise weitergehende Details des Benutzerverhaltens zu erheben, indem z.B. eine Kamera, die (unsichtbar) in der Nähe eines Displays eines adaptiven Systems installiert ist, die Blickrichtungen und Augenbewegungen des Benutzers aufzeichnen könnte (Stichwort: Eye Tracking, s. auch [Poo+05]).

Ein entscheidender Aspekt bei der Anwendung des Konzepts ist unter anderem die Festlegung der relevanten Kontexteinflüsse. In Kapitel 3.3 wurden der räumliche Abstand eines Benutzers zu einem äußeren Einfluss und die subjektive Wahrnehmung von Umgebungseinflüssen durch den Beobachter als mögliche Heuristiken genannt, um die Auswahl der möglichen Kontexteinflüsse zu begrenzen. Bezüglich der Wahl der relevanten Kontexteinflüsse könnten weitere Heuristiken entwickelt werden, um die Menge der zu messenden Kontextattribute zu begrenzen und damit die Messung zu vereinfachen und die Qualität der erhobenen Daten zu verbessern. Als Ansatzpunkt für die Entwicklung möglicher Heuristiken könnten z.B. statistische Analysen von den in früheren Beobachtungen erhobenen Kontextattributen in einer Action Area dienen.

Bei der Auswertung der erhobenen Daten könnten verschiedene Data-Mining Techniken sowie statistische Analysen helfen, die genaueren Zusammenhänge zwischen den gemessenen Kontextattributen und den Abweichungen des Benutzerverhaltens vom erwarteten Verhalten noch konkreter zu bestimmen.

68

Nachdem das Benutzerverhalten in der Nähe eines adaptiven Systems in einer Action Area über einen längeren Zeitraum beobachtet und dokumentiert worden ist, wäre es möglich, basierend auf den erhobenen Daten jene Kontextattribute zu bestimmen, die sich häufig als Störfaktoren bezüglich der Zielerreichung eines Benutzers herausgestellt hatten. Die Kenntnis dieser Störfaktoren könnte die Basis für die Entwicklung eines adaptiven Systems sein, welches diese Störeinflüsse selbstständig kompensieren könnte. Verallgemeinert gesehen, wäre eine Entwicklung eines Frameworks für die Entwicklung von adaptiven Systemen, die speziell auf die Kompensation von Störeinflüssen in ihrem Umfeld spezialisiert sind, eine Perspektive.

Eine Vergleichsstudie zwischen dem in dieser Arbeit entwickelten Konzept und anderen Erhebungstechniken für Anforderungen in unterschiedlichen Szenarien könnte zudem Hinweise für einen noch zielgerichteteren Einsatz des Konzepts geben und Vorschläge liefern, welche ergänzenden Erhebungstechniken zusätzlich zu dem Konzept eingesetzt werden könnten, um in Kombination optimale Ergebnisse zu erzielen.

Die Implementierung könnte in Bezug auf Usability-Aspekte (insbesondere für die Nutzung auf Smartphones) weiter optimiert werden, um eine noch schnellere Dateneingabe zu ermöglichen. Auch die Erweiterung der Implementierung um erfahrungsbezogene Ansätze, wie z.B. die Nutzung von Daten aus bereits durchgeführten Beobachtungen in Form von Hinweisen und Hilfestellungen, könnten eine sinnvolle Maßnahme für eine effizientere Nutzung darstellen.

69

8 Literaturverzeichnis[SWE04]: IEEE Computer Society, Guide to the Software Engineering Body of Knowledge

(SWEBOK), http://www.computer.org/portal/web/swebok/htmlformat, 2004

[Sin+09]: L. Singer, O. Brill, S. Meyer, K. Schneider, Utilizing Rule Deviations in IT Ecosystems for Implicit Requirements Elicitation, Second International Workshop on Managing Requirements Knowledge (MaRK'09) at RE'09, 2009

[Bro10]: Brockhaus AG, Der Brockhaus multimedial premium 2010, Brockhaus AG, 2010

[Poh08]: K. Pohl, Requirements Engineering, dpunkt.verlag, 2008, S. 346, 347, 55 - 62, 89 - 91, 108 - 114, 122 - 125

[Rup07]: C. Rupp, Requirements-Engineering und Management, 4. Auflage, Hanser, 2007, S. 110, 120 - 122, 132

[Bey+98]: H. Beyer, K. Holtzblatt, Contextual Design, Academic Press, 1998, S. 37 - 66

[Sø+07]: I. D. Sørby, Ø. Nytrø, Towards a Tomographic Framework for Structured Observation of Communicative Behaviour in Hospital Wards, REFSQ 2007, Trondheim, Norway, 2007

[Nie93]: J. Nielsen, Usability Engineering, Morgan Kaufmann, 1993, S. 195 - 208

[Dza08]: J. A. B. D. Dzaack, Analyse kognitiver Benutzermodelle für die Evaluation von Mensch-Maschine-Systemen, Dissertation, Technische Universität Berlin, 2008

[Poo+05]: A. Poole, L. J. Ball, Eye Tracking in Human-Computer Interaction and Usability Research: Current Status and Future Prospects, Psychology Department, Lancaster University, UK, 2005

[Sit09]: W. O. Sitou, Requirements Engineering kontextsensitiver Anwendungen, Dissertation, Technische Universität München, 2009

[Sut+05]: A. Sutcliffe, S. Fickas, M. Moore Sohlberg, Personal and Contextual Requirements Engineering, RE '05: Proceedings of the 13th IEEE International Conference on Requirements Engineering, Paris, France, 2005

[Sch+98]: A. Schmidt, M. Beigl, H.-W. Gellersen, There is more to Context than Location, Computers & Graphics Journal, 1998

[Sey+08]: N. Seyff, F. Graf, P. Grünbacher, N. Maiden, Mobile Discovery of Requirements for Context-Aware Systems, REFSQ 2008, Montpellier, France, 2008

[Dey+99]: A. K. Dey, G. D. Abowd, Towards a Better Understanding of Context and Context-Awareness, HUC ’99: Proceedings of the 1st international symposium on Handheld and Ubiquitous Computing, Karlsruhe, Germany, 1999

70

[Wei09]: D. Weiß, Kontext-abhängige Personalisierung multimedialer Inhalte auf mobilen Endgeräten, Dissertation, Ludwig-Maximilians-Universität München, 2009

[Che+09]: B. H.C. Cheng, R. de Lemos, H. Giese, P. Inverardi, J. Magee, Software Engineering for Self-Adaptive Systems: A Research Roadmap, Dagstuhl Seminar 08031 on “Software Engineering for Self-Adaptive Systems, Dagstuhl, Germany, 2009

[Gei08]: K. Geihs, Selbst-adaptive Software, Informatik-Spektrum, Ausgabe 31, Number 2, S. 133-145, 2008

[Wel+09]: K. Welsh, P. Sawyer , Requirements Tracing to Support Change in Dynamically Adaptive Systems, REFSQ 2009, Amsterdam, Netherlands, 2009

[Sal09]: M. Salehie, L. Tahvildari, Self-Adaptive Software: Landscape and Research Challenges, ACM Transactions on Autonomous and Adaptive Systems (TAAS), Volume 4, Issue 2 (May 2009), 2009

[Lad01]: R. Laddaga, Active Software, First International Workshop, IWSAS 2000 Oxford, UK, April 17-19, 2000 Revised Papers, 2001

[Lad06]: R. Laddaga, Self Adaptive Software – Problems and Projects, SOFTWARE-EVOLVABILITY '06: Proceedings of the Second International IEEE Workshop on Software Evolvability, 2006

[Hor01]: P. Horn, Autonomic Computing: IBM’s Perspective on the State of Information Technology, IBM, http://www.research.ibm.com/autonomic/manifesto/, 2001

[Mei+07]: L. Mei, S. Easterbrook, Evaluating User-centric Adaptation with Goal Models, First International Workshop on Software Engineering for Pervasive Computing Applications, Systems, and Environments (SEPCASE '07), 2007

[Her+08]: S. Herol, H. Klus, D. Niebuhr, A. Rausch, Engineering of IT Ecosystems: Design of Ultra-Large-Scale Software-Intensive Systems, ULSSIS’08, May 10–11, 2008, Leipzig, Germany, 2008

[Wel+08]: K. Welsh, P. Sawyer, When to Adapt? Identification of Problem Domains for Adaptive Systems, REFSQ 2008, Montpellier, France, 2008

[BDSG09]: Bundesdatenschutzgesetz, http://www.gesetze-im-internet.de/bundesrecht/bdsg_1990/gesamt.pdf, 2009

71