Agiles Requirements Engineering (RE)

Anforderungsmanagement bzw. Requirements Engineering beschreibt “das ingenieurmäßige Festlegen der Anforderungen an ein System; in der Systemanalyse auf computergestützte (Computersystem) betriebliche Informationssysteme bezogen, im Software Engineering auf Softwareprodukte.” (Gabler Wirtschaftslexikon)

Eine Managementdisziplin also, die als agiles Requirements Engineering stets dort gefragt ist, wo komplexe Systeme in stark arbeitsteiligen Prozessen entwickelt werden.

Zu den Hauptaufgaben des Requirements Engineerings gehört anhand der Darstellung zuerst einmal das Ermitteln des jeweiligen Anforderungsprofiles – auch Anforderungsanalyse genannt. Weiterführend werden diese ermittelten Anforderungen dokumentiert. Agiles Requirements Engineering fordert in diesem Kontext, dass eine aktive Wissensvermittlung an das Team erfolgt. Beim Prüfen und Abstimmen der Anforderungen muss seitens des RE die Richtigkeit der Anforderungen plausibel und schlüssig nachgewiesen werden. Als letzte Kerntätigkeit beschreiben Chris Rupp und die SOPHISTen (2014, S. 14) das Verwalten der Anforderungen. Somit werden diesem Aspekt auch Teile des Risikomanagements beigemessen.

Ramesh et al. (2010, S. 456) stellen fest, dass in Zeiten, in denen Technologien schnell wechseln und sich weiterentwickeln, die Anforderungen immer komplexer werden sowie eindeutige Zeitprobleme vorherrschen, agile RE Praktiken gefragt sind.  Durch häufigere Tests und Überprüfungen, ständige persönliche Kommunikation mit den Entwicklern, extreme Priorisierung ergeben sich komplexe Herausforderungen auf die aktuell keine Antworten gefunden werden.

So liefern diese einem ersten Ansatz für die Integration von RE in Scrum eine Alternative. Das Prinzip kann nach vor, während oder nach dem Sprint integriert werden. So kann während der Entwicklung das Problem der Uncertainty genau beobachtet werden und eine genauere, aktuellere Aussage über die Realisierbarkeit der Zielsetzung getroffen werden. Damit ist die Möglichkeit einer zeitnahen, zielgerichteten Anpassung der Anforderungen gegeben. Eine genaue Anwendung ist aktuell noch nicht in der Literatur zu finden und wird derzeit in Fallstudien evaluiert.

Die Geschichte von Requirements Engineering

Requirements Engineering ist eine noch sehr junge Disziplin und wurde zum ersten mal 1993 in der ICRE Konferenz ernsthaft erwähnt. Mit der Entstehung von UML wurde es zum ersten mal im Feature-Driven Development und später dann im Rational Unified Process von IBM verwendet. Seit 2006 befasst sich die IREB mit der Professionalisierung von Requirements Engineering und seit 2013 findet man viele Publikationen zum Thema agiles Requirements Engineering.

Requirements Engineering im Scrum Prozess

Aber wie sieht nun modernes und agiles RE genau aus? Wie wir bereits wissen, vereint Scrum und Agilität alles in einem Prozess. Es stellt sich daher die Frage, ob man in diesem Fall überhaupt noch von RE im klassischen Sinne sprechen kann. Wenn wir uns ansehen wie Scrum eigentlich aussieht – Baumgärnter et al (2013, S. 3) liefern hierzu eine schöne Abbildung – merken wir schnell, dass aus der Position des „Requirements Engineers“ nun die Rolle des Requirements Engineers wird. Dieser ist also weiterhin ein elementarer Bestandteil des Prozesses.

Die Rolle des RE

Allerdings verändert sich das Rollenverständnis des RE. Der Requirements Engineer ist nun auch ein Manager innerhalb des Prozesses. Neben seinen üblichen Aufgaben plant dieser nun mehr als früher und wechselt ständig zwischen beiden Rollen hin und her. Wie jede Rolle bekommt der RE nun mehr Verantwortung und dadurch mehr Chancen und Möglichkeiten sich einzubringen.

Schauen wir eine Ebene nach oben und stellen uns die Frage, wo der Requirements Engineer im Prozess zu finden ist. In modernen Prozessen wird er oft durch den Product Owner abgelöst, in größeren Projekten und Organisationen gibt es ihn aber durchaus noch. Der RE ist dann als Fachabteilung oder einzelne Person parallel zum Product Owner zu finden.

Agiles Requirements Engineering im Projektverlauf

