Nur eine Empfehlung … wie wir unsere Informationsanforderungen organisieren
Fachanwender in sämtlichen Branchen sind auf verlässliche Informationen angewiesen. Im Rahmen unserer Beratungsprojekte stellen wir jedoch häufig fest, dass es an einer präzisen Beschreibung dessen fehlt, was die Fachbereiche tatsächlich benötigen.
Daher möchten wir Ihnen in diesem Artikel zeigen, wie wir Informationsanforderungen sowohl intern bei Scalefree als auch für viele unserer Kunden strukturieren.
Was ist mit User Stories?
Wir alle kennen User Stories aus Scrum und vielen Business-Intelligence-Projekten.
Ihre typische Struktur sieht etwa so aus:
Als <Benutzertyp>möchte ich <some goal> damit <ein Grund/Nutzen>.
Das folgende Beispiel zeigt eine typische User Story, wie wir sie in einem Projekt vorfinden könnten:
Als <Marketing-Mitarbeiter>möchte ich <einen Übersichtsbericht mit der Anzahl der Leads aus einem Marketingkanal> damit <ich das Marketingbudget entsprechend anpassen kann>.
Was fangen wir nun mit dieser User Story an?
Es fehlen viele Details. Zwar gibt es das Product Backlog Refinement, doch für Vorhaben im Bereich Business Intelligence reicht eine User Story allein meist nicht aus – eine detailliertere Strukturierung ist hier zwingend erforderlich.
Informationsanforderungen
Entwickler im Bereich Enterprise Data Warehousing und Business Intelligence benötigen weitaus mehr Details als nur eine reine User Story. Dennoch ist sie ein guter Ausgangspunkt für die Informationsanforderung und kann hervorragend als Einleitung dienen. Die Gesamtstruktur sieht wie folgt aus:
- User Story (Einleitung)
- Grafisches Mockup
- Detaillierte Erläuterung
- Liste der KPIs
- Liste der Datenquellen
- Testfälle
Lassen Sie uns diese Abschnitte im Folgenden genauer betrachten.
Einleitung
Wie bereits erwähnt, dient die User Story als idealer Einstieg, um die Informationsanforderung aus Sicht des Fachanwenders zu formulieren. Aus Gründen der Effizienz sollten Sie sicherstellen, dass der geschäftliche Nutzen (Business Value) klar formuliert ist, damit er für das Entwicklungsteam unmittelbar verständlich ist.
Grafisches Mockup
Grafische Entwürfe erhöhen die Klarheit einer Informationsanforderung enorm. Sie sind ein wirkungsvolles Mittel, um dieselbe Anforderung aus einer visuellen Perspektive zu beleuchten. Das Mockup kann dabei ganz unterschiedlich gestaltet sein:
- ein Screenshot oder Ausdruck des Altreports (Legacy Report), der abgelöst werden soll
- ein Tabellenkalkulations-Mockup, das dem finalen Report oder Dashboard ähnelt
- eine Zeichnung in einem Werkzeug wie Microsoft Visio, Lucidchart oder vergleichbaren Programmen
- eine handgezeichnete Skizze auf Papier
Allen Optionen ist gemeinsam, dass sie dem Endprodukt so nahe wie möglich kommen und möglichst viele Details abbilden sollten, einschließlich visueller Elemente, Diagrammtypen, Beispielwerten, Hervorhebungen und Filtern.
Detaillierte Erläuterung
Dieser Abschnitt beschreibt das vorangegangene Mockup in allen relevanten Einzelheiten. Beziehen Sie sich konkret auf die Darstellung und erläutern Sie sämtliche Inhalte des Endergebnisses, die das Entwicklerteam benötigt, um den Bedarf, den Umsetzungsumfang und die fachliche Erwartungshaltung vollständig zu erfassen. Querverweise auf bestimmte Elemente des Mockups helfen dabei, Details eindeutig zuzuordnen.
Liste der KPIs
Kennzahlen (Measures) und weitere Berechnungslogiken sollten an dieser Stelle detailliert beschrieben werden. Intern nutzen wir ein zentrales Repository, in dem wir die Definitionen und Abhängigkeiten der KPIs pflegen. Dazu gehören alle erforderlichen Details zur Berechnung sowie zum fachlichen Verständnis: Was gilt beispielsweise als positiver Trend (steigend, fallend, gleichbleibend)? Gibt es definierte Schwellenwerte? Wer ist der fachliche Verantwortliche (Owner) der Kennzahl?
In einfachen Fällen reicht eine Wiki-Seite pro KPI völlig aus. In komplexeren Szenarien können Sie diese in einem MDM- oder einem spezialisierten KPI-System verwalten.
Nutzen Sie andere Ansätze? Hinterlassen Sie uns gerne einen Kommentar, wenn Sie Erfahrungen mit kommerziellen oder Open-Source-Lösungen zur KPI-Definition teilen möchten.
Liste der Datenquellen
Sobald die fachlichen Details definiert sind, stellt sich die entscheidende Frage: Woher stammen die benötigten Daten? Listen Sie diese im entsprechenden Abschnitt vollständig auf. Intern verwenden wir einen eigenen Namensraum im Wiki, in dem wir unsere Datenquellen mit allen relevanten Details dokumentieren.
Wenn Sie an diesem Aufbau interessiert sind, hinterlassen Sie uns gerne einen Kommentar
Bei entsprechendem Interesse widmen wir diesem Thema einen eigenen Blogartikel. Wir freuen uns auch über Ihre Best Practices und Beispiele.
Testfälle
Ein weiterer zentraler Bestandteil sind manuelle Testfälle für den User Acceptance Test (UAT). Diese sollten von Beginn an transparent dokumentiert sein, um langwierige Abstimmungen im Sprint-Review-Meeting zu vermeiden. Vollständige Transparenz ermöglicht es jedem Teammitglied, die Anforderungen frühzeitig und eigenständig zu überprüfen.
Den Wert von Informationsanforderungen maximieren
Damit ist die Struktur der Informationsanforderung vollständig. Doch wie lässt sich ihr Nutzen maximieren? Die Vorlage eignet sich hervorragend zur Spezifikation durch den Fachbereich, doch wir gehen üblicherweise einen Schritt weiter: Sobald die Anforderungen umgesetzt sind und das Dashboard oder der Report produktiv geht, wird eine Benutzerdokumentation benötigt. Wir wandeln die ursprüngliche Informationsanforderung direkt in das Benutzerhandbuch um, indem wir das Mockup durch einen aktuellen Screenshot des fertigen Artefakts ersetzen und den Text final redigieren.
Dieser Ansatz maximiert den Ertrag des ursprünglichen Aufwands, senkt die Dokumentationskosten und hält die Inhalte dauerhaft aktuell. Bei künftigen Change Requests erstellen wir ein entsprechendes Ticket und aktualisieren sowohl den Report als auch die Dokumentation im Rahmen der „Definition of Done“.
Wir hoffen, dass dieser Einblick zeigt, wie sich Informationsanforderungen effizient und nachhaltig dokumentieren lassen. Teilen Sie diesen Leitfaden gerne mit Ihren Fachbereichen und lassen Sie uns Ihr Feedback in den Kommentaren da!
