Hinweis: Dieser Blogbeitrag stammt aus der Zeit vor dem Zusammenschluss und wurde von ARS realisiert – heute Teil von ATVANTAGE. Unsere Erfahrung bleibt – nur unser Name hat sich geändert. Hier finden Sie weitere Informationen rund um die Fusion.

Lesezeit: 5 Minuten
 

Warum dein Projekt Requirements Engineering oder Business Analyse braucht


Wer ist mein Requirements Engineer, wo finde ich einen Business Analysten und wofür benötige ich diese Rollen in meinem Projekt?


Berechtigte Fragen, die in Summe ein großes Fragezeichen hinterlassen. Aber lasst uns gemeinsam Licht ins Dunkle bringen.

Immer mehr Projekte, Unternehmen und Teams berufen sich auf das Einbringen qualifizierter Rollen im Bereich des Requirements Engineering und der Business Analyse. Aber nur ein Bruchteil kann genau wiedergeben, was die Aufgaben dieser Rollen sind, wo unterscheiden sich diese und ist es aus wirtschaftlicher Sicht ein Muss, diese in jedem Projekt zu involvieren? Um diese Frage zu beantworten, ist ein Verständnis der Aufgaben beider Rollen wichtig und wie sich Requirements Engineering und Business Analyse unterscheiden.

So kann man sich die Arbeit eines Requirements Engineer und eines Business Analysten wie die Arbeit eines Detektivs vorstellen. Wie Detektiv Benoit Blanc (Daniel Craig) bei den Ermittlungen und der Lösung von Rätseln in der Filmreihe „Knives-Out“ eine wichtige Rolle spielte, so sind auch die beiden Rollen für eine Organisation oder Projekte von hoher Bedeutung.

In einem Vergleich beider Rollen, stellt sich das Requirements Engineering (RE) als die kleinere, aber bei weitem nicht zu unterschätzende Rolle/Aufgabe dar und ist das Mindestmaß beider Rollen in IT-Projekten. Die Kernkompetenzen im Requirements Engineering sind fast deckungsgleich zu denen in der Business Analyse (BA). Die Business Analyse wird allerdings noch um meist strategische sowie fachliche Kompetenzen und Tätigkeitsfelder erweitert.

Das Requirements Engineering konzentriert sich speziell auf den Prozess der Erhebung, Analyse und Dokumentation von Anforderungen für ein Projekt. Dafür ist die Zusammenarbeit mit den Stakeholdern sehr wichtig. Das Ziel ist es, deren Bedürfnisse bedarfsgerecht zu ermitteln, zu dokumentieren und sicherzustellen, dass die Anforderungen klar, präzise und eindeutig sind. Nur kleinste Nuancen lassen bereits Interpretationsspielraum für Anwender, Entwickler und Tester.

Dies resultiert meist in einer hohen Anzahl an Änderungen der Anforderungen sowie der IT-Lösung und geht zulasten der Motivation aller Beteiligten, - von einem häufig überschrittenen Projektbudget oder einer verspäteten Inbetriebnahme ganz zu schweigen. Die Fähigkeit eines Requirements Engineers, schnell neue fachliche Domänen zu erschließen, ist von enormer Bedeutung. Dies haben wir bereits in zahlreichen Projekten erfolgreich bewiesen, in denen wir fachspezifische Anforderungen mit hoher Qualität dokumentiert und verwaltet haben.

So erarbeitet das Requirements Engineering z.B. Grob- und Feinkonzepte, die als Basis für die klassische, aber auch für die agile Entwicklung dienen. Diese frühzeitige Einbindung derartiger Ressourcen bietet eine zeitnahe Bewertung der Machbarkeit des Projektvorhabens. Anforderungen werden validiert und der bekannte Spruch „über den Tellerrand schauen“, ist tief in den jeweiligen Aufgabenfeldern manifestiert. Auch werden Fragen gestellt, die helfen, die Anforderungen und die daraus resultierende Lösung ‚wasserdicht‘ zu gestalten. Dies lässt wenig Platz für Interpretationsspielraum und reduziert kostenintensive Nacharbeiten und minimiert das Risiko von Frustration und Unzufriedenheit.

Im Bereich der Business-Analyse sind die erweiterten Tätigkeitsfelder das Verstehen und Analysieren von Strukturen, Geschäftsregeln sowie Kommunikations- und Geschäftsprozessen von Unternehmen oder bestimmten Unternehmensstrukturen. So können Lösungen empfohlen werden, die es dem Unternehmen ermöglichen, diese Strukturen und Prozesse zu verbessern.

