In meinem diesjährigen Consulting Einsatz ist mir aufgefallen, dass in keiner Entwicklungsabteilung des Kunden über das Thema Requirements Engineering (RE) gesprochen wird. Es gibt natürlich die Rolle Business Analyst und es gibt immer noch Anforderungen. Befrage ich aber die Abteilungs- und Teamleiter auf das Thema RE, fällt mir auf, dass sehr selten über klassische RE Disziplinen gesprochen wird. Keine Rede von "Dokumentieren oder Validieren von Anforderungen". Das wundert mich ein wenig, auch weil viele Themen des diesjährigen Swiss Requirements Days (SRD) aus dem klassischen RE waren.
Auf diesen Gedanken hin habe ich den T&B Report gewälzt. Im RE-Kapitel fand ich dann die Bestätigung meiner Vermutung. Klassische RE Disziplinen sind nicht mehr an oberster Stelle der Statistiken. Nachdem sich Requirements Engineers jahrelang bemüht haben den RE Prozess in den Unternehmen zu etablieren, sieht es nun so aus, als wäre es nicht mehr gefragt. Das Thema ist sozusagen gestorben.
Ich, als Requirements Engineer muss mich damit jedoch erstmal abfinden, das klassische RE also quasi "zu Grabe tragen".
Für mich als RE gehört zum Abfinden natürlich eine ordentliche Analyse der Situation. Bevor ich analysiere, ob klassisches RE "OUT" ist, muss ich erstmal festhalten, was klassisches RE überhaupt ist. Woraus besteht die RE Methodik? Immerhin ist methodisches Wissen beim Requirements Engineering von besonders hoher Bedeutung, laut dem T&B Report 2015.
Was ist RE?
Hierbei stütze ich mich auf das International Requirements Engineering Board (IREB). Im T&B Report 2015 haben schliesslich mehr als 50 Prozent der Befragten angegeben den IREB FL Kurs besucht zu haben. Gemäss IREB besteht der klassische RE-Prozess aus folgenden Disziplinen und deren Aspekten:
- Anforderungen ermitteln: Beim diesem Thema geht es unter anderem um Ermittlungstechniken, Stakeholder oder Anforderungsquellen
- Anforderungen dokumentieren: Das Thema "Anforderungen dokumentieren" beschäftigt sich mit Dokumentationsarten (z. B. UML, oder Sprachschablonen) und Werkzeugen zur Dokumentation uvm.
- Anforderungen prüfen und abstimmen: Dieses Thema behandelt zum Beispiel Qualitätsaspekte, Techniken zur Prüfung und Konfliktmanagement
- Anforderungen verwalten: "Anforderungen verwalten" handelt unter anderem von Rückverfolgbarkeit, Versionierung oder Anforderungsänderungen
Was bedeutet denn nun "RE ist tot"?
Die RE Trendwave ordnet RE Themen (gemäss Antworten auf T&B Fragen) in eine Maturitätsgrafik ein und gibt so jedes Jahr eine Aussage über Trends im Requirements Engineering in der Schweiz.
Beim Betrachten der Trendwave 2015 für Requirements Engineering fällt auf, dass das Thema Requirements Engineering sich in der "Post-Maturiy" Phase befindet, heisst, dass es sich nicht lohnt Wissensaufbau in diesem Bereich zu betreiben. Begleitet wird dieses Thema von einem weiteren Thema, welches eng mit RE verbunden ist, nämlich Business Process Engineering. Schlägt man dann im T&B Report 2015 nach, sieht man, dass Requirements Engineering seinen Platz sucht.
RE wird nicht mehr als wichtig für den strategischen Erfolg gesehen und die Zufriedenheit mit den Tätigkeiten aus dem RE-Prozess liegt (über alle Tätigkeiten hinweg) bei unter 50 Prozent. Unternehmen investieren auch weniger in RE als im Vorjahr. Das Interview ist auch nicht mehr die beliebteste Technik zur Erhebung von Anforderungen. Beim Dokumentieren von Anforderungen ist die Use Case Spezifikation (UML) ebenfalls gefallen. Die Sprachschablonen werden lediglich von 14.2 Prozent der Befragten verwendet. Betrachtet man die Dokumentationstechniken in agilen Projekten, welche derzeit voll im Trend liegen, so kommt das Use Case Diagramm gerade mal auf 16 Prozent.
Aber reichen diese Statistiken um eine solche Aussage zu tätigen? Ich habe mich einer weiteren Quelle bedient. Es handelt sich um die wahrscheinlich mächtigste Quelle des Internets. Es geht natürlich um Google. Dabei wurde eine Auswertung zwischen dem Jahr 2004 und 2015 auf die Themen "Requirements Engineering" und "Business Analyse" gemacht. Die Auswertung bezog sich auf die Schweiz. Folgende Punkte sind mir ganz besonders aufgefallen:
- Nach dem Begriff "Requirements Engineering" wird nicht mehr gesucht als schon vor 10 Jahren. Im Vergleich dazu sind zum Beispiel die Suchanfragen nach "Design Thinking" oder "User Experience" sehr stark gestiegen.
- Bei der Suche nach Arbeitsstellen wurden die Begriffe "Product Owner" oder "Scrum Master" öfter verwendet.
- Die Suche nach dem Begriff "UML" geht seit 2005 zurück.
Beide Quellen scheinen auf das gleiche Ergebnis zu deuten. Klassisches RE ist im Jahr 2015 tatsächlich tot.
Warum ist das so?
Aber warum ist das so? Warum werden Interviews beim Erheben von Anforderungen nicht mehr so oft genutzt? Warum ist RE nicht mehr für den strategischen Erfolg von IT-Unternehmen wichtig?
- RE ist in Agile nicht genau beschrieben:
Guckt man sich die Aussagen über die Vorgehensmodelle im T&B Report an, stellt man fest, dass Agile die am meisten verwendete Vorgehensweise ist. Die Teams setzen dabei meistens Scrum ein. Der Wasserfall kommt noch hier und dort vor, ist jedoch nicht mehr so dominant. Bei Scrum ist das Thema RE nicht genau definiert. Die RE Tätigkeiten, sind zwar in Scrum vorhanden, wie Beat Bourquin in seinem Blogbeitrag beschreibt. Jedoch wird RE nicht explizit in Scrum erwähnt. - Klassisches RE führt zu viel Dokumentation:
Eins der vier Agile Manifesto Prinzipien heisst "Working software over comprehensive documentation". Im klassischen Requirements Engineering wird oft von Dokumentation der Anforderungen gesprochen. Diese zwei Denkweisen passen nicht immer zueinander. Im klassischen RE werden die Anforderungen dokumentiert und im Software-Lebenszyklus gepflegt. In der agilen Welt wird nur noch das nötigste dokumentiert. User Stories sind oft nur ein Arbeitsprodukt und werden nach der Umsetzung der Funktionalität nicht weitergepflegt. Vielleicht ist das klassische RE deshalb tot. - Klassisches RE wird oftmals als "Upfront Engineering" gesehen:
Wenn man im klassischen RE vom Anforderungen Erheben und Dokumentieren spricht, dann verstehen viele darunter, dass alle Anforderungen für die Software direkt zu Beginn des Projekts erhoben, dokumentiert und abgestimmt werden. In der agilen Welt ist dies nicht gewünscht. Der Trend geht hier weg von vollständigen Anforderungen und hin zur "Just-In-Time Specification", also zur Spezifikation der Anforderung, erst wenn diese auch implementiert wird, wie David Berger in seinem Blogbeitrag schildert.
Fazit
Es gibt sicherlich noch weitere Gründe für das Sterben des klassischen Requirements Engineering und diese Aussage gilt sicherlich auch nicht für alle Branchen. In stark regulierten Branchen wie zum Beispiel dem Medizinalbereich ist klassisches RE sehr wohl präsent. Für mich persönlich reichen jedoch die drei oben genannten Gründe für den Sargnagel des klassischen Requirements Engineering. Allerdings bin ich der Meinung, dass die Tätigkeiten und Aufgaben aus dem klassischen RE weiterhin benötigt werden und somit im Unternehmen präsent bleiben.
Diese werden in Zukunft lediglich anders bezeichnet werden. Der Blog-Beitrag "Die Rollen des PO, RE und BA im Vergleich" unterstreicht diese Behauptung. Fakt ist, dass der RE Markt sich in der Schweiz bereits jetzt in einer Veränderungsphase befindet und die Richtung noch nicht ganz definiert ist. Es zeichnet sich allerdings ein Trend in Richtung des agilen Requirements Engineering ab. Ich beobachte diese Entwicklung ganz gespannt und freue mich auf die anstehenden Herausforderungen.
Nun ist meine Analyse abgeschlossen und ich kann abschliessend mit gutem Recht sagen klassisches Requirements Engineering ist tot, lang lebe agiles Requirements Engineering!