Was macht eigentlich ein Requirements-Engineer?

Heute haben wir mit unserem Requirements-Engineer Rainer über dessen Arbeitsalltag gesprochen und wollten von ihm wissen, was Requirements-Engineering eigentlich ist, was die Arbeit für ihn so besonders macht und wie es ihm bei isento gefällt:

Was macht ein Requirements-Engineer denn eigentlich?

Rainer: Meine Sicht der Dinge hat sich im Laufe der Jahre immer wieder verändert. Was mir aktuell sehr gut gefällt, ist die Formulierung: „Dem Requirements-Engineer geht es darum Wissen zu durchdringen und Wissen zu vermitteln.“ Das hat also einerseits mit mir selbst zu tun. Dass ich mir Wissen aneigne, indem ich es mir von Wissensträgern abhole. Das können Dokumentationen jedweder Art sein (materiell Geschaffenes, Geschriebenes, Gemaltes, Modelliertes, …). Das können aber auch Menschen sein, mit denen ich mich in Gesprächen, Workshops, Simulationen, Games, o. ä. auseinandersetze. Immer mit dem Ziel, dass ich verstehe und das Neue in meine vorhandene Wissensstruktur integriert habe.

Übrigens passiert dieser Wissenszugewinn oft auch anders herum. Mein Kunde, Auftraggeber oder einfach die Person, die Bedürfnisse, Wünsche oder Forderungen an ein zu schaffendes Produkt hat, lernt bei unserer Zusammenarbeit oft ebenso dazu. Oder den Menschen werden Dinge wieder bewusst, die über die Zeit bereits in deren Unterbewusstsein abgesunken sind. Das ist ein sehr angenehmer Aspekt bei dieser Arbeit: Wenn beide Parteien dabei lernen und einen Nutzen daraus ziehen können. Das macht zufrieden und schweißt zusammen.

Regelrecht Spaß macht das Ganze, wenn man eine gewisse Freude an Erkenntnisgewinn und Lernbereitschaft mitbringt. Mir geht es oft so, dass ich denke oder sage „Ah, jetzt hab‘ ich’s kapiert.“ oder „Das habe ich verstanden.“ Toll, wenn einem ein Licht aufgeht. Wenige Minuten später ist das Licht dann wieder aus, weil man merkt, dass man es doch noch nicht so ganz verstanden hat. Aber gut, dann muss man dranbleiben. Aufgeben gilt nicht. Nur ein tiefes Verständnis des Fachwissens bringt mich weiter.

Denn: Eigentlich geht es gar nicht um mich und meine Tätigkeit, sondern immer um andere Menschen, die ich mit diesem erlangten Wissen bediene. Soll heißen: Ich muss das Wissen so tief durchdrungen haben, dass ich es anderen Menschen weitergeben kann. Vorhin hatte ich das „Vermitteln“ genannt. Die Herausforderung ist allerdings nicht das Weitergeben. Dafür haben wir Requirements-Engineers diverse Techniken, die man in ganz klassischen Ausbildungs- oder Lernprozessen erlernen und üben kann. Sondern: Mein Wissensempfänger muss das benötigte Wissen verstehen, also ebenso durchdringen wie ich. Darum geht es am Ende.

Ich verstehe mich deshalb als ein Übersetzer oder Katalysator. Ich muss dafür sorgen, dass die Wünsche (wir Requirements-Engineers machen daraus Anforderungen) eines Menschen möglichst exakt im Kopf eines anderen Menschen landen, welcher das Gewünschte anschließend umsetzen kann. Die Kunst dabei ist, dass beide das exakt gleiche Bild des zu entwickelnden Systems im Kopf haben.

Und wie machst du das konkret in deinem Arbeitsalltag?

Rainer: Hm, jetzt kommt die Realität. Grundsätzlich hilft mir dabei mein „Handwerkszeug“. Das sind allerlei Techniken zur Wissensermittlung, Dokumentation, Qualitätssicherung, Verwaltung, Analyse und Vermittlung von Wissen oder eben Anforderungen.

Ich persönlich visualisiere und modelliere gerne, weil mir das für mein eigenes Verständnis hilft und weil ich zu Papier gebrachte Dinge gut für Diskussionen und Abstimmungen nutzen kann.

Um zu wissen was ich in mehr oder weniger formalen Beschreibungsmöglichkeiten zu Papier bringen muss, bereite ich Workshops vor, führe diese durch und bereite diese nach. In diesen Workshops nutze ich verschiedene Ermittlungstechniken und Simulationen. Ich arbeite dabei gerne sehr interaktiv mit den Teilnehmern.

Das erhobene Wissen wird dann dokumentiert. Das dient in erster Linie zu dessen Bewahrung, aber auch zur Rückspiegelung zu den Teilnehmern, um sicherzustellen, dass alle das Gleiche Bild im Kopf haben.

Meine Dokumentation nutze ich ebenso für die Vermittlung zu den Entwicklern. Das reicht aber nicht aus. Auch mit den Menschen, die die Informationen weiterverarbeiten, muss ich direkt und persönlich arbeiten. Nur lesen ist hierbei nicht das Maß der Dinge.

Neben dem Herausfinden dessen, was ein System können soll, gibt es oft auch die Aufgabe zu dokumentieren, was ein entwickeltes System (egal in welchem Stand) tatsächlich tut. Hierfür erstelle ich Produktdokumentationen fachlicher Art oder auch Benutzerhandbücher. Das sind zusätzliche Liefergegenstände für den Kunden neben der eigentlichen Software.

