Klassisches RE ist tot


SwissQ,

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 2015 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 klassisches 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:

Klassische Anforderungstätigkeiten

  • 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 „klassisches 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.

TB2015_Cover_Online

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.

SQ_TB_2015_Investitionen_im_RE

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.

UML Grafik

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!

Beratung anfragen

10 thoughts on “Klassisches RE ist tot”


  • nuria.izard@gmx.net' Nuria Izard sagt:

    Lieber Anton, das ist ein sehr interessanter Blogeintrag, den du da geschrieben hast. Ich bin allerdings nicht ganz der gleichen Meinung, beziehungsweise ich denke, dass dieser Trend, den du da feststellst, sich wieder umkehren wird. Tatsächlich produziert klassisches RE viel Papier, aber das tut auch PRINCE2, um nur ein Beispiel zu nennen unter den modernen trendigen Projektmethoden. Es kann schon sein, dass die Menschen heutzutage nicht mehr willens (oder nicht mehr in der Lage?) sind, so viel zu lesen. Und trotzdem – was nicht aufgeschrieben wird, kann man nicht nachprüfen.
    In der heutigen Welt werden viele Häppchen News an die Leute gebracht (siehe z.B den Erfolg von 20 Minuten), und das macht meines Erachtens faul und nervös zugleich. Die Leute, die solche Gratiszeitungen lesen, sind nur sehr oberflächlich informiert. Jedoch haben sie sich abgewöhnt, längere Artikel zu lesen, und das finde ich fatal. In der Arbeitswelt begegnet man dann ebenfalls vielen solchen Leuten. Sie wollen sich nicht tiefer mit der Materie befassen. Gleichzeitig wird die Software, die sie bestellen, immer komplexer.
    Wenn man das Bauen solcher Software nicht seriös angeht, wird es teuer und braucht mehr Zeit.
    Agile Methoden sind gut, aber nur für die Kommunikation zwischen BA oder RE und Programmierer. Zwischen user und RE braucht es meines Erachtens immer noch ein strukturiertes Vorgehen mit solider Dokumentation. Sonst ist das zum Schluss so eine Zeitverschwendung wie eine Sitzung ohne Protokoll – nett, dass wir miteinander geredet haben. Aber was genau beschlossen wurde, weiss nach einer Woche niemand mehr. Und es steht auch nirgends.

    • Anton Podokschik sagt:

      Hallo Nuria,

      vielen Dank für Deinen Kommentar.
      Mit der Feststellung, dass Menschen heutzutage schwergewichtige Dokumentation nicht mehr akzeptieren (bzw. verkraften), hast Du natürlich Recht. Das stellt eine grosse (aber auch interessante) Herausforderung für REs dar. Ich selbst stelle fest, dass das Ausweichen auf UML (kondensierte Darstellung von Requirements) auch nicht immer zielführend ist, da den Lesern das Know-How fehlt. Vielleicht wird es in wenigen Jahren eine neue Dokumentationsform geben (Video, oder Visualisierung).
      Es benötigt auf jeden Fall Dokumentation, zum Beispiel als Diskussionsgrundlage, aber auch für Traceability. Es spielt dabei keine Rolle, ob nach Scrum, Kanban oder Wasserfall vorgegangen wird. Wieviel genug ist (Wegwerfprodukt vs nachhaltige Dokumentation), ist natürlich eine andere Frage. Auch diese Herausforderung wird die RE Welt meiner Meinung nach zum Positiven verändern.

  • Andreas.Hsu@sanitas.com' Andreas Hsu sagt:

    Hallo Nuria und Anton
    Ja, das Thema ist auch bei uns sehr wesentlich, wenn man über Kosteneinsparungen sprechen möchte. Ihr habt, aus der Sicht meiner täglichen Arbeit, beide recht. Für meinen Teil nehme ich 2 Dinge für mit:
    * „Just-In-Time Specification“ beginnt auch bei uns „Klassisches RE“ abzulösen. Abgesehen von den Nachteilen, welche sich aus der damit einhergehenden mangelhaften Dokumentation der Anforderung ergeben, sehe ich dabei auch viel Positives: Tatsächlich kann (könnte) durch den zu diesem Zeitpunkt schon gestarteten Dialog zwischen Entwickler und BA/RE präziser formuliert werden, was essentielle und was kritische Punkte sind. Denn erst dann weiss man genauer, wie viel Zeit wirklich noch zur Verfügung stehen wird und deshalb auch, an welchen Enden Kompromisse (mehr Features versus Termin) gemacht werden können oder müssen. Die Dokumentation – wenn sie denn geschrieben wird – ist dadurch kürzer und meist besser. Der Abwärts-Trend punkto Sprachkultur betrifft dabei leider fast alle von uns, verheerend … und ebenso unvermeidlich in der heutigen Arbeitswelt.
    * Das von Nuria erwähnte strukturierte Vorgehen braucht es auch zwischen BA/RE und Programmierer, aber in neuer Ausprägung: Im agilen Prozess darf nicht vergessen gehen, gerade auch „Just-In-Time“-Anforderungen“ auf Readiness zu testen, bevor sie in die Umsetzung gehen. Und: Die „Just-In-Time“-Dokumentation muss, gerade weil sie so kurz vor der Umsetzung geschrieben wird, unbedingt erwähnen, was denn alles im Test erfüllt sein soll, damit eine Umsetzung genügt.
    Besten Dank für Euren Input.

    • Anton Podokschik sagt:

      Hallo Andreas,

      ich finde Deinen Ansatz sehr spannend. Tatsächlich versuchen wir in meinem laufenden Projekt in der QA Abteilung genau dies umzusetzen. Die Anforderung sollte stärker auf Testbarkeit geprüft werden, vor allem weil sie „Just-In-Time“ geschrieben wird. Nur so können wir die Qualität der Anforderungen aufrechterhalten bzw. sicherstellen.

  • Danke für die interessanten Einsichten. Bei dem Hype um das Wort agil besteht die Gefahr, dass Requirements Engineering fälschlich als nicht mehr so wichtig angesehen wird. Dabei sind die Anforderungen das wichtigste Fundament jeder Applikation. Das ändert auch nicht, wenn man sie nur noch App nennt oder aus der Cloud bezieht. Das, was beim klassischen RE tot ist, ist das verstaubte Abstrakte daran. Und die Erkenntnis, dass sich die Informatik längst vom Ingenieur (Engineer) emanzipiert hat.

    • Anton Podokschik sagt:

      Hallo Frau Ilsanker,

      vielen Dank für Ihren Kommentar. Natürlich gebe ich Ihnen Recht. Mir als Requirements Engineer liegt es ganz besonders am Herzen die Anforderungen qualitativ erhoben, dokumentiert und spezifiziert werden. Das wird sich wohl auch nicht bei der agilen Vorgehensweise ändern. Ich glaube jedoch, dass die IT derzeit versucht die Disziplin RE in die agile Softwareentwicklung hinein zu flanschen. Dadurch wird, wie sie sagen, das „Verstaubten“ in der RE Disziplin auf Dauer wohl abgelegt werden. Ich hoffe, dass Requirements Engineering aus diesem Prozess in einer besseren Form kommt, quasi neu aufsteigen wird, wie der Phönix aus der Asche eben.

  • Das Titel hat mich sofort geschockt und ich habe mich sofort gefragt, wo stehen wir da. Meiner Ansicht nach wird zuviel Gewicht auf die Namensgebung gegeben. Wenn man eine Maschine entwickelt, die während 10-15 Jahre ständing erweitert, verbessert werden muss, kann man nicht ständing auf die Prozessänderungen rücksicht nehmen. Wenn man für sich einen Prozess definiert hat, womit POs und Entwickler einig sein werden, was genau gemacht werden muss und wie, interessiert sich „niemand“ wirklich, ob es klassische RE oder Agiles oder … ist. Es ist so oder so meistens eine Mischung von allen. Berater Aussagen wie „Was ihr macht is nicht RE sondern Function Description“ interessiert niemandem, ausser die Person, die dafür bezahlt worden ist, eine solche Aussage zu machen.

    Ich kann mich vorstellen, das verschiedenen Firmen in einer ähnlichen Lage sind und nicht genau wissen, wo sie stehen. In unserer Firma ist RE sicher immer als wichtig betrachtet. Es ist aber einfach Teil vom „Daily Business“ geworden und so redet man inzwischen viel weniger darüber, als man vor Jahren einen passende Prozess für unsere Entwicklung gesucht haben.

    • Anton Podokschik sagt:

      Hallo Jacques,

      RE wird sicherlich nicht aus dem Softwareengineering verschwinden. Wie bereits in meinen früheren Kommentaren erwähnt sucht sich das Requirements Engineering einen neuen Platz in der agilen Softwareentwicklungswelt. Es entwickelt sich also weiter, wie die von Dir erwähnte Maschine. Ich finde schon, dass man auf Prozessänderungen Rücksicht nehmen muss. Dies macht die Requirements Engineering Community nun, indem sie versucht dem RE eine neue „Bleibe“ zu geben. Meiner Meinung nach wird RE weiterhin in den Unternehmen bestehen bleiben. Sobald die Community einen neuen (mit Agile vereinbaren) Ort für das Requirements Engineering gefunden hat, wird die Disziplin auch wieder wachsen.

  • alex.loetscher@finnova.com' Alex Lötscher sagt:

    RE ist tot – es lebe RE

    Die Frage ist bloss: Steht das zweite RE für Requirements Engineering oder für Reverse Engineering? Denn letzteres blüht in einigen Jahren denen, die heute das Agile Manifest dahingehend deuten, dass es zum Non-Engineering der Anforderungen legitimiere. Ich denke eher, dass RE als Disziplin einem Lebenszyklus unterworfen ist wie jede andere Disziplin auch. Und ich meine dabei Zyklus. Nicht einmal rum und tot. Mehr die gute alte Cosinus-Kurve. Klassisches RE scheint aktuell tatsächlich auf dem absteigenden Ast, wurde einige Jahre schwer gewichtet, hatte eine hohe Ressourcenallokation ohne die ROI-Erwartungen wirklich erfüllen zu können und geriet damit in Misskredit.

    Ich denke aber auch, dass die Gründe für die verfehlten Erwartungen weniger darin zu suchen sind, dass RE (das systematische Erforschen, Fixieren, Prüfen und Verwalten von Anforderungen) keine notwendige Disziplin in der Softwareentwicklung ist. Fail Fast heisst doch eine wichtige Devise der Agilität und Anforderungen stehen nun mal in den meisten Prozessen ziemlich weit links. Vielmehr fehlten wohl die richtigen Werkzeuge, um die Ergebnisse des RE lesbar und nutzbar an die nach folgenden Disziplinen zu übergeben. Waren auf der einen Seite die grafisch orientierten Methoden (UML, BPMS, …) nur für RE-Nerds lesbar und wurden auf der anderen Seite die textuellen und matrix-orientierten Verwaltungstools eher von Bibliothekaren geliebt.

    Ist deshalb RE überflüssig? Kaum! Ist RE tot? Ich würde sagen: Etwa so tot wie Schneewittchen. Wer also die zündende Idee hat, wie die Anforderungen von morgen vom Requirements Engineer bis zum Release Manager für alle lesbar, nutzbar und akzeptabel gefunden, festgehalten, geprüft und verwaltet werden können, der sei eingeladen, die Wiedergeburt des RE einzuleiten.

    • Anton Podokschik sagt:

      Hallo Alex,

      wow, was für eine tolle Aussage. Der Aspekt der Lesbarkeit für alle Stakeholder (von RE bis Release Manager) ist eine sehr wichtige Komponente bei der Definition des Requirements Engineering. Ich freue mich auf diese spannende Aufgabe, welche die Requirements Engineering Community in der Schweiz sicherlich vor eine grosse Herausforderung stellt. Umso mehr, wenn man sich das Thema Tooling im Softwareentwicklungsbereich anguckt. Die Tool-Landschaft verändert sich ständig. Das ist auch im Trends & Benchmarks Report 2015 (Link: http://report.swissq.it/de/) gut zu erkennen. Weiterhin versucht die SwissQ ebenfalls die Rolle des RE für die Zukunft zu definieren. Hierzu kannst Du unser Plakat (Link: http://swissq-1.hs-sites.com/agile-re-poster-order) für das agile Requirements Engineering herunterladen.

Schreibe einen Kommentar