Freitag, 21. November 2014

Mit Zielen zum User Interface.

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 haben wir einen User-Centered-Designprozess beschrieben, der durch das Ebenenmodell von Jesse James Garrett vertieft wurde. Dieser Prozess setzt auf dem Requirements Engineering auf. Aus der Sicht des Requirements Engineers beschreibt unser Anforderungsmodell das zu lösende Problem. Eine Lösung ist aus seiner Sicht ein Schnittstellenmodell für das User Interface. Aus der Sicht des Usability Engineers ist dieses Schnittstellenmodell jedoch wieder eine Problembeschreibung, die den Oberflächendesigner zu einer Lösung motiviert. Auf diese Art und Weise "alterniert der Entwicklungsprozess zwischen Problemdefinition und Lösungsbeschreibung". [S.20, POHL08] Es ist die Perspektive des jeweiligen Fachgebietes, die etwas zum Problem oder zu seiner Lösung macht.

Mit dem Requirements Engineering besitzen wir einen Prozess, der die umzusetzende Funktionalität definiert. Der Entwurf eines User Interfaces und die Definition von Workflows sind bereits Lösungsbeschreibungen aus der Sicht des Requirements Engineering. Oft wird der Fehler gemacht, ein Requirements Engineering durchzuführen, welches gedanklich von der Bedienoberfläche ausgeht. Dazu werden Anforderungen formuliert, wie "der Button soll die Tabelle speichern". Dabei werden Problembeschreibung und Lösungsansatz auf einer Stufe miteinander vermischt. Das Auseinanderhalten verschiedener Entwurfsstufen ist dabei nicht trivial und oft nur durch gemeinsame Arbeit und lange Erfahrung erlernbar. Im folgenden Text gehen wir davon aus, dass das Erarbeiten einer Benutzeroberfläche eine technische Umsetzung ist. Viele Benutzer können funktionale Anforderungen nur mithilfe der Oberflächenvorstellung formulieren. Dagegen spricht erst einmal nichts. Es ist die Aufgabe des Requirements Engineers die eigentliche Anforderung zu entdecken und das WAS vom WIE zu trennen. Das Nachdenken über die Möglichkeiten des User Interfaces sollte nicht unzulässig eingeschränkt werden. Sollte es wirklich ein Button sein? Ist der Gesamtablauf dieser Anforderung in einen optimierten Web Flow eingebaut? Trennen Sie das WAS und das WIE auf verschiedenen Entwurfsstufen? In diesem Fall ergründen wir mit Hilfe der Anforderungen aus dem Requirements Engineering die Anforderungen an die Oberfläche. Dabei treffen wir bereits eine Reihe von technischen Entscheidungen. Da Entwicklung in einem iterativen Prozess erfolgt, muss der Kunde von diesem Vorgang gar nichts bemerken.



Der Beginn unseres Usability Engineerings ist ein Teil der im Requirements-Engineering-Modell formulierten Anforderungen des Kunden, die funktionalen Anforderungen und die Qualitätsanforderungen, die mit der Schnittstelle zwischen Mensch und Programm zusammenhängen. In den Prozess der Beschreibung von User-Interface-Anforderungen muss nach Möglichkeit natürlich auch wieder der Kunde miteinbezogen werden. Für das Usability Engineering bauen wir ein eigenes Ziel-UseCase-Anforderungs-Modell auf. Natürlich gibt es zwischen diesen Modellen Wechselwirkungen. Beim Bearbeiten des User-Interface-Modells können uns wesentliche Dinge in Bezug auf das Requirements-Engineering-Modell einfallen. Beide Modelle sind in unserem inkrementellen und iterativen Prozess beheimatet.



Im ersten Schritt durchforsten wir die Objekte des Requirements-Engineering-Modells, ob sie Informationen für den Aufbau unseres Usability-Engineering-Modells liefern. Diese werden im Team, unter Teilnahme von Kundenvertretern, diskutiert und als Artefakte des Usability-Engineering-Modells formuliert. Dem User-Centered-Designprozess hatten wir im letzten Post zwei Denkebenen von [GARRETT12] zugeordnet, die Strategieebene und die Umfangsebene. Beide Ebenen korrespondieren hervorragend mit den schon entwickelten Objekten unseres Requirements-Engneering-Prozesses.