Wie das in einem konkreten Arbeitstag aussieht ist abhängig von anstehenden Terminen, die vorbereitet werden wollen oder der Priorisierung meiner Aufgaben. Es gibt Tage, an denen ich nur modelliere, es gibt aber auch Tage, an denen ich viele kleinere Aufgaben nacheinander abarbeite. Oder ich bin beim Kunden vor Ort und führe Workshops durch. Die Tage sind also nicht immer gleich – jedenfalls nicht über einen längeren Zeitraum. So wird es nie langweilig.

Gibt es Dinge, die du besonders beachten musst?

Rainer: Ja, die gibt es. Neben dem bisher Erzählten muss ich mit weiteren Herausforderungen umgehen. Als erstes zu nennen wäre: Bei all meinen Tätigkeiten muss ich mich in die Prozesse und Vorgehensweisen beim Kunden (das kann auch die Produktentwicklung im eigenen Haus sein) integrieren, damit der Gesamtentwicklungsprozess gut läuft. Das ist immer wieder unterschiedlich, aber auch spannend.

Heute arbeiten viele Projekte agil. Das gab es früher in dieser Ausprägung noch nicht. Auch daran muss ich mein Vorgehen und meine Methodik anpassen. Es macht einen Unterschied, ob ich Requirements-Engineering in einem Vorgehen nach Wasserfall durchführe, oder ob ich Teil eines Teams in Scrum bin, um nur zwei Möglichkeiten zu nennen. Die Variationen von Entwicklungsprozessen und deren Randbedingungen scheinen fast unendlich. Man muss also auch mit den unterschiedlichsten Vorgehensweisen umgehen können. Dennoch gibt es gleichartige Muster, die man mit ein bisschen Erfahrung erkennt.

Ein weiteres Beispiel: Wenn es um sicherheitskritische Systeme geht, müssen Anforderungen eine hohe Qualität besitzen. Hierbei gilt es sehr darauf zu achten, dass die Anforderungen vollständig, eindeutig, nachvollziehbar sind und vorgegebene Standards einhalten.

Zu guter Letzt ist es notwendig sich auf die unterschiedlichen Charaktere einzustellen, mit denen man arbeitet. Jeder Mensch ist anders und deshalb muss ich meine Kommunikation und meinen Umgang je nach Gesprächspartner anders wählen.

Du bist schon lange dabei. Was macht es (immer noch) interessant für dich?

Rainer: Gute Frage. Mir gefallen daran eine Menge unterschiedlicher Dinge:

• Ich habe bis heute Spaß daran, mich in neue und unbekannte Themenfelder hineinzudenken. Anders ausgedrückt: Es ist richtig interessant zu verstehen, wie z. B. Fluglotsen arbeiten, wie ein Paket von A nach B gelangt, wie ein Auto und dessen Elektronik gebaut ist, was kritische Aspekte an einem Medizingerät sind oder wie ein Onlineportal im Detail funktioniert.
• Spannend ist es auch zu erkennen, wie die Entwicklungsprozesse in den verschiedenen Unternehmen bzw. Branchen ablaufen und warum Produkte so sind, wie sie sind.
• Es gibt Zeiten, die verbringe ich ohne Störung vor meinen Anforderungen. Ebenso gibt es Zeiten, in denen ich sehr interaktiv mit Menschen zusammenarbeite. Beides hat etwas für sich und bringt Abwechslung.
• Wenn man mit dem erlangten Wissen einem Entwicklungsteam wirklich weiterhilft, entsteht ein angenehmes Gefühl. Das motiviert und macht zufrieden.
• Das Gleiche gilt, wenn der Kunde zufrieden ist, weil das entwickelt wird, was er tatsächlich will. Genau das unterstützt meine Arbeit ja.
• Meine Affinität dafür, Dinge zu strukturieren und koordiniert, methodisch durchdacht, sowie organisiert zu arbeiten spielt mir in die Karten, denn das ist beim Requirements-Engineering wirklich von Vorteil.
• Oft ist es einfach der Aspekt, dass man Menschen unterstützt klar zu erkennen, was sie eigentlich wollen und eine Software so zu gestalten, dass alle damit zufrieden sind. Dafür setze ich mich mit meiner Tätigkeit ein.

Du bist einer unserer neuesten Kollegen. Was gefällt dir besonders gut bei isento?

Rainer: Ich kann selbstverantwortlich planen und arbeiten und bin kein Leidtragender des Verhaltensmusters „Reportismus“. Reporten muss ich nur die notwendigsten Dinge. Das fühlt sich super an, weil ich somit zu meinen eigentlichen Aufgaben komme.

Dass ich hier „Nein“ sagen kann und darf und mich dabei nicht schlecht fühle ist Gold wert und führt dazu, dass ich nicht überplant bin. Folglich kann ich mich auf meine jeweilige Aufgabe in angemessenem Maße konzentrieren und erforderliche Qualität erzeugen, ohne dass mir ständig viele Aufgaben im Nacken sitzen, die bereits gestern erledigt sein wollten.

Und ich habe noch etwas, was ich als sehr positiv wahrnehme: Ich bekomme kaum Mails! Aus anderen Unternehmen oder Projekten kenne ich, dass zig Mails pro Tag eingehen. Das gibt es in diesem Ausmaß hier gar nicht. Ich bin begeistert.