Beispiele dafür sind optimierte Arbeitsabläufe, Änderungen der Aufbauorganisation und insbesondere der Einsatz von IT-Tools und individuellen Lösungen. Dazu werden die Anforderungen und Erwartungen unterschiedlicher Personen und Personengruppen (Stakeholder) innerhalb und außerhalb des Unternehmens ermittelt. Vor allem die zugehörigen Prozesse werden gemeinsam mit dem Fachbereich in einfachen und zwanglosen Workshops, in denen sich alle Beteiligten einbringen dürfen, analysiert und dokumentiert nach bekannten Notationen (z.B.: BPMN). Risikobewertung von bestehenden und neuen Prozessketten, sowie die zugehörige Optimierung sind im Anschluss einfacher zu realisieren.

Man merkt bereits, Requirements Engineering und Business Analyse sind zwei verwandte, aber dennoch verschiedene Rollen. Es gibt zwar Überschneidungen zwischen diesen Rollen, aber auch einige wichtige Unterschiede.

Die Business Analyse stellt oft einen eher strategischen und ganzheitlichen Ansatz zum Verstehen und Optimieren eines Unternehmens dar und kann aus mehreren Rollen bestehen. Das Requirements Engineering ist eine der bekanntesten dieser Rollen und ist eher taktisch und auf spezifische Projektleistungen ausgerichtet. Somit ist das Requirements Engineering eine Menge der Business Analyse. Verdeutlicht wird dies unter anderem im Business Analyse Vorgehensmodell. Aus dem Schaubild ergeben sich die fünf Haupttätigkeiten in der Business-Analyse, die sich auf die strategische, sowie operative Business Analyse aufteilen.

 

Abb. nach: Das Business-Analyse-Vorgehensmodell der Gerstbach Business Analyse GmbH (Quelle: Fachbuch «Basiswissen Business-Analyse», erschienen im Redline Verlag, 2015)

Dabei wird hervorgehoben, dass vor allem das Requirements Engineering im Bereich der operativen Business Analyse verankert ist. Wie bereits erläutert, kann Requirements Engineering eine Menge der Business Analyse darstellen, kann aber auch losgelöst vom Begriff der Business Analyse durchgeführt werden.

So finden beide Rollen in der klassischen, sowie agilen Vorgehensweise von IT-Projekten Aufmerksamkeit und werden bei Bedarf mit einbezogen. Durch verschiedene Methodiken, die im Requirements Engineering und der Business Analyse mitgebracht werden, können IT-Projekte frühzeitig eingeschätzt werden. Dadurch wird für eine bessere Planungssicherheit für das gesamte IT-Projekt gesorgt. Beide Rollen können darüber hinaus die Entwicklung begleiten und als fachlicher Ansprechpartner fungieren. Zusätzlich übernehmen sie teilweise auch den Testprozess und sind maßgeblich an der Durchführung von Anwenderschulungen beteiligt.

Warum ist Requirements Engineering so wichtig?

Aber warum ist Requirements Engineering so wichtig und wie überzeugt man Projektverantwortliche von der Einbindung des Requirements Engineerings?

Folgende Darstellung ist kaum noch wegzudenken, wenn es um die Erläuterung des Anforderungsmanagements geht. Was häufig ohne Requirements Engineering passiert und was das Requirements Engineering deshalb so wichtig macht, zeigt das folgende Schaubild.

 

Abb.  www.projectcartoon.com

Es wird recht einfach verdeutlicht, wie falsches, oder gar fehlendes Requirements Engineering zu Missverständnissen, einer Ausweitung des Projektumfangs, schlechter Qualität des Ergebnisses, erhöhten Projektkosten und einem verzögerten Projektabschluss führen kann. Ein dem Projekt und den Beteiligten angepasstes Requirements Engineering kann daher maßgeblich über Erfolg oder Misserfolg eines Projektes entscheiden.

In kleineren Projekten, die zumeist von technischer Natur sind und nur geringfügig größere fachliche Interaktionen und Einflüsse mit sich bringen, können die Tätigkeiten aus dem Requirements Engineering durch Entwickler und dem Projektmanagement übernommen werden.

Dies lässt sich allerdings nicht pauschalisieren und auch kleinere Projekte können bereits von den Rollen eines Business Analysten oder Requirements Engineer profitieren. So kann es für manche Projekte sinnvoll sein, eine kleine Analyse-Phase als eigenes Projekt durchzuführen. Dies ermöglicht uns, die Machbarkeit und Anforderungen in einem groben Detail zu dokumentieren und durch die Erstellung von Fachkonzepten festzuhalten.

Aber vor allem im Bereich größerer Projekte, hat es sich für uns und unsere Kunden über die letzten Jahre eindeutig abgezeichnet, dass der Einsatz von Requirements Engineering und Business Analyse unerlässlich ist. Der hohe Erfolg durch die frühzeitige Erhebung und Dokumentation von Anforderungen, und ein für das jeweilige Projekt adaptierte Vorgehen, sowie die Abstimmung mit den Stakeholdern und das Verwalten bei möglichen Änderungen, spiegelt sich vor allem in der Zufriedenheit unsere Kunden wider.

