Freitag, 5. Dezember 2014

Dem Ziel entspringt die Anforderung. Alles ist im Fluss.

Ein System für den Entwurf einer Benutzerschnittstelle.

Artikelübersicht
1. Teil Die Erweiterung des Requirements Engineering durch das Usability Engineering.
2. Teil Mit Zielen zum User Interface.
3. Teil Dem Ziel entspringt die Anforderung. Alles ist im Fluss.
4. Teil Von Erwartungen und Konzepten. Struktur für das User Interface.
5. Teil Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.
6. Teil Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.
7. Teil Elemente verteilen ohne Ausraster.
8. Teil Mit den Sinnen den Sinn der Oberfläche erfassen.


Im letzten Post wurde der Zielbaum durch spezifische Ziele in Bezug auf das User Interface ergänzt. Im Modell von [GARRETT12] haben wir damit die Strategieebene abgearbeitet. Aus diesen ermittelten Bedürfnissen leiten wir nun konkrete Anforderungen an unsere Benutzeroberfläche ab. Welche Inhalte, welche Funktionen und Workflows soll die Schnittstelle bieten? [GARRATT12] erläutert zwei wichtige Gründe, warum wir uns überhaupt mit der Definition von Anforderungen beschäftigen sollten. Der erste Grund ist, "damit Sie wissen, was Sie entwickeln" [S.59, GARRATT12] und der zweite Grund ist, "damit Sie wissen, was Sie nicht entwickeln". Leider gibt es sehr viele, denen das trivial erscheint und die deshalb auf eine Anforderungsdefinition verzichten. Allen denen, die mit mir glauben, dass gerade trivial erscheinende Dinge sehr schwierig sein können, empfehle ich vor der Umsetzung die Beantwortung der Frage: "Was werden wir entwickeln?" [S.61, GARRATT12]

Antworten auf diese Frage können wir durch vielfältige Techniken gewinnen. In der Systemkontextanalyse haben wir eine Vielzahl von Stakeholdern gefunden, aber auch Personas und extreme Charaktere gebildet. Im Kontakt mit zukünftigen Benutzern, Administratoren, aber auch im Gedankenexperiment können wir Nutzungsszenarios entwickeln. "Diese Personas können wir bei der Definition der Anforderungen wiederverwenden. Dazu setzen wir unsere fiktiven Charaktere in kleinen Geschichten namens Szenarios ein. Ein Szenario ist eine kurze, einfache Erzählung, die beschreibt, wie eine Persona versucht, ihre Benutzerbedürfnisse zu befriedigen." [S.67, GARRATT12] [GARRATT12] schränkt seine Beschreibung auf Personas ein, den Vorgang können wir natürlich auch mit realen Stakeholdern durchspielen. Interessant ist der Output dieses Prozesses. Schon im Prozess des Requirements Engineering habe ich Szenarios verwendet. Dort wurden mit Hilfe von Zielen, Systemkontextobjekten und User Stories Szenarien entwickelt, die dann im weiteren Verlauf zu Use Cases zusammengesetzt wurden. Das kann man in den Posts Die Geschichten der Benutzer - User Stories erstellen, Wie User Stories Use Cases gebären und Szenarien setzen sich zu Use Cases zusammen nachlesen.



Den gleichen Weg möchte ich für das Entwickeln von Anforderungen für das User Interface vorschlagen. Die Ziele wurden inzwischen in Hinblick auf das User Interface erweitert. Ebenso sollten wir Systemkontextobjekt und User Stories kennzeichnen, die Bedeutung für das Usability Engineering besitzen. Im Folgenden entwickeln wir also spezifische Benutzerszenarios. Auch diese können wir in Hauptszenarios, Alternativszenarios und Ausnahmeszenarios unterteilen. Eine kurze Erinnerung: Das Haptszenario zeigt uns den normalen Weg ein Ziel zu erreichen, das Alternativszenario zeigt uns, wie wir auf einem alternativen, nicht so üblichen Wege zum Ziel kommen und das Ausnahmeszenario zeigt uns, wie wir mit Situationen umgehen, in denen wir nicht zum Ziel kommen. Das wird ausführlich im Post Szenarien setzen sich zu Use Cases zusammen. beschrieben. Danach können wir diese Szenarios zu Use Cases zusammensetzen. Jeder Use Case besteht aus genau einem Hauptszenario, ggf. aus mehreren Alternativ- und Ausnahmeszenarien. Diese spezifischen User-Interface-Use-Cases bilden den Ausgang für die Formulierung spezifischer User-Interface-Anforderungen.

