Freitag, 10. Oktober 2014

Die Erweiterung des Requirements Engineering durch das Usability Engineering.

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.


In der Artikelreihe Ein System zur Anforderungsentwicklung habe ich Ihnen vorgestellt, wie ich strukturiert Anforderungen entwerfe. Wir haben gesehen, wie Ziele, User Stories, Use Cases und verschiedenen Arten von Anforderungen zusammenhängen. Damit wurde sich um die grundlegenden Wünsche des Kunden gekümmert. Nun müssen wir eine Software entwickeln, mit der die Anwender zufrieden sind. Sie muss gut zu pflegen, leicht zu erweitern und gut zu bedienen sein. Neben einer durchdachten Architektur benötigen wir ein strukturiertes Usability Engineering. Zu beiden Teilgebieten benötigen wir einen guten Übergang vom Requirements Engineering.

Es gibt Firmen, in denen das Requirements Engineering sehr stiefmütterlich behandelt wird. Dem Usability Engineering geht das nicht anders. Oft entwickeln Programmierer das User Interface aus dem Bauchgefühl heraus. Ein durchdachtes und strukturiertes Usability Engineering wird, wie auch ein wirkliches Requirements Engineering als zu teuer und zeitraubend angesehen. Die Rechnung wird jedoch ohne den Wirt gemacht. Unzufriedene Kunden und verbuggte Software sind die Folge. Billiges Produzieren ergibt auch billige Produkte. Wie prüft ein Kunde, dass die Firma, welche das Produkt zum halben Preis bietet, wirklich Qualität liefert? Dazu müsste er Anhaltspunkte und Informationen besitzen, die es zu diesem Zeitpunkt nicht gibt. Die "besseren Firmen" sind jene, die Wege gefunden haben, dem Kunden nachträglich Kosten aufzudrücken, um die Qualität zu erhalten.

Ich persönlich würde ein transparentes Verhältnis zum Kunden bevorzugen, einen Weg, der sich auf den Bahnen der Realität bewegt, und nicht im Wunschdenken steckenbleibt. Bestimmte Informationen sind nur zu bestimmten Zeitpunkten zu bekommen und bestimmte Produkte, die qualitativ hochwertig und sinnvoll zu benutzen sind, haben Ihren Preis. Der Weg kann nur eine enge Zusammenarbeit zwischen Auftraggeber und Auftragnehmer sein, in der beide Seiten den Prozess controllen. Mit Controlling meine ich in diesem Zusammenhang nicht zwanghaft Kontrollieren, sondern bewusstes gemeinsames Steuern. Wenn dazu keine Zeit vorhanden ist, hilft wohl nur Vertrauen.

Das Anliegen dieser kleinen Reihe ist die mögliche Formulierung eines Übergangs vom Requirements Engineering hin zu einem Usability Engineering. Natürlich gibt es für alles einen internationalen Standard, so auch für die Mensch-Computer-Interaktion. Da finden wir sogar mehrere, die DIN EN ISO 9241-11, welches die Gebrauchstauglichkeit definiert und die DIN EN ISO 9241-110, welche die Grundsätze der Dialoggestaltung erörtert. Auf vielen, vielen Seiten werden Definitionen, Grundsätze und Empfehlungen gegeben. Im Folgenden möchte ich mich jedoch darauf konzentrieren, was in kleinen und mittleren Firmen machbar ist und das ist weit mehr, als oft gemacht wird. Alleine schon die Betrachtung der folgenden drei Punkte, die [GRECH10] aus der Definition herauszieht, bringt uns ein ganzes Stück weiter:"
  • Effektivität: Die Genauigkeit und Vollständigkeit, mit der Benutzer ein bestimmtes Ziel erreichen.
  • Effizienz: Der im Verhältnis zur Genauigkeit und Vollständigkeit eingesetzte Aufwand, mit dem Benutzer ein bestimmtes Ziel erreichen.
  • Zufriedenheit: Freiheit von Beeinträchtigungen und positive Einstellung gegenüber der Nutzung des Produkts.
" [S.522, GRECH10]