So wirken Requirements Engineers und Business Analysten nicht rein auf die saubere Erhebung und Dokumentation ein, sondern bringen auch Vorteile in weiteren Bereichen mit:

Change Facilitation

Durch das frühe Einbinden von Requirements Engineers und einer offenen Kommunikation mit den Stakeholdern wird Hilfe im Widerstandsmanagement geboten, und es wird auf eine mit den Fachbereichen und weiteren Stakeholdern vereinbarte Kommunikation im Change-Prozess geachtet. Die Änderungsprozesse werden gemeinsam mit den Kunden identifiziert, erarbeitet und gestaltet.

Erhöhte Kundenzufriedenheit

Durch den engen und offenen Austausch, das Stakeholdermanagement und die gute Kommunikation (Brücke zwischen Fachbereich und Entwicklung) wird die Kundenzufriedenheit gesteigert, und somit auch die Zufriedenheit der weiteren Beteiligten (Kunden-Projektmanagement, Auftraggeber, Entwicklungsteam und weitere Beteiligte Personenkreise). Der enge und offene Austausch mit den Stakeholdern und eine gute Kommunikation als Brücke zwischen Fachbereich und Entwicklung erhöhen die Zufriedenheit des Kunden und aller weiteren Projektbeteiligten.

Anwenderschulung und Kompetenzaufbau

Es wird um eine frühe Einbindung von Key-Usern gekümmert, die bereits bei der Entwicklung involviert werden. Durch eine strukturierte fachliche Dokumentation während der Entwicklung können Schulungsunterlagen mit hohen Qualitätsaspekten erstellt werden. In Zusammenarbeit mit den Key-Usern kann die Schulung mit hoher Akzeptanz gegenüber den weiteren Stakeholdern durchgeführt werden.

Vermeidung von Kosten

Durch die Analyse und abgestimmte Dokumentation im Bereich der Anforderungen können Risiken minimiert und somit Projektkosten reduziert werden. Änderungswünsche würden sonst erst zu späteren Projektphasen oder gar erst nach der Inbetriebnahme identifiziert und wären dann meist kaum noch realisierbar oder nur unter immensem Kostenaufwand. Durch eine vorherige Analyse und eine abgestimmte Dokumentation im Bereich der Anforderungen unterstützen wir in der Risikominimierung und reduzieren somit Projektkosten. Änderungswünsche können so frühzeitiger identifiziert, bewertet und berücksichtigt werden. Dabei wird auf ein bereits in vorherigen Projekten etabliertes Vorgehen gesetzt, das sich bewährt hat.

Fazit

Schlussfolgernd lässt sich erkennen, dass bei kleineren Projekten selbstorganisierte Teams in Zusammenarbeit mit den Stakeholdern Anforderungen und Prozesse durchaus selbst analysieren, dokumentieren und für die Entwicklung aufbereiten können. Vor allem technisch-getrieben Anwendungsfälle stellen hier seltener eine Problematik dar.

Mit steigender Komplexität, vor allem aus fachlicher Sicht, sind Business Analysen und Requirements Engineer eine Bereicherung. Durch unsere Expertise bilden wir das Bindeglied zwischen Fachbereich und Entwicklung und bieten durch erhöhte Kompetenzen im Bereich der Change-Facilitation, der Anforderungserhebung, des Stakeholder Managements, sowie Bedarfs- und weiteren Analysen und dem Prozess-Management, eine hohe Projekt- und Planungssicherheit.

Uns ist wichtig, dass die Rollen Requirements Engineering und Business Analyse den Fokus nicht rein auf die technische Realisierung setzen, sondern auch den Faktor Mensch mit einbeziehen. Die Zufriedenheit aller Stakeholder ist hierbei besonders wichtig.

Blogautor

Philipp Schebitz
Business Analyst ARS Computer und Consulting GmbH

Ihr Erfolg ist unser Ziel

Stehen Sie vor komplexen IT-Projekten? Mit unserer Expertise bieten wir Ihnen maßgeschneiderte Lösungen. Erfahren Sie mehr.

Werde Teil unseres Teams

Wir suchen ständig nach neuen Talenten. Für dich haben wir genau die richtige Stelle. Schau dir unsere offenen Positionen an.

Noch Fragen? Wir helfen Ihnen gerne!

Blog 26.10.23

Given/When/Then und ATDD - Eine Win-Win-Win-Situation!?

Erfahren Sie, wie die Methode Given, When, Then (GWT) und Acceptance Test-Driven Development (ATDD) in agilen Projekten angewendet werden können, um Akzeptanzkriterien frühzeitig zu beschreiben.

Kompetenz 28.07.21

Software Engineering

