So organisieren Sie Anforderungen als Business-Analyst

Eine Geschäftsanforderung ist ein formales Dokument, das die Bedürfnisse der Stakeholder für ein Projekt oder Produkt erfasst. Es gibt kein einheitliches Standardformat für die Darstellung von Geschäftsanforderungen, aber jede Version sollte das Produkt oder Projekt so detailliert beschreiben, dass es diskutiert, analysiert, dokumentiert und validiert werden kann.

Eine Geschäftsanforderung kann auf eine der folgenden Arten dargestellt werden:

• Eine Tabelle oder eine Tabelle
• Ein Diagramm (Workflow)
• Ein Graph
• Ein Modell (Entity-Relationship-Diagramm)
• Ein Prototyp oder eine Simulation
• Eine strukturierte Satz- oder Textvorlage

So organisieren und präsentieren Sie eine Geschäftsanforderung

Im Folgenden sind die Schritte zum Schreiben und Organisieren von Anforderungen aufgeführt. Geschäft Analytikerin.

Schritt 1) Kategorisieren Sie die Anforderungen.

• Ordnen Sie jede Anforderung der Kategorie zu, zu der sie gehört.
• Technische Stakeholder sollten eine Kategorie für technische Anforderungen sehen, nicht-technische Stakeholder hingegen eine Kategorie für geschäftliche oder allgemeine Anforderungen.
• Jede Organisation sollte selbst entscheiden, welche Kategorien ihren eigenen Standards entsprechen.
• Die Kategorisierung kann auch auf der Art der Anforderungen basieren – funktional versus geschäftlich –, allerdings ist diese Aufteilung nicht für jedes Projekt geeignet.

Schritt 2) Anforderungen vereinbaren.
Die Anforderungen sollten gesammelt und in einer logischen Reihenfolge angeordnet werden, damit die Beteiligten das Dokument leicht durchsuchen und fehlende Angaben erkennen können.

Schritt 3) Bereiten Sie eine Liste vor.
Erstellen Sie eine Prüfliste der Anforderungen, gruppiert nach den Stakeholdern, die diese abzeichnen müssen.

Ein Stakeholder mit technischem Hintergrund interessiert sich beispielsweise nur für den technischen Aspekt des Produkts.

Schritt 4) Verwenden Sie eindeutige Kennungen.
If tracDie Anforderungen aneinander anzupassen ist schwierig; verwenden Sie daher eindeutige Kennungen. traceinfachere Zugänglichkeit.

Schritt 5) Die Anforderungen in der vom Stakeholder bevorzugten Methode darstellen.
Möglicherweise müssen Sie dieselbe Anforderung in unterschiedlichen Formaten für verschiedene Interessengruppen präsentieren – die eine bevorzugt eine grafische Darstellung, die andere strukturierte Sätze.

Schritt 6) Bereiten Sie ein Inhaltsverzeichnis vor.
Erstellen Sie ein Inhaltsverzeichnis für alle Anforderungen. Das hilft den Beteiligten. track und sie schnell finden.

Schritt 7) Nutzen Sie Business-Analyse-Tools.
Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen, Tools zur Geschäftsanalyse die dabei helfen, Anforderungen über verschiedene Releases hinweg einheitlich darzustellen und zu kategorisieren.

Schritt 8) Organisieren Sie Anforderungsdokumente nach Prozessablauf.
Entfernen Sie unnötige Anforderungen aus dem Dokument und ordnen Sie die verbleibenden Anforderungen nach dem Prozessablauf, den sie unterstützen.

Schritt 9) Ordnen Sie die Anforderungen zu.
Ordnen Sie jede erfasste Anforderung einem bestimmten Schritt im Prozessablauf zu, damit die Prüfer die Anforderung mit dem zugehörigen Arbeitsablauf in Verbindung bringen können.

Schritt 10) Verwenden Sie Tabellen und Aufzählungspunkte.
Komplexe Anforderungen lassen sich am besten in Tabellenform darstellen, die wichtigsten Aspekte jeder Anforderung in Stichpunkten.

