Es gibt keinen klaren Konsens über das, was ein benutzerzentriertes Design ausmacht. John Gould und seine Kollegen bei
IBM haben jedoch in den achtziger Jahren einen Ansatz (Design for Usability [GOU88]) entwickelt,
der die gemeinhin akzeptierten Definitionen beinhaltet. Dieser Ansatz stützt sich auf praktische Erfahrung in einer
Reihe von interaktiven Systemen, von denen insbesondere das Olympic Messaging System der IBM von 1984 [GOU87] zu erwähnen ist. Der Ansatz hat vier Hauptkomponenten, die im Folgenden
beschrieben sind.
Gould schlägt vor, dass Entwickler die Zielgruppe festlegen müssen und sie zum frühestmöglichen Zeitpunkt
einbezieht. Er schlägt eine Reihe von Methoden vor, um sich mit den Benutzern, ihren Aufgaben und Anforderungen
vertraut zu machen:
· Mit Benutzern
sprechen
|
· Kunden besuchen
|
· Benutzer bei der Arbeit
beobachten
|
· Videos von Benutzern bei
der Arbeit erstellen
|
· Informationen zur
Arbeitsorganisation sammeln
|
· Selbst
ausprobieren
|
· Benutzer dazu bringen,
bei der Arbeit laut zu denken
|
· Kooperatives
Design
|
· Erfahrene Benutzer in
das Designteam aufnehmen
|
· Aufgabenanalyse
durchführen
|
· Umfragen machen und
Fragebogen austeilen
|
· Testfähige Ziele
entwickeln
|
In Rational Unified Process (RUP) werden in mehreren Schlüsselstadien Workshops abgehalten, aber
diese müssen durch die von Gould beschriebenen Arten von Aktivitäten ergänzt werden, um ein genaues Bild zu erhalten.
(Ein Grund hierfür ist, dass Personen häufig etwas anderes beschreiben als das, was sie wirklich tun. Häufig
ausgeführte Aufgaben und scheinbar unwichtige Details wie der Zeitpunkt, zu dem eine Aktivität ausgeführt wird, oder
die Existenz "mysteriöser" Zettel werden häufig vergessen oder weggelassen, weil sie "offiziell" nicht zum aktuellen
Prozess gehören.)
Aufgaben im Bereich Benutzerfreundlichkeit müssen bereits in einem frühen Stadium der Entwicklung parallel
ausgeführt werden. Zu diesen Aufgaben gehören beispielsweise das Skizzieren der Benutzerschnittstelle und das Erstellen
eines Entwurfs für die Benutzerhandbücher oder die Onlinehilfe. Gould stellt sogar das Prinzip auf, dass
Benutzerfreundlichkeit in die Hände einer speziellen Gruppe gelegt werden sollte.
Ein wichtiges Merkmal des integrierten Design ist, dass der Gesamtansatz - das Framework - für detailliertes
Benutzerschnittstellendesign in einem frühen Stadium entwickelt und getestet wird. Es besteht ein wichtiger Unterschied
zwischen benutzerzentriertem Design und anderen rein inkrementellen Techniken. Das benutzerzentrierte Design stellt
sicher, dass inkrementelles Design, das in späteren Phasen durchgeführt wird, sich nahtlos in das Framework einfügt und
dass die Benutzerschnittstelle in Erscheinung, Terminologie und Konzept konsistent ist.
In RUP kann dieses Framework durch Verwendung eines Domänenmodells eingerichtet werden, um sicherzustellen, dass
Terminologie und Konzepte, die in der Benutzerschnittstelle vorkommen, in ihrer Gesamtheit im Geschäft im Allgemeinen
und bei den Benutzern im Besonderen bekannt sind und verstanden werden. (Außerdem wird es Teile des Domänenmodells
geben, die nur für bestimmte Gruppen von Benutzern relevant sind. Es sollte sorgfältig darauf geachtet werden, dass das
Domänenmodell so aufgebaut ist, dass diese Teile leicht zu erkennen sind.) Mit fortschreitendem
Benutzerschnittstellendesign werden viele Domänenklassen als Benutzerschnittstellenelemente dargestellt. Die
Benutzerschnittstellenelemente und ihre Beziehungen untereinander müssen mit dem Domänenmodell konsistent sein und in
allen Teilen des entworfenen Systems konsistent dargestellt werden. (Dies hilft nicht nur den Benutzern, sondern
unterstützt auch die Wiederverwendung von Benutzerschnittstellenkomponenten.)
Frühe Benutzertests bedeuten Storyboarding und Entwicklung von Prototypen mit geringer Genauigkeit in einem
frühen Stadium. Prototypen mit hoher Genauigkeit folgen später im Prozess.
Storyboards können zusammen mit Anwendungsfällen verwendet werden, um konkrete Szenarios für das zu entwerfende System
zu schreiben. Diese können eine erzählende Form oder eine erzählende Form mit Bildern (unter Einbeziehung der
Benutzerschnittstellenmodelle zur Veranschaulichung) annehmen. Storyboards, Walkthroughs (mit Benutzern) und
benutzerkonzentrierte Gruppen sind Ansätze, mit denen viele Softwareentwickler möglicherweise nicht vertraut sind.
Diese Ansätze sind jedoch ganz eindeutig kostenwirksamer, als nach der Implementierung erkennen zu müssen, dass das
Design nicht angemessen ist oder die Anforderungen missverstanden wurden.
Objektorientierte Entwicklung ist zu einem Synonym für einen iteratives Prozess geworden. Iteratives Design
eignet sich bestens für Probleme, die einer Verständnisklärung bedürfen und Anforderungsänderungen unterliegen. Deshalb
ist es nicht überraschend, dass iteratives Design eine Schlüsselkomponente des benutzerzentrierten Designs ist. Dies
ist teilweise auf die Bedürfnisse der Benutzer zurückzuführen, die sich mit der Zeit ändern, aber auch auf die
inhärente Komplexität der Erstellung von Designlösungen, die unterschiedliche Bedürfnisse bewältigen können.
In benutzerzentrierten Methoden findet iteratives Design innerhalb eines integrierten Frameworks statt. Wir
meiden inkrementelle Entwicklung außerhalb eines beschlossenen Frameworks absichtlich, da dies zu einer
"Patchwork-Lösung" führen könnte.
Erfolgreiche interaktive Systeme stützen sich auf ihre Fähigkeit, die Bedürfnisse von Benutzern zu erfüllen. Dies
bedeutet nicht nur, die diversen Benutzergruppen zu ermitteln, sondern auch das Know-how, die Erfahrung und die
Vorlieben einzelner Benutzer zu erkennen.
Obwohl es für viele Entwickler und Manager verlockend ist, davon auszugehen, sie würden verstehen, was der Benutzer
braucht, bewahrheitet sich dies in der Praxis nur selten. Häufig liegt die Aufmerksamkeit darauf, wie der Benutzer
Aufgaben ausführen sollte, und nicht, wie er bevorzugt, die Aufgaben auszuführen. In vielen Fällen ist
der Aspekt von Vorlieben viel mehr, als einfach das Gefühl der Kontrolle zu haben, obwohl dies für sich selbst genommen
ein wichtiger Aspekt ist. Vorlieben werden auch durch Erfahrung, Fähigkeiten und Verwendungskontext bestimmt. Diese
Aspekte werden als so wichtig für den Designprozess betrachtet, dass sie in dem internationalen Standard [ISO 13407] mit dem Titel Benutzer-orientierte Gestaltung interaktiver Systeme
Berücksichtigung gefunden haben. Der Standard und zugehörige Aspekte werden im verbleibenden Teil allgemein
beschrieben.
Benutzer begreifen ein System über seine Benutzerschnittstelle, über die sie mit ihm interagieren. Die Konzepte, Bilder
und Terminologie, die in der Schnittstelle präsentiert werden, müssen den Bedürfnissen der Benutzer entsprechen. Ein
System, das Kunden ermöglicht, Tickets zu kaufen, würde sich beispielsweise erheblich von einem System unterscheiden,
das professionell von Ticketverkaufspersonal verwendet wird. Die Hauptunterschiede sind nicht bei den Anforderungen und
auch nicht bei den detaillierten Anwendungsfällen, sondern bei den Merkmalen der Benutzer und den Umgebungen, in denen
die Systeme betrieben werden, zu finden.
Die Benutzerschnittstelle muss außerdem einen potenziell weiten Bereich von Erfahrungen in mindestens zwei Dimensionen
- Computer- und Domänenerfahrung - ansprechen. Vergleichen Sie dazu Abbildung 1. Computererfahrung bezieht sich nicht
nur auf eine allgemeine Vertrautheit mit Computern, sondern auch auch Erfahrung mit dem entwickelten System. Benutzer,
die wenig Erfahrung mit Computern oder der Problemdomäne haben (linke Ecke der Abbildung) erfordern einen grundsätzlich
anderen Ansatz in der Benutzerschnittstelle als erfahrene Benutzer (in der rechten Ecke der Abbildung).
Abbildung 1: Die Auswirkungen von Computer- und Domänenerfahrung auf die Erlernbarkeit vs.
Benutzerfreundlichkeit
Es ist nicht selbstverständlich, dass unerfahrene Benutzer mit der Zeit Experten werden. Seltene Verwendung, geringe
Motivation und hohe Komplexität sind Faktoren, die einer solchen Entwicklung im Wege stehen können. Umgekehrt können
einige Systeme vorwiegend erfahrene Benutzer haben. Faktoren können hier eine gute Schulung, häufige Verwendung und
hohe Motivation (Jobabhängigkeit) sein. Einige dieser Aspekte und ihre Auswirkungen auf das
Benutzerschnittstellendesign sind in Tabelle 1 gezeigt.
|
Niedrig
|
Hoch
|
Computererfahrung
|
Einfache Frage und Antwort, Ausfüllen einfacher Formulare, Schnittstelle im Web- (Hyperlink-) oder
Menüstil
|
Ausfüllen komplexer Formulare, Schnittstelle im Web- (Hyperlink-) oder Menüstil; (Frage und Antwort
oder Ausfüllen einfacher Formulare können für erfahrene Benutzer sehr frustrierend sein)
|
Domänenerfahrung
|
Allgemeine Terminologie und Konzepte
|
Domänenspezifische Terminologie und Konzepte
|
Schulung
|
Fokus auf Erlernbarkeit (konsistent, vorhersagbar, einprägsam)
|
Fokus auf Benutzerfreundlichkeit (direkt, anpassbar, unaufdringlich)
|
Verwendungshäufigkeit
|
Einfach zu lernen und merken, einfacher Schnittstellenstil
|
Einfach zu verwenden, mehrere Direktaufrufe und Techniken für Benutzereingabesteuerung
|
Motivation
|
Interessante Verwendung, leistungsstark, ohne komplex zu erscheinen.
|
Ausgereift mit vielen innovativen und anpassbaren Features.
|
Tabelle 1, Einige Faktoren, die das Benutzerschnittstellendesign beeinflussen
Interaktive Systeme müssen entweder so entworfen werden, dass sie einen entsprechenden Bereich von Benutzererfahrung
und Situationen abdecken, oder es müssen Schritte eingeleitet werden, um das Designuniversum einzuschränken.
Beispielsweise können durch Schulungen die Anforderungen für die Erlernbarkeit in einem komplexen System verringert
werden. Alternativ kann ein System in seinem Umfang reduziert werden, so dass es den Kernanforderungen seiner Benutzer
besser entgegenkommt (ein Vorschlag, den Alan Cooper in seinem Buch The Inmates Are Running the Asylum [COO99] macht).
Beim benutzerzentrierten Design müssen wir das Know-how und die physischen Attribute von Benutzern berücksichtigen.
Diese Aspekte werden immer mehr in gesetzliche Vorschriften eingebettet. Diese Vorschriften zielen zum Großteil darauf
ab, Benutzern mit Behinderungen Rechnung zu tragen. Systeme einem breiteren Bereich von Benutzern zugänglich zu machen,
wird jedoch generell als vorteilhaft für die Benutzergemeinde als Ganzes angesehen.
In der folgenden Tabelle sind die relevanten gesetzlichen Vorschriften und die zugehörigen Quellen aufgeführt, die für
viele Teile der Welt gelten:
Tabelle 2a, Gesetzliche Vorschriften, die sich auf Behinderungen
beziehen, sortiert nach Land, Region und Behörde
Benutzerzentriertes Design und Benutzerschnittstellendesign finden nicht nur in den gesetzlichen Vorschriften,
sondern auch in der Standardisierung immer mehr an Beachtung, wie die folgende Tabelle zeigt.
Beschreibung
|
Website/Standards
|
ANSI
|
www.ansi.org
|
ANSI
ANSI-HFES
ANSI-NSC
|
ANSI und die Human Factors and Ergonomics Society haben eine Reihe gemeinsamer Standards
veröffentlicht. ANSI hat unter anderem den Standard ANSI-NSC Z365 entwickelt, der sich auf die
Kontrolle und Vorbeugung kumulativer Stresssyndrome (auch Repetitive Strain Injury oder RSI
genannt) bezieht.
ANSI entwirft Standards, die sich im Rahmen des Information Infrastructure Standards Panel (IISP)
mit der Mensch-Computer-Interaktion (HCI, Human Computer Interaction) beschäftigen.
|
ISO
|
www.iso.ch
|
ISO 9241
|
Eine umfangreiche Reihe von Standards, die sich hauptsächlich mit der Ergonomie von Workstations
beschäftigen, aber auch Anleitung zur Benutzerfreundlichkeit (Teil 11) enthalten und die Basis für den
gerade entwickelten Standard ANSI-HFES 200 bilden.
|
ISO 10075: 1991
|
Ergonomische Richtlinien für mentale Belastung
|
ISO 17041-1: 1995
|
Cursorsteuerung für Textverarbeitung
|
ISO 11581
|
Reihe von Entwicklungsnormen für Symbole und Zeiger.
|
ISO 13407: 1999
|
Standard für benutzerzentrierte Gestaltung von Prozessen für interaktive Systeme.
|
Tabelle 2b, ANSI- und ISO-Standards für
Benutzerschnittstellen- und benutzerzentriertes Design
Die Entwicklung von Systemen, die Benutzerbedürfnissen entsprechen, bedeutet einen erheblichen Aufwand bei der
Anforderungsanalyse. Beim benutzerzentrierten Design konzentriert sich dieser Aufwand auf Endbenutzer.
Die Disziplin Geschäftsmodellierung deckt die Modellierung der Mitarbeiter (innerhalb des Geschäfts) und der
Geschäftsakteure (außerhalb des Geschäfts) ab.
Ein wesentlicher Schwerpunkt im benutzerzentrierten Design liegt auf dem Verständnis der Anforderungen der realen
Personen, die die Rollen ausfüllen, die in den zuvor beschriebenen Arbeitsergebnissen beschrieben sind. Im Besonderen
müssen wir vermeiden, hypothetische Benutzer zu entwerfen, für die das Design von Softwaresystem ein Leichtes ist. Die
Arbeitsergebnisse, die Benutzer beschreiben, dürfen erst nach ausgiebigem und direktem Kontakt mit Benutzern
geschrieben werden. Beim benutzerzentrierten Design ist der direkte Kontakt zu Benutzern Teil eines Prozesses, der
zuweilen auch als kontextbezogene Recherche bezeichnet wird. Hugh Beyer und Karen Holtzblatt beschreiben (in
ihrem Buch Contextual Design, [BEY98]) die
Voraussetzung für eine kontextbezogene Recherche wie folgt:
"...go where the customer works, observe the customer as he or she works, and talk to the customer about the work."
(Einige konkrete Beispiele hierfür wurden bereits unter Fokus auf Benutzer
aufgeführt.) Dieser Ansatz wird nicht nur verwendet, um ein besseres Verständnis der Systemanforderungen zu erlangen,
sondern auch ein besseres Verständnis der Benutzer selbst, ihrer Aufgaben und ihrer Umgebungen. Jeder Benutzer hat
eigene Attribute, die zusammen den so genannten Verwendungskontext bilden. Diese Attribute sind im ISO-Standard für
benutzerzentriertes Design, der im Folgenden beschrieben wird, ausführliche dargelegt.
Der ISO-Standard Benutzer-orientierte Gestaltung interaktiver Systeme [ISO13407] beschreibt
den ersten Schritt im Design als Verstehen und Spezifizieren des Verwendungskontextes. Die vorgeschlagenen Attribute
sind:
Kontext
|
Attribut
|
Aufgaben
|
Ziele der Systemverwendung, Häufigkeit und Dauer der Aufgaben, Arbeitsschutzüberlegungen, Zuordnung
von Aktivitäten, Interaktion zwischen Benutzern und technischen Ressourcen. Aufgaben sollten
nicht nur mit Funktionen oder Features beschrieben werden, die ein Produkt oder ein System
bereitstellt.
|
Benutzer (für jeden Typ oder jede Rolle)
|
Wissen, Know-how, Erfahrung, Ausbildung, Schulung, physische Attribute, Gewohnheiten, Vorlieben,
Fähigkeiten.
|
Umgebungen
|
Hardware, Software, Material; physische und soziale Umgebungen, relevante Standards, technische
Umgebung, räumliches Umfeld, gesetzgebende Umgebung, soziale und kulturelle Umgebung.
|
Tabelle 3: Verwendungskontext aus dem ISO-Standard für benutzerzentriertes Design
Es ist hilfreich, den Benutzerkontext in zwei Bestandteile (Benutzertyp und Rolle) aufzuteilen und anschließend die
Beziehungen zwischen allen vier Kontexten zu betrachten:
Abbildung 2: Beziehungen zwischen Kontexten
Abbildung 2 zeigt, dass jede Aufgabe innerhalb einer Rolle ausgeführt wird, die ein Benutzer in
einer Umgebung einnimmt. Diese Kontexte entsprechen den RUP-Arbeitsergebnissen, die in Tabelle 4 aufgelistet
sind.
ISO-13407-Kontext
|
RUP-Arbeitsergebnisse
|
Umgebungen
|
|
Benutzer
|
|
Rollen
|
-
Hohe Ebene:
-
Geschäftsakteur (externe Benutzer),
-
Mitarbeiter oder Geschäftssystem (interne Benutzer)
-
Detailliert:
|
Aufgaben
|
|
Tabelle 4, Gegenüberstellung der
ISO-Standardkontexte für benutzerzentriertes Design und der RUP-Arbeitsergebnisse
Jeder dieser Kontexte kann nicht unerhebliche Auswirkungen auf das Design einer entsprechenden Benutzerschnittstelle
haben. Deshalb stehen wir einer potenziell hohen Anzahl von Permutationen gegenüber. Selbst für ein kleines System kann
es zwei Umgebungen (z. B. Geschäft und Kunde), drei Typen von Benutzern (Vertriebsneuling, Vertriebsexperte und
Management) sowie sechs Rollen (Telefonvertriebsassistent, externe Vertriebsbeauftragte usw.) geben. Dies bedeutet 36
potenzielle Varianten pro Aufgabe, obwohl die Anzahl realistischer Kombinationen gewöhnlich wesentlich kleiner ist.
Aufgaben müssen ganz eindeutig individuell beschrieben werden, aber eine einzelne Beschreibung reicht für alle
Permutationen wahrscheinlich nicht aus. Ein Ansatz ist, die Benutzer- und Umgebungskontexte in der Rollenbeschreibung
zu berücksichtigen. Diese Lösung wird von Constantine und Lockwood [CON99] angewendet.
Bei dieser Lösung wird eine separate "Benutzerrolle" für jede wichtige Permutation von Rolle, Benutzer und Umgebung
verwendet. Anschließend wird diese Benutzerrolle mit einer beschreibenden Wortfolge und nicht nur mit einem einzelnen
Substantiv benannt. Vergleichen Sie beispielsweise die Rolle "Kunde" mit den Benutzerrollen "Gelegentlicher Kunde",
"Webkunde", "Regelmäßiger Kunde" und "Erfahrener Kunde".
Jede Beschreibung einer Benutzerrolle enthält Details zur Rolle selbst und zu ihren Benutzern (den so genannten
Rolleninhabern) und zur Umgebung. Dieser Ansatz kann in RUP übernommen werden, indem Akteure ausgewählt werden, die den
Benutzerrollen entsprechen.
Die Begriffe Szenarios, Anwendungsfälle und wesentliche Anwendungsfälle weisen einen teilweise verwirrenden Grad von
Überlappung auf und werden in unterschiedlichen Designansätzen verwendet, um etwas geringfügig Anderes zum Ausdruck zu
bringen. In RUP bedeutet "Szenario" beispielsweise eine Anwendungsfallinstanz, d. h. einen speziellen "Pfad" durch die
möglichen Basis- und Alternativabläufe. Häufig findet man jedoch Methoden im benutzerzentrierten und
Benutzerschnittstellendesign, die Szenarios als Verwendungsstorys beschreiben, die wesentlich mehr Details als
lediglich den Ereignisablauf enthalten. Obwohl diese zusätzlichen Informationen in späteren Designphasen irrelevant
sein können, tragen sie zum Verständnis von Benutzern, Aufgaben und Umgebungen bei. Deshalb können Szenarios (beim Storyboarding und Rollenspiel) in
der Disziplin Geschäftsmodellierung ausgiebig verwendet werden, wohingegen sich der Fokus in der Disziplin
Anforderungen auf Anwendungsfälle verlagert.
Abbildung 3 zeigt die Art dieser Überlappung. Die obere Skala umfasst eine Reihe unterschiedlicher Faktoren, die
gewöhnlich miteinander variieren. Wenn sich die Zielsetzung beispielsweise mehr in Richtung Anforderungen
verschiebt, wird die Struktur gewöhnlich formaler. Wesentliche Anwendungsfälle werden rechts von den generischen
Anwendungsfällen dargestellt, weil Benutzerrollen sie ein wenig spezifischer machen (siehe vorheriger Abschnitt) und
weil sie eine formalere Struktur haben.
Abbildung 3: Überlappung der Konzepte von Szenarios und Anwendungsfällen im benutzerzentrierten
Design
Die Unterschiede zwischen Systemanwendungsfällen und wichtigen Anwendungsfällen lassen sich am besten anhand von
Beispielen veranschaulichen. Tabelle 5 zeigt einen Anwendungsfall aus der Veröffentlichung "Software for Use" von
Constantine und Lockwood [CON99]:
Benutzeraktion
|
Systemantwort
|
Karte einführen
|
Magnetstreifen lesen
PIN anfordern
|
PIN eingeben
|
PIN prüfen
Transaktionsauswahlmenü anzeigen
|
Taste drücken
|
Kontomenü anzeigen
|
Taste drücken
|
Betrag anfragen
|
Betrag eingeben
|
Betrag anzeigen
|
Taste drücken
|
Karte ausgeben
|
Karte nehmen
|
Geld ausgeben
|
Geld entnehmen
|
|
Tabelle 5: Generischer Anwendungsfall für Abheben von Bargeld an einem Geldautomaten
Dieses Beispiel zeigt detailliert die Abfolge der Ereignisse zwischen dem Akteur und dem System. Die vertikale Linie
zwischen den beiden Spateln stellt die Benutzerschnittstelle dar. Obwohl Constantine und Lockwood diesen Stil für
wesentliche Anwendungsfälle empfehlen, ist dieser spezielle Anwendungsfall kein wichtiger, weil er auf den
syntaktischen Interaktionsdetails basiert. Hier wird gezeigt, wie die Interaktion stattfindet. Ein wichtiger
Anwendungsfall konzentriert sich darauf, worum es bei der Interaktion geht (die Semantik). Tabelle 6 zeigt die
essenzielle Version der Interaktion.
Benutzerabsicht
|
Systemzuständigkeit
|
sich selbst identifizieren
|
Identität prüfen
Auswahl anbieten
|
Auswahl
|
Geld ausgeben
|
Geld entnehmen
|
|
Tabelle 6: Wesentlicher Anwendungsfall für Abheben von Bargeld an einem Geldautomaten
Dieser Anwendungsfall erfasst das Wesentliche der Interaktion "Geld abheben". Die Überschriften Benutzeraktion
und Systemantwort wurden durch Benutzerabsicht bzw. Systemzuständigkeit ersetzt, um die Verlagerung des Schwerpunkts zu
veranschaulichen. Ein gutes Schnittstellendesign konzentriert sich auf Benutzerziele und -absichten. Diese bleiben in
konventionellen Anwendungsfällen häufig verborgen. Wesentliche Anwendungsfälle sind besonders hilfreich in den
folgenden Situationen:
-
Es gibt nur wenige Designeinschränkungen (beispielsweise gilt die implizierte Designeinschränkung für die
Verwendung von Bankkarten hier nicht).
-
Das System wird möglicherweise erweitert, um andere Mittel der Identifizierung zuzulassen (z. B. eine Art sicheren
Internetzugangs).
-
Es besteht der Wunsch, Anwendungsfälle ohne Designeinschränkungen zu erstellen, um sie unter Umständen in Projekten
wiederverwenden zu können, in denen diese Einschränkungen nicht bestehen.
Wesentliche Anwendungsfälle haben jedoch auch ihre Nachteile. Ganz eindeutige Anwendungsfälle wie der in Tabelle 5
können ausgedehnte Debatten auslösen, wenn es darum geht, das Wesentliche herauszuarbeiten. Wird beispielsweise beim
Einführen der Karte der Kunde oder das Konto identifiziert? Bei den meisten Geldautomaten ist letzteres der Fall,
obwohl Constantine und Lockwood vorgezogen haben, diese Tatsache so zu interpretieren, dass der Kunde identifiziert
wird. Dies mag angesichts neuerer Technologien wie Identifizierung durch Scannen der Netzhaut oder durch Fingerabdruck
eine absichtliche Entscheidung, kann aber auch ein Versehen gewesen sein. Die Konsequenzen sind in diesem Fall, dass
eine zusätzliche Auswahl von solchen Kunden getroffen werden muss, die mehrere Konten haben.
Eine weitere Schwierigkeit wesentlicher Anwendungsfälle ist die, dass sie nicht für die Prüfung durch Benutzer und
andere Stakeholder geeignet sind, weil sie abstrakter Natur sind. Ein Teil dieses Problems ist darauf zurückzuführen,
dass wesentliche Anwendungsfälle in eine konkrete Form mit Benutzeraktionen zurück übersetzt werden müssen. Dies kann
getan werden, sobald ein Designmodell verfügbar ist, indem Szenarios geschrieben werden, die die Interaktion konkret
beschreiben (ähnlich im Konzept wie eine Anwendungsfallrealisierung, obwohl es hier um die Interaktion
zwischen Benutzer und System und nicht um interne Objektkollaboration geht).
Zusammenfassend gesagt, die Erstellung von wesentlichen Anwendungsfällen bietet sich in den folgenden Situationen nicht
an:
-
Die Benutzerschnittstellentechnologien sind absichtlich mit vielen Einschränkungen belegt (z. B. das System muss
Bankkarten akzeptieren).
-
Die Zeit, die Benutzer brauchen, um die abstrakteren Anwendungsfälle zu verstehen, steht in keinem Verhältnis zu
den zu erwartenden Vorteilen.
RUP verweist nicht explizit auf wesentliche Anwendungsfälle, aber in der Aufgabe Benutzerschnittstelle entwerfen werden wesentliche
Anwendungsfälle als Ausgangspunkt verwendet, die dann mit Anforderungen an die Benutzerfreundlichkeit entwickelt und
erweitert werden, um Storyboards zu erstellen (siehe Richtlinie:
Storyboard).
Alle Design- bzw. aktuellen Implementierungsdetails werden entfernt, so dass nur die Semantik, d. h. die Bedeutung der
Interaktion, verbleibt. Anschließend werden verschiedene Designalternativen untersucht und dem wesentlichen
Anwendungsfall als Typ der Realisierung syntaktische Details (wie findet die Interaktion statt) hinzugefügt. (Jedes
alternative Design ist eine Realisierung desselben wesentlichen Anwendungsfalls.)
Storyboards können anschließend als Eingabe für die Aufgabe Prototyp der Benutzerschnittstelle erstellen verwendet werden, um den
Benutzerschnittstellenprototyp zu entwickeln.
|