Software Engineering ist die Kunst, gute Software zu erschaffen. Software Engineering ist die Disziplin mit durch Wissenschaft und Praxis erprobten Methoden ihre digitalen Produkte zu schaffen.

Blog 04.07.24

Warum Shift Left jetzt unverzichtbar ist

Erfahren Sie, warum Shift Left und Feedbackschleifen unverzichtbar für eine erfolgreiche Softwareentwicklung sind. Verbessern Sie Qualität, Sicherheit und Effizienz in Ihrem Unternehmen.

Service 17.09.25

Cloud Engineering

Cloud Engineering

Service 19.09.25

Software Engineering

Software Engineering

Blog 10.11.22

Architekturarbeit im Zeitalter Cloud-nativer Architekturen 2

Aufgaben von Softwarearchitekten im Cloud-native-Umfeld, benötigte Skills und ihr Arbeitsalltag zwischen Kundenanforderungen, Zieldefinition und Deadlines.

Blog 08.12.22

Teil 4: Eigenschaften einer Cloud-native Architektur

Beitrag zu Cloud-native Architekturen, ihre Möglichkeiten und Zielsetzungen sowie die Philosophie und Arbeitsweise, die daraus folgt.

Blog 26.04.24

Team Topology: Ein Wegweiser für effektive DevOps-Kultur

Erfahren Sie, wie Team Topology und effektive Kommunikationsmodi die DevOps-Kultur fördern und die Softwareentwicklung revolutionieren. Ein Wegweiser für erfolgreiches Teammanagement.

Blog 05.01.23

Teil 6 - Die Architektenrolle in DevOps-Teams/Organisationen

Erfahren Sie in diesem Blogbeitrag mehr über die Rolle der Architekten in DevOps-Teams und wie sich die Architekturarbeit im cloud-native Umfeld verändert hat.

Blog 16.02.23

Keine Angst vor Komplexität

Wie kann man die Komplexität der Organisation u. Technologie, die neue Plattformen, Architekturen und neue Entwicklerkultur mit sich bringen, beherrschen?

Blog 27.10.22

Architekturarbeit im Zeitalter Cloud-nativer Architekturen 1

Die beschleunigte Digitalisierung und ihr Einfluss auf Softwarearchitekturen und IT-Teams beschreibt der Autor. Sind Cloud-native-Strategien sinnvoll?

Blog 19.09.24

Die Zukunft datenbankzentrierter IT-Architekturen

Datenbankzentrierte IT-Architekturen prägen viele Unternehmen. Doch ist dieser Ansatz noch zukunftsfähig? Dieser Artikel beleuchtet die Herausforderungen und Alternativen.

Blog 16.03.23

Bedeutung von APIs als Interaktionsmodell

APIs sind mehr als Schnittstellen, sie sind Teil der Interaktion zwischen Geschäftspartnern. Eine API First Strategie schafft echte Wertschöpfung.

Blog 30.03.23

Eine API kommt selten allein - APIs in der freien Wildbahn

API's als Produkt zu verstehen ist ein Merkmal agiler Arbeitsweise. API's sind immer im Kontext des geplanten Services und des Ökosystems zu betrachten.

Blog 18.07.24

Ticket-Schneiden: Best Practices und Agile Methoden

Erfahren Sie, wie Sie effektive Tickets für die Softwareentwicklung schreiben und schneiden, um Probleme zu vermeiden. Mehr über die Bedeutung von User Stories und deren korrekte Umsetzung.

Blog 12.01.24

Infrastructure as Code (IaC)

Infrastructure as Code (IaC) und die neuesten Entwicklungen in der Cloud-Infrastrukturverwaltung mit Tools wie Terraform und Crossplane. Ein Blick auf die Zukunft des Infrastrukturmanagements.

Blog 02.02.24

So kommt Ordnung in den Infrastructure as Code-Werkzeugkaste

Ordnung im IaC-Dschungel: Welches Tool passt? Dieser Artikel gibt Überblick über die wichtigsten Werkzeuge für Infrastructure as Code.

Blog 22.12.22

Teil 5 - Einfluss von Cloud-native auf die Architekturarbeit

Wir beleuchten technische Aspekte von cloud-native Architekturen, die Vorteile verteilter Systeme und wie wichtig API-Management-System ist.

Blog 19.01.23

Digitalisierung und das richtige Mindset

Digitalisierung erfordert Umdenken weg von Projekten hin zu Produkten. DevOps und offene Fehlerkultur bestimmen moderne IT-Organisationen - auch bei Ihnen?

Blog 01.08.24

Migration von HOST-Anwendungen zu AWS: Modernisierung

Lernen Sie, wie moderne AWS-Services nahtlos in bestehende Host-Landschaften integriert werden und profitieren Sie von den Vorteilen von Serverless-Technologien.