Management-Zusammenfassung dieses Beitrags:
Der Requirements Engineer (mögliche Abkürzung: REeng) ist für die Entwicklung und Verwaltung von Anforderungen in Organisationen zuständig. Was dies konkret bedeuten kann, sollte für den jeweiligen Kontext genau definiert werden, wobei → Rollenbeschreibungen dabei helfen.
In diesem Beitrag werden die Aufgaben (und Rollen) des Requirements Engineers kurz beschrieben.
Die Darstellung in diesem Beitrag ist in erster Linie für Requirements Engineers geschrieben — es wird daher davon ausgegangen, dass Sie (als Leser) bereits Requirements Engineer sind oder werden möchten. Der Begriff Business Analyst wird dem Requirements Engineer gleichgesetzt.
1. Einleitung und Grundlagen
1.1 Definitionen
Im Lehrplan zum CPRE steht zum Requirements Engineer /→ IREB-24/:
“Requirements Engineer ist typischerweise keine Berufsbezeichnung, sondern eine Rolle, die Personen einnehmen, die:
- Als Teil ihrer Aufgaben Anforderungen ermitteln, dokumentieren, validieren und / oder verwalten.
- Über fundierte Kenntnisse im RE verfügen.
- Die Lücke zwischen dem → Problem und möglichen Lösungen überbrücken können.
In der Praxis agieren Business-Analysten, Anwendungsspezialisten, → Product Owner, Systemingenieure und sogar Entwickler in der Rolle eines Requirements Engineers.”
Schreib- und Sprechweisen:
In diesem Beitrag wie auch auf dieser Website wird durchgängig der Begriff “Requirements Engineer” benutzt. Folgende Synonyme finden sich in der Literatur und Praxis: Anforderungsingenieur, Systemanalytiker, Anforderungsanalytiker oder Anforderungsentwickler. Auf die Verwendung dieser Synonyme wird in diesem Beitrag verzichtet.
1.2 Das Persönlichkeitsprofil des Requirements Engineers
Bei Pohl /IREB21/ werden sieben → Soft Skills für Requirements Engineers benannt, die neben Methodenwissen und technischen Kenntnissen wichtig sind; diese werden zusammenfassend als Persönlichkeitsprofil bezeichnet (Abbildung 1.1).
Die Fähigkeiten im Einzelnen:
- Analytisches Denken
- Empathie
- Kommunikationsfähigkeit
- Konfliktlösungsfähigkeit
- Moderationsfähigkeit
- Selbstbewusstsein
- Überzeugungsfähigkeit
Abbildung 1.1: Das Persönlichkeitsprofil des Requirements Engineers (nach /IREB21/)
Entsprechend dem Persönlichkeitsprofil muss der Requirements Engineer ausgebildet oder geschult sein.
1.3 Der Requirements Engineer in agilen Projekten
Die Rolle des Requirements Engineers gibt es nicht in agilen Projekten: Die Aufgabe des Requirements Engineerings fällt dort dem Product Owner zu. Der Product Owner muss jedoch ähnlich wie der Requirements Engineer in klassischen Projekten arbeiten — daher sind die Rollenbeschreibungen für den Requirements Engineer auch für den Product Owner relevant.
2. Die Aufgaben des Requirements Engineers
Der Requirements Engineer agiert üblicherweise in Projekten. Daher gibt es Schnittstellen zu den verschiedenen Projektbeteiligten. Bei Hruschka /Hruschka19/ sind einige Projektbeteiligte benannt und ihre Aufgaben mit Bezug zum Requirements Engineer aufgeführt (Abbildung 2.1).
Abbildung 2.1: Die Aufgaben des Requirements Engineers im Projektkontext (nach /Hruschka19/)
In ähnlicher Form wie Hruschka beschreibt Wiegers den Austausch (mit Austauschinformationen) eines Business Analysten mit den Projektbeteiligten (Abbildung 2.2).
Abbildung 2.2: Die Aufgaben des Business Analysten im Projektkontext (nach /Wiegers13/)
2.1 Der Requirements Engineer und die Stakeholder
Bei Pohl /IREB21/ werden einige Rechte und Pflichten des Requirements Engineers benannt, die in einer “→ Stakeholder-Vereinbarung” festgehalten werden können. Dort steht:
“Der Requirements Engineer …
- spricht die Sprache der Stakeholder,
- arbeitet sich in das Fachgebiet gründlich ein,
- erstellt ein Anforderungsdokument,
- kann die Arbeitsergebnisse verständlich machen (z.B. mithilfe von Diagrammen oder Grafiken),
- pflegt einen respektvollen Umgang mit den Stakeholdern,
- präsentiert seine Ideen und Alternativen und deren Realisierung,
- ermöglicht es den Stakeholdern, Eigenschaften zu fordern (z.B. um das System einfach und benutzerfreundlicher zu machen),
- sorgt dafür, dass die Anforderungsspezifikationen des zu entwickelnden Systems den funktionalen und qualitativen Ansprüchen der Stakeholder gerecht wird.”
2.2 Der Requirements Engineer in klassischen Projekten
Der Requirements Engineer kann in Projekte involviert sein. Auch wenn die eigentliche Aufgabe des Requirements Engineer das Erfassen und nicht das Umsetzen der Anforderungen ist, so hat der Requirements Engineer in der Regel einen sehr guten Überblick über das von ihm bearbeitete Teilgebiet. Daher ist seine Mitarbeit in klassischen Projekten sinn- und wertvoll. Er nimmt dabei typischerweise folgende Rollen an:
- Experte: Aufgrund seiner Kenntnisse über das von ihm erarbeitete Fachgebiet, kann / muss der Requirements Engineer immer als Experte agieren und bei Bedarf seine Expertenmeinung
- Teilprojektmanager / ‑leiter: Es kann sein, dass der Requirements Engineer für die Umsetzung von Teilprojekten verantwortlich ist. Als Teilprojektmanager sollte er zumindest die Grundlagen des Projektmanagements kennen
- Technischer → Projektmanager / ‑leiter: Falls das Projekt groß ist und der Projektmanager stark mit der reinen Projektabwicklung beschäftigt ist, kann der Projektmanager auch als technischer Projektmanager fungieren. Ähnlich wie der Product Owner beim agilen Vorgehen, ist er dann Ansprechpartner für alle Produktthemen im Projekt. Der Projektmanager bleibt zwar gesamtverantwortlich, verlässt sich aber bei den Inhalten auf den technischen Projektmanager, der dem Projektmanager “zuarbeitet”
2.3 Der Requirements Engineer als treibende Kraft
Der Requirements Engineer ist für die Entwicklung und Verwaltung von Anforderungen zuständig — dies ist unstrittig. Damit ist aber nicht definiert, …
- woher die Zuteilung der zu betrachtenden Themenfelder kommt,
- wer der primäre Abnehmer und wer das Zielpublikum für die zu entwickelnden Anforderungen ist und
- inwieweit der Requirements Engineer aktiv seine Anforderungen zur Umsetzung bringen muss.
In der Theorie und Praxis finden sich hierzu unterschiedliche Auffassungen. In der Regel wird durch einen verantwortlichen Manager vorgegeben, welche Themenfelder / Teile eines Systems betrachtet werden sollen, um daraus die Anforderungen abzuleiten. Das Zielpublikum kann stark unterschiedlich sein, je nachdem, welche → Anforderungstypen betrachtet werden: Bei Lösungsanforderungen bilden die Lösungsumsetzer das Zielpublikum.
Der Requirements Engineer geht aktiv auf die Stakeholder zu, um so die an die Anforderungen zu gelangen (“→ Pull-→ Funktion”, linker Bereich in Abbildung 2.3). Welcher Stakeholder relevant für den Ermittlungsprozess sind, wird vorab mit dem Kunden / → Auftraggeber festgelegt. Doch was passiert, wenn ein Anforderungsbündel bereit für die Umsetzung ist? Entweder teilt dies der Requirements Engineer nur mit (“passives Verhalten mit Signalisierung”) oder er verteilt gezielt und aktiv die Anforderungen an die Umsetzer / Entwickler (“→ Push-Funktion”, rechter Bereich in Abbildung 2.3). Die zweite Sichtweise (aktive Rolle) überwiegt heute — gerade vor dem Hintergrund agiler Vorgehensweisen.
Abbildung 2.3: Der Requirements Engineer als treibende Kraft zwischen Kunden und Entwickler
3. Häufig gestellte Fragen und Antworten (FAQ) zum Requirements Engineer
Einige Fragen zum Requirements Engineer werden häufig gestellt – diese werden hier wiedergegeben und beantwortet.
- F: Muss der Requirements Engineer eine (formale) Ausbildung haben?
A: Ja und nein. Auch wenn es ohne “formale” Ausbildung möglich ist, Anforderungen zu entwickeln (und zu verwalten), so hilft eine Ausbildung dabei, die “richtigen” Anforderungen “richtig” zu entwickeln. - F: Muss es in jedem Projekt einen oder mehrere Requirements Engineers geben?
A: Ja — auch wenn diese Rolle vielfach durch andere Rollen mit ausgeführt wird. - F: Kann der Requirements Engineers in einem Projekt auch gleichzeitig der Projektmanager sein?
A: Ja. Aber dies sollte vermieden werden, da dann eine Kontrollinstanz fehlt.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
A.1 Meine öffentliche Präsentation zum Requirements Engineer
Die Aufgaben des Requirements Engineers werden in der Präsentation zum → Requirements Engineering beschrieben.
| Inhalt | Typ |
|---|---|
| Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | 
|
A.2 Literatur
- /IREB21/ siehe /Pohl21/
- /Hruschka19/ Peter Hruschka: → Business Analysis und Requirements Engineering: Prozesse und Produkte nachhaltig verbessern, Hanser, München 2. Auflage 2019, ISBN 978–3‑446–45589‑4
- /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-→ Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 5. Auflage 2021, ISBN 978–3‑86490–814‑9
- /Rupp20/ Chris Rupp: Requirements-Engineering und ‑Management. Das Handbuch für Anforderungen in jeder Situation, Hanser, München 7. Auflage 2020, ISBN 978–3‑446–45587‑0
- /Wiegers13/ Karl E. Wiegers, Joy Beatty: Software Requirements, Microsoft Press, Redmond, Washington 3rd Edition 2013, ISBN 978–0‑7356–7966‑5
A.3 Weblinks
- /IREB/ IREB – International Requirements Engineering Board: Website (deutsche Fassung)
- /IREB-24/, /#IREB-24/, /#IREB-CPRE-FL-24/ IREB – International Requirements Engineering Board: Lehrplan / Syllabus zum CPRE-FL, Version 3.2.0 vom Februar 2024 (deutsch, pdf-Datei, 51 Seiten)
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 22.08.2021 © Peterjohann Consulting, 2005–2024