Daraus kann man eine Reihe von Grundanforderungen an eine gut benutzbare Software ableiten. Kann der Benutzer sie intuitiv anwenden oder ist die Anwendung leicht zu erlernen? Kann man mit der Anwendung flüssig seine Arbeit erledigen, oder leitet sie uns auf Um- und Irrwege? Haben wir uns das Grundsystem der Anwendung schnell eingeprägt, sind die Arbeitsschritte eingespielt und sicher? Ergeben sich aus Fehlern unüberbrückbare Hindernisse oder ist ein Fehlerleitsystem vorhanden, welches uns schnell aus der Patsche hilft? Ist die Anwendung leicht steuerbar und können wir sie an unsere individuellen Bedürfnisse anpassen? Lehnen sich unsere Anwender am Abend zufrieden zurück und genießen, mit einem wirklich guten Produkt zu arbeiten? Denken Programmierer oft über diese Fragen nach oder versuchen sie in erster Linie eine gestellte Anforderung umzusetzen? Schon das gemeinsame Reflektieren im Team bringt uns ein ganzes Stück weiter. Wenn zudem ein Teammitglied sich in die Richtung Usability Engineering bewegt, besitzen wir auch eine kompetente Beratung, die wir uns natürlich auch an bestimmten Punkten von Außen holen können.

[GRECH10] entwirft in Anlehnung an die DIN EN ISO 13407 einen User-Centered-Designprozess. Seit dem Januar 2011 ist als Ersatz für diese Norm allerdings die EN ISO 9241-210 gültig. Der User-Centered-Designprozess besteht aus vier Teilprozessen. Im ersten Schritt geht es darum, Anforderungen in Bezug auf die Usability aufzunehmen. Das geschieht, wie im Requirements Engineering, in einem kunden- und benutzerorientierten Ermittlungsprozess. Ausgehend von den aufgenommen Anforderungen, werden die Anforderungen der Usability definiert. Im zweiten Schritt wird ein Design entworfen, um dann im dritten Schritt einem Prototyping zugeführt zu werden. Im vierten Schritt kann dann mithilfe eines Prototyps eine Evaluierung beim Anwender durchgeführt werden. Auch dieser Prozess ist als iterativer Prozess zu verstehen, in dem mehrere Durchläufe vonstatten gehen müssen, damit am Ende ein gutes Ergebnis erreicht wird.



Jesse James Garret hat in seinem Buch "Die Elemente der User Experience" zudem fünf Ebenen für ein anwenderzentriertes Design gefunden. [GARRETT12] Er konzentriert sich dabei hauptsächlich auf Webanwendungen. Die Erkenntnisse sind jedoch genauso in der Entwicklung anderer User Interfaces benutzbar. Die oberste der fünf Ebenen ist die Strategieebene. Diese ist am besten mit unserem Zielmodell aus dem Requirements Engineering vergleichbar. Wir werden unser Zielmodell in Bezug auf das User Interface erweitern. Die darunter liegende Ebene ist die Umfangsebene. Hier wird, immer in Bezug auf die definierten Ziele, die Anforderungsdefinition in Bezug auf das User Interface erweitert. Eine Ebene weiter folgt die Strukturebene. Hier legen wir die abstrakte Struktur unseres User Interfaces fest. Zudem beschreiben wir konzeptuelle Modelle und wie wir mit Fehlern umgehen. Die Strukturebene beschreibt die grundsätzliche Organisationsstruktur des User Interfaces. Eine Ebene tiefer, auf der Rasterebene, geht es schon sehr viel konkreter zu. Hier geht es um die konkrete Anordnung der Bedienelemente in einem festzulegenden Raster. Neben diesem Interfacedesign wird das Navigationsdesign entwickelt, also wie und wo gelangen wir von einem Ort zum Anderen, und das Informationsdesign, wie und welche Information stellen wir dar. Die unterste Ebene ist die Oberflächenebene. Hier geht es um die zu benutzenden Farben, Schriften und Töne. Unsere Anwendung benötigt ein ästhetisches, einheitliches und benutzbares Erscheinen.

Im erwähnten Schritt Anforderungen des User-Centered-Designprozess werden diese fünf Ebenen durchlaufen. Auf den beiden oberen Ebenen, der Strategieebene und der Umfangsebene, sind sie eng mit den Objekten des Requirements Engineering zu verknüpfen. Ab der Strukturebene spiegeln sie eher das zu entwerfende Design. Für den Entwurf können wir zur visuellen Beschreibung Wireframe-Modelle verwenden. Dazu gibt es eine Menge an verfügbaren Tools. Im folgenden möchte ich eine Verbindung der beiden Modelle zeigen.



