Teil 01: Warum jedes Projekt sein Rezept braucht

Eine Einführung in Requirements Engineering für Neueinsteiger

 

Stell Dir vor, Du willst für Deine Familienfeier einen Marmorkuchen backen. Ohne Rezept. Du wirfst einfach irgendwelche Zutaten zusammen und hoffst auf das Beste und wunderst Dich am Ende, warum der Kuchen nicht schmeckt, zu trocken ist oder gar nicht erst aufgeht. Genau das passiert täglich in unzähligen IT-Projekten weltweit. Teams stürzen sich in die Entwicklung, ohne zu wissen, was genau sie eigentlich bauen sollen. Das Ergebnis! Gescheiterte Projekte, frustrierte Stakeholder und verschwendete Ressourcen.

Das Problem: Projekte ohne klare Anforderungen

Laut dem Chaos Report 2020 des Standish Group scheitern noch immer 19% aller IT-Projekte vollständig, während nur 31% als erfolgreich eingestuft werden. Der Hauptgrund? Unklare oder sich ständig ändernde Anforderungen. Stell Dir vor, Du würdest einem Bäcker sagen: "Backen Sie mir etwas Süßes für 20 Personen. Es soll lecker sein und nicht zu teuer." Was würdest Du erwarten? Einen Schokoladenkuchen? Cupcakes? Donuts? Der Bäcker wäre genauso ratlos wie ein Entwicklerteam ohne klare Requirements.

Typische Szenarien aus der Praxis​​

Szenario 1: Der "Ich erkenne es, wenn ich es sehe"-Kunde: "Entwickeln Sie uns eine moderne Webanwendung. Sie wissen schon, benutzerfreundlich und schnell." Das ist, als würdest Du sagen: "Backen Sie einen Kuchen. Er soll gut aussehen und schmecken."

​

Szenario 2: Der Scope-Creep-Spezialist: "Ach übrigens, die App braucht auch noch eine mobile Version. Und KI-Features wären toll. Aber Budget und Timeline bleiben gleich." In unserem Kuchenbeispiel: "Der Kuchen soll auch glutenfrei sein. Und vegan. Und für Diabetiker geeignet. Aber kosten soll er nicht mehr."

 

Szenario 3: Der Stille-Post-Effekt: Der CEO wünscht sich "bessere Kundenkommunikation", der CTO interpretiert das als "Chatbot", die Projektleiterin denkt an "CRM-System" und das Entwicklerteam baut ein "Forum".

Die versteckten Kosten unklarer Anforderungen

Unklare Requirements kosten nicht nur Geld – sie zerstören Vertrauen, Motivation und Beziehungen:

• Finanzielle Kosten: Nachbesserungen in späten Projektphasen kosten das 10-100fache der ursprünglichen Anforderungserhebung

• Zeitverlust: Projekte dauern im Durchschnitt 222% länger als geplant, wenn Requirements nicht klar definiert sind

• Reputation: Gescheiterte Projekte beschädigen das Vertrauen zwischen Auftraggeber und Auftragnehmer nachhaltig

• Opportunitätskosten: Während das falsche System gebaut wird, erobert die Konkurrenz den Markt

Die Lösung: Requirements Engineering als Fundament

Requirements Engineering ist die systematische Herangehensweise an die Ermittlung, Analyse, Spezifikation und Verwaltung der Anforderungen an ein System. Es ist das Rezept für Dein Projekt. Genau wie ein gutes Kuchenrezept beantwortet Requirements Engineering die wichtigsten W-Fragen:

• Was soll gebaut werden? (Zutaten)

• Warum wird es gebraucht? (Anlass)

• Wer nutzt es? (Gäste)

• Wie soll es funktionieren? (Zubereitungsschritte)

• Wann wird es benötigt? (Backzeit)

• Wo wird es eingesetzt? (Küchenbedingungen)

Die drei Säulen des Requirements Engineering

1. Erhebung (Requirements Elicitation) :Wie bei einem Familienrezept musst Du erst herausfinden, was alle Beteiligten wollen. Mag Onkel Herbert keine Rosinen? Ist Tante Emma Diabetikerin? Welche Größe soll der Kuchen haben?

2. Analyse und Spezifikation: Jetzt schreib das Rezept auf – so präzise, dass es jeder nachbacken kann. 250g Mehl, nicht "etwas Mehl". 180°C Umluft, nicht "mittlere Hitze".

3. Verwaltung (Requirements Management): Rezepte ändern sich. Neue Allergien kommen dazu, Zutaten werden verfügbarer oder teurer. Ein gutes Requirements Management sorgt dafür, dass alle Beteiligten über Änderungen informiert sind.

Die Anatomie eines guten "Projekt-Rezepts"

Agile Projekte: Der experimentelle Bäcker: In agilen Projekten entwickeln wir das Rezept iterativ. Wir backen erst einen kleinen Testkuchen, lassen probieren, passen an und wiederholen. Die Requirements werden in Form von User Stories formuliert und kontinuierlich verfeinert.

​

Traditionelle Projekte: Das Familienrezept: Bei traditionellen Projekten schreiben wir das komplette Rezept vor dem ersten Backvorgang. Das funktioniert gut, wenn wir genau wissen, was wir wollen und die Rahmenbedingungen stabil sind.