Nützliche Tipps zum Schreiben und Präsentieren eines Geschäftsanforderungsdokuments

Für eine bessere Darstellung und tracIm Hinblick auf die Anforderungen an Geschäftsprozesse sind die folgenden Tipps für jeden Business Analysten (BA) hilfreich.

• Die Kategorisierung von Anforderungen ist zeitaufwändig. Definieren Sie daher einen Standardsatz von Kategorien, die Business-Analysten, Stakeholder, Fachexperten und technische Teams projektübergreifend wiederverwenden können, anstatt jedes Mal neue zu erfinden.
• Bereiten Sie jede Anforderung im Kontext ihrer Zielgruppe vor. Verstehen Sie die wichtigsten Akteure, Einflussnehmer und Entscheidungsträger (Stakeholder, technisches Personal, Entwickler usw.).
• Definieren Sie jeweils eine Anforderung. Jede Anforderung sollte atomar sein.
• Vermeiden Sie Mehrdeutigkeiten – verwenden Sie in einer Anforderungsbeschreibung keine vagen Zusätze wie „usw.“ oder „ca.“.
• Verweisen Sie nicht auf eine Anforderung, die noch nicht definiert wurde.
• Entfernen Sie doppelte und widersprüchliche Aussagen aus dem Dokument.
• Komplexe Anforderungen in kleinere, überschaubare und überprüfbare Punkte unterteilen.
• Beschreiben was Das System wird es schon schaffen, nicht wie Es wird funktionieren – die Implementierung gehört in die Entwurfsphase.

Gängige Techniken zur Visualisierung von Geschäftsanforderungen

Ein Textwust ist der schnellste Weg, Stakeholder zu verlieren. Business-Analysten ergänzen daher jede textbasierte Anforderung durch eine Visualisierung, sodass die Intention auf einen Blick ersichtlich ist. Die folgenden Techniken finden sich im BABOK Guide und sind in den meisten Business-Analysten-Praktiken in Unternehmen üblich.

• Geschäftsprozessmodell und Notation (BPMN): BPMN bildet durchgängige Geschäftsprozesse mit Pools, Lanes, Gateways und Ereignissen ab. Es eignet sich ideal, um darzustellen, wer was wann tut.
• Anwendungsfalldiagramme und DescriptIonen: Erfassen Sie die Interaktionen zwischen Akteuren und Systemen sowie die von jedem Akteur erwarteten Ergebnisse. Ideal für funktionsorientierte Backlogs.
• User Stories mit Akzeptanzkriterien: Kurze Aussagen der Form „Als … möchte ich …, damit …“ in Verbindung mit dem „Gegeben-Wenn-Dann“-Kriterium. Das Standardformat in agilen Teams.
• Wireframes und Mockups: Siebe mit niedriger oder mittlerer Wiedergabetreue, die in Figma, Balsamiq oder Axure die UI-Anforderungen für nicht-technische Stakeholder greifbar machen.
• Entity-Relationship-Diagramme (ERD): Zeigen Sie die Datenentitäten, die die Lösung speichern muss, und die Beziehungen zwischen ihnen auf – dies ist entscheidend für die Berichts- und Integrationsanforderungen.
• Datenflussdiagramme (DFD): Trace wie Daten durch Prozesse, Speicher und externe Akteure fließen, insbesondere in Analyse- oder Integrationsprojekten.

Die Technik sollte auf die Zielgruppe abgestimmt sein: Führungskräfte reagieren auf Prozesslandkarten und Journey-Diagramme, Entwickler auf ER-Diagramme und User Stories und Endbenutzer auf Wireframes und Prototypen.

Gängige Werkzeuge zur Organisation von Geschäftsanforderungsdokumenten

Sobald die Anzahl der Anforderungen ein paar Dutzend übersteigt, stößt ein Word-Dokument an seine Grenzen. Business-Analysten greifen daher auf speziell entwickelte Tools zurück, die die Erstellung von Baselines und die Überprüfung unterstützen. tracFunktionalität und Änderungsmanagement. Die folgenden sind die branchenweit am weitesten verbreiteten.

