Requirements Engineering | Teil1: Vom Wunsch zur Anforderung

Wer in den letzten Wochen die IT Berichterstattung aufmerksam verfolgt hat, ist sicher über die Geschichte mit Lidl und SAP gestolpert. Nachdem Lidl sieben Jahre versucht hat mit SAP ein Warenwirtschaftssystem umzusetzen, wurde das Projekt nach kolportierten Investitionen in der Höhe von 500 Millionen Euro zu Grabe getragen. Wer die Geschichte noch nicht kennt, oder gerne nachlesen möchte, hier ein Link.
Natürlich drängt sich bei solchen Summen und investierten Jahren die Frage auf, wie so etwas passieren kann und die verzweifelte Suche nach einem Schuldigen beginnt. Der ist aber in den meisten Fällen gar nicht so leicht zu finden. Wie auch das Beispiel von Lidl zeigt. Auch wenn es aktuell keinen eindeutigen Hinweis darauf gibt, dass das bei diesem Projekt der Fall war, liegt das Problem, das später zum Scheitern führt oft ganz zu Beginn eines Projektes. Nämlich schon bei der Auswahl des Produktes.

Zu Beginn des Auswahlprozesses treffen meist zwei sehr unterschiedliche Welten aufeinander: Der Auftraggeber mit einem Rucksack voller Ideen, die das neue System erfüllen soll. Der mögliche Auftragnehmer mit einem Produkt, das bereits mehrfach erfolgreich implementiert wurde. Auf beiden Seiten herrscht ein gewisser Druck: Der Auftraggeber möchte im Rahmen seines Budgets das Projekt möglichst rasch umsetzen und möglichst viele Features für sein Geld bekommen. Der Auftragnehmer möchte sein Produkt verkaufen und dabei erreichen, dass bei der Implementierung möglichst wenig Individualisierung und somit Aufwand notwendig ist.
So formuliert der Auftraggeber seine Wünsche an das System und der Auftragnehmer ist davon überzeugt, dass diese Wünsche durch sein Produkt realisiert werden können. Dennoch zeigt sich dann während der Umsetzung, oder im schlimmsten Fall erst nach der Fertigstellung, dass die Wünsche vom Auftragnehmer ganz anders aufgenommen wurden, als ursprünglich vom Auftraggeber gedacht. Wünsche lassen einfach viel Interpretationsspielraum – viele kennen diese schmerzhafte Erfahrung aus der Kindheit, wenn das Christkind wieder einmal das Falsche gebracht hat.

Und genau hier setzt Requirements Engineering ein. Eine der wichtigsten Aufgaben eines Requirement Engineers ist aus Wünschen Anforderungen zu formulieren. Anforderungen sind Vorgaben, die beiden Seiten Klarheit verschaffen, was das System erfüllen soll. Ein Leitfaden, der durch das Projekt führt. Eine Möglichkeit für Auftraggeber und -nehmer immer wieder zu überprüfen ob man sich am richtigen Weg befindet, oder ob Anpassungen notwendig sind. Wenn das Fundament eines Hauses bereits steht, oder im schlimmsten Fall das gesamte Haus fertig gestellt ist und es sich anstatt des gewünschten Palastes um ein Einfamilienhaus handelt, muss alles abgerissen und neu gebaut werden. Das ist natürlich teuer und für beide Seiten frustrierend. Sind die Anforderungen an das Haus aber von Anfang an klar definiert, gibt es vielleicht kleine Anpassungen, die durchgeführt werden müssen – aber die Richtung ist klar. Und das entscheidet letzten Endes auch darüber ob ein Projekt erfolgreich umgesetzt werden kann, oder ob es zum Scheitern verurteilt ist und hilft somit nicht nur Geld, sondern auch Nerven zu sparen.