Die zunehmende Vernetzung und Komplexität von Produkten lassen die Anzahl interner und externer Anforderungen gleichzeitig steigen. Deshalb spielt das Requirements Engineering sowohl in der Software- als auch in der Hardwarebranche eine immer wichtigere Rolle für die Produktentwicklung. Christian Bock ist Lead Requirements Engineer bei Materna Virtual Solution und sorgt mit seiner Expertise dafür, dass die Produkte zielgerichtet weiterentwickelt werden. Im folgenden Interview erklärt Christian, was Requirements Engineering ist und wie seine Arbeit als Requirements Engineer aussieht.
Editorial Office: Lieber Christian, Du bist vor circa fünf Monaten zur MVS gekommen und bereicherst seitdem als Lead Requirements Engineer unsere Fachabteilungen mit Deinem Know-How. Kannst Du Dich bitte kurz vorstellen und uns erzählen, wie Du zum Thema Requirements Engineering gekommen bist?
Christian Bock: Mein Name ist Christian Bock, ich bin 27 Jahre alt und in Nürnberg geboren und aufgewachsen. Ursprünglich bin ich eher durch Zufall zum Thema Requirements Engineering gekommen – rückblickend würde ich es aber eher als Glück bezeichnen. 😉 Aber lass mich versuchen, die Geschichte in aller Kürze zu erzählen: Ich war damals dualer Student der Elektrotechnik und habe schon geahnt, dass ich nicht mein ganzes Leben in diesem Bereich tätig sein werde. Eines Tages erzählte mir ein Freund von einer Jobmesse, auf der verschiedene Unternehmen junge Berufstätige suchten, die an Praktika, Ausbildungen und dualen Studiengängen interessiert waren. Obwohl ich noch nicht auf der Suche nach einem neuen Job war, war ich ein guter Freund und habe ihn als moralische Unterstützung begleitet. Als wir dort ankamen, wurden wir direkt von einem der Unternehmen angesprochen. Es war ein Beratungsunternehmen aus Nürnberg, das sich auf dieses seltsame Thema namens Requirements Engineering spezialisiert hat. Ich hatte noch nie zuvor davon gehört, aber war von dem, was sie erzählt haben, sehr faszinierend. Nach dem Gespräch habe ich mir die Broschüren angesehen und noch ein wenig mehr über Requirements Engineering recherchiert. Was soll ich sagen? Ich war überzeugt! Also bewarb ich mich bei genau diesem Unternehmen und bekam eine Ausbildungsstelle als Fachinformatiker für Anwendungsentwicklung angeboten. Requirements Engineering hat mich also von Anfang an so fasziniert, dass ich bereit war meinen Job zu kündigen und bis heute im Requirements Engineering arbeite. Nach ca. 8 Jahren als (Senior) Berater und Trainer in den verschiedensten Branchen – Automobil, Gesundheitswesen, Industrieautomatisierung, Versicherungen, Maschinenbau, Telekommunikation, Pharma, um nur einige zu nennen – habe ich mich entschlossen, die Beratungsbranche zu verlassen und bin in das Produktmanagement-Team der Materna Virtual Solution gewechselt. Ich bin sehr glücklich ein Teil der MVS zu sein und die Zukunft des sicheren ultramobilen Arbeitens mitgestalten zu können.
Editorial Office: Danke Christian, dass Du die Geschichte mit uns geteilt hast! Manchmal passieren solche Dinge einfach aus Schicksal. 🙂 Kannst Du uns bitte erklären, worum es bei Requirements Engineering geht und mit welchen typischen Aufgaben man sich als Requirements Engineer beschäftigt?
Christian Bock: Das ist ganz einfach erklärt: Es geht darum, die Bedürfnisse und Wünsche der Kund:innen/Nutzer:innen zu verstehen, damit die Entwicklungsteams Produkte entwickeln können, die einen maximalen Nutzen bieten. Im Grunde ist das Requirements Engineering der Übersetzer/die Schnittstelle zwischen Unternehmen/Stakeholdern und der Entwicklung. Und wie wir alle wissen: Unterschiedliche Menschen sprechen unterschiedliche Sprachen. Daher müssen wir im Requirements Engineering in der Lage sein, uns in Menschen einzufühlen, um zu verstehen, was ihre Anforderungen/Bedürfnisse sind, auch wenn sie nicht in der Lage sind, diese zu beschreiben – was übrigens schwieriger ist, als es klingt. Und hier kommt mir sofort ein Satz eines ehemaligen Kollegen in den Sinn: „Gib deinen Kund:innen, was sie brauchen, nicht was sie wollen!“. Und das ist meines Erachtens ein sehr wichtiger Satz, denn diese geben in der Regel an, was sie wollen, auch wenn es nicht unbedingt das ist, was sie brauchen. Als Requirements Engineer ist es also meine Aufgabe, Fragen zu stellen, um herauszufinden, was der Kunde/die Kundin braucht, und zwar auf Grundlage der Informationen, die mir ursprünglich gegeben wurden. Aber das ist noch nicht alles! Requirements Engineering umfasst mehrere Hauptaufgaben, so z. B. das Ermitteln und Sammeln von Anforderungen und Informationen im Allgemeinen; das Analysieren und Verfeinern von Anforderungen, um sicherzustellen, dass sie vollständig, kohärent und realisierbar sind; das strukturierte Dokumentieren von Anforderungen, damit sie von anderen Parteien/Stakeholdern verwendet werden können; das Validieren von Anforderungen mit den Stakeholdern, um sicherzustellen, dass sie deren Bedürfnissen und Erwartungen entsprechen; und nicht zuletzt Managementthemen wie Priorisierung, Change Management und die Release-Planung.
Editorial Office: Das klingt wirklich faszinierend. Requirements Engineering scheint ein sehr vielfältiges Feld zu sein, in dem kommunikative Menschen gut aufgehoben sind. Kannst Du uns bitte noch mehr über den Requirements Engineering Prozess erzählen? Welche Schritte muss eine Funktionsanforderung bis zur endgültigen Implementierung durchlaufen?
Christian Bock: Grundsätzlich beginnt der Requirements Engineering Prozess mit der Identifizierung und dem Verständnis der gewünschten Funktion oder des zu lösenden Problems. Dazu müssen Informationen von den Stakeholdern eingeholt und ihre Bedürfnisse geklärt werden. An dieser Stelle ist es wichtig zu betonen, dass Stakeholder nicht nur Nutzer:innen und/oder Kund:innen sind, sondern im Grunde alle, die direkt und indirekt an der Produktentwicklung beteiligt sind. So gehören sowohl interne Parteien wie Entwicklung, Vertrieb, Marketing, Support und Qualitätssicherung als auch externe Parteien wie Kund:innen, Nutzer:innen, Partner:innen, Gerätehersteller und Infrastrukturanbieter zu unserer Zielgruppe. Sobald die Anforderung identifiziert ist, wird sie analysiert und in kleinere, besser handhabbare Teile zerlegt. Dabei werden funktionale und nicht-funktionale Anforderungen identifiziert, nach Prioritäten geordnet und etwaige Konflikte oder Unklarheiten beseitigt. Der nächste Schritt besteht darin, die ermittelten und analysierten Anforderungen in klarer und strukturierter Form zu dokumentieren. Dabei ist es besonders wichtig das Big Picture im Auge zu behalten und sich nicht in Details zu verlieren, die in der ganzheitlichen Betrachtung möglicherweise nicht relevant sind. Die dokumentierten Anforderungen werden dann validiert, indem sie mit den beteiligten Parteien, einschließlich dem Entwicklungsteam, dem Kunden/der Kundin und den Nutzer:innen, besprochen werden. Dieser Schritt stellt sicher, dass die Anforderungen vollständig, konsistent und realisierbar sind. Natürlich können sich die Anforderungen im Laufe des Entwicklungsprozesses ändern oder weiterentwickeln. Dann liegt es in unserer Verantwortung, die Änderungen zu verfolgen und zu verwalten, um sicherzustellen, dass sie ordnungsgemäß kommuniziert und hinsichtlich ihrer Auswirkungen bewertet werden. Sobald die Anforderungen validiert sind, fährt das Entwicklungsteam mit der Implementierung des Produkts gemäß den definierten Anforderungen fort. Dies umfasst die Codierung, das Testen und das Bereitstellen der Lösung. Nach der Implementierung wird die endgültige Lösung überprüft, um sicherzustellen, dass sie die festgelegten Anforderungen erfüllt. Hier kommen Tests, Bewertungen der Nutzungsakzeptanz und andere Verifizierungstechniken zum Einsatz. Es ist wichtig zu erwähnen, dass es sich nicht unbedingt um einen sequenziellen Prozess handelt, sondern vielmehr um einen iterativen Prozess, bei dem der Requirements Engineer verschiedene Interessengruppen zu unterschiedlichen Zeitpunkten während des gesamten Prozesses einbezieht.
Editorial Office: Ein wirklich umfangreicher Prozess, an dem viele Parteien beteiligt sind. Aber wie Du bereits erwähnt hast, ist der Prozess wichtig, um Produkte und Lösungen in die richtige Richtung weiterzuentwickeln. Jetzt würde ich gerne mehr über die Zusammenarbeit in Deinem Team erfahren. Wie sieht Eure Zusammenarbeit aus und mit welchen Abteilungen arbeitet das Requirements Engineering zusammen?
Christian Bock: Zunächst einmal möchte ich erwähnen, dass unsere Zusammenarbeit außergewöhnlich ist und ich möchte mich bei dieser Gelegenheit bei all meinen Kolleg:innen für die großartige und ambitionierte Arbeit bedanken! Mein Team besteht aus drei Rollen – einem Produktmanager, einem Solution Architect und einem Requirements Engineer – die aus meiner Sicht unglaublich gut miteinander harmonieren. In der Regel bringt unser Produktmanager neue Themen auf den Tisch und steht in engem Kontakt mit Kund:innen, Management und anderen internen Stakeholdern. Diese Themen werden dann vom Requirements Engineer analysiert und in konkrete Anforderungen heruntergebrochen, um eine ganzheitliche Sicht auf das Thema zu erhalten. Danach kommt der Solution Architect ins Spiel, der die technische Spezifikation auf hoher Abstraktionsebene, die Systemarchitektur und Vorschläge/Empfehlungen zu den zu verwendenden Technologien für die Entwicklungsteams ableitet. Im Grunde arbeiten wir mit fast allen Abteilungen des Unternehmens zusammen, da diese ebenfalls Stakeholder mit individuellen Anforderungen sind, die wir berücksichtigen müssen. Einige Beispiele: Wir arbeiten eng mit dem Entwicklungsteam zusammen, um die Anforderungen zu kommunizieren und zu klären, die notwendige Dokumentation bereitzustellen und ein gemeinsames Verständnis der gewünschten Ergebnisse sicherzustellen. Wir unterstützen unser Projektmanagement- und Vertriebs-Team, indem wir die Anforderungen mit den Kund:innen klären, um sicherzustellen, dass die Erwartungen angemessen gemanagt werden können und dass die Entwicklungsteams Schätzungen zur Ableitung von Budgets/Kosten und Zeitplänen abgeben können. Als Teil des Produktmanagement-Teams versuchen wir auch sicherzustellen, dass die Anforderungen aus den Projekten mit unserer Produktstrategie in Einklang gebracht und priorisiert werden können. Da unser Customer Excellence-Team regelmäßig in direktem Kontakt mit unseren Kund:innen steht, liefern uns die Kolleg:innen wertvolle Erkenntnisse, die wir dann in Anforderungen umsetzen können. Wenn es um Marketing geht, führen wir Interviews, wenn das Team uns darum bitten. Spaß beiseite. 😉 Für das Marketing versuchen wir die notwendigen Informationen zu liefern, damit neue Funktionen, Produkte und/oder Projekte angemessen beworben werden können. Zu diesem Zweck fassen wir relevante Informationen in Faktenübersichten zusammen, die im gesamten Unternehmen als zentrale Informationsquelle dienen, so dass alle Beteiligten mit denselben Informationen arbeiten können.
Editorial Office: Ihr seid sozusagen mit dem gesamten Unternehmen vernetzt. Das klingt super spannend! Und es freut mich zu hören, dass ihr im Team so gut miteinander harmoniert. Meine letzte Frage: Kannst Du uns von einem typischen Arbeitstag als Requirements Engineer bei Materna Virtual Solution erzählen?
Christian Bock: Einen typischen Arbeitstag gibt es tatsächlich nicht, was ich persönlich aber sehr schätze. Wie Du Dir vorstellen kannst, ist jedes Thema anders und erfordert unterschiedliche Beiträge von verschiedenen Stakeholdern. Aber ich werde versuchen, einen typischen Tag im Requirements Engineering für Dich zu skizzieren: Morgens habe ich in der Regel ein kurzes Sync-Meeting mit meinem Team, um die aktuell relevanten Themen zu besprechen. Danach verbringe ich die meiste Zeit damit, mit unseren Stakeholdern zu sprechen. Anschließend analysiere und dokumentiere ich den erhaltenen Input, den ich dann mit unserem Solution Architect, Product Manager oder unseren Product Ownern bespreche. Aber natürlich gibt es auch Tage, an denen ich einfach nur versuche, ein Thema vollständig zu verstehen, um die Anforderungen ableiten zu können. Andere Tage sind gefüllt mit Kund:innen-Workshops vor Ort, Abklärungen mit unseren Partner:innen oder der Überlegung, welche Features wir mit welchem Release-Zyklus ausliefern werden. Ich liebe meinen Job – vor allem bei MVS! Und ich kann ihn jedem empfehlen, der gerne und viel kommuniziert und starke analytische Fähigkeiten hat!
Editorial Office: Danke, lieber Christian, für den offenen Dialog und die interessanten Einblicke in Dein Arbeitsgebiet. Ihr macht wirklich einen tollen Job, mit dem wir sicherstellen können, dass unsere Produkte im Sinne unserer Kund:innen und Nutzer:innen weiterentwickelt werden. Wir sind froh, Dich an Bord zu haben! 🙂