Vorlage zur Anforderungserhebung: 7 Kniffe aus meinen Projekten

Eine Vorlage zur Anforderungserhebung verdient ihren Platz nur, wenn sie die schwierigen Gespräche früh erzwingt: Wer unterschreibt, wer kann blockieren, wie sieht Erfolg aus und wie schnell muss das System sein. Dieser Leitfaden richtet sich an Projektleiter, Business-Analysten und SAP-Verantwortliche, die eine Vorlage brauchen, die über den ersten Lenkungsausschuss hinaus trägt. Unten steht die vollständige Gliederung, die ich verwende, mit einem Verantwortlichen für jeden Abschnitt, den fünf Abschnitten, die ich nie auslasse, und sieben Kniffen für Interviews, Priorisierung und Änderungen. Kopieren Sie die Gliederung in Ihr eigenes Dokument und füllen Sie sie aus, bevor der Entwurf beginnt.

Ich habe einmal erlebt, wie ein Projekt im sechsstelligen Bereich implodierte, weil niemand ordentlich Anforderungen erhoben hatte. Der Kunde erwartete das eine. Das Entwicklungsteam baute etwas anderes. Jeder wurde zum Sündenbock erklärt, und genau da wurde ich dazugeholt.

Das Muster ist nicht ungewöhnlich. Der Pulse-of-the-Profession-Bericht des PMI von 2014 zum Anforderungsmanagement ergab, dass 47 % der erfolglosen Projekte ihre Ziele wegen mangelhaften Anforderungsmanagements verfehlten. Ich habe das dutzende Male erlebt.

Beinahe wäre ich bei einem großen System-Rollout selbst in dieselbe Lage geraten. Die Stakeholder waren überall und nirgends. Die Entwickler rieten. Wir hielten an, stellten eine ordentliche Anforderungsvorlage zusammen und lieferten, was das Business brauchte, termingerecht und im Budget.

Das Unternehmen eines Freundes gab 350.000 $ für ein individuell entwickeltes CRM aus, das niemand nutzt. Der Vertrieb brauchte das eine, das Marketing wollte etwas anderes, und die Entwickler bauten, was ihrer Meinung nach alle wollten.

Ein Kunde aus dem Gesundheitswesen verschwendete 18 Monate auf eine EMR-Einführung, die die Ärzte nicht nutzen wollten. Niemand hatte sie gefragt, was sie in ihrem Arbeitsalltag brauchten. Das Projekt wurde eingestellt und neu gestartet.

Spätes Entdecken ist teuer. Eine NASA-Studie zur Kostenentwicklung von Fehlern stellte fest, dass ein Anforderungsfehler, der in Integration und Test entdeckt wird, 21- bis 78-mal so viel in der Behebung kostet wie einer, der in der Anforderungsphase auffällt. Im Betrieb entdeckt, lag das Vielfache zwischen 29 und mehr als 1.500. In einem Enterprise-Programm ist das der Unterschied zwischen einem Workshop und einem Change Request über mehrere Hunderttausend.

1. AnforderungenDie Basiskosten der BehebungEntdeckt, solange die Anforderungen noch geschrieben werden
2. Integration und Test21 bis 78 Mal so teuerEntdeckt, sobald das System gebaut ist und getestet wird
3. Betrieb29 bis mehr als 1,500 Mal so teuerEntdeckt, nachdem das System live ist

Quelle: NASA-Studie zur Kostenentwicklung von Fehlern

Nachdem ich das auf die harte Tour gelernt habe, sind das die fünf Abschnitte, die keine Anforderungsvorlage auslassen sollte.

1. Management-Zusammenfassung mit Unterschriftenblock

Beschäftigte Führungskräfte lesen kein Anforderungsdokument mit 30 Seiten. Ich hatte einmal einen Sponsor, der ein Projekt freigab, ohne zu verstehen, was er unterschrieb, und dann die Beherrschung verlor, als er das Ergebnis sah. Beschränken Sie sich auf eine Seite: Geschäftsauswirkung, Zeitplan, Ressourcen, erwarteter Nutzen und ein Unterschriftenblock auf derselben Seite, damit die Freigebenden nicht behaupten können, sie hätten die entscheidenden Details übersehen.

2. Rollen- und Einflussanalyse