Wie funktioniert das Ganze nun in der Praxis? Wenn wir den Verlauf eines Projektes betrachten, erkennen wir, dass normalerweise gerade zu Beginn viele Requirements-Engineers benötigt werden, deren Notwendigkeit im Projektverlauf signifikant abnimmt. In ersten Interviews bemerken wir allerdings, dass eine gleiche Verteilung der Requirements Engineers über den Projektverlauf  angestrebt werden sollte und das normale Vorgehen nicht optimal ist.  So schätzen mittlerweile die Requirements Engineers ebenfalls den Spezifikationsaufwand, planen bereits größere Features zu Beginn als Epics vor und sorgen daher für die Möglichkeit zu flexiblen Änderungen selbiger. Auch evaluieren die REs bereits zu Beginn die Software mit dem Kunden und bleiben diesem Prozess bis zum Ende treu. So habe ich im Laufe der Beobachtung eine gleiche Verteilung der Disziplin des Requirements Engineering erlebt.

Tipps für den product Owner

Viele RE’ler werden gerne zum Product Owner gemacht. Doch dies ist ein Unterschied zum Product Owner. Doch was tut der so? Dazu habe ich im Blog von Boris Gloger eine Definition gefunden:

Die Rolle des Product Owner ist vielleicht die einfachste Rolle und doch auch jene, die von vielen vollkommen missverstanden wird. Der Product Owner ist Teil des Scrum-Teams. Er arbeitet mit dem Scrum-Team. Das heißt: Er ist kein Anforderer, der etwas vom Team bauen lässt, sondern ein integraler Teil. Er hat eine spezielle Sicht auf die gemeinsame Arbeit. Er will, dass das Scrum-Team möglichst nur das liefert, was auch wertvoll ist – also vom Kunden gekauft werden wird. Für mehr Informationen können Sie in das Buch von Boris Gloger zu Scrum schauen.

Doch was kann ein guter Product Owner? Ich habe ein paar Beispiele des Charakters auf verschiedenen Internetseiten zusammengesucht und zähle diese hier auf:

• vertritt die Produktvision
• trifft Entscheidungen
• kennt Businessmodelle
• teilt Erfahrungen
• Kommunikationsstark
• lebt Agilität vor
• versteht das Produkt
• ist für das Team da
• kann Nein sagen
• ist ein Entrepreneur

Genderhinweis: Seit Anfang 2022 achte ich darauf, dass ich immer genderneutrale Formulierungen verwende. Vor 2022 habe ich zur leichteren Lesbarkeit die männliche Form verwendet. Sofern keine explizite Unterscheidung getroffen wird, sind daher stets sowohl Frauen, Diverse als auch Männer sowie Menschen jeder Herkunft und Nation gemeint. Lesen Sie mehr dazu.

Rechtschreibung: Ich führe diesem Blog neben dem Job und schreibe viele Artikel in Bahn/Flugzeug oder nach Feierabend. Ich möchte meine Gedanken und Ansätze als Empfehlungen gerne teilen. Es befinden sich oftmals Tippfehler in den Artikeln und ich bitte um Entschuldigung, dass ich nicht alle korrigieren kann. Aber Sie können mir helfen: Sollten Sie Fehler finden, schreiben Sie mich gerne an! Lesen Sie mehr dazu.

Helfen Sie meinem Blog, vernetzen Sie sich oder arbeiten Sie mit mir

Ich suche aktuell außerdem Werbepartner für Bannerwerbung für meinen Blog. Sollte es für Sie spannend sein Fachkräfte oder Kunden auf Ihre Seite zu leiten, dann bekommen Sie mehr Informationen hier.

Tipp: Ich vergebe auch über den Blog eine gratis Zertifizierung zum Digital & Agile Practioner!

Vernetzen Sie sich in jedem Fall auf Xing oder LinkedIn oder kontaktieren Sie mich direkt für einen Austausch, wenn Sie gleich mit mir ins Gespräch kommen wollen. Werfen Sie auch einen Blick in meine Buchvorschläge zur Digitalisierung, vielleicht wollen Sie mir auch ein Buch empfehlen?

Ich arbeite gerne mit Unternehmen zusammen. Sie können mich ebenfalls gerne bezüglich folgender Punkte anfragen:

• Sehen Sie übersichtlich alle Möglichkeiten zur Zusammenarbeit
• Halten von Vorträgen zu Arbeit, Führung und Agilität
• Veröffentlichung von Gastartikeln
• Content Marketing & Texterstellung
• Workshops und Seminare
• Softwareentwicklung für Unternehmen
• Whitepaper für B2B Leads
• IT-Administation AWS, Kubernetes, Ansible, Cloud und Terraform
• Public Relations (PR) für Unternehmen
• Influencer Marketing
• Whitepaper für B2B Leads

Verwendete Quellen anzeigen