Diese Erweiterung des Requirements Engineering durch das Usability Engineering bleibt dem Objekt-Aufgaben-Modell des Requirements Engineering treu. In den nächsten Artikeln werden wir Objekttypen entwickeln, die in diesem Prozess entstehen. Damit durchdenken wir die Gestaltung eines Interfaces, aus dem wir dann Schlüsse für andere Interfaces und andere Erweiterungen unseres Modells in Richtung Softwarearchitektur ziehen können.

  • [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


folgender Post dieses Themas


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

1 Kommentar:

  1. Usability ist ein schönes Thema. Dazu fallen mir viele Gedanken ein. Ich hoffe es ist nicht zu durcheinander.

    Ich finde Ihre Ausführungen absolut richtig, aber etwas Prozess-lastig. Ich glaube ein solcher Prozess überfordert schon die meisten Softwarefirmen. Ich fände es wichtiger einen passionierten UI-Entwickler in der Firma zu haben, der andere Entwickler von Grundsätzen überzeugen und einfache Mittel an die Hand geben kann, um gute Oberflächen selbst zu entwickeln. Sie haben auch Ästhetik und UX erwähnt. Ich finde dieser Anspruch geht schon zu weit.

    Ich möchte Ihnen CD-Burner XP als Beispiel nennnen, was ein hervorragend benutzbares Tool ist. Es ist nicht im klassischen Sinn ästhetisch, aber mit einer sehr guten Informationsarchitektur umgesetzt (siehe haben es Informationsdesign benannt), obwohl es durchaus nicht-triviale Funktionen beinhaltet, konnte ich mit meinem IT-Grundwissen über das Brennen dieses Programm sofort richtig und effektiv einsetzen.

    Ich möchte Ihnen Beispiele für grundsätzliche Entscheidungen nennen, welche man ohne Hang zu Ästhetik richtig fällen kann:
    Beispielsweise ob eine Formularbasierte, eine objektorientierte GUI oder eine werkzeugbasierte GUI verwendet werden soll. Rein formularbasierte Systeme wirken etwas unmodern, können aber manchmal eine hervorragende Usability haben. Ich möchte noch einmal betonen, dass man bei Usability zu leicht die visuelle und ästhetische Seite fokusiert (auch wenn Sie es in ihrem Beitrag nur als eins von vielen genannt haben).

    Einen Fehler den ich in der Vergangenheit selbst gemacht habe, war zwingend immer sehr individuelle UIs zu konzipieren, um die tatsächlich gut gewählte Informationsarchitektur abzubilden. Dazu habe ich ähnliche Schritte durchlaufen, wie Sie beschrieben haben. Dies verursachte aber enormen Aufwand und ich denke, da sollte man sich schon fragen, ob dadurch wirklich ein relevanter Geschäftswert entsteht.

    Insoweit wäre mein Tipp an jeden, der sich mit Usability bisher schwer tut: eine übliche passende UI zu nehmen (nennen wir es nicht "klauen", das wäre unschön) und diese mit Leben zu füllen. Ja, obwohl ich ein großer Fan von Wireframes bin, meine ich, dass man sich diesen Wireframing-Schritt sparen sollte, zumindest in Bezug auf Usability-Effekte. Ich denke 80% aller Softwareanwendungen benötigen keine innovative UI, daher würde ich dafür plädieren die Informationsarchitektur/das Informationsdesign direkt in der UI (z.B: WPF, HTML5, JavaSwing) durchzuführen.

    Überdies finde ich, dass man als Ziel meist nicht sehr gute Usability, sondern die Vermeidung von schlechter Usability haben sollte. Wenn man das KANO-Modell im Hinterkopf hat, ist Usability immer ein Hygienefaktor. Kaum jemand wird sie wegen guter Usability loben, nur bei katastrophaler Usability werden Kunden unzufrieden sein. Natürlich sind die Erwartungen an eine Website meist höher.

    Das bringt mich zu dem Punkt: wenn ein Projekt wie im Web von Nutzern mit geringer Motivation abhängt, dann ist Usability geschäftskritisch (dann braucht man vielleicht wirklich ein Usability-Agentur oder Umsetzungen à la BJ Fogg). Dort ist dann auch Usability und UX sehr nahe beeinander.

    Aber ich denke, Sie zielten eher auf Geschäftsanwendungen ab. Mit dem beschriebenen Vorgehen (UI klauen+Informationsdesign gut überlegen)
    ist dafür kaum Mehraufwand im Projekt nötig, bis eben auf die Awareness und Beschäftigung mit dem Thema.

    AntwortenLöschen