Eine Namensliste reicht nicht. Sie brauchen eine Machtkarte: Wer kann das Projekt versenken, wer muss konsultiert werden, wer braucht nur Updates. In einem früheren Job waren wir sechs Monate in der Entwicklung, als die Rechtsabteilung mit Anforderungen kam, die ein Redesign erzwangen. Niemand hatte daran gedacht, sie einzubeziehen. Erfassen Sie jede betroffene Abteilung, ihren Vertreter und ihren Einfluss.

3. Geschäftsziele, keine technischen Anforderungen

Welches Problem lösen wir, und woran messen wir den Erfolg? Ein Fertigungskunde führte eine Bestandssoftware exakt nach Spezifikation ein, und sie verlangsamte den Lagerbetrieb um 20 %. Die Vorlage sollte die Stakeholder zwingen, geschäftlichen Erfolg mit einem aktuellen Ausgangswert zu definieren, nicht mit einer Funktionsliste.

4. Funktionale Anforderungen, mit denen Entwickler arbeiten können

Lassen Sie den Jargon weg. Machen Sie jede Anforderung konkret und testbar. „Das System soll die Kundenerfahrung verbessern“ ist nutzlos. „Anwender müssen eine Retoure bearbeiten und eine Erstattung in unter 3 Minuten auslösen können“ ist eine Anforderung. Wenn Sie nicht prüfen können, ob sie erfüllt wurde, schreiben Sie sie neu.

5. Nichtfunktionale Anforderungen

Performance, Sicherheit, Compliance, Verfügbarkeit, Skalierbarkeit. Diesen Abschnitt lassen fast alle aus, und dann bricht das System unter Last zusammen oder fällt bei einem Security-Audit durch. Ich habe von einem Handelsprojekt gehört, in dem das System bis zum Black Friday einwandfrei lief und dann unter der Last zusammenbrach, weil niemand Performance-Anforderungen festgelegt hatte. Halten Sie Antwortzeiten, Verfügbarkeit, Spitzenlasten der Nutzer und Compliance-Pflichten als Zahlen fest.

Hier ist die vollständige Gliederung. Die fünf Abschnitte von oben stecken darin, zusammen mit den Protokollen, die sie nach der Freigabe am Leben halten.

Abschnitt	Was hineingehört	Verantwortlich	Freigabe durch
1. Management-Zusammenfassung	Problem, Geschäftsauswirkung, Zeitplan, Ressourcen, erwarteter Nutzen. Eine Seite mit Unterschriftenblock	Sponsor, Entwurf durch BA-Leiter	Sponsor und Finanzen
2. Scope und Bereitstellungs-Baseline	Was im und außerhalb des Scopes liegt, Randbedingungen. Für SAP: Public Edition, Private Edition oder On-Premise	Programmleiter	Lenkungsausschuss
3. Rollen- und Einflusskarte	Abteilungen, Vertreter, Einflussniveau, konsultieren oder informieren	BA-Leiter	Sponsor
4. Geschäftsziele	Jedes Ziel mit einem KPI, seinem aktuellen Ausgangswert und einem Zielwert	Prozessverantwortliche	Sponsor
5. Funktionale Anforderungen	ID (z. B. REQ-FUN-023), Beschreibung, Herkunft, Priorität, Abnahmekriterien, Fit-to-Standard-Entscheidung	Funktionale Leads	Prozessverantwortliche
6. Nichtfunktionale Anforderungen	Performance, Sicherheit, Compliance, Verfügbarkeit; bei SAP der Erweiterungsansatz für jede Lücke	Lösungsarchitekt	IT, Sicherheit und Compliance
7. Parkplatz	Zurückgestellte Anfragen, wer gefragt hat, nächstes Prüfdatum	BA-Leiter	Keine, bis sie hochgestuft werden
8. Ablehnungsprotokoll	Was abgelehnt wurde, warum, wann und von wem	BA-Leiter	Sponsor
9. Änderungsprotokoll	Jede Änderung nach der Freigabe mit ihren Auswirkungen auf Zeit und Kosten	PMO	Change Board

1. Die Fünf-Warum-Methode in Stakeholder-Interviews nutzen

