Requirements Engineering ist nicht sexy


Christoph Wolf, Principal Consultant

„Requirements Engineering ist nicht sexy“. Das war ein der Aussage, die ich bei einer Umfrage unter RE-Verantwortlichen von verschiedenen Firmen bekommen habe. Als passionierter Requirements Engineer war ich natürlich zuerst einmal empört über diese Aussage. Nach einigem Nachdenken musste ich dann aber zugeben, dass dies doch nicht so falsch ist. Warum ist das so und was kann man dagegen tun?

RE ist nicht sexy – wieso?

In SW-Entwicklungsprojekten geben Produktmanager oder Produkt Owner vor, was implementiert werden soll. Projektleiter steuern das Projekt. Entwickler sind sowieso cool, vor allem wenn sie objektorientiert programmieren und/oder in einem agilen Team sind. Alle diese Rollen werden als sexyer angesehen als REs. Und Tester … OK, Testing wird wohl als noch weniger sexy angesehen als RE (das dürfen meine Test-Kollegen gerne kommentieren).
In der Tat hat das Ansehen von RE in der letzten Zeit abgenommen. Im Vergleich zu 2014 ist in unserem neuesten Trends & Benchmark-Report die Zustimmung zur Aussage „RE ist für den Erfolg der Organisation strategisch“ stark von über 50% auf 14% gefallen. Dagegen ist die Zustimmung zu „RE ist ein wichtiger Faktor um verlässliche Software zu produzieren“ von 20% auf 50% gestiegen . Das hört sich immer noch OK an – aber sexy?

Ansehen von Requirements Engineering Tätigkeiten

In agilen Projekten muss der RE oft um seine Daseinsberechtigung kämpfen. Man ist ja ein Team und da braucht es keine speziellen Rollen (Tester sind davon auch betroffen, aber etwas weniger). Wenn der RE Glück hat, darf er noch Proxy-PO für den vielbeschäftigten Produktmanager spielen. Dabei muss er bei Entscheidungen aber immer rückfragen, was nicht gerade sein Ansehen stärkt.

Irgendwie hat ja schon jeder im Projekt das Gefühl, dass der RE einen wichtigen Beitrag zum Projekterfolg leistet. Aber können wir das auch beweisen? Man kann für RE relevante KPIs definieren. Aber auf die für das Management entscheidende Frage fällt es zumindest mir schwer, eine Antwort zu geben: „Um wieviel sind die Einsparungen durch professionelles Requirements Engineering höher als die Kosten, die es verursacht?“ Also, was kann mal also sonst machen?

Und was kann man tun?

Eine Antwort ist, dass Profil zu schärfen: Dazu gehört, die Rolle des Requirements Engineers klar zu definieren. Dabei ist insbesondere die Abgrenzungen zu anderen Rollen im Projekt deutlich darzustellen. Das heisst nicht, dass der RE nicht auch andere Aufgaben übernehmen darf, z.B. mit zu testen. Aber es muss klar sein, was zu seinem Kernaufgabengebiet gehört und was nicht.

Ausserdem gilt: „Tue Gutes und sprich darüber“. Viele RE-Organisationen sind noch zu defensiv, wenn es um Selbstmarketing geht. Die eigene Leistung und Erfolge herauszustellen hat nichts mit Überheblichkeit zu tun, sondern ist ein wichtiges Mittel, um Akzeptanz im Unternehmen zu erreichen. Ein monatliches Newsletter ist OK, wird aber oft nicht gelesen. Etwas besser ist es, ab und zu in Management-Meetings die vergangenen Highlights zu präsentieren. In einer Roadshow wichtigen Stakeholder (z.B. Produktmanager, Architekten, Testmanager) darzustellen, welche Dienstleistungen man anbietet, wie die Prozesse aussehen und was man von ihnen erwartet, hilft, die Akzeptanz der eigenen Arbeit zu steigern.

Weiterhin ist es wichtig, laufend zu reflektieren, ob die Dienstleistungen, die wir als RE anbieten, noch angemessen sind. Wenn sich das Unternehmen z.B. in Richtung Agilität entwickelt, kann eine Facilitator-Rolle in den Teams nötig werden. Diese kann durch kommunikative REs gut gefüllt werden. Gibt es im Unternehmen schon jemand, der sich mit Usability beschäftigt? Wenn nicht, kann ein RE sich weiterbilden und diese Rolle abdecken.

Ein scharfes Profil, ein gesundes Selbstmarketing und die Reflektion der eigenen Tätigkeit können also einen wertvollen Beitrag dazu leisten, dass Requirements Engineering in Zukunft als ein bisschen sexyer angesehen wird.

Weitere Informationen, Ideen und Anregungen zu Requirements Engineering

The Business Analysis Center of Excellence, Requirements Engineering Magazine 2015-3, IREB

Beratung anfragen

2 thoughts on “Requirements Engineering ist nicht sexy”


  • tp@thomit.com' Thomas Prosser sagt:

    Ich halte Requirements Engineering vor allem für eine buchhalterische Tätigkeit, die der Business Analyse angehängt ist. Als solches ist RE weniger eine Rolle, sondern ein Skillset, dass es erleichtert, Anforderungen in ein grosses Ganzes so einzuordnen, dass funktionierende Software damit entsteht. Aus dieser Perspektive erstaunen auch die Umfrageergebnisse nicht besonders (was heisst: „ist für die Organisation strategisch?“, strategisch wichtig, oder ist der Entscheid, RE zu betreiben, strategisch? Wohl keines von beiden). Strategische Entscheide betreffen meist die Ausrichtung am jeweiligen Markt und an der Konkurrenz. Damit spielen Business Prozesse und deren Umsetzung eine sehr grosse Rolle. Diese Prozesse gilt es zu verstehen. Das tut der BA. Wenn sie dann in Software gegossen werden sollen, so müssen die Anforderungen dazu konzise formuliert werden. Bislang ist mir nicht recht klar, wieso das nicht auch der BA tun kann. Anforderungen verwalten ist mit den heute üblichen Tools ja dann auch nicht mehr so schwer. So gesehen verwässert sich das Rollenbild RE halt ziemlich – und ist damit auch nicht besonders sexy. Das hat aus meiner Sicht mit strukturellen Missverständnissen gegenüber der Tätigkeit zu tun. Nicht so sehr mit mangelndem Selbstverständnis / -Marketing

    • Christoph Wolf sagt:

      Vielen Dank für den Kommentar. Über die Abgrenzung von Business Analyse und Requirements Engineering kann man sicherlich lange diskutieren, da es viele Meinungen dazu gibt. Ich sehe RE nicht als buchhalterische Tätigkeit. Dies trifft auf Requirements Management zu. Wenn Sie also RE rein auf diese Verwaltung von Anforderungen reduzieren gebe ich ihnen recht.

      Aber zu RE gehören meiner Meinung nach und wie auch vom IREB propagiert z.B. auch die Erhebung und Abstimmung von Anforderungen. Hierbei gibt es eine enge Zusammenarbeit zwischen dem Requirements Engineer und Business. Dabei darf der Requirements Engineer durchaus auch Business herausfordern, ob gewisse Anforderungen wirklich Business Value bringen, und Alternativen darstellen – und damit seinen Beitrag zu einer erfolgreichen Geschäftsentwicklung leisten. Dies ist auch, wie ich finde, der spannendste Teil von RE. Und nicht die Verwaltung von Anforderungen.

Schreibe einen Kommentar