Ich möchte zum Titel meines neuen Buches Business Analysis und Requirements Engineering zunächst die typischen Vorurteile aufgreifen.

Vorurteil 1: „Business Analysis“ ist etwas für Banken, Behörden und Versicherungen. Die wollen oder müssen ihr „Business“ optimieren.

Meine Antwort: Ja, aber nicht nur die. Auch andere haben ihr Business, nur einfach eine andere Art von Business. Die einen stellen Dienstleistung zur Verfügung (neben Banken, Versicherungen und Behörden sicherlich auch Telekommunikationsunternehmen, die Transport und Logisitikbranche, oder auch ich in Form von Training und Projektberatung). Die anderen erzeugen Produkte (wie zum Beispiel Automobilbauer und ihre Zulieferer, Hersteller medizinischer Geräte, Hersteller von Mobiltelefonen, …). Das ist deren BUSINESS.
Business Analyse bedeutet für mich sein jeweiliges Geschäft gut zu verstehen, Schwachstellen zu identifizieren und (funktionale, qualitative oder quantitative) Verbesserung anzustreben – was auch immer Ihr Business ist.

Vorurteil 2: „Requirements Engineering“ ist etwas, was die Auftragnehmer bzw. die IT-Unternehmen machen sollten, bevor Sie IT-Lösungen designen und implementieren.

Meine Antwort: Ja, das auch. Aber Requirements Engineering ist eine Methodik, um – ausgehend entweder von neuen Ideen oder von heutigen Problemen und Schwachstellen – Anforderungen aus dem Business herauszukitzeln, diese zu strukturieren und zu präzisieren, natürlich auch widersprüchliche Wünsche aufzudecken, zu konsolidieren und noch einiges mehr. Und das ist nicht nur Sache des Auftragnehmers, sondern auch der Auftraggeber hat eine Mitwirkungspflicht dabei, seine Wünsche derart zu präzisieren.

In der Praxis erfolgt die Arbeitsteilung jedoch oft im Verhältnis 20:80 bezüglich des Aufwands. Nur 20% sind originäre „User Requirements“; die anderen 80% bleibt die Arbeit von Business Analysts oder Requirements Engineers, die aus vagen Ideen präzise Vorgaben machen sollten.

Im Kern geht es bei beiden Disziplinen um nachhaltige Verbesserung dessen, was unser Geschäft ist: um die Verbesserung oder Ausweitung unserer Dienstleistungen oder um die qualitative oder funktionale Verbesserung der von uns angebotenen Produkte, bis hin zum „Neuerfinden“ von lukrativen Geschäftsideen.

Früher haben wir diese Aufgabe Systemanalytikern übertragen – so stand es zumindest als Berufsbezeichnung in meinem ersten Anstellungsvertrag. Heute sagen wir „neudeutsch“ Business Analyst oder Requirements Engineer. Die Aufgabe solcher Personen oder Abteilungen ist immer noch dieselbe: herausfinden, wo der Schuh drückt und genau formulieren, was anders oder besser gemacht werden könnte. Formaler ausgedrückt: ein existierendes Problem oder eine neue Geschäftsidee durch gut verständliche Anforderungen systematisch anzupacken, damit es einer Lösung zugeführt werden kann.

Wir finden für jedes Problem eine Lösung, wenn wir uns nur darauf einigen könnten, was genau unser Problem ist.

Ja, es gibt sicherlich einige Probleme der Menschheit, die nicht zu leicht oder kurzfristig zu lösen sind, auch wenn wir die Probleme gut artikulieren können. Schwere Krankheiten wie Krebs oder Aids, friedliches Zusammenleben, u.ä.

Für die meisten Probleme in unserem Berufsleben sind wir jedoch schlau genug Lösungen zu finden – wenn wir das Problem gut genug identifiziert und beschrieben haben. Denn die meisten Probleme in Projekten sind nicht technologischer Natur – wie meine Kollegen Tom DeMarco und Tim Lister so eloquent in ihrem Buch „Peopleware“ („Wien wartet auf Dich“, 3. Auflage 2014) beschrieben haben.

Wir haben seit langem auch die Methoden, Verfahren und Notationen, um – ausgehend von Zielen – die Anforderungen systematisch zu erheben, zu dokumentieren, zu prüfen und zu verwalten.

Im Überblick geht es also bei Business Analysis und Requirements Engineering darum, wie man einerseits aus Zielen und anderseits aus erkannten Schwachstellen oder neuen Ideen zu detaillierten Vorgaben für eine Lösung kommt, unter Einhaltung von vorgegebenen Randbedingungen.

Peter Hruschka, VORURTEILE – und was man dagegen tun sollte. Abbildung 1

Davon handelt mein Buch. Ich bin zwar Informatiker, zähle mich jedoch zu den angewandten Informatikern und nicht zu den abgewandten. Deshalb schlage ich sehr pragmatische Verfahren vor, dieses Ziel zu erreichen. Leistbare Aufwände, pragmatische Anwendung der bekannten Methoden und ein Minimum an Dokumentation statt Tonnen von Papier. Also so viel wie nötig, nicht so viel wie möglich.

Ich wünsche Ihnen viel Vergnügen beim Lesen. Und Seien Sie bitte nicht zu ehrgeizig. Jede kleine Technik, die ich Ihnen empfehle, wie etwas eine frühzeitig exakte Festlegung Ihres Projektumfangs, oder die Einigung auf Kernbegriffe durch ein Glossar, oder die klare Identifizierung aller relevanten Stakeholder, oder, oder … können Ihre Projekte und Ihre Produktentwicklung schon nachhaltig verbessern. Sie müssen nicht gleich alle Tricks von Business Analysis oder Requirements Engineering“ beherrschen, sondern auch mit Teilen davon schon sehr erfolgreich sein.

Ich freue mich auf Ihr Feedback und Kommentare (peter@systemsguild.com) und wünsche Ihnen nachhaltig verbesserte Produkte und Prozesse und somit Erfolg und eines sicheren Arbeitsplatz.

Peter Hruschka

Hier gibts mehr Informationen zu Business Analysis und Requirements Engineering und natürlich nicht zu vergessen: das Videointerview bei Hanser.

Hruschka, Business Analysis