Fragen Sie „Was brauchen Sie?“, und Sie bekommen eine Wunschliste. Fragen Sie stattdessen nach dem Schmerz: „Was bringt Sie dazu, Ihren Computer aus dem Fenster werfen zu wollen?“ Dann fragen Sie nach dem Warum, und noch einmal nach dem Warum, fünfmal. Die eigentliche Anforderung unterscheidet sich meist von der ersten Anfrage.

Ein Stakeholder bestand auf komplexen Berichtsfunktionen. Nachdem wir seine tatsächlichen Anwendungsfälle durchgegangen waren, brauchte er drei einfache Dashboards.

2. Einen Parkplatz für Anforderungen anlegen

Ein beachtlicher Teil dessen, was Stakeholder verlangen, wird nie genutzt. Wenn jemand auf etwas Fragwürdigem beharrt, diskutiere ich nicht. Ich lege es auf den Parkplatz und schicke jeden Monat eine Erinnerung mit der Frage, ob es zu den aktiven Anforderungen wechseln soll. Die meisten bleiben für immer dort stehen.

3. Die Dreierregel für Stakeholder, die ständig ihre Meinung ändern

Zweimal dürfen sie die Richtung ohne Folgen ändern. Bei der dritten Änderung schreiben sie ihrem Vorgesetzten eine E-Mail, in der sie die Änderung und ihre Auswirkungen erklären. Niemand will diese E-Mail schicken. Die Änderungen hören auf.

4. Mit der Technik der Mittelverteilung eine Priorisierung erzwingen

Geben Sie jedem Stakeholder 100 virtuelle Dollar, die er auf alle Anforderungen verteilen kann. Er kann nicht alles haben, also setzt er das Geld dort ein, wo es zählt. Ich habe das bei einem Finanzdienstleister gemacht, der mehr als 200 „kritische“ Anforderungen hatte. Innerhalb einer Stunde hatten wir die echten Top 20.

5. Jede Anforderung nummerieren

Nutzen Sie ein einheitliches Format wie REQ-FUN-023. Es beendet die Verwirrung „Über welche Anforderung reden wir gerade?“, die Besprechungszeit verschwendet. Halten Sie die Herkunft fest, wer gefragt hat und warum, damit Sie wissen, wen Sie anrufen, wenn Punkte gestrichen werden müssen.

6. Anforderungen in der Sprache des Stakeholders zurückspielen

Lesen Sie die Anforderungen nach der Dokumentation den Stakeholdern in deren eigenen Worten vor. Bauen Sie für alles Komplexe einen schnellen Prototyp oder Wireframe, bevor die Entwicklung beginnt. Missverständnisse kommen ans Licht, solange sie noch günstig sind.

7. Dokumentieren, was abgelehnt wurde

Irgendjemand bringt im fünften Monat eine abgelehnte Anforderung zurück. „Wir haben das im April besprochen, und hier steht, warum wir uns dagegen entschieden haben“ beendet dieses Gespräch schnell. Ohne das Protokoll führen Sie die Diskussion von vorn.

Die sieben Kniffe funktionieren in jedem Projekt. SAP-Programme brauchen in der Vorlage drei zusätzliche Dinge.

Das Bereitstellungsmodell gehört in die Baseline

Halten Sie das Bereitstellungsmodell fest, bevor Sie funktionale Anforderungen erheben: S/4HANA Cloud Public Edition (über GROW with SAP oder RISE), Private Edition (meist über RISE) oder On-Premise. Es bestimmt, was möglich ist. Die Public Edition erlaubt keine Modifikation des Kerns, daher müssen Anforderungen, die von Nicht-Standardprozessen abhängen, umgeformt oder abgelehnt werden. Private Edition und On-Premise erlauben mehr, auf Kosten von Upgrade-Aufwand.

Erheben Sie Anforderungen vor dieser Entscheidung, werden Sie viele davon neu schreiben, sobald sie fällt.

Eine Erweiterungsentscheidung für jede Lücke

Der Clean-Core-Ansatz von SAP bedeutet, dass jede Lücke eine dokumentierte Entscheidung braucht: konfigurieren, über freigegebene APIs erweitern (On-Stack mit ABAP Cloud oder Side-by-Side auf SAP BTP) oder ablehnen. In der Public Edition erzwingt das Produkt dies. In der Private Edition und On-Premise ist es eine klare Empfehlung von SAP, und jede Modifikation, die Sie zulassen, wird später zu Upgrade-Arbeit. Tragen Sie die Entscheidung in Abschnitt 6 der Vorlage ein, neben Performance und Sicherheit, und geben Sie einem Architekten die Befugnis, sie freizugeben. Mein Leitfaden zu Clean Core erklärt die Level.

