Requirements Engineering:
Gründe für und gegen RE

Requirements Engineering: Gründe für und gegen RE

Requirements Engineering (RE), oder Anforderungsmanagement für diejenigen, die Anglizismen nichts abgewinnen können, ist ein weites Feld im Rahmen eines Projekts, in dem man sehr schnell und sehr einfach den Überblick verlieren kann. Im Rahmen dieser Blogserie und eines Beispielprojekts möchte ich Ihnen aufzeigen, wie sinnvoll RE ist und wie schnell es durch fehlerhafte Verwendungsszenarien als „Kostentreiber ohne Nutzen“ abgestempelt wird und natürlich werde ich dort meine Erfahrungen im Projektalltag einbringen, um nicht den Anschein zu erwecken, dass ich RE auf Teufel komm raus in jedem Projekt vollumfänglich durchziehen möchte.

Situationen, in denen Requirements Engineering genutzt wird

Es ist mir des Öfteren aufgefallen, dass sowohl Kunde als auch Dienstleister in der Regel einen großen Bogen um Requirements Engineering machen und es als Preistreiberei ansehen. Dabei ist beispielsweise bereits die Erstellung einer Ausschreibung durch den Kunden Teil einer Anforderungsanalyse, denn eine Ausschreibung ohne Beschreibung der Anforderungen ist relativ wertlos. Nur so können die passenden Kandidaten gefunden werden. Andere Beispiele, in denen RE unumgänglich ist, sind neben den klassischen Projekten in den verschiedensten Branchen etwa Verhandlungen zweier Vertragsparteien, in denen man sich an die Anforderungen der anderen Partei annähert, die Konfiguration eines Autos, welches gewissen Anforderungen des zukünftigen Inhabers entsprechen soll, oder auch die Planung einer Geburtstagsfeier, die dem Feiernden gefallen soll.

RE wird also tatsächlich in irgendeiner Ausführung tagtäglich benutzt – es wird nur selten derart kommuniziert. Bewusst angewendet wird RE in der Regel immer dann, wenn die Parteien scheinbar aneinander vorbeigeredet haben und viel zu spät – nämlich, wenn beispielsweise die entwickelte Fachanwendung fertig ist, aber die Nutzer diese aufgrund verschiedener Unzulänglichkeiten gar nicht nutzen.

Projekte ohne RE sind fast zum Scheitern verurteilt

Es passiert leider auch viel zu oft in IT-Projekten, dass eine neue Fachanwendung teilweise oder komplett von der Zielgruppe abgelehnt wird. Aus der Erfahrung heraus ist der häufigste Grund dafür das fehlende Requirements Engineering. Der Dienstleister versteht nicht oder nur unvollständig, was der Kunde haben möchte und der Kunde kann sich nicht so ausdrücken, dass der Dienstleister ihn versteht. Und um die Situation noch schwieriger zu machen, ist das, was der Kunde möchte, nicht zwingend das, was der Kunde auch tatsächlich benötigt. Das herauszufinden und nicht nur das Gesagte beziehungsweise Verstandene umzusetzen, ist die noch größere Schwierigkeit.

Wenn Sie nicht wissen, was Ihr Kunde von Ihnen erwartet, werden Sie fast todsicher die falsche Wahl treffen, es sei denn, Sie sollen eine Münze werfen und der Kunde erwartet Zahl – dann haben Sie eine Chance von 50:50. Anforderungen haben demzufolge viel mit Erwartungshaltungen zu tun und daher auch mit Zielen. Diese sollte man klären, ehe man das Projekt startet.

Wenn Sie die Anforderungen und Erwartungshaltungen nicht klären, werden Sie im Laufe des Projekts immer wieder und häufiger auf Widerstände stoßen, welche mit folgenden Fragen und Aussagen einhergehen:

  • Warum haben Sie das so umgesetzt?
  • Warum kann ich hier nicht X sehen?
  • Wer hat denn gesagt, dass das hier an der Stelle sein soll/diese Farbe haben soll?
  • Also unsere Experten hätten das so und so gemacht.

Das sind Fragen und Aussagen, die Ihnen im Laufe des Projekts das Genick brechen werden, weil Sie sie nicht mehr beantworten können, wenn Sie die Anforderungen nicht aufgenommen und dokumentiert haben.

Situationen, in denen RE genutzt werden sollte

