Requirements-Engineering und Usability-Engineering methodisch kombinieren
Wie lassen sich Usability-Aspekte in die Anforderungsermittlung integrieren?
Heutzutage stoßen Benutzer beim Bedienen von Softwaresystemen immer wieder an ihre Grenzen. Dies hat häufig gar nichts mit den Fähigkeiten der Benutzer zu tun, sondern vielmehr mit einer schlecht bedienbaren Benutzungsschnittstelle, wie das mentale Modell von Donald Norman [1] zeigt. Das mentale Modell (vgl. Abb.1) beschreibt die Repräsentation, wie sich ein Benutzer ein System vorstellt und wie es tatsächlich arbeitet. Es besteht aus drei Teilen: dem User-Modell (Vorstellung eines Benutzers, wie das System funktioniert), dem Implementierungs-Modell (Programmier-Sicht) und dem Repräsentations-Modell (Benutzerschnittstelle) [2].
Stimmt das Implementierungs-Modell nicht mit den Vorstellungen des Benutzers über die Funktionsweise des Systems überein, so ist ein System schlecht benutzbar. Ähneln sich jedoch User-Modell und Repräsentations-Modell, so wird das System intuitiv bedienbar. Überwiegend liegt die mangelhafte Umsetzung daran, dass die Ziele, Bedürfnisse und Verhaltensweisen der Benutzer nicht analysiert werden und diese wichtigen Ergebnisse im weiteren Entwicklungsprozess fehlen. Zudem werden die Disziplinen Requirements-Engineering (RE) und Usability-Engineering (UE) getrennt voneinander betrachtet und durchgeführt, sodass es bisher kein Vorgehen gibt, welches die Usability-Aspekte frühzeitig in die Anforderungsermittlung integriert.
![Abb.1: Das mentale Modell [2]. © Stefan Rölle](/fileadmin/templates/wr/pics/Artikel/02_Entwicklung/Methoden/RE_abb1_Roelle.jpg "Abb.1: Das mentale Modell [2]. © Stefan Rölle")
Wie kann das Requirements-Engineering dieser Problematik entgegenwirken?
Wir SOPHISTen haben eine erste Version eines Vorgehensmodels entwickelt, welches UE-Methoden systematisch in das RE integriert. Dabei sollen sich die Methoden der beiden Disziplinen bestmöglich ergänzen, sodass eine qualitativ hochwertige Anforderungsspezifikation entsteht, die als Basis für den weiteren Entwicklungsprozess zur Verfügung steht. Im ersten Teil unserer Forschungsarbeit haben wir die Ermittlungs- und Dokumentationstechniken beider Disziplinen genauer betrachtet und auf Schnittstellen und Unterschiede hin untersucht. Da sich die genannten Teilbereiche in der Analyse-Phase des allgemeinen Entwicklungsprozesses befinden, war dieses Vorgehen möglich. Bei der Untersuchung stellte sich heraus, dass die Ermittlungstechniken der beiden Disziplinen recht ähnlich sind. Somit kann das RE auf Ergebnisse des UEs aufbauen und umgekehrt.
Problematisch dagegen schien, dass der Fokus der Ermittlung und Dokumentation jeweils ein ganz anderer ist. Das Requirements-Engineering stellt in der Systemanalyse das System mit seinen Funktionalitäten in den Mittelpunkt und arbeitet eher top-down. Im Usability-Engineering wird dagegen der Fokus auf die Benutzer gelegt und bottom-up vorgegangen. Doch genau diese unterschiedliche Fokussierung eröffnet ein enormes Potential für die kombinierte Variante. So entstehen durch die verschiedenen Schwerpunkte neue Betrachtungswinkel, die als Basis für weitere Anforderungen dienen.
Methodische Schnittstellen
Abb.2 zeigt die drei Schnittpunkte, an denen wir die beiden Disziplinen bisher methodisch kombiniert haben. In diesem Artikel geben wir einen Überblick über alle drei Schnittpunkte.
Restaurantbeispiel
Um das Ganze nicht so abstrakt zu halten, erklären wir unser Vorgehen an folgendem Beispiel: Für eine Restaurantkette soll ein System entwickelt werden, welches die Tätigkeiten des Kellners größtenteils ersetzt (z. B. Bestellung entgegennehmen, Weinempfehlung aussprechen), indem der Gast beim Betreten des Restaurants ein Bedienteil in die Hand bekommt. Mit dem Bedienteil tätigt der Gast z. B. seine Bestellungen, informiert sich über die Herkunft der Lebensmittel und bezahlt die Rechnung. Neben den Tätigkeiten des Kellners soll das System auch administrative Tätigkeiten der weiteren Angestellten systemisch unterstützen (z. B. Lebensmittel bestellen, Urlaub planen).
Anforderungen ermitteln
Die erste Schnittstelle "Anforderungsquellen ermitteln" zeigt auf, wie sich die klassische Stakeholder-Analyse des Requirements-Engineering [3,4], mit dem Persona-Konzept von Alan Cooper bestmöglich ergänzen lässt und wann Personas als neue Anforderungsquellen verwendet werden können. Im klassischen RE werden alle Stakeholder (Projektbeteiligte) mit Hilfe der Stakeholder-Checkliste ermittelt und befragt, da eine unvollständige Stakeholder-Analyse zu einer lückenhaften Anforderungsspezifikation führen kann [3,4]. Die Stakeholder im Restaurantbeispiel sind zum einen die Mitarbeiter des Restaurants (z. B. Geschäftsführer, Koch, Thekenmitarbeiter) sowie alle Gäste, aber auch Wartungskräfte und Entwickler. Bei der Befragung der Stakeholder im klassischen RE wird der Fokus meist weniger auf die Bedürfnisse und Verhaltensweisen der Benutzer, als auf Systemanforderungen gelegt.
Anders dagegen das Vorgehen im Usability-Engineering. Im UE werden zu Beginn der Systementwicklung Markt- und Designforschung betrieben. Denn bevor ein Produkt den Kundenwünschen nach entwickelt werden kann, müssen erst verschiedene Daten der potenziellen und tatsächlichen Benutzer des Produkts vorliegen. So steht in der sogenannten Research-Phase (Forschungsphase) die Suche nach Bedürfnissen, Ansichten und Zielen der Benutzer im Mittelpunkt [5]. Auf das Restaurantsystem bezogen, werden die Benutzer des Systems (Mitarbeiter und Gäste) nach ihren Aktivitäten, Zielen, technischen Einstellungen, kognitiven Fähigkeiten, ihrem Umgang mit IT-Systemen aber auch ihren Ängsten befragt. Besonders wichtig ist, das mentale Modell der Benutzer zu erforschen. Denn liegt die technische Umsetzung des Restaurantsystems später nahe bei den Vorstellungen der Benutzer, können diese das System intuitiv bedienen (vgl. Abb.1).
Wichtig bei der Beobachtung und Befragung von Benutzern ist es, dass sie in ihrer Umgebung, dem sogenannten Nutzungskontext, betrachtet werden. So wird der Koch bei seinen täglichen Arbeitsschritten in der Küche beobachtet und gegebenenfalls dazu befragt. Die Ergebnisse der Research-Phase werden mit Hilfe von Personas, einem Modell von Alan Cooper [2], zusammengefasst und visualisiert. Personas sind keine realen Personen, sondern User-Archetypen, die die verschiedenen Ziele und beobachteten Verhaltensmuster der potentiellen Benutzer beschreiben. Mit Hilfe von Personas kann im Projektteam über verschiedene Benutzertypen und ihre Bedürfnisse kommuniziert werden, um dann zu entscheiden, welcher für das Design von Form und Verhalten des Systems am wichtigsten ist. Im Restaurantbeispiel wurden mit Hilfe der Personas verschiedene Typen von Gästen identifiziert, zum Beispiel Stammgast, Laufkunde oder Single. So besucht die Persona Stammgast regelmäßig das Restaurant, reserviert meist für zwei Personen und genießt am liebsten die regionale Küche.
Hier wurden Personas erstellt, da die Rolle Gast von zu vielen realen Personen repräsentiert wird, die nicht alle befragt werden können. Sind Stakeholder sehr schwer erreichbar, oder existieren im Moment noch keine realen Stakeholder für ein Interview (zukünftiger Markt), so werden auch in diesen Fällen Personas erstellt. In allen anderen Fällen werden keine Personas erstellt, sondern alle realen Stakeholder – wie im klassischen RE – befragt. Kombinieren wir nun die gezeigten Vorgehensweisen der Disziplinen RE und UE (vgl. Abb.3), so gelangen wir zu einer vollständigen und fundierten Benutzeranalyse. Als Ergebnisartefakte entstehen nach diesem Schritt eine Stakeholder-Liste und entsprechende Persona-Dokumente, auf denen in den nächsten Schritten aufgebaut wird.
Abgrenzung durchführen
Um nun eine optimale Kontextabgrenzung durchführen zu können, kombinieren wir die Ergebnisse aus Stakeholder-Interviews und Persona-Beschreibungen. Vor allem die Ziele, das reale Arbeitsumfeld des Benutzers und die Festlegung seiner Relevanz für das System sind dabei von zentraler Bedeutung.
Bevor die Entwicklung eines Systems beginnen kann, werden auf höchster Ebene die sogenannten Projektziele definiert. Diese werden im RE und im UE gleichermaßen erforscht, da in beiden Disziplinen die gleichen realen Personen befragt werden. Projektziele des Geschäftsführers im Restaurantbeispiel könnten "Die Anzahl der Gäste, die mindestens zwei Getränke und ein Essen pro Besuch bestellt, soll verdoppelt werden" oder "Das Projekt soll bis zum 31.12.2013 mit der Installation des Systems in drei Restaurants erfolgreich abgeschlossen werden" lauten. Im RE werden nach den Projektzielen die Produktziele festgelegt, welche anschließend den Systemkontext [4] definieren. Produktziele sind Ziele des Produkts, die aber nicht durch eine breite Forschung der Benutzer entstanden sind, sondern durch eine Ziel-Befragung der Stakeholder [3]. Nachdem erst die Projektziele festgelegt wurden, wird nun davon auch auf die Produktziele geschlossen, natürlich dann mit dem Input der entsprechenden Anforderungsquellen, z. B. Manager. Anschließend wird ein Zielabgleich durch ein zentrales Zieldokument, in dem sich alle Ziele befinden, durchgeführt. Diese Dokumentation erhöht die Chance auf Vollständigkeit und Eindeutigkeit der Ziele. Im RE werden alle Ziele aus der Sicht des Unternehmens für das System formuliert und entsprechen mehreren Qualitätskriterien [3]. Die Zielfindung im RE geschieht somit eher top-down.
Im UE hingegen nehmen die Benutzerziele einen zentralen Platz ein, da diese Disziplin auf dem zielgerichteten Ansatz [2] aufbaut. So werden dort bei der Modellierung von Personas jeweils deren verschiedene Ziele in der Persona-Beschreibung dokumentiert. Personas bieten ein sehr gutes Verfahren um Ziele zu finden und zu dokumentieren, da es verschiedene Zielkategorien gibt (z. B. Basisziele, Lebensziele [5]) und stellen somit eine gute Basis für die Zielfindung im RE dar. Die Ziele der Personas können sich untereinander widersprechen, da verschiedene Personas auch unterschiedliche Ziele besitzen. Die Verteilung der Ziele auf verschiedene Personas hat Vor- und Nachteile. Ein Vorteil besteht darin, dass Ziele immer einer Persona zugeordnet werden können. Dies ist wichtig, da die Motive das Verhalten beeinflussen und Motive in Zielen festgehalten werden. Nachteilig ist, dass die Ziele schlecht miteinander verglichen werden können. Dadurch gibt es im UE keinen klassischen Konsolidierungsansatz. Das UE verwendet die Methodik der Priorisierung von Personas, bei der sich immer die Primär-Persona [2] mit ihren Zielen durchsetzt. Im UE wird also nicht konsolidiert, sondern priorisiert. Ziele geben im UE eine Richtung vor, die für die Visionsbeschreibung des Produkts wichtig ist. Die Ziele im UE werden eher bottom-up festgelegt.
Im kombinierten Vorgehen werden für alle Stakeholder und Personas Ziele, wie oben beschrieben, definiert. Anschließend werden die Ziele der Stakeholder gegenseitig konsolidiert, die der Personas priorisiert. Diese Ziele werden dann gegenseitig und mit den Projektzielen konsolidiert. Als Ergebnisartefakt entsteht ein konsolidiertes Zieldokument.
Parallel zur Zielfindung findet eine Kontextabgrenzung statt. Dazu werden die Benutzerinteraktionen mit dem System, auf Basis von Stakeholder-Interviewprotokollen und der Persona-Beschreibungen, ermittelt. Diese Ergebnisse werden dann in einem Use-Case-Diagramm dargestellt. Das Use-Case-Diagramm wird hier gewählt, da es die Informationen besonders gut auf Vollständigkeit prüfen kann. Außerdem ist es eine gute Grundlage für die nachfolgenden Schritte, wie sich später zeigen wird. Im Use-Case-Diagramm werden die Personas und die Stakeholder, die das System benutzen, als Akteure abgebildet. In der kombinierten Variante gibt es pro Use-Case genau einen primären Akteur. Dieser ist entweder eine Primär-Persona [2] oder ein Stakeholder. Da im Beispiel die Persona Stammgast unter den Gästen am häufigsten das Restaurant besucht und entsprechende Use-Cases ausführt, wird sie zum primären Akteur. Die Use-Cases werden hier nach fachlichen Zusammenhängen gruppiert (z. B. Bestellvorgang). Die daraus entstehenden fachlichen Schnittstellen werden als Rahmen um die Use-Cases dargestellt. Das entstandene Use-Case-Diagramm bezeichnen wir als Kontextdiagramm, da es Systemkontext [4] und Nutzungskontext [6] vereint. Nicht nur die Benutzerschnittstellen, sondern auch Informationen über den Nutzungskontext der Personas (Attribut "Umgebung" in Persona-Beschreibung) und ähnliche Informationen aus den Stakeholder-Interviews werden nach relevanten Informationen für das Kontextdiagramm durchsucht. Diese sonstigen Informationen, wie Nachbarsysteme (Banksystem, Einkaufsystem) werden ebenfalls im Kontextdiagramm abgebildet. Bei der Ergänzung des Kontextdiagramms durch Nachbarsysteme entstehen neue Use-Cases. Im Beispiel wird der Use-Case "Rechnung bezahlen" aufgeteilt in "Rechnung bar bezahlen" und "Rechnung mit Karte bezahlen". Das gleiche geschieht mit dem Use-Case "Trinkgeld geben". Außerdem können nun neue Stakeholder abgeleitet werden. Im Beispiel wird ein Stakeholder gebraucht, der etwas über die Schnittstelle zum Banksystem erzählen kann. Durch die Priorisierung auf Use-Case-Ebene und die grafische Darstellung können Zuständigkeitskonflikte zwischen Personas und Stakeholdern frühzeitig erkannt und gelöst werden. Außerdem hat jede Persona und jeder Stakeholder einen eigenen Blick auf das System. Werden die Sichten der Primär-Personas und der notwendigen Stakeholder kombiniert, entsteht eine gute Gesamtsicht auf das System.
Durch die gemeinsame Betrachtung von Systemkontext und Nutzungskontext ist eine klarere Abgrenzung des Systems zu seiner Umwelt möglich. Außerdem lassen sich die Ziele der Stakeholder mit den Zielen der Personas kombinieren, wodurch der Prozess der Zielfindung und -konsolidierung gestärkt wird.
Anforderungen erheben
Im letzten Schritt "Anforderungen erheben" zeigen wir auf, welche Faktoren der Benutzeranalyse als Basis für funktionale und nichtfunktionale Anforderungen dienen und wie diese richtig extrahiert werden.
Das Use-Case-Diagramm aus der Kontextabgrenzung wird nun weiter verfeinert. So wird jetzt jeder Use-Case mit Hilfe der Use-Case-Schablone genauer beschrieben. Die Use-Case-Beschreibung enthält standardmäßig folgende Attribute: Name, Kurzbeschreibung, Akteure, Vorbedingungen, fachlicher Auslöser, Normalfall und Ergebnis [3].
Das UE verwendet Kontextszenarien, um die Benutzeraktivitäten mit dem System darzustellen. Kontextszenarien sind knappe erzählerische Beschreibungen im Fließtext, welche die ideale Interaktion mit dem System aus Sicht der Persona beschreibt [3]. Use-Cases und Kontextszenarien sind beides Methoden, die die Interaktion von Benutzern mit einem System beschreiben und sich nur in der Dokumentationsform unterscheiden. Dadurch werden in der kombinierten Variante beide Methoden eingesetzt, um aus Benutzeraktivitäten funktionale Anforderungen abzuleiten. Der Ablauf (= Normalfall) einer Use-Case-Beschreibung kann nun entweder modelliert oder mit einem Kontextszenario beschrieben werden. Kontextszenarien sind in einigen Fällen sehr nützlich, um mit dem Nutzer noch einmal seine Aktivitäten und Bedürfnisse durchzusprechen, da sie den Ablauf leicht verständlich und sehr konkret darstellen. In dem Fall, dass ein Kontextszenario erstellt wurde, werden daraus anschließend Bedürfnisse abgeleitet. Bedürfnisse können auch mit dem Begriff Kundenwünsche gut übersetzt werden, da es sich dabei um noch nicht geprüfte Anforderungen handelt. Bedürfnisse sind somit eine Vorstufe zu Anforderungen, wie sie im RE definiert sind. Die extrahierten Bedürfnisse werden anschließend mit den Ergebnissen der Modellierung auf neue Funktionalitäten hin überprüft. Gehen neue Funktionalitäten aus den Bedürfnissen hervor, so werden diese mit aufgenommen. Danach startet das klassische RE-Vorgehen, das aus Funktionalitäten funktionale Anforderungen erstellt. Dabei spielt es keine Rolle, ob die Aktivitäten zuvor als Szenarien oder als Use-Cases dokumentiert wurden.
Neben funktionalen Anforderungen gibt es im RE auch nichtfunktionale Anforderungen (NFA), die in verschiedene Kategorien eingeteilt werden. Zum Beispiel in der Kategorie "Anforderungen an die Benutzerschnittstelle" wird eine Menge von Faktoren beschrieben, die sich mit dem visuellen, akustischen oder auch haptischen Erscheinen und der Bedienung des Produkts befassen. Sie ergänzen die funktionalen Anforderungen – zumindest diejenigen, die sich an der Oberfläche zeigen – und spezifizieren, wie die funktionalen Anforderungen zu erscheinen haben. Darunter fallen Bedienkonzept, Rahmenbedingungen für die Gestaltung der Benutzungsoberfläche und Bedienelemente [3].
Im UE werden nun alle restlichen Attribute der Personas – wie mentales Modell, physische Umgebung, Ängste und Ziele – auf Bedürfnisse überprüft.
Im kombinierten Vorgehen werden nicht nur die restlichen Attribute der Personas auf nichtfunktionale Anforderungen hin überprüft, sondern auch die gesamten Interviewdokumente und alle bereits verwendeten Informationen (Benutzeraktivitäten, Kontextszenarien, Use-Case-Beschreibungen). Die NFAs werden anschließend anhand der NFA-Kategorien aus dem RE eingeteilt und auf Vollständigkeit geprüft. Die NFA-Kategorien dienen dabei als Checkliste, da sie generisch wiederverwendbar sind. Die erhobenen nichtfunktionalen Anforderungen werden im nächsten Schritt noch nach RE-Methoden qualitätsgesichert. Nichtfunktionale Anforderungen sind im Restaurantbeispiel unter anderem "Die Benutzeroberfläche des Systems soll in den Sprachen Deutsch, Englisch und Italienisch zur Verfügung gestellt werden" oder "Die Bedienung des Systems soll konform zu MS Office gestaltet sein". Abb.4 zeigt den Prozess der Anforderungserhebung in der kombinierten Variante.
Fazit
Nun ist ersichtlich, dass die klassische Anforderungserhebung durch die Integration
von Usability-Engineering-Methoden optimiert wird, so dass eine qualitativ hochwertige Anforderungsspezifikation erreicht werden kann. Die beiden Disziplinen ergänzen sich dabei in ihrer Vorgehensweise perfekt, indem das UE an vielen Stellen immer wieder die Kreativität des Analytikers anregt und das RE gleichzeitig die nötige Struktur liefert. Speziell die Benutzeranalyse liefert essentielle Daten wie Ziele, Verhaltensweisen und Bedürfnisse der Benutzer, die im klassischen RE nicht so detailliert erhoben werden. Die Analyse und Modellierung von Benutzern ist somit eine wichtige Anforderungsquelle für funktionale und nichtfunktionale Anforderungen, da sie bei Entwicklungs- und Designentscheidungen hilft und die Sichtweise auf das System und seine Interaktion erweitert. Speziell in der Phase der Zielfindung und Kontextabgrenzung zeigt das UE durch seinen Priorisierungsansatz, dass es manchmal sinniger ist, die potentiellen Anforderungsquellen klar zu priorisieren anstatt später zu viele sich wiedersprechende Informationen unterschiedlicher Quellen zu konsolidieren. Die Kombination der beiden Disziplinen erweitert nicht nur den Blickwinkel auf das System, sondern bringt Vollständigkeit für die weiteren Entwicklungsphasen und sichert die Akzeptanz der Nutzer. Außerdem fördert eine Verschmelzung der beiden Disziplinen das Miteinander der Projektteilnehmer langfristig.
- D. A. Norman, 1988: The Design Of Everyday Things; Basic Books, New York
- A. Cooper, R. Reimann, D. Cronin, 2007: About Face – Interface und Interaction Design, mitp, Heidelberg
- C. Rupp, die SOPHISTen, 2014: Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil; Hanser, Nürnberg
- K. Pohl, C. Rupp, 2015: Basiswissen Requirements Engineering – Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level; dpunkt.verlag GmbH, Heidelberg
- K. Goodwin, 2009: Designing For The Digital Age, Wiley Publishing, Inc., Indianapolis
- Deutsches Institut für Normen e.V., 1999: Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten – Anforderungen an die Gebrauchstauglichkeit, Beuth, Berlin
