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.

agiles requirements engineering
Die Hauptkriterien von Requirements Engineering (eigene Darstellung auf Basis der Idee von Chris Rupp und die SOPHISTen)

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.

Agile-Anforderungsmanagement-2
Komplexere Anforderungen bedingen agile RE Pratiken, die zu mannigfaltigen Herausforderungen führen. Schaubild: Ramesh et al. (2010, S. 456)

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.

agile anforderungsanalyse scrum
Integration von RE in Scrum (eigene Darstellung aber inspiritiert durch Chris Rupp und die SOPHISTen)
Die Darstellung inspiriert von Chris Rupp und die SOPHISTen (2014, S. 62) verdeutlicht den Ansatz der Integration von RE in Scrum.

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

timeline-agilitaet
Eigene Darstellung basierend auf einigen Google Recherchen.

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

agile requirementsengineering
Idee von Scrum: ein Prozess über alles (eigene Darstellung auf Basis der Idee von Baumgärtner)

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.

agile re
Aufgaben des Requirements-Engineer (Inhalt eigene Darstellung und Idee aus Baumgartner et al 2013, S. 101)

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.

agile re anforderung
Die Notwendigkeit im Projektverlauf, wie es nicht sein sollte (Eigene Abbildung aber inspiriert von Baumgartner et al. 2013, S. 78)

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: Ich habe 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.

Falls es noch Fragen gibt, können Sie mich gerne anrufen. Hierzu einfach im Buchungssystem nach einen freien Termin schauen. Ich nehme mir jeden Monat einige Stunden Zeit um mit Lesern zu interagieren.

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

Sie haben eigene, interessante Gedanken rund um die Themenwelt des Blogs und möchten diese in einem Gastartikel auf meinem Blog teilen? – Aber gerne! Sie können dadurch Kunden und Fachkräfte ansprechen.

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.

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:



Verwendete Quellen anzeigen

Baumgartner, M., Klonk, M., Pichler, H., Seidl, R., & Tanczos, S. (2013). Agile Testing. München: Hanser Verlag.

Ramesh, B., Cao, L., & Baskerville, R. (2010). Agile Requirements Engineering Practices and Challenges: an Empirical Study. Information Systems Journal, 20(5), 449–480. http://doi.org/10.1111/j.1365-2575.2007.00259.x

Rupp, C. (2014). Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil. München: Hanser Verlag.

Avatar
Autor

Externer Doktorand an der Universität Erlangen-Nürnberg am Lehrstuhl für IT-Management. Ich untersuche wie sinnvoll skalierte Agilität im Zuge des digitalen Wandels zur Zukunftsfähigkeit von Unternehmen beitragen kann. Neben der Promotion arbeite ich Vollzeit in einem Unternehmen.

Durch die weitere Nutzung der Seite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen