Vorlagen · Anforderungen & Analyse
Vorlage für ein Geschäftsanforderungsdokument (BRD)
Diese kostenlose Vorlage für ein Dokument zu den geschäftlichen Anforderungen bietet Ihnen ein strukturiertes BRD in zwei Teilen: einen BRD-Überblick für Ziele, Umfang, Stakeholder und Freigabe sowie ein Anforderungsprotokoll , in dem jede Anforderung eine ID, einen Typ, eine Begründung, eine MoSCoW-Priorität, eine Quelle, Abnahmekriterien und einen Status hat. Download für Google Sheets, Excel oder PDF, in Einsteiger-, Fortgeschrittenen- oder Expertenversion.
Das Wichtigste in Kürze
- Ein Dokument zu den geschäftlichen Anforderungen (Business Requirements Document, BRD) hält fest, was das Unternehmen von einem Projekt braucht und warum und woran Sie erkennen, dass jeder Bedarf erfüllt wurde. Es beschreibt den Bedarf, nicht die Lösung.
- Die Vorlage hat zwei Tabs: einen BRD-Überblick mit zehn Abschnitten und ein Anforderungsprotokoll mit acht Spalten und Dropdowns für Typ, Priorität und Status.
- Gute Anforderungen sind lösungsneutral, prüfbar, eine pro Zeile formuliert und auf ein Geschäftsziel und eine Quelle zurückführbar.
- Priorisieren Sie mit MoSCoW und seien Sie streng: Wenn alles ein Must ist, ist nichts eines.
- Holen Sie die Freigabe ein, bevor Design oder Beschaffung beginnen, und steuern Sie Änderungen dann über einen Prozess für Änderungsanträge.
Kostenloser Download · ohne Anmeldung
Vorlage für das Dokument zu den geschäftlichen Anforderungen herunterladen
Wählen Sie Stufe und Format: Google Sheets, Excel oder ein druckfertiges PDF. Die Tabellen enthalten Dropdowns, Formeln und Beispielzeilen, die Sie überschreiben können.
Die vollständige Vorlage mit allen Tabs, Dropdowns und Formeln.
Was ist ein Dokument zu den geschäftlichen Anforderungen?
A Dokument zu den geschäftlichen Anforderungen (BRD) ist ein Dokument, das festlegt, was ein Unternehmen von einem Projekt oder einer Lösung braucht, warum es das braucht und wie Erfolg gemessen wird. Es umfasst Ziele, Umfang, Stakeholder, Randbedingungen und eine Liste priorisierter Anforderungen mit Abnahmekriterien. Es beschreibt, was benötigt wird, nicht wie es gebaut wird.
Ein BRD wird meist früh in einem Projekt geschrieben, nachdem die Idee in einem Business Case oder Projektauftrag genehmigt wurde und bevor Design, Entwicklung oder Beschaffung beginnen. Es gibt den Personen, die die Lösung bauen oder kaufen werden, ein klares, vereinbartes Ziel und dem Sponsor eine Grundlage, um das Ergebnis am Ende abzunehmen.
BRDs schreiben meist Business Analysts, bei kleineren Projekten oft aber auch der Projektmanager oder Product Owner. Wer auch immer es schreibt: Der Inhalt kommt von den Stakeholdern; das BRD ist eine geprüfte und vereinbarte Aufzeichnung dessen, was sie brauchen.
Das Gesamtbild zu übergeordneten und detaillierten Anforderungen finden Sie in unserem Leitfaden zu Projektanforderungen.
Vorschau der BRD-Vorlage
Der erste Tab ist der BRD-Überblick. Jeder Abschnitt hat einen kurzen Hinweis in der Spalte „Hinweise“; Ihre Antworten gehören in „Ihr Inhalt“.
| Abschnitt | Hinweise | Ihr Inhalt |
|---|---|---|
| Projektname und Verantwortlicher | ||
| Management-Zusammenfassung | Der Bedarf und das angestrebte Ergebnis in Kürze. | |
| Geschäftsziele | Messbare Ziele, die das Projekt unterstützt. | |
| Hintergrund / aktueller Zustand | Wie die Dinge heute funktionieren und welche Probleme es gibt. | |
| Umfang | Im Umfang und nicht im Umfang. | |
| Stakeholder | Wer betroffen ist und wer genehmigt. |
Die Beispielzeilen sind nur Beispiele: Ersetzen Sie sie durch Ihre eigenen.
Was die BRD-Vorlage enthält
Die Vorlage ist eine Tabelle mit zwei Tabs, die zusammenarbeiten. Der BRD-Überblick legt den Kontext in zehn kurzen Abschnitten fest; der Anforderungen -Tab listet jede Anforderung in einem strukturierten, filterbaren Protokoll auf.
- BRD-Überblick: Abschnitt, Hinweise, Ihr Inhalt
- Anforderungen: ID, Anforderung, Typ, Begründung, Priorität (MoSCoW), Quelle, Abnahmekriterien, Status
Tab „BRD-Überblick“
Drei Spalten (Abschnitt, Hinweise, Ihr Inhalt) und zehn Abschnitte: Projektname und Verantwortlicher, Management-Zusammenfassung, Geschäftsziele, Hintergrund / aktueller Zustand, Umfang, Stakeholder, Annahmen und Randbedingungen, Anforderungen (mit Verweis auf den Tab „Anforderungen“), Erfolgskriterien und Freigabe.
Tab „Anforderungen“
Acht Spalten: ID, Anforderung, Art, Begründung, Priorität (MoSCoW), Herkunft, Akzeptanzkriterien und Status. In der Fortgeschrittenen- und Expertenversion haben drei Spalten Dropdowns:
- Typ: Funktional, Nicht-funktional, Randbedingung, Daten, Reporting.
- Priorität (MoSCoW): Must, Should, Could, Won't.
- Status: Entwurf, Im Review, Genehmigt, Abgelehnt, Zurückgestellt.
Vier Beispielanforderungen für ein Kundenportal-Projekt zeigen, wie jede Spalte auszufüllen ist; überschreiben Sie sie mit Ihren eigenen.
Welche Version sollten Sie herunterladen?
| Version | Leistungsumfang | Am besten für |
|---|---|---|
| Einsteiger | Nur der Tab „BRD-Überblick“: zehn Abschnitte mit Hinweisen, plus leere Zeilen | Kleine Projekte, deren Anforderungen in wenige Absätze passen |
| Fortgeschritten | Beide Tabs: der BRD-Überblick und das vollständige Anforderungsprotokoll mit acht Spalten und Dropdowns für Typ, Priorität (MoSCoW) und Status | Die meisten Projekte mit einem Business Analyst oder mehreren Stakeholder-Gruppen |
| Experte | Alles aus der Fortgeschrittenenversion, plus ein Anleitungs-Tab, ein Dashboard, das Anforderungen automatisch nach Typ, MoSCoW-Priorität und Status zählt, farbcodierte Status (genehmigt, im Review, abgelehnt) und ein Tab für die Änderungshistorie | Größere Projekte, Beschaffungen und PMOs, die über den Fortschritt der Anforderungen berichten |
Was in ein Dokument zu den geschäftlichen Anforderungen gehört
Die zehn Überblicksabschnitte geben den Lesenden den Kontext, den sie brauchen, bevor sie zu den eigentlichen Anforderungen kommen. Hier steht, was in jeden gehört.
| Abschnitt | Was zu schreiben ist | Beispiel |
|---|---|---|
| Projektname und Verantwortlicher | Das Projekt und der fachliche Verantwortliche, der für die Anforderungen zuständig ist | Kundenportal; Leitung Kundenservice |
| Management-Zusammenfassung | Der Bedarf und das angestrebte Ergebnis in wenigen Sätzen. Schreiben Sie dies zuletzt | Kunden können Rechnungen nicht selbst einsehen oder Passwörter zurücksetzen und rufen daher beim Support an. Ein Self-Service-Portal wird die Anrufe reduzieren. |
| Geschäftsziele | Messbare Ziele, die das Projekt unterstützt | Kontobezogene Anrufe innerhalb von 6 Monaten nach dem Launch um 30 % senken |
| Hintergrund / aktueller Zustand | Wie die Dinge heute funktionieren und welche Probleme es gibt | Alle Kontoänderungen laufen per Telefon oder E-Mail über das Supportteam |
| Umfang | Was im Umfang ist und was nicht | Im Umfang: Kontoansicht, Rechnungen, Passwortzurücksetzung. Nicht im Umfang: mobile App, Zahlungen |
| Stakeholder | Wer betroffen ist und wer genehmigt | Kundenservice, IT, Finanzen, Recht, Kunden |
| Annahmen und Randbedingungen | Was Sie annehmen und innerhalb welcher Grenzen Sie arbeiten müssen | Abrechnungs-API bis Februar verfügbar; Daten müssen in der EU bleiben |
| Anforderungen | Ein Verweis auf den Tab „Anforderungen“ | Siehe Tab „Anforderungen“ (BR-01 bis BR-04) |
| Erfolgskriterien | Wie Sie den Erfolg nach der Lieferung beurteilen | Anrufvolumen, Nutzung des Portals, Kundenzufriedenheit |
| Freigabe | Namen, Rollen und Termine der Freigebenden | Sponsor, IT-Leitung, Datenschutzbeauftragter |
Viele veröffentlichte BRD-Formate enthalten zudem eine Kosten-Nutzen-Analyse. Wenn Ihr Projekt bereits einen Business Case hat, verlinken Sie ihn, statt die Zahlen zu wiederholen; das BRD sollte sich auf die Bedürfnisse konzentrieren. Unser Leitfaden zur Kosten-Nutzen-Analyse erklärt die Methode, falls Sie eine brauchen.
So formulieren Sie gute geschäftliche Anforderungen
Das Anforderungsprotokoll ist das Herzstück des BRD. Eine gute Anforderung ist:
- Notwendig: Sie unterstützt ein Geschäftsziel. Wenn Sie nicht sagen können, welches, stellen Sie sie infrage.
- Lösungsneutral: Sie sagt, was benötigt wird, nicht wie es gebaut wird. „Kunden müssen ihr Passwort zurücksetzen können, ohne den Support zu kontaktieren“ lässt das Design offen.
- Klar: Nur eine vernünftige Lesart. Vermeiden Sie Wörter wie „benutzerfreundlich“, „schnell“ oder „flexibel“ ohne Maßstab.
- Prüfbar: Jemand kann prüfen, ob sie erfüllt wurde. Dafür ist die Spalte „Abnahmekriterien“ da.
- Atomar: Eine Anforderung pro Zeile. Teilen Sie alles auf, was mit „und“ verbunden ist.
- Rückverfolgbar: Sie hat eine ID, eine Quelle (eine Person, ein Dokument, eine Vorschrift oder Daten) und eine Begründung.
| Schwache Anforderung | Bessere Anforderung | Warum sie besser ist |
|---|---|---|
| Das Portal soll schnell sein | Seiten müssen in unter 2 Sekunden laden (95. Perzentil) | Messbar und prüfbar |
| Einen per CRM versendeten Link zur Passwortzurücksetzung nutzen | Kunden müssen ihr Passwort zurücksetzen können, ohne den Support zu kontaktieren | Nennt den Bedarf, nicht die Lösung |
| Kunden können Rechnungen einsehen und ihre Adresse aktualisieren | Zwei Zeilen: eine für das Einsehen von Rechnungen, eine für die Aktualisierung der Adresse | Eine Anforderung pro Zeile, damit jede priorisiert und getestet werden kann |
| Datenvorschriften einhalten | Kundendaten müssen in der EU gespeichert werden | Konkret, mit klarer Quelle (Recht / DSGVO-Richtlinie) |
Arten von Anforderungen
Das Dropdown „Typ“ der Vorlage hält das Protokoll leicht filterbar: Funktional (was die Lösung leisten muss), Nichtfunktional (wie gut sie es leisten muss, etwa Leistung, Verfügbarkeit, Sicherheit oder Benutzerfreundlichkeit), Restriktion (Grenzen wie Vorschriften, Technologie oder Budget), Daten und Reporting.
Wenn Ihre Organisation dem BABOK Guide des IIBA folgt, finden Sie eine umfassendere Einteilung: Geschäftsanforderungen (Ziele und Ergebnisse), Stakeholder-Anforderungen (die Bedürfnisse bestimmter Gruppen), Lösungsanforderungen (aufgeteilt in funktionale und nicht-funktionale) und Übergangsanforderungen (was für den Wechsel vom aktuellen zum künftigen Zustand nötig ist, etwa Datenmigration oder Schulung). Sie können diese als zusätzliche Optionen in die Typliste aufnehmen.
Mit MoSCoW priorisieren
MoSCoW ordnet Anforderungen in vier Gruppen ein, und die Spalte „Priorität“ der Vorlage nutzt sie:
| Priorität | Bedeutung | Testen |
|---|---|---|
| Must | Ohne sie scheitert die Lösung oder ist nicht rechtskonform oder sicher | Würden Sie den Launch absagen, wenn dies fehlte? |
| Should | Wichtig, aber es gibt eine Ausweichlösung | Schmerzhaft, wenn sie fehlt, aber die Lösung funktioniert trotzdem |
| Could | Wünschenswert, wenn Zeit und Budget es erlauben | Schön zu haben; fällt unter Druck als Erstes weg |
| Won't (diesmal nicht) | Vorerst als außerhalb des Umfangs vereinbart | Festgehalten, damit die Entscheidung sichtbar ist |
Der häufigste Fehler ist, fast alles als Must zu markieren. Stellen Sie für jede Anforderung die Frage „Würden Sie den Launch absagen?“. Won't-Einträge festzuhalten ist ebenso nützlich: Es verhindert, dass dieselbe Anfrage jeden Monat wiederkommt.
Abnahmekriterien formulieren
Abnahmekriterien beschreiben, wie Sie bestätigen, dass eine Anforderung erfüllt wurde. Halten Sie sie konkret und beobachtbar: „Zurücksetzung in unter 2 Minuten abgeschlossen“, „alle Rechnungen seit 2024 sichtbar“, „Hosting-Region als EU bestätigt“. Sie werden zur Grundlage für Tests und für die Abnahme durch den Sponsor am Projektende und knüpfen natürlich an Ihren Qualitätsmanagement -Ansatz an.
So füllen Sie die BRD-Vorlage Schritt für Schritt aus
- Beginnen Sie mit dem Projektauftrag oder Business Case. Übernehmen Sie Ziele und Umfang, damit das BRD mit dem Genehmigten übereinstimmt.
- Identifizieren Sie die Stakeholder. Listen Sie alle auf, die die Lösung nutzen, betreiben, bezahlen oder regulieren. Unser Leitfaden zum Stakeholdermanagement zeigt, wie Sie sie analysieren.
- Beschreiben Sie den aktuellen Zustand. Halten Sie fest, wie die Dinge heute funktionieren und was schiefläuft. Belege wie Anrufdaten oder Umfrageergebnisse helfen.
- Erheben Sie die Anforderungen. Nutzen Sie Interviews, Workshops, Beobachtung, Dokumentenanalyse und Daten. Notieren Sie dabei die Quelle jeder Anforderung; Besprechungsprotokolle aus Workshops sind eine nützliche Aufzeichnung.
- Schreiben Sie jede Anforderung in eine eigene Zeile. Geben Sie ihr eine ID, eine klare Aussage, einen Typ und eine mit einem Ziel verknüpfte Begründung.
- Priorisieren Sie und ergänzen Sie Abnahmekriterien. Vereinbaren Sie die MoSCoW-Prioritäten mit dem fachlichen Verantwortlichen und schreiben Sie für jede Anforderung einen Test.
- Mit Stakeholdern reviewen. Gehen Sie das Protokoll durch, lösen Sie Konflikte und aktualisieren Sie die Status von Entwurf über Im Review zu Genehmigt.
- Holen Sie die Freigabe ein und legen Sie die Baseline fest. Bitten Sie die benannten Freigebenden, den Überblick zu unterzeichnen. Von da an laufen Änderungen über Änderungssteuerung mithilfe eines Änderungsantrag.
Beispiel für ein Dokument zu den geschäftlichen Anforderungen
Die Beispielzeilen der Vorlage beschreiben ein Kundenportal-Projekt. Hier das Anforderungsprotokoll im Auslieferungszustand, mit einem Hinweis dazu, warum jede Zeile so formuliert ist.
| ID | Anforderung | Art | Priorität | Akzeptanzkriterien | Status |
|---|---|---|---|---|---|
| BR-01 | Kunden müssen ihr Passwort zurücksetzen können, ohne den Support zu kontaktieren | Funktional | Must | Zurücksetzung in unter 2 Minuten abgeschlossen | Genehmigter |
| BR-02 | Das Portal muss die Rechnungen der letzten 24 Monate anzeigen | Funktional | Must | Alle Rechnungen seit 2024 sichtbar | Genehmigter |
| BR-03 | Seiten müssen in unter 2 Sekunden laden | Nichtfunktional | Should | 95. Perzentil unter 2 s | Entwurf |
| BR-04 | Daten müssen in der EU gespeichert werden | Restriktion | Must | Hosting-Region bestätigt | Genehmigter |
- BR-01 stammt aus Supportdaten und dient direkt dem Ziel, Anrufe zu reduzieren, ist also ein Must.
- BR-02 stammt aus einer Kundenumfrage und hat eine klare Grenze (24 Monate), was eine uferlose Datenmigration vermeidet.
- BR-03 ist eine nicht-funktionale Anforderung aus der UX-Forschung. Sie ist noch ein Entwurf, weil das 2-Sekunden-Ziel noch nicht mit der IT abgestimmt ist.
- BR-04 ist eine Randbedingung der Rechtsabteilung auf Basis der DSGVO-Richtlinie. Sie ist ein Must, weil die Lösung ohne sie nicht live gehen könnte.
Jede Zeile lässt sich auf ein Ziel (weniger Anrufe), eine Quelle und eine Begründung zurückführen. Diese Rückverfolgbarkeit ermöglicht es Ihnen, sechs Monate später die Frage „Warum bauen wir das?“ zu beantworten, und lässt Sie zuerst die richtigen Anforderungen streichen, wenn die Zeit knapp wird.
BRD vs. FRD, SRS, PRD und User Stories
Anforderungsdokumente überschneiden sich, und die Bezeichnungen variieren zwischen Organisationen. Diese Tabelle zeigt die üblichen Unterscheidungen.
| Dokument | Schwerpunkt | Typischer Verfasser | Hauptleserschaft |
|---|---|---|---|
| Dokument zu den geschäftlichen Anforderungen (BRD) | Was das Unternehmen braucht und warum; Ziele, Umfang, übergeordnete Anforderungen | Business Analyst | Sponsor, fachliche Stakeholder, Lieferteam |
| Dokument zu den funktionalen Anforderungen (FRD) / Fachkonzept | Wie sich die Lösung verhalten wird, um die geschäftlichen Anforderungen zu erfüllen | Business Analyst oder Systemanalytiker | Designer, Entwickler, Tester |
| Software Requirements Specification (SRS) | Detaillierte funktionale und nicht-funktionale Anforderungen an ein Softwaresystem | Systemanalytiker oder Architekt | Entwickler, Tester, Lieferanten |
| Product Requirements Document (PRD) | Was ein Produkt oder Release für seine Nutzer leisten soll, oft Feature für Feature | Produktmanager | Produkt-, Design- und Engineering-Teams |
| User Stories | Kleine, nutzerorientierte Funktionsscheiben mit Abnahmekriterien | Product Owner mit dem Team | Scrum- oder agiles Team |
| Statement of Work (SOW) | Was ein Lieferant liefern wird und zu welchen Bedingungen | Käufer, oft mit dem Einkauf | Lieferanten |
Ein BRD fließt oft in eine Angebotsanfrage (RFQ) oder ein Leistungsbeschreibung ein, wenn die Lösung gekauft statt gebaut wird, und es fließt in die Umfangsbeschreibung des Projekts jedes Projekts ein.
Ein BRD in agilen Projekten nutzen
Agile Teams schreiben selten vorab ein langes BRD, doch die Denkweise dahinter bleibt nützlich. Ein kurzes BRD, das Ziele, Umfangsgrenzen, Randbedingungen und die wichtigsten geschäftlichen Anforderungen festhält, gibt dem Product Owner und dem Team ein gemeinsames Ziel.
Die Details wandern dann in das Product Backlog als User Stories, jeweils rückverfolgbar auf eine ID einer geschäftlichen Anforderung. Nicht-funktionale Anforderungen und Randbedingungen werden oft Teil der Definition of Done des Teams. Die Einsteigerversion der Vorlage, also nur der Überblicks-Tab, reicht dafür meist aus; kombinieren Sie sie mit unserer Vorlage für User Stories oder Vorlage für das Product Backlog.
Häufige Fehler beim BRD
- Die Lösung entwerfen. Bildschirmlayouts und Technologieentscheidungen gehören ins Design, nicht ins BRD.
- Vage Wörter. „Einfach“, „schnell“ und „sicher“ brauchen einen Maßstab, sonst lassen sie sich nicht testen.
- Alles ist ein Must. Ohne echte Prioritäten kann das Team keine Abwägungen treffen, wenn die Zeit knapp wird.
- Fehlende Stakeholder. Anforderungen von Recht, Finanzen, Sicherheit oder Betriebsteams tauchen oft spät auf und verursachen Nacharbeit.
- Keine Quelle oder Begründung. Anforderungen, die niemand erklären kann, sind schwer zu verteidigen und laden zu überflüssigen Extras ein.
- Die Freigabe auslassen. Ohne Genehmigung ist das BRD ein Entwurf, und der Umfang bleibt offen. Siehe Scope Creep.
- Es als für immer festgeschrieben behandeln. Anforderungen ändern sich. Legen Sie das genehmigte BRD als Baseline fest und steuern Sie Änderungen offen, statt es stillschweigend zu bearbeiten.
Verwandte Vorlagen und Leitfäden
Ein BRD steht in einer Kette von Dokumenten. Vor ihm kommen der Vorlage für einen Business Case und Projektauftrag-Vorlage; daneben rahmen die Vorlage für die Problemstellung und Vorlage zur Gap-Analyse den Bedarf ein; danach tragen die Vorlage für den Projektumfang, Vorlage für User Stories und Vorlage für Änderungsanträge die Anforderungen in die Lieferung. Eine RACI-Matrix-Vorlage hilft Ihnen zu vereinbaren, wer sie schreibt, prüft und genehmigt.
Vorlage für die Inhalts- und UmfangsbeschreibungKostenlose Vorlage für den Projektumfang: Ziele, Lieferobjekte, im Umfang, außerhalb des Umfangs, Abnahme…Einsteiger · Fortgeschritten · Experte
User-Story-VorlageKostenlose User-Story-Vorlage: Als / möchte ich / damit, Akzeptanzkriterien, Epic, Schätzung…Einsteiger · Fortgeschritten · Experte
Gap-Analyse-VorlageKostenlose Gap-Analyse-Vorlage, die Ist- und Soll-Zustand vergleicht, jede Lücke bewertet und…Einsteiger · Fortgeschritten · Experte
Vorlage für eine ProblembeschreibungKostenlose Vorlage für eine Problembeschreibung: wer betroffen ist, was, wo und wann, Auswirkung, Belege,…Einsteiger · Fortgeschritten · Experte
Vorlage für die Ursachenanalyse (5 Warum)Kostenlose Vorlage für die Ursachenanalyse mit der 5-Warum-Methode: Problembeschreibung, Warum-Kette, Grund…Einsteiger · Fortgeschritten · Experte- Projektanforderungen: übergeordnete und technische Anforderungen
- Stakeholdermanagement: identifizieren, analysieren, einbinden
- Projektumfang: Definition, Inhaltsbeschreibung und Beispiele
- User Stories schreiben: Anleitung mit Beispielen
Wie übergeordnete und detaillierte Anforderungen zusammenpassen, erfahren Sie in unserem Leitfaden zu Projektanforderungen.
Häufig gestellte Fragen
Was ist eine Vorlage für ein Dokument zu den geschäftlichen Anforderungen?
Eine Vorlage für ein Dokument zu den geschäftlichen Anforderungen ist eine fertige Struktur, um Geschäftsziele, Umfang, Stakeholder, Randbedingungen und Anforderungen eines Projekts festzuhalten, jede mit Priorität und Abnahmekriterien. Diese hat einen Tab für den BRD-Überblick und ein Anforderungsprotokoll.
Ist diese BRD-Vorlage kostenlos?
Ja. Die Vorlage für das Dokument zu den geschäftlichen Anforderungen steht kostenlos und ohne Registrierung in Google Sheets, Excel und PDF zum Download bereit.
Was sollte ein Dokument zu den geschäftlichen Anforderungen enthalten?
Eine Management-Zusammenfassung, Geschäftsziele, Hintergrund und aktuellen Zustand, Umfang, Stakeholder, Annahmen und Randbedingungen, die Anforderungen selbst mit Priorität und Abnahmekriterien, Erfolgskriterien und Freigabe.
Wer schreibt ein Dokument zu den geschäftlichen Anforderungen?
Meist ein Business Analyst in Zusammenarbeit mit Stakeholdern, Sponsor und Projektmanager. Bei kleineren Projekten schreibt es oft der Projektmanager oder Product Owner.
Wer genehmigt das BRD?
Der Sponsor oder fachliche Verantwortliche genehmigt es, meist zusammen mit den Leitungen der wichtigsten Stakeholder-Gruppen und Spezialisten, etwa aus Recht oder Sicherheit, deren Anforderungen es enthält.
Was ist der Unterschied zwischen einem BRD und einem FRD?
Ein BRD sagt, was das Unternehmen braucht und warum. Ein Dokument zu den funktionalen Anforderungen (FRD) beschreibt, wie sich die Lösung verhalten wird, um diese Bedürfnisse zu erfüllen, und zwar detailliert genug für Designer, Entwickler und Tester.
Welche Arten von geschäftlichen Anforderungen gibt es?
Diese Vorlage nutzt funktional, nicht-funktional, Randbedingung, Daten und Reporting. Der BABOK Guide des IIBA unterteilt Anforderungen in Geschäfts-, Stakeholder-, Lösungs- (funktional und nicht-funktional) und Übergangsanforderungen.
Wie lang sollte ein BRD sein?
So kurz wie möglich, solange es klar bleibt. Ein kleines Projekt braucht vielleicht wenige Seiten; ein großes System oder eine große Beschaffung deutlich mehr. Halten Sie den Kontext im Überblick und schreiben Sie jede Anforderung in eine eigene Zeile des Protokolls.
Wann sollte man ein BRD schreiben?
Nachdem das Projekt über einen Business Case oder Projektauftrag grundsätzlich genehmigt wurde und bevor Design, Entwicklung oder Beschaffung beginnen.
Wie priorisiert man geschäftliche Anforderungen?
Nutzen Sie MoSCoW: Must, Should, Could und Won't have this time. Vereinbaren Sie die Prioritäten mit dem fachlichen Verantwortlichen und prüfen Sie jedes Must mit der Frage, ob Sie den Launch ohne es absagen würden.
Können agile Teams ein Dokument zu den geschäftlichen Anforderungen nutzen?
Ja, auf übergeordneter Ebene. Nutzen Sie ein kurzes BRD für Ziele, Umfang, Randbedingungen und wichtige geschäftliche Anforderungen und erfassen Sie die Details dann als User Stories im Product Backlog.
Was passiert, wenn sich Anforderungen nach der Freigabe ändern?
Stellen Sie einen Änderungsantrag, bewerten Sie die Auswirkung auf Umfang, Terminplan und Kosten und holen Sie die Genehmigung ein, bevor Sie das BRD aktualisieren. Halten Sie die Änderung und die Entscheidung fest, damit die Baseline klar bleibt.
Kann ich die BRD-Vorlage in Word verwenden?
Der Download ist eine Tabelle und ein PDF. Sie können die Überblicksabschnitte in ein Word-Dokument kopieren, wenn Ihre Organisation Word bevorzugt, und das Anforderungsprotokoll in der Tabelle behalten, wo es sich leichter filtern und sortieren lässt.