KI entwirft, Menschen entscheiden

KI hilft inzwischen beim Schreibkram. SAP Cloud ALM bietet eine Funktion zur Generierung von Anforderungen, die aus Transkripten von Fit-to-Standard-Workshops Anforderungen in einer Vorlage entwirft und über AI Units abgerechnet wird. Allgemeine Assistenten wie Microsoft Copilot entwerfen Zusammenfassungen und Protokolle aus Besprechungsnotizen.

KI-Entwurfswerkzeuge sparen beim Schreibkram echte Zeit, wenn das Quellmaterial sauber ist. Das Interview ändern sie nicht. Die Warum-Fragen stellt weiterhin ein Mensch. Und kein Werkzeug bringt einen Abteilungsleiter dazu, die Management-Zusammenfassung zu unterschreiben. Validierung, Priorisierung und Freigabe bleiben Menschenarbeit.

Softwareentwicklung. Ergänzen Sie technische Randbedingungen, Integrationspunkte, User Flows (die tatsächlichen Schritte der Anwender, nicht nur die Funktionen) und Abnahmekriterien mit klarem Bestanden/Nicht bestanden. Das haben wir bei einem Kundenportal-Projekt versäumt und drei Monate darüber gestritten, ob Funktionen „richtig funktionieren“.

Prozessverbesserung. Bilden Sie den Ist-Zustand samt all der unsauberen Umgehungslösungen ab, die in Besprechungen nicht erwähnt werden, bewerten Sie die Auswirkungen je Rolle und erfassen Sie harte Performance-Ausgangswerte. Ein Fertigungskunde überarbeitete seinen Lagerprozess ohne Ausgangswerte. Sechs Monate später konnte er weder die Verbesserung belegen noch die Ausgaben rechtfertigen.

Anbieterauswahl. Trennen Sie Muss- von Kann-Kriterien, gewichten Sie die Bewertungskriterien und beschreiben Sie Erwartungen an Support und Einführung bis ins schmerzhafte Detail. Ich habe erlebt, wie ein Unternehmen einen Anbieter fast ausschließlich nach Funktionen und dem Eindruck der Demo wählte. Es ignorierte die Support-Anforderungen und stand am Ende mit einem System da, das es ohne hohe zusätzliche Beratungskosten nicht einführen konnte.

Für kleinere Projekte: Trello, um Anforderungen durch die Freigabestufen zu führen, Google Docs mit Kommentaren für das Review und Miro für die Prozessabbildung in Workshops.

Für Enterprise-Programme: Jira mit einem Add-on für Anforderungsmanagement, Confluence für lebende Dokumente (die KI-Funktionen laufen inzwischen unter der Marke Rovo von Atlassian) und Modern Requirements, wenn Sie Azure DevOps nutzen. In SAP-Programmen hält SAP Cloud ALM Anforderungen, User Stories und Testfälle an einem Ort, verknüpft mit der SAP-Activate-Roadmap.

Das Werkzeug zählt weniger als die Verknüpfung. Verbinden Sie Anforderungen mit Ihrem Projektplan und Ihren Testfällen und verschicken Sie automatische Benachrichtigungen, wenn sich eine Anforderung ändert. „Ich wusste nicht, dass sich das geändert hat“ bringt mehr Projekte zu Fall als schlechte Werkzeuge. Sind die Anforderungen einmal freigegeben, zeigt mein Leitfaden zum Vermeiden von Scope Creep in SAP-Einführungen, wie das so bleibt, und die SAP Quality Gates zeigen, wo die Freigabe der Anforderungen im Governance-Zyklus ihren Platz hat.

Eine Vorlage, die nach der Freigabe niemand mehr öffnet, ist Theater. Die, die funktionieren, sind kurz, abschnittsweise verantwortet und werden jedes Mal aktualisiert, wenn jemand seine Meinung ändert, und das passiert in jedem Programm, das sich zu führen lohnt, jede Woche.

Was sind die 5 Phasen der Anforderungserhebung?

