Häufig gibt es in Unternehmen keine dedizierte Rolle „Requirements Engineer“. Dafür aber Projektmanager / Projektleiter, Product Owner, Business Analysten, Entwickler, Tester etc.
Tatsächlich ist es so, dass alle diese Rollen mit unterschiedlicher Intensität Requirements Engineering betreiben. Und folglich das Handwerkszeug des Requirements Engineerings beherrschen sollten.

Im Scrum haben wir den Product Owner, der den wirtschaftlichen Erfolg des Scrum Teams verantwortet und „Herrscher“ über das Product Backlog ist. Zumindest der Scrum Guide erläutert jedoch nicht, wie das Product Backlog initial entsteht. Was muss ich als Product Owner tun vor dem ersten Sprint? Requirements Engineering! Denn der Product Owner

  • führt eine Stakeholderanalyse durch
  • lernt die Sprache des Kunden (Domänenklassenmodell -> Statische Perspektive)
  • lernt die Soll-/ oder Ist-Abläufe des Kunden kennen (Ablaufdiagramme -> Funktionale Perspektive)
  • dokumentiert sein Wissen (soweit erforderlich)
  • Vermittelt sein Wissen in Workshops (Grooming Sessions, Sprint Planning)
  • Sammelt das Feedback des Kunden ein und lässt die Erkenntnisse  in neue Product Backlog Einträge einfließen
  • Sammelt die Ideen des Scrumteams ein bzw. sortiert und bewertet diese
  • etc.

All dieses Wissen muss ich als Product Owner meinem Developer Team vermitteln.  Diese Kernaufgabe impliziert, dass der Product Owner auch ein Requirements Engineer ist – nicht der einzige, aber der wichtigste im Scrum Team.