In der Strategieebene sucht [GARRETT12] Ziele. Er unterteilt die Ziele in Produktziele und in Geschäftsziele. Im Post die Analyse des Problemraums führt zum Zielmodell wurde ein Und-Oder-Baum zur Beschreibung der Ziele beschrieben. Auf einer hohen Hierarchiestufe sollten wir schon in diesem Modell die Unterteilung in Produkt- und Geschäftsziele nachtragen. Theoretisch sollten diese Ziele schon lange in unserem Modell vorhanden sein. Doch niemand wird uns davor schützen, auch in Zukunft neue Erkenntnisse zu gewinnen und schon vorhandene Gedanken erweitern zu müssen. Dieses so verbesserte Zielmodell des Requirements Engineering durchforsten wir dann nach Zielen, die sich auf das User-Interface beziehen. Die Sicht auf diese ausgewählten Ziele erweitern wir mit technischen Umsetzungszielen in Bezug auf diese Schnittstelle.

Mithilfe der Stakeholder, die wir bereits in der Systemkontextanalyse gefunden haben, definieren wir spezifische Nutzergruppen und erweitern so unsere Kontextobjekte. Auch das Auffinden von Personas und extremen Charakteren ist von Bedeutung. Mithilfe von Vertretern der gefundenen Nutzergruppen bzw. mit den gebildeten künstlichen Charakteren machen wir uns auf die Suche nach Zielen für das User Interface. Es gibt einige Punkte, die wir immer wieder zu beachten haben. Produkte unserer Firma sollten als solche erkennbar sein. Die Nutzerbedürfnisse und ihre Arbeitsabläufe müssen Ausgangspunkt der Zieldefinition sein. Wichtiges Wissen dazu wurde bereits in der Systemkontextanalyse gewonnen. Dort werden Prozesse als Kontextobjekte hinterlegt. Sie spielen bei der Definition optimaler Arbeitsabläufe eine große Rolle. Die Definition des User-Interfaces kann also zu einer vertiefenden Untersuchung unseres Systemkontextes führen.



Das Zielmodell des Usability Engineering ist also eine Verfeinerung eines Teils des Zielmodells des Requirements Engineering durch technische Ziele. Anstatt mehrere Und-Oder-Bäume für das Zielmodell aufzubauen, ist es sinnvoller weitere Ordnungskriterien und Sichten in das vorhandene Zielmodell einzuführen. Bisher konnten wir Ziele verfeinern, indem wir Oder-Zerlegungen und Und-Zerlegungen durchgeführt haben. Das wurde ausführlich im Artikel Die Analyse des Problemraums führt zum Zielmodell beschrieben. Durch die Verfeinerung entstand ein hierarchisches Modell. Durch Sichten können wir Teile des Gesamtmodells ausblenden. Es sind nur noch die Pfade im Modell sichtbar, die für ein spezifisches Problem wichtig sind, in unserem Fall das Usability Engineering. Technische Umsetzungsziele sollten als solche gekennzeichnet werden. Dadurch wird klar, dass wir bereits im Stadium der technischen Lösungssuche sind.

Eine weitere Gedankenhilfe, die wir durch die Unterteilung in Produkt- und Geschäftsziele gefunden haben, ist die Verfeinerung durch Zielkategorien. Diese Kategorisierung ist auf verschiedenen Hierarchiestufen möglich und hilft, sich auf verschiedene Schwerpunkte zu konzentrieren. Mögliche Kategorien können in Checklisten hinterlegt werden. Zielkategorisierungen sind Generalisierungen bestimmter Zielarten.



Nun können wir von einer Denkebenen auf die nächste Denkebene wechseln, von der Strategieebene auf die Umfangsebene. Die Umfangsebene von [GARRETT12] definiert die spezifischen Anforderungen für das User Interface, die aus den gewonnenen Ziele resultieren. Damit beschäftigen wir uns im nächsten Post dieser Reihe.
  • [GARRETT12] : Jesse James Garrett: "Die Elemente der User Experience", Addison-Wesley Verlag, 2012
  • [GRECH10] : Thomas Grechening, Mario Bernhart, Roland Breiteneder, Karin Kappel: "Softwaretechnik", Pearson Studium, 2010


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