Ein Requirements Engineer ermittelt, dokumentiert, prüft und verwaltet Anforderungen an ein System. Die Arbeit schafft ein gemeinsames Verständnis darüber, was gebraucht wird und wie sich eine passende Lösung überprüfen lässt.
Wenn alle zustimmen und trotzdem etwas anderes meinen
„Die Anwendung muss einfach zu bedienen sein.“ Das klingt vernünftig. Für die Entwicklung ist aber noch unklar, wer sie verwendet, für welche Aufgaben und unter welchen Bedingungen. Eine erfahrene Sachbearbeiterin hat andere Bedürfnisse als jemand, der das System einmal im Jahr öffnet. Genau solche Unterschiede müssen sichtbar werden.
Requirements Engineering verbindet sorgfältiges Zuhören mit präziser Sprache. Du arbeitest mit Fachbereichen, Nutzenden, Entwicklung und Test zusammen. Dabei geht es nicht darum, jede Unsicherheit sofort zu beseitigen. Es geht darum, Unsicherheiten zu benennen und so zu bearbeiten, dass das Team begründete Entscheidungen treffen kann.
Von einem Wunsch zu einer prüfbaren Anforderung
Vier wiederkehrende Aufgaben
Ermitteln: Du sammelst Informationen durch Gespräche, Beobachtung und die Untersuchung vorhandener Abläufe. Unterschiedliche Beteiligte können widersprüchliche Ziele haben. Diese Widersprüche gehören auf den Tisch, bevor sie sich in der Umsetzung verstecken.
Dokumentieren: Du hältst Anforderungen verständlich fest, beispielsweise als Text, Modell oder Szenario. Die Form ist dem Zweck untergeordnet. Ein Team muss erkennen können, was verbindlich ist und was noch eine Annahme darstellt.
Prüfen: Du besprichst Anforderungen mit den Beteiligten. Sind sie verständlich, konsistent und überprüfbar? Beschreiben sie das benötigte Ergebnis oder legen sie vorschnell eine technische Lösung fest?
Verwalten: Anforderungen ändern sich. Du hältst Entscheidungen, Prioritäten und Zusammenhänge nachvollziehbar. So lässt sich erkennen, welche Tests oder Systemteile von einer Änderung betroffen sind.
Welche Fähigkeiten besonders helfen
Du solltest Unklarheiten bemerken und freundlich nachfragen können. Präzises Schreiben ist wichtig, ebenso das Verstehen von Abläufen und technischen Zusammenhängen. Du musst nicht automatisch selbst programmieren. Du brauchst aber genügend Verständnis, um Auswirkungen und Grenzen mit dem Entwicklungsteam zu besprechen.
Manchmal wirkt diese Arbeit langsamer als sofortiges Bauen. Ihr Nutzen zeigt sich darin, dass ein Team weniger aneinander vorbeiarbeitet. Ein Requirements Engineer ist dabei kein Mensch, der allein ein perfektes Dokument erstellt und danach verschwindet. Austausch und Rückfragen bleiben Teil des gesamten Vorhabens.
Probiere die Rolle an einer Anmeldung aus
Ein Verein möchte Online-Anmeldungen zu Veranstaltungen ermöglichen. Formuliere fünf Anforderungen. Prüfe jede mit drei Fragen: Wer braucht das? Welches Verhalten wird erwartet? Woran erkenne ich, dass es funktioniert? Ergänze anschließend zwei Ausnahmen, etwa einen ausgebuchten Termin und eine doppelte Anmeldung.
Lass eine andere Person deine Beschreibung lesen und erklären, was sie bauen würde. Wenn ihr Unterschiedliches versteht, verbessere die Formulierung. Genau dieser Abgleich ist ein guter erster Eindruck von der Arbeitsweise. Für einen systematischen Einstieg bietet IREB frei zugängliche Informationen und Lernmaterialien zu den Grundlagen des Requirements Engineering.
Zum Weiterdenken: Was macht ein IT Business Analyst?.