Bisher verwenden wir genau dieselben Objekte, die wir auch im Requirements Engineering verwenden. Für diese Objekte sollte es eine Usability-Engineering-Kennzeichnung geben. Mithilfe dieser Kennzeichnung können wir die Sicht auf das Modell auf unseren spezifischen Blickwinkel eingrenzen. Wie beim Zielmodell verfeinern wir die Modelle des Requirements Engineering in Bezug auf Szenarien, Use Cases und Anforderungen.

Beachtet werden sollte, dass es auf dieser Stufe noch nicht um die Struktur des User Interfaces geht, bei der wir uns folgende Fragen stellen können: Stehen die Seiten in einer hierarchischen Struktur oder bilden sie eine Matrixstruktur ab? Wie navigieren wir durch die Seiten? Auch geht es noch nicht um die Anordnung der Elemente auf den Seiten und schon gar nicht um die Oberflächengestaltung. Im Modell von [GARRATT12] erfolgen diese Schritte in den drei folgenden Ebenen: Strukturebene, Rasterebene, Oberflächenebene. Erst dann verfügen wir über einen vollständigen User-Interface-Entwurf, der umgesetzt werden kann. Theoretisch könnten das Zielmodell und die anderen Requirements-Engineering-Modelle schon mit dem Requirements Engineering vollständig beschrieben worden sein. In einem realen Entwicklungsprozess wird das jedoch nicht der Fall sein. Jede Sichtweise, in der wir den Fokus auf ein spezifisches Problem richten, hilft uns unser Modell zu vervollständigen. Ein Modell, in dem wir die Elemente auf diesen Fokus eingrenzen können, hilft uns wiederum den Überblick zu behalten und spezifische Probleme in ihren Feinheiten abzuarbeiten.

Schon des öfteren habe ich erwähnt, dass der von mir beschriebene Entwicklungsprozess iterativ und inkrementell ist. Wir durchlaufen immer wieder einzelne Prozessschritte, springen zurück, streichen Erarbeitetes und ergänzen. Diesen wichtigen Umstand sollte man immer beachten. Wenn wir an einem vollständigen Zielmodell arbeiten, werden wir ewig daran arbeiten. Müssen wir zu lange über neue Modellobjekte nachdenken, sollten wir einen Prozessschritt weitergehen und mit neu erworbenen Wissen im weiteren Prozessschritt wird der alte um so genauer.



Kommen wir zum Schluss zu einer Anforderungsart, die oft sehr stiefmütterlich (bzw. stiefväterlich) behandelt wird. Die Beschreibung von funktionalen Anforderungen, in welcher Art und Weise auch immer, wird meistens durchgeführt. Bei der Beschreibung der Inhaltsanforderungen sieht das schon anders aus. Oft improvisieren die Entwickler aufgrund fehlender Angaben. Inhalte sind Texte, Fehlermeldungen, begleitende Texte, Bilder, Videos aber auch Audio. Welche Ressourcen werden für unser Produkt benötigt? Wie spielen diese zusammen. [GARRATT12] erwähnt ein schönes Beispiel zu FAQs. "Wenn ich inhaltliche Anforderungen mit Stakeholdern diskutiere, höre ich normalerweise gleich am Anfang: 'Wir sollten FAQs haben'. Aber der Begriff FAQ (Frequently Asked Questions) meint in Wirklichkeit nur ein inhaltliches Format: eine einfache Abfolge von Fragen und Antworten. Der wirkliche Wert eines FAQ für die Nutzer besteht im schnellen Zugang zu oft benötigten Informationen; wenn der Fokus aber auf dem Format liegt, wird der Zweck möglicherweise vergessen. In sehr vielen Fällen wird bei FAQs der 'frequently'-Teil vernachlässigt und stattdessen gibt es Antworten auf alle Fragen, die dem Anbieter der Inhalte einfallen – nur damit es eine FAQ gibt." [S.72, GARRATT12] Es ist also zu beschreiben, welche Inhalte verwendet werden sollen, wie sie zusammenhängen, wie sie dargestellt werden sollten und welchen Zweck sie verfolgen. Einzelne Wörter erzeugen Illusionen, jedoch keine umzusetzenden Anforderungen. Wäre die Imaginationskraft der Entwickler schlecht ausgebildet, würden viele Dinge nicht programmiert werden.

Damit haben wir eine weitere Kennzeichnung für Anforderungen gefunden, die Inhaltsanforderung. Mit dem vervollständigten Anforderungsmodell und mit der Sicht auf die Objekte, die für ein User Interface wichtig sind, verfügen wir über die notwendige Voraussetzung um die Struktur unserer Oberfläche zu entwerfen.

  • [GARRETT12] : Jesse James Garrett: "Die Elemente der User Experience", Addison-Wesley Verlag, 2012


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen