Anforderungen brauchen wir in all unseren Projekten, bauen wir darauf basierend doch unsere Systeme. Leider können Anforderungslisten aber auch unglaublich lang werden und manchmal fragt man sich einfach: „Wer hat sich das jetzt schon wieder überlegt?“
Und „Überlegt“ ist das richtige Stichwort, denn leider ist es oft so, dass Anforderungen aus Gesprächen zwischen Projektleitern, Auftraggebern, Vertrieblern oder anderen Rollen resultieren, in denen Annahmen darüber getroffen werden, was Nutzer benötigen – oder besser: benötigen könnten. Das zeigt sich schnell in Formulierungen wie „Bestimmt machen die Nutzer das so…“ oder „Ich gehe mal davon aus, dass…“. Viel zu oft stellt sich später heraus, dass kein Nutzer die aus solchen Annahmen entstandene Funktion tatsächlich benötigt.
Mich persönlich stört dieses Arbeiten auf Annahmen enorm – sowohl die Nutzer, als auch wir Entwickler haben gar nichts davon. Mein Anspruch ist es, dass wir Lösungen entwickeln, die der Nutzer wirklich braucht – in seiner Gesamtheit.
User Requirements Engineering als nächster Schritt
Anfang Dezember hab ich daher eine Weiterbildung zum User Requirements Engineer (CPUX-UR) bei Thomas Geis belegt – die übrigens sehr zu empfehlen ist, alleine schon aufgrund des enormen Erfahrungsschatzes des Trainers. Dieser hat unter anderem an der ISO 9241, die essentiell im Usability Engineering ist, mitgewirkt.
User Requirements Engineering ist sowohl eine Teildisziplin des Requirements als auch des Usability Engineerings (wer es noch nicht wusste: Der Schritt der Erhebung von Nutzungsanforderungen ist tatsächlich einer der ersten Schritte im benutzerzentrierten Gestaltungsprozess, was wieder einmal zeigt: Usability ist viel mehr als nur Design).
Eine Aussage aus dem Training ist bei mir hängen geblieben: „Das, was der Nutzer sieht, d. h. die Benutzeroberfläche, ist für ihn das Produkt – nicht die zugrundeliegende Technik.“ Letztere nimmt der Nutzer einfach als gegeben wahr.
Was bedeutet diese Aussage für das Requirements Engineering? Ganz einfach: Wir sollten uns zunächst darauf konzentrieren, Anforderungen zu identifizieren, die beschreiben, was der Nutzer am späteren System erkennen, auswählen oder eingeben können muss, und uns (erstmal) von Systemanforderungen fernhalten. Diese Anforderungen nennt man auch Nutzungsanforderungen.
Ich möchte euch im Folgenden vorstellen, wie ihr zu Nutzungsanforderungen kommt, die nicht nur auf Annahmen beruhen. Dazu gibt es nämlich ein ziemlich strukturiertes Vorgehen.
Wie komme ich zu einer Nutzungsanforderung?
Das wirklich Spannende an Nutzungsanforderungen ist, dass diese nicht plötzlich da sind, oder sich irgendjemand überlegt, was man noch alles im System tun müsste. Nutzungsanforderungen sind begründet abgeleitet – aus dem Nutzungskontext eines Benutzers.
Der Nutzungskontext leicht erklärt
Wenn wir eine Aufgabe erledigen – sei es an einem System oder auch nicht systemunterstützt – machen wir dies immer in einem bestimmten Nutzungskontext. Wir nutzen dabei bestimmte uns zur Verfügung stehende Ressourcen (wie Materialien, Hardware, Software) und bewegen uns dabei immer in einer Umgebung (physisch, sozial und kulturell). Je nachdem, wie unser Nutzungskontext gestaltet ist, hat das einen Einfluss auf unsere Tätigkeit. Wenn wir in einem Großraumbüro (physische Umgebung) mit vielen Kollegen zusammen (soziale Umgebung) arbeiten, bedingt das beispielsweise, wie wir uns an unserem Arbeitsplatz verhalten. Wenn wir Musik hören (unsere Aufgabe), werden wir diese sehr wahrscheinlich nicht laut, sondern mit Kopfhörern hören, während unsere Kollegen konzentriert arbeiten. Sind wir dagegen alleine, nehmen wir uns ganz andere Freiheiten heraus.
Informationen zum Nutzungskontext ermitteln
Detaillierte Informationen zum Nutzungskontext erhalten wir beispielsweise, indem wir Interviews mit Personen durchführen, die für das zu entwickelnde Produkt von Interesse sind (sprich: mit Nutzern). Alternativ oder ergänzend beobachten wir Nutzer, während sie ihre Aufgaben erledigen – innerhalb ihres Kontextes. Alle gesammelten Informationen formulieren wir in sogenannten Kontextszenarien, welche beispielsweise in narrativer Form beschreiben, wie die befragten Nutzer ihre Aufgaben in ihrem Nutzungskontext ausführen.
Aus dem Nutzungskontext Erfordernisse ableiten
Jetzt kommen wir zu einem der zentralsten Schritte im User Requirements Engineering: Aus den Informationen zum Nutzungskontext leiten wir sogenannte Erfordernisse ab. Erfordernisse sind notwendige Voraussetzungen, damit ein Nutzer in seinem Nutzungskontext ein Ziel erreichen kann. Sie sind in ihrer Formulierung daher so aufgebaut, dass sie aus einer Voraussetzung bestehen („Der Benutzer muss irgendwas wissen, können oder verfügbar haben“) und aus einem Ziel in Form einer Aktivität („…, um etwas zu entscheiden oder zu tun“).
Stellt euch vor, ich hätte euch zu eurem Schlafverhalten interviewt. Ihr habt mir erzählt, dass es immer wieder vorkommt, dass ihr nachts wach werdet und die Blase drückt. Eure Entscheidung aufzustehen, hängt davon ab, wie lange es noch dauert, bis euer Wecker klingelt. Außerdem seid ihr Brillenträger und es stört euch, dass ihr immer erst die Brille aufsetzen müsst, um die Uhrzeit abzulesen.
Was ist hier euer Erfordernis? Ich würde es so formulieren:
„Der brillentragende Schlafende muss – auch ohne seine Brille aufzusetzen – wissen, wie lange er noch schlafen kann, um zu entscheiden, ob er auf die Toilette geht.“
Aus Erfordernissen zu Nutzungsanforderungen kommen
Wir haben also jetzt ein Erfordernis aus dem Nutzungskontext abgeleitet. Was machen wir jetzt damit? Ganz einfach: Wir leiten daraus eine Nutzungsanforderung ab.
Nutzungsanforderungen beschreiben, was der Nutzer am System erkennen, eingeben oder auswählen muss, während er eine Aufgabe in seinem Nutzungskontext ausführt. Uns ist zu diesem Zeitpunkt noch völlig egal, um was für ein System es sich handelt. Der Kreativitäts- und Gestaltungsprozess kommt später.
Um Nutzungsanforderungen abzuleiten, stellt man sich einfach drei Fragen:
- Was muss der Nutzer während der Erledigung einer Aufgabe erkennen können, damit sein Erfordernis erfüllt wird?
- Was muss der Nutzer während der Erledigung einer Aufgabe eingeben können, damit sein Erfordernis erfüllt wird?
- Was muss der Nutzer während der Erledigung einer Aufgabe auswählen können, damit sein Erfordernis erfüllt wird?
Ich würde beispielsweise die folgende Nutzungsanforderung aus dem obigen Erfordernis ableiten:
„Der Benutzer muss am System – auch ohne seine Brille aufzusetzen – erkennen können, wie lange er noch schlafen kann.“
Damit haben wir eine begründete Grundlage, aus der wir eine Systemanforderung ableiten können und die sich später (wie auch immer gestalterisch umgesetzt) in der entwickelten Lösung wiederfindet.
Jetzt denkt an eure Wecker: Nur wenige Wecker zeigen euch an, wie lange ihr noch schlafen könnt. Der Apple-Wecker geht zwar in diese Richtung, als Brillenträger habe ich aber dennoch meine Probleme. Wir haben also eine gute, herausfordernde Nutzungsanforderung ermittelt, die sich aus dem Nutzungskontext ergeben hat. Diese können wir jetzt als Grundlage verwenden, um in einen Kreativitäts- und Gestaltungsprozess einzusteigen und zu erarbeiten, mit welcher Lösung wir den Nutzer bestmöglich unterstützen können.
Warum solltet ihr Nutzungsanforderungen beim Requirements Engineering mit berücksichtigen?
Das Wecker-Beispiel zeigt, dass wir über den Weg von Nutzungskontext über Erfordernisse zu Nutzungsanforderungen kommen, denen eine Begründung für ihr Dasein zugrunde liegt. Wir arbeiten also nicht mehr nur mit Annahmen, sondern fokussieren uns auf wirklich notwendige und unterstützende Anforderungen. Adieu lange, unnötige Anforderungslisten!
Über diesen Weg können wir außerdem sogar zu Innovationen kommen: Wir haben in unserem Beispiel ein wesentliches Problem identifiziert, nämlich, dass Brillenträger nachts eigentlich keine Lust haben, ihre Brille aufzusetzen, um die Uhrzeit zu erkennen. Wenn wir eine Lösung finden, die das unterstützt, haben wir etwas gefunden, was es so auf dem Markt noch nicht gibt und wie wir uns von unserer Konkurrenz abheben.
Kommentare