Hybride Ansätze: Das flexible Rezept

 

Viele erfolgreiche Projekte kombinieren beide Ansätze: Ein grobes Rezept als Rahmen, aber flexibel genug für Anpassungen während der "Zubereitung"

Die häufigsten Fehler und wie Sie sie vermeiden

• Fehler 1: Requirements zu früh "einfrieren" - Stellen Dir vor, Du entscheidest Dich für ein Rezept, bevor Du weisst, wie viele Gäste kommen. Requirements sind lebende Dokumente – sie müssen anpassbar bleiben.

• Fehler 2: Alle Stakeholder ignorieren - Der Kuchen mag Dir schmecken, aber was ist mit den Gästen? Vergessene Stakeholder rächen sich immer – meist kurz vor Projektende. 

• Fehler 3: Zu technisch werden - Requirements beschreiben das "Was", nicht das "Wie". "Der Kuchen soll saftig sein" ist ein Requirement. "Mit Buttermilch statt normaler Milch" ist ein Implementierungsdetail.

Requirements Engineering Starter-Kit

1.  Stakeholder-Liste erstellen: Wer sind die "Gäste" Deines Projekts? Liste alle auf, die das Ergebnis beeinflussen oder davon betroffen sind. 

2. Die "5 Warum"-Technik anwenden: Frag Dich (oder Deinen Auftraggeber) fünfmal "Warum?", um zum wahren Bedürfnis vorzudringen. Beispiel:

• "Warum brauchen Sie eine neue Website?" – "Die alte ist hässlich."

• "Warum ist das ein Problem?" – "Kunden verlassen sie schnell."

• "Warum verlassen sie sie?" – "Sie finden nicht, was sie suchen."

• "Warum finden sie es nicht?" – "Die Navigation ist unlogisch."

• "Warum ist sie unlogisch?" – "Sie wurde nie mit echten Nutzern getestet."

3. Ein einfaches Requirements-Template verwenden. Beginnen Sie mit diesem einfachen Format:

​

Als [Rolle] möchte ich [Funktionalität] damit [Nutzen].

Beispiel: "Als Online-Shop-Kunde möchte ich Produkte in einen Warenkorb legen können, damit ich mehrere Artikel auf einmal kaufen kann."

Fazit: Jedes Projekt verdient sein Rezept

Ein Marmorkuchen ohne Rezept wird selten gelingen. Ein IT-Projekt ohne klare Requirements noch seltener. Requirements Engineering ist keine lästige Pflicht, sondern die Grundlage für jeden Projekterfolg. Beginne heute damit, die wichtigsten Fragen zu stellen:

 

• Was willst Du wirklich erreichen?

• Wer sind Deine Stakeholder?

• Wie wirst Du Deinen Erfolg messen?

 

Denn am Ende des Tages ist es viel einfacher, ein gutes Rezept zu befolgen, als aus einem misslungenen Kuchen noch etwas Genießbares zu zaubern.

Artefakte und Dokumente für den Einstieg

Die folgenden Dokumente helfen Dir dabei, Requirements Engineering in Ihrem nächsten Projekt umzusetzen:

Stakeholder-Register

Liste aller Projektbeteiligten

• Kontaktdaten und Rollen

• Einfluss und Interesse bewerten

• Kommunikationspräferenzen

Requirements-Liste (einfach)

Eindeutige ID für jedes Requirement

• Beschreibung in klarer Sprache

• Priorität (Hoch/Mittel/Niedrig)

• Status (Neu/Analysiert/Genehmigt/Implementiert)

Stakeholder-Map

Visualisierung der Beziehungen zwischen Stakeholdern

• Einfluss vs. Interesse Matrix

• Kommunikationswege

Templates für den Start

 

User Story Template

Als [Rolle] möchte ich [Funktionalität] damit [Nutzen/Grund]. Akzeptanzkriterien: - Kriterium 1 - Kriterium 2 - Kriterium 3

Requirement-Dokumentation (traditionell)

REQ-001: [Titel] Beschreibung: [Was soll das System tun?] Priorität: [Hoch/Mittel/Niedrig] Quelle: [Wer hat es gefordert?] Akzeptanzkriterien: [Wie wird Erfolg gemessen?]

Prüflisten

Requirements-Qualitätsprüfung

•  Ist das Requirement eindeutig formuliert?

•  Ist es testbar?

•  Ist es vollständig?

•  Ist es realisierbar?

•  Ist es nachverfolgbar?

 

Ausblick: Was kommt als Nächstes?

In den kommenden Artikeln dieser Serie werden wir tiefer in die Kunst des Requirements Engineering eintauchen. Wir lernen:

1. Wie Du die "Zutaten" Deines Projekts sammeln kannst (Stakeholder-Analyse)

2. Welche Arten von Requirements es gibt (funktionale vs. nicht-funktionale)

3. Wie Du das perfekte "Mischverhältnis" findest (Priorisierung)

4. Und vieles mehr...

 

Über die Autorin: Michaela Kühn, Sparringspartnerin zum Thema Requirements Engineeting

 

Hast Du Fragen oder eigene Erfahrungen mit Requirements Engineering? Teilen Sie sie in den Kommentaren oder diskutieren Sie mit mir auf LinkedIn.