Der blinde Fleck des Requirements Engineering

Im Requirements Engineering ist immer häufiger die Rede von den Anforderungen der User. Meist beschäftigt sich Requirements Engineering damit, was die User brauchen, aber nicht damit, wie sie es brauchen. Die Anforderungen sind also zu wenig spezifisch. In der konkreten Umsetzung führt das oft dazu, dass die User von den Systemen nicht effizient in ihrer Arbeit unterstützt werden. Sie behelfen sich dann vielfach damit, die teuer entwickelten Systeme zu umgehen.

Schwer verständliche und erlernbare Applikationen

Jedes Mal, wenn ich in MS Word einen Text in eine Tabelle umformatieren will, ärgere ich mich. Denn in der Menüführung geht das über Einfügen > Tabelle > Text in Tabelle umwandeln. Das weiss ich auch. Und doch empfinde ich es jedes Mal als störend, dass ich für den Text, der ja schon da ist, den Bereich «Einfügen» wählen muss. Für einen Bruchteil einer Sekunde beschäftige ich mich damit, das für mich unlogische System zu «verstehen», statt mich meiner eigentlichen Aufgabe zu widmen. Das wiederholt sich mit anderen Funktionen dieses und anderer Programme, die ich täglich anwende. Immer wieder.

Das Verständnis der User ...

Benutzerfreundliche Applikationen beginnen damit, dass sie gut integriert sind in das Verständnis der User. Um das zu erreichen, muss dieses bekannt sein und in die Anforderungen einfliessen. Und zwar möglichst, bevor die Spezifikationen an die Umsetzer gehen. Denn es gibt immer unterschiedliche Möglichkeiten, eine Anforderung umzusetzen, wenn sie nicht ausreichend spezifiziert ist. Dies führt dazu, dass Lösungen implementiert werden, die User schlecht in ihrer Arbeit unterstützen.

In einem konkreten Beispiel mussten die User ihren Projekten Länder zuordnen. Doch die Auswahlliste der Länder war nach Regionen geordnet, so dass die User bei jedem Land überlegen mussten, in welcher Region es sich befindet, und mindestens zwei Schritte benötigten, um es auszuwählen. Nach der Verarbeitung der Daten erschienen die Projekte nach Nummern geordnet. Bevor das Land angezeigt wurde, erschien eine Menge anderer Informationen. Für die User war das Land das zentrale Merkmal des Projekts. Doch das war aus den Anforderungen nicht klar geworden.

Grafische Darstellung des Beispiels mit der Länderauswahl im Text — Wenn die Requirements Engineers das «Wie» einer Anforderung nicht definieren, entwickeln die Umsetzer nicht das, was die User brauchen.

... und das Leid der Umsetzer

Entwickler werden oft unfreiwillig zu Requirements Engineers. Sie interpretieren und setzen um, was aus ihrer Sicht von ihnen verlangt wird. Nur kennen sie meist die User und deren Anforderungen nicht. Sie wissen nicht, wie die User ihre Daten einpflegen. Auch wissen sie nicht, wie die Datenausgabe aussehen soll, damit die User sie verstehen. So haben die Entwickler mehr Aufwand und Druck in der Umsetzung. Und am Schluss sind die User erst noch unzufrieden.

Licht ins Dunkel der Black Box bringen

Das Requirements Engineering muss der Erhebung der Anforderungen der User die gleiche Sorgfalt widmen wie der Erhebung der Anforderungen der Datenverarbeitung. Denn sonst ist die Folge, dass die User

im Projektverlauf und im Betrieb immer neue Change Requests stellen
ihre Arbeit nicht effizient erledigen
die teuer entwickelten Systeme nach Möglichkeit umgehen
und alles in allem die Kosten der Software immer weiter in die Höhe treiben.

Die Formulierung technischer Anforderungen gewährt bewusst einen lösungsunabhängigen Freiraum. Doch die Anforderungen der User müssen sehr spezifisch formuliert sein. Nehmen Sie sich zu Projektbeginn Zeit für die genaue Spezifikation des User Interface. Man kann Arbeit, diese Anforderungen zu formulieren, nicht «wegsparen». Denn irgendwann im Projekt müssen die Anforderungen interpretiert werden – doch geschieht das nicht immer im Sinn der User und Ihres Budgets.