Es gibt viele erfolgreiche Software-Projekte und wahrscheinlich noch mehr Software-Projekte, die scheitern. Es gibt auch viele Analysen über die möglichen Gründe für das Scheitern. Einer dieser Gründe ist ein falsch durchgeführtes Requirements-engineering. Heißt: Anforderungen werden auf irgendeine nicht sinnvoll Art und Weise aufgenommen bzw verarbeitet. Dafür kann es viele Gründe geben. Ich denke der häufigste Grund ist, dass die Leute keine Awareness für das Thema haben. Dieser Artikel versucht, das ein bisschen zu ändern und dabei auf den Unterschied zwischen was und wie aus der IT-Perspektive einzugehen.
Wie sollten Anforderungen aufgenommen werden? Das Problem ist: Auf diese Frage gibt es keine eindeutige Antwort, weil die Antwort vom gewählten Entwicklungsprozess abhängt. Soll z. B. Scrum als Prozess benutzt werden, dann können, Anforderungen jederzeit hinzukommen oder auch geändert werden, aber man kann nicht erwarten, dass das noch im selben Sprint umgesetzt wird. Arbeitet man nach einem klassischen legacy Wasserfall-Modell, kann man Anforderungen nur am Anfang einbringen und diese normalerweise auch nicht mehr ändern. Es gibt beliebig viele weitere solche Prozess-Modelle. Alle haben aber gemeinsam, dass Anforderungen – wenn sie denn aufgenommen werden – richtig aufgenommen werden müssen. Klingt wie eine Binsenweisheit, aber es gibt ein paar Details, die man sich bewusst machen sollte.
Normalerweise stellt ein Kunde nur funktionale Anforderungen. Es gibt selten einen legitimen Grund, dass ein Kunde eine nicht-funktionale Anforderung stellt. Und dennoch passiert es in der Praxis viel zu oft. Das kommt auch daher, dass nicht immer objektiv eindeutig ist, ob eine Anforderung funktional oder nicht funktional ist. Dies hängt vom Kontext ab. Und so vermischen Leute dann Sachen. Beispiel: “Ein Administrator soll Nutzern Rollen für Aktionen geben.” Ist das eine funktionale oder eine technische Anforderung? Normalerweise eine technische Anforderung. Es beschreibt einen konkreten Vorgang. Es beschreibt das “wie”. Der Kunde sollte sowas normalerweise nicht als Anforderung formulieren. Der Kunde sollte funktionalie Anforderungen formulieren, was bedeutet, dass man sagt, “was” gemacht werden soll bzw. welches Ziel erreicht werden soll. Das heißt ein Kunde, der oben genannte Anforderung stellt, meint wahrscheinlich als Anforderung eigentlich “Es soll steuerbar sein, welcher Nutzer welche Aktionen im System machen kann.” Ob das “wie” (also die konkrete Umsetzung) dann mittels Rollen oder eines anderen Berechtigungsmodells implementiert wird, muss das Entwickler-Team entscheiden, nicht der Kunde. Warum ist es nun aber nicht immer eindeutig? Wenn man für den Kunden ein Authorisierungs-System entwickelt, und es bereits eine vorherige Design-Entscheidung war, Berechtigungen über Rollen abzubilden, dann kann das Geben von Rollen sehr wohl eine fachliche Anforderung sein. Diese objektive Nicht-Eindeutigkeit macht die Sache schwerer, weil man sich ihr bewusst werden will. Kunden sollten immer nur Anforderungen stellen, die in ihrem konkreten Fall eine fachliche Anforderung sind. Sie sollten beschreiben, “was” sie erreichen wollen mit der Anforderung, nicht mehr und nicht weniger. Das wird oft gerade von Kunden verwechselt. Das kann man Kunden aber auch nicht übel nehmen, weil Kunden meistens nicht geschult sind, diese feinen Semantik-Unterschiede in der Formulierung zu erkennen. Erst recht nicht, wenn man dann die Erfahrung macht, dass es ohnehin oft auf das gleiche hinausläuft. Also ein Kunde kann ja als Anforderung in seinem Dokument-Management-System “Es soll steuerbar sein, welcher Nutzer welche Aktionen im System machen kann.” formulieren. Und es kann sein, dass das Entwickler-Team entscheidet, das über Rollen abzubilden. Dann kann man auch sagen, der Kunde hätte ja gleich die Formulierung mit den Rollen benutzen können. Ja, hätte er, wäre aber falsch gewesen, weil ein Kunde nicht über die technische Umsetzung entscheidet. Der Kunde hat die Kompetenz für z. B. die Anforderungsdefinition und Fachlogikdefinition, aber eben nicht für die technische Umsetzung. Wenn dann Product-Manager und Entwickler-Team die Anforderungen so wie sie kommen blind umsetzen, bestimmt der Kunde zumindest in Teilen die technische Architektur, und das geht meistens nicht gut. Das ist ein Grund (von mehreren), warum Software-Projekte scheitern oder zumindest teurer werden als nötig.
In einer idealen Welt, werden fachliche Anforderungen dokumentiert und darüber hinaus wird in der technischen Dokumentation auch Dokumentiert, welche Design-Entscheidungen die Entwickler getroffen haben, um die jeweiligen Anforderungen umzusetzen. (Macht in der Praxis keiner, weil es für viele Anforderungen auch trivial oder immer Schema F ist, das ist mir klar, aber wenn man ordentlich und vollständig dokumentieren will, sollte man das dennoch machen.) Der Kunde hat dann nicht nur eine Übersicht über alle fachlichen Anforderungen (sprich: eine Liste aller Funktionen, die man beim Akzeptanz-Test durchtesten muss), sondern es gibt auch eine klare Trennung zwischen Anforderungen und Design-Entscheidungen zur Umsetzung. Das sollte eigentlich immer so sein, ist aber nicht so, daher erwähne ich es hier. Damit hat der Kunde übrigens auch den Vorteil, dass wenn etwas nicht formuliert, dann muss er sich keinen Kopf machen, wie er die Anforderung umformulieren muss, um den Entwicklern zu sagen, wie sie das Problem lösen sollen, sondern es reicht, zu sagen “Bug-report: Anforderung 17 funktioniert nicht mehr, bitte beheben.” Das klingt trivial, aber leider habe ich viel zu oft in der Praxis gesehen, dass es genau so nicht läuft. Da ist dann z. B. das klassische Ziel, die viel zu groß und wichtig gewordene Excel-Tabelle durch eine entsprechende Software zu ersetzen. Wenn man jetzt jede Tabellen-Zelle, jedes Makro und jedes existierende Diagram darin einfach zu einer Anforderung an die neue Software macht, dann beschreibt man eben das “wie” und nicht das “was”. Wenn das alles genau so umgesetzt wird, hat man letztendlich wenig gewonnen, weil man die Excel-Datei nur in einer anderen Progarmmiersprache nachgebaut hat. Das ist aber selten das, was Kunden wirklich wollen. Man muss sich überlegen: “Was” erreicht man mit dieser Tabelle? (Also beispielsweise: Welche Erkenntnisse ziehe ich durch die Daten, “was” kann ich durch die Makros machen, etc.) Und das muss man dann als Anforderung an die neue Software definieren, aber eben nicht die konkrete Implementierungsidee. Beispiel: Der Kunde hat in der obsoleten Excel-Tabelle eine aus den Daten generierte Graphik, in der zu erkennen ist, welches Produkt am meisten Gewinn generiert. Das ist dann ein Hochpunkt im Diagram-Graph, den man schön ablesen kann. Dadurch weiß der Kunde, welches für Produkt sich Werbung am ehesten lohnt. (Nur ein ganz vereinfachtes Beispiel, BWL ist natürlich vielseitiger, hier geht es lediglich ums Prinzip der Anforderungen.) Und wenn man sich dann mit dem Kunden mal unterhält, stellt man fest: Man braucht gar kein aufwendig programmiertes Diagramm, der Kunde will einfach nur wissen, für welches Produkt sich Werbung am meisten lohnt. Das hat der Kunde als Umsetzung (also um das “wie” zu implementieren) bislang mit einem Diagramm gemacht. Ist das Diagramm aber erforderlich, um diese Information zu bekommen? Nicht unbedingt. Es ist also keine fachliche Anforderung. Die fachliche Anforderung ist: Das Programm soll möglichst leicht erkennbar machen, welches das Produkt ist, in dem das Werbe-Budget am besten investiert ist. Und das kann man dem Kunden ja so berechnen, wie es auch die Excel-Tabelle tat, aber ein Software-Entwickler hat andere (womöglich bessere und zugleich einfachere) Möglichkeiten, um diesen Wert anzuzeigen, ohne dass man dafür ein Diagramm generieren muss. Die technische Umsetzung ist also eine andere.
Fazit:
Anforderungen von Kunden müssen immer hinterfragt werden. Es muss immer gefragt werden, welche Ziel man eigentlich erreichen will, und da sind viele genannte Sachen oft tatsächlich nicht die richtige Antwort, sondern schon eine angedachte Implementierung (siehe auch xy-Problem). Es ist daher normal, dass man oft Fragen stellen muss wie “Was willst du damit eigentlich erreichen” oder “Was ist der Mehrwert, den man dadurch hat?”. Gute Designer können dabei übrigens eine wertvolle Unterstützung sein, um die eigentlichen Anforderungen der Kunden in einen guten UI-/UX-Entwurf zu bringen, damit die Kunden eine Software nicht nur gern bedienen, sondern damit die Bedienung auch effektiv undeffizient wird. In jedem Fall aber muss ein Product-Manager Anforderungen validieren und ggf. auch herausfiltern, damit sein Produkt wirklich sinnvolle Features bekommt, und nicht Funktionen nur bekommen, damit der Kunde umständlich etwas machen kann, was auch auf anderem Wege einfacher oder besser umsetzbar wäre.