Der kritische Punkt der nutzerorientierten Anforderungsanalyse

Während wir heute den ersten Prototypen unseres Tweedback-Projekts den Projektbetreuern und somit auch Endkunden den ersten Prototypen vorgestellt haben, ist mir ein interessantes Problem aufgefallen, das in der Anforderungsanalyse zwar immer betont, aber oft nicht beachtet wird: Das „Analysis-Synthesis-Bridge-Model“ beschreibt vier Punkte, die es zu beachten gilt, wenn man den Nutzer des Produktes in den Mittelpunkt stellen will. Während die ersten drei noch vergleichsweise intuitiv und selbstverständlich sind, hat man den vierten in Termin- und Fertigstellungsdruck schnell vergessen.

Analysis-Synthesis-Bridge-Model

Das Brückenmodell beschreibt das Vorgehen während der Anforderungsanalyse, insbesondere der Recherche und des Prototypings. Es ist im wesentlichen eine Vierfeldertafel:

Die Tafel beschreibt die Schritte, die es zu beachten gilt.

1. Man benötigt detaillierte Kenntnisse über die aktuelle Situation, in welcher die Software eingesetzt werden soll. Um Probleme zu beheben, ist es absolut notwendig, diese zunächst genau zu verstehen.
2. Die Situation muss modelliert werden. Es entsteht ein deskriptives Modell, welches die Realität auf das wesentliche reduziert. Dies heißt auch, dass zu behebende Probleme mit modelliert werden und deren Behebung im Modell möglich ist.
3. Aufgrund dieses Modells gilt es Lösungen zu finden und diese in das Modell zu integrieren. Um sicherzugehen, dass ein Ansatz auch wirklich funktioniert, ist hier ein Prototyp ein geeigneter Ansatz.
4. Die gefundenen Lösungen müssen auf ihre Realitätsnähe geprüft werden. Dies beinhaltet selbstverständlich, dass die modellierte Lösung auch wirklich funktioniert. Aber auch andere Aspekte sind wichtig: Wird der Nutzer die Software auch wirklich so nutzen, dass das Problem gelöst wird? Wird dies in angemessener Zeit möglich sein? Sind hierfür ausführliche Schulungen notwendig? Neben der Effektivität der Lösung ist somit auch immer ihre Effizienz in Bezug auf ihre Benutzbarkeit zu beachten.

Unser Vorgehen bei Tweedback

Die ersten drei Schritte macht jeder Software-Entwickler intuitiv richtig. Das Problem ist vor allem der vierte. Auch wir sind bei Tweedback sauber der Vorgabe gefolgt: Wir haben das Problem analysiert, modelliert und eine Lösung auf dem Modell erarbeitet.

Wir haben uns bewusst gemacht, welche Probleme es in Vorlesungen gibt und detailliert beschrieben, welche Fragestellungen bei Studenten aufkommen. Anschließend haben wir die Dozenten betrachtet und uns mit dem Problem auseinandergesetzt, dass diese sich nicht auf Feedback-Bildschirme konzentrieren können, sondern Auf-einen-Blick-Übersichten benötigen.

Das Problem mit dem vierten Schritt

Das Ergebnis war eine detaillierte Vorstellung von Nachrichten, die zwischen Studenten und Dozenten ausgetauscht werden müssen. Diese gilt es nun ein- und auszugeben. Folglich versucht man möglichst knappe und intuitive Darstellungsmöglichkeiten und Eingabemasken zu entwickeln.

Was an sich nicht verwerflich klingt ist aber schnell falsch gemacht: Man baut auf sein eigenes Wissen um Programm- und Nachrichtenstruktur. Man kennt die einzelnen Funktionen des Programmes und bildet diese auf knapp bemessene Formulare ab. Für die Direktevaluierung fragt man sich vor allem eines: Würde ich Funktion x auf der Programmoberfläche finden? Diese Frage unterstellt aber, dass der Nutzer um Funktion x weiß. Dies ist aber vor allem am Anfang keineswegs der Fall.

Nicht „Wie mache ich was?“, sondern „Was kann ich machen?“

Und hier ist vor allem der vierte Schritt wichtig: Man muss sich bewusst werden, wer in welcher Situation mit der Oberfläche arbeiten muss. Es geht darum zu erkennen, was ein Nutzer von einem Programm erwartet. Da er keinerlei Vorwissen über interne Abläufe und Funktionen mitbringt, sucht der Nutzer auf der Oberfläche nach Möglichkeiten, seine Erwartungen umzusetzen. Dabei gilt es ihn an die Hand zu nehmen und Möglichkeiten aufzuzeigen.

Wir wussten um unsere Konzepte: Wir haben die Formulare zur Teilnahme an einer Veranstaltung und Erzeugung neuer Veranstaltungen nebeneinander gestellt. Wir wussten, wann welches zu nutzen ist. Die Frage, ob jeder Nutzer überhaupt den Unterschied versteht, stellt man sich hingegen nicht mehr. Auch unsere nächste Darstellung war für uns klar: Man kann bereits dargestellte Rückmeldungen anderer unterstützen. Folglich sucht man diese Möglichkeit in der darstellenden Feedback-Wolke. Weiß ein Nutzer allerdings nichts von dieser Möglichkeit, wird ihm diese auch verborgen bleiben.

Erwischt man sich bei solchen Problemen, redet man sich schnell damit raus, dass es sich nur um einen Prototypen handele. Aber das verschärft das Problem: Man gewöhnt sich an ein Konzept und hält es für selbstverständlich. Bei der Implementierung möchte man schnell und effizient arbeiten, man möchte fertig werden. Daher ist es aber gerade so wichtig, dass eine effiziente Darstellung des Programms und seiner Funktionen möglichst früh zu durchdenken und zu implementieren. Es sind vor allem Details, die bei der Fertigstellung gerne mal vergessen werden.