RE sollte tatsächlich wesentlich häufiger bewusst genutzt werden. Es kommt nicht immer darauf an, alle Methoden bis ins letzte Detail durchzuziehen, aber gewisse Grundlagen sollten in jedem Projekt realisiert sein. Im Laufe meiner beruflichen Tätigkeit habe ich einige Projekt begleitet und geleitet und folgende Situationen vermerkt, die RE, in welchem Umfang auch immer, sinnvoll werden lassen, wobei nur eine davon zutreffen muss:

1. Der Kunde ist mir neu

2. Die Branche ist mir neu

3. Die regionalen Gegebenheiten sind mir neu (i.d.R. erst europaweit relevant)

  Beispiel: Religion, kulturelle Gepflogenheiten, Sprache

4. Das umzusetzende Projekt ist mir neu

  Beispiel: Wenn ich noch nie ein Vertragsmanagementtool entworfen habe, ist mir das neu

5. Das umzusetzende Projekt bei diesem Kunden ist mir neu

  Beispiel: Der Kunde möchte ein neues Projekt starten

Der aufmerksame Leser wird erkennen, dass eine RE nur dann nicht mehr gemacht werden muss, wenn ich bei diesem einen Kunden das Vorprojekt für beispielsweise das Vertragsmanagement bereits selbst gemacht habe und auch dann möchte ich meinen, dass der Kunde inzwischen neue und andere Anforderungen hat.

Fazit

Das heißt also schlussendlich: Es gibt keine (mir bekannten) Gründe, warum RE nicht sinnvoll ist. RE ist in jedem beruflichen oder privaten Projekt sinnvoll und wenn es nur das gemeinsame einstündige Brainstorming ist, an dessen Ende drei Anforderungen für beispielsweise die neue Terrasse herauskommen:

1. Material: Holz

2. Lage: Halbschattig in der Nähe des Bachs

3. Größe: Platz für drei Liegen und einem Esstisch mit vier Stühlen

Ein Weg (sicherlich nicht der einzige) in die richtige Richtung bei den ersten Schritten im Hinblick auf den Projektstart stelle ich in Teil 2 der Serie vor.

 

Die kommende Blogserie im Überblick

Teil 1: Requirements Engineering – Gründe für RE und auch dagegen

Teil 2: Requirements Engineering – Erste wichtige Schritte bei RE

Teil 3: Requirements Engineering – Zielmodelle nutzen, um Anforderungen zu definieren

Teil 4: Requirements Engineering – Dokumentation der Anforderungen

Teil 5: Requirements Engineering – Erfahrungen mit RE in der Praxis des IT-Umfelds

Sie wünschen sich Unterstützung?

Sie wünschen sich eine individuelle Beratung oder haben Fragen zu einem Requirements Engineering in Ihrem Unternehmen? Kein Problem. Wir unterstützen Sie gern bei Ihrem Anliegen.

Kontaktieren Sie uns
  • Mittwoch 13 November 2019

Kommentieren Sie diesen Artikel

Hinterlassen Sie einen Kommentar, um uns mitzuteilen, was Sie von diesem Thema halten!

Kommentar hinterlassen

Autor

Henrik Krumbholz Senior Consultant SharePoint

  • 03 Dezember 2019
  • Henrik Krumbholz
  • User Productivity

Requirements Engineering: Erste wichtige Schritte bei RE

Requirements Engineering: Wie beginnt man sinnvoll mit der Einführung? Wir zeigen die ersten wichtigen Schritte auf, die beim Start von RE helfen.

So steuern und kontrollieren Sie Assets in der Adobe Creative Cloud und Document Cloud
  • 04 Juni 2019
  • Tobias Hübner
  • Publisher Advisory, User Productivity
  • Adobe

So steuern und kontrollieren Sie Assets in der Adobe Creative Cloud und Document Cloud

In der Adobe Creative Cloud und Document Cloud gibt es Tools, um die Verbreitung von Assets zu kontrollieren. Wir erklären, wie sie funktionieren.

Einführung in PowerApps
  • 16 Mai 2019
  • User Productivity, Unified Communications
  • PowerApps, SharePoint

Einführung in PowerApps

PowerApps ist ein Microsoft Dienst zur Erstellung von Business-Apps für Ihr Unternehmen. Hier erfahren Sie alles zu den Vorteilen und Anwendungsbereichen.