1. Ermittlung: Informationen durch Interviews, Workshops und Beobachtung sammeln
2. Analyse: Anforderungen ordnen, priorisieren und Konflikte zwischen ihnen lösen
3. Dokumentation: die Spezifikation schreiben (BRD, FRD oder User Stories, je nach Methode)
4. Validierung: bestätigen, dass die Anforderungen den tatsächlichen Bedarf abbilden und testbar sind
5. Verwaltung: Änderungen für den Rest des Projekts nachverfolgen

Jede Phase baut auf der vorigen auf. Wer die Ermittlung überstürzt, wie es die meisten Teams tun, schafft Probleme in jeder späteren Phase.

Was ist der Unterschied zwischen einem BRD und einem FRD?

Ein Business Requirements Document (BRD) beschreibt den fachlichen Bedarf: Hintergrund, Ziele, Stakeholder, Randbedingungen und übergeordnete Anforderungen. Es beantwortet die Frage „Was braucht das Business?“

Ein Functional Requirements Document (FRD) beschreibt, wie sich das System verhalten wird: User Stories, Systemverhalten, Schnittstellen und Abnahmekriterien. Es beantwortet die Frage „Was muss das System leisten?“

Ich beginne immer mit dem BRD, um vor dem FRD die fachliche Abstimmung zu erreichen. Teams, die direkt zum FRD springen, bauen oft ein technisch korrektes System, das das falsche Problem löst.

Welche 3 Arten von Anforderungen gibt es?

1. Geschäftsanforderungen: warum das Projekt existiert, seine Ziele und Erfolgsmaße
2. Funktionale Anforderungen: was das System leisten muss
3. Nichtfunktionale Anforderungen: wie gut es das leisten muss (Performance, Sicherheit, Skalierbarkeit, Compliance)

Die meisten Projektpannen, die ich gesehen habe, gehen auf fehlende nichtfunktionale Anforderungen zurück. Das System tut, was verlangt wurde, bricht dann aber unter echter Last zusammen oder fällt bei einem Compliance-Audit durch.

Wie verändert das SAP-Bereitstellungsmodell die Anforderungserhebung?

Halten Sie es zuerst fest. S/4HANA Cloud Public Edition erlaubt keine Modifikation des Kerns, daher müssen Anforderungen, die auf Nicht-Standardprozessen beruhen, umgeformt oder abgelehnt werden. Private Edition und On-Premise bieten mehr Flexibilität, aber jede Modifikation erhöht den Upgrade-Aufwand.

Erheben Sie funktionale Anforderungen vor der Entscheidung, werden Sie viele davon überarbeiten müssen. Ergänzen Sie für jede Lücke eine dokumentierte Erweiterungsentscheidung (konfigurieren, über freigegebene APIs erweitern oder ablehnen).

Was macht eine Anforderung testbar?

Eine klare, messbare Bedingung für Bestanden oder Nicht bestanden. „Das System soll schnell sein“ ist nicht testbar. „Suchergebnisse müssen bei Standardlast für 95 % der Anfragen in unter 2 Sekunden zurückkommen“ ist es.

Mein Test: Können Sie den Testfall sofort schreiben, mit klaren Kriterien für Bestanden und Nicht bestanden? Wenn nicht, schreiben Sie die Anforderung neu. Nicht testbare Anforderungen verursachen mehr Streit zum Go-live als alles andere, was ich sehe.

Wie verhindert man, dass sich Anforderungen ständig ändern?

1. Änderungssteuerung: Jede Änderung nach der Freigabe dokumentiert ihre Auswirkungen auf Zeit, Budget und Ressourcen, bevor sie jemand genehmigt. Machen Sie die Kosten von Änderungen sichtbar.
2. Parkplatz: Neue Anfragen kommen auf den Parkplatz, nicht direkt in den Scope. Prüfen Sie monatlich. Die meisten scheinbar dringenden Anfragen überstehen das Warten nicht.
3. Quality Gates: Definieren Sie, was „Anforderungen vollständig“ bedeutet, und beginnen Sie erst mit dem Design, wenn das erfüllt ist.

In SAP-Programmen kommt mit der Erweiterungsentscheidung eine technische Prüfung hinzu: Eine Anfrage, die eine Modifikation des Kerns braucht, muss den Architekten passieren, bevor sie genehmigt werden kann.