• Jira mit Confluence: Die Standardkombination für agile Teams. Anforderungen werden als Epics und Stories in Jira dargestellt und durch Confluence-Seiten ergänzt, die die BRD-Beschreibung und Diagramme enthalten.
• Jama Connect: Unternehmensplattform mit Fokus auf Anforderungsmanagement, Baseline-Erstellung und Live-Betrieb tracEignung für regulierte Branchen wie Medizinprodukte und Luft- und Raumfahrt.
• IBM Engineering Requirements Management-TÜREN: Ein seit langem etabliertes Werkzeug, das in der Verteidigungsindustrie, der Automobilindustrie und in sicherheitskritischen Systemen eingesetzt wird, wo jede Anforderung erfüllt werden muss. tracmöglich.
• Modern Requirements für Azure DevOps: Erweitert Azure DevOps mit Überprüfung, Freigabe, Baseline-Erstellung und BRD-Export im Word-Format direkt aus Arbeitselementen.
• Miro or Lucidchart: Mithilfe von Whiteboard- und Diagrammwerkzeugen werden BPMN-Diagramme, ERDs, User Journeys und Workshop-Notizen entworfen, die später in das formale BRD einfließen.
• Balsamiq und Figma: Wireframe- und Prototyping-Tools, die UI-Anforderungen visuell statt textuell darstellen.

Wählen Sie die Toolsets passend zum Umfang und den Prüfungsanforderungen Ihres Projekts. Kleinere Projekte können mit Confluence und Jira beginnen, während regulierte Programme in der Regel Jama oder DOORS benötigen, um die Anforderungen zu erfüllen. tracEability-Audits.

Häufige Fehler bei der Präsentation von Geschäftsanforderungen

Selbst eine gut recherchierte Anforderung kann abgelehnt werden, wenn sie schlecht präsentiert wird. Die folgenden Fehler treten in den meisten Nachbesprechungen von Business-Ansatz-Projekten auf und sollten bei der Überprüfung unbedingt vermieden werden.

• Was und wie mischen: Rutschenping Die Aufnahme von Implementierungsdetails in die Anforderungsbeschreibung zwingt das Designteam zu einer bestimmten Lösung, noch bevor die Analyse abgeschlossen ist.
• Mehrdeutige Formulierung: Begriffe wie „schnell“, „benutzerfreundlich“ oder „flexibel“ sind nicht testbar. Ersetzen Sie sie durch messbare Akzeptanzkriterien.
• Ein Format für alle Beteiligten: Wenn Führungskräften, Entwicklern und Endnutzern dieselbe Sichtweise präsentiert wird, ist in der Regel keiner von ihnen zufrieden. Passen Sie das Format an die jeweilige Zielgruppe an.
• Vermisst tracFähigkeit: Anforderungen, die nicht mit Geschäftszielen, Designelementen und Testfällen verknüpft sind, können bei einem Änderungsantrag nicht verteidigt werden.
• Keine Priorisierung: Die Präsentation hunderter Anforderungen ohne MoSCoW, gewichtete Bewertung oder einen ähnlichen Rahmen zwingt die Beteiligten dazu, über den Umfang statt über den Wert zu streiten.
• Überladene Dokumente: Wenn man alle Diagramme, Protokolle und Begründungen in ein einziges 200-seitiges PDF packt, gehen die wichtigen Anforderungen verloren. Teilen Sie das BRD in logische Abschnitte mit einem übersichtlichen Inhaltsverzeichnis auf.
• überspringenping abmelden: Die Vorlage des BRD ohne formellen Genehmigungsschritt öffnet die Tür für eine Ausweitung des Projektumfangs und gegenseitige Schuldzuweisungen im weiteren Verlauf der Umsetzung.

RevEin Blick auf die BRD anhand dieser Liste vor jeder Stakeholder-Sitzung deckt die meisten Probleme auf, die in späteren Phasen Nacharbeiten verursachen.

Häufig gestellte Fragen