<\/p>\n
Fachanwender in s\u00e4mtlichen Branchen sind auf verl\u00e4ssliche Informationen angewiesen. Im Rahmen unserer Beratungsprojekte stellen wir jedoch h\u00e4ufig fest, dass es an einer pr\u00e4zisen Beschreibung dessen fehlt, was die Fachbereiche tats\u00e4chlich<\/i><\/span> ben\u00f6tigen.<\/span><\/span> <\/p>\n Daher m\u00f6chten wir Ihnen in diesem Artikel zeigen, wie wir Informationsanforderungen sowohl intern bei Scalefree als auch f\u00fcr viele unserer Kunden strukturieren. <\/span><\/p>\n Wir alle kennen User Stories aus Scrum und vielen Business-Intelligence-Projekten. <\/span> Als <Benutzertyp>m\u00f6chte ich <some goal> damit <ein Grund\/Nutzen>.<\/span><\/p>\n Das folgende Beispiel zeigt eine typische User Story, wie wir sie in einem Projekt vorfinden k\u00f6nnten:<\/span><\/p>\n Als <Marketing-Mitarbeiter>m\u00f6chte ich <einen \u00dcbersichtsbericht mit der Anzahl der Leads aus einem Marketingkanal> damit <ich das Marketingbudget entsprechend anpassen kann>.<\/span><\/p>\n Was fangen wir nun mit dieser User Story an? <\/span> Entwickler im Bereich Enterprise Data Warehousing und Business Intelligence ben\u00f6tigen weitaus mehr Details als nur eine reine User Story. Dennoch ist sie ein guter Ausgangspunkt f\u00fcr die Informationsanforderung und kann hervorragend als Einleitung dienen. Die Gesamtstruktur sieht wie folgt aus: <\/span> Lassen Sie uns diese Abschnitte im Folgenden genauer betrachten.<\/span><\/p>\n Wie bereits erw\u00e4hnt, dient die User Story als idealer Einstieg, um die Informationsanforderung aus Sicht des Fachanwenders zu formulieren. Aus Gr\u00fcnden der Effizienz sollten Sie sicherstellen, dass der gesch\u00e4ftliche Nutzen (Business Value) klar formuliert ist, damit er f\u00fcr das Entwicklungsteam unmittelbar verst\u00e4ndlich ist. <\/span><\/p>\n Grafische Entw\u00fcrfe erh\u00f6hen 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: <\/span><\/p>\n Allen Optionen ist gemeinsam, dass sie dem Endprodukt so nahe wie m\u00f6glich kommen und m\u00f6glichst viele Details abbilden sollten, einschlie\u00dflich visueller Elemente, Diagrammtypen, Beispielwerten, Hervorhebungen und Filtern. <\/span><\/p>\n Dieser Abschnitt beschreibt das vorangegangene Mockup in allen relevanten Einzelheiten. Beziehen Sie sich konkret auf die Darstellung und erl\u00e4utern Sie s\u00e4mtliche Inhalte des Endergebnisses, die das Entwicklerteam ben\u00f6tigt, um den Bedarf, den Umsetzungsumfang und die fachliche Erwartungshaltung vollst\u00e4ndig zu erfassen. Querverweise auf bestimmte Elemente des Mockups helfen dabei, Details eindeutig zuzuordnen. <\/span><\/p>\n 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\u00e4ngigkeiten der KPIs pflegen. Dazu geh\u00f6ren alle erforderlichen Details zur Berechnung sowie zum fachlichen Verst\u00e4ndnis: Was gilt beispielsweise als positiver Trend (steigend, fallend, gleichbleibend)? Gibt es definierte Schwellenwerte? Wer ist der fachliche Verantwortliche (Owner) der Kennzahl? <\/span><\/p>\n In einfachen F\u00e4llen reicht eine Wiki-Seite pro KPI v\u00f6llig aus. In komplexeren Szenarien k\u00f6nnen Sie diese in einem MDM- oder einem spezialisierten KPI-System verwalten. <\/span> Sobald die fachlichen Details definiert sind, stellt sich die entscheidende Frage: Woher stammen die ben\u00f6tigten Daten? Listen Sie diese im entsprechenden Abschnitt vollst\u00e4ndig auf. Intern verwenden wir einen eigenen Namensraum im Wiki, in dem wir unsere Datenquellen mit allen relevanten Details dokumentieren. <\/span> Ein weiterer zentraler Bestandteil sind manuelle Testf\u00e4lle f\u00fcr den User Acceptance Test (UAT). Diese sollten von Beginn an transparent dokumentiert sein, um langwierige Abstimmungen im Sprint-Review-Meeting zu vermeiden. Vollst\u00e4ndige Transparenz erm\u00f6glicht es jedem Teammitglied, die Anforderungen fr\u00fchzeitig und eigenst\u00e4ndig zu \u00fcberpr\u00fcfen. <\/span><\/p>\n Damit ist die Struktur der Informationsanforderung vollst\u00e4ndig. Doch wie l\u00e4sst sich ihr Nutzen maximieren? Die Vorlage eignet sich hervorragend zur Spezifikation durch den Fachbereich, doch wir gehen \u00fcblicherweise einen Schritt weiter: Sobald die Anforderungen umgesetzt sind und das Dashboard oder der Report produktiv geht, wird eine Benutzerdokumentation ben\u00f6tigt. Wir wandeln die urspr\u00fcngliche Informationsanforderung direkt in das Benutzerhandbuch um, indem wir das Mockup durch einen aktuellen Screenshot des fertigen Artefakts ersetzen und den Text final redigieren. <\/span><\/p>\n Dieser Ansatz maximiert den Ertrag des urspr\u00fcnglichen Aufwands, senkt die Dokumentationskosten und h\u00e4lt die Inhalte dauerhaft aktuell. Bei k\u00fcnftigen Change Requests erstellen wir ein entsprechendes Ticket und aktualisieren sowohl den Report als auch die Dokumentation im Rahmen der \u201eDefinition of Done\u201c. <\/span><\/p>\n 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! <\/span>[\/vc_column_text][\/vc_column][\/vc_row]\n","protected":false},"excerpt":{"rendered":" [vc_row type=“in_container“ full_screen_row_position=“middle“ scene_position=“center“ text_color=“dark“ text_align=“left“ overlay_strength=“0.3″][vc_column column_padding=“no-extra-padding“ column_padding_position=“all“ background_color_opacity=“1″ background_hover_color_opacity=“1″ column_shadow=“none“ width=“1\/1″ tablet_text_alignment=“default“ phone_text_alignment=“default“ column_border_width=“none“ column_border_style=“solid“][vc_column_text] Nur eine Empfehlung \u2026 wie wir unsere Informationsanforderungen organisieren Fachanwender in s\u00e4mtlichen…<\/p>\n","protected":false},"author":91,"featured_media":60457,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3947],"tags":[],"class_list":["post-60456","post","type-post","status-publish","format-standard","has-post-thumbnail","category-datenarchitektur"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tWas ist mit User Stories?<\/span><\/h1>\n
\n<\/span>Ihre typische Struktur sieht etwa so aus:<\/span><\/p>\n
\n<\/span>Es fehlen viele Details. Zwar gibt es das Product Backlog Refinement, doch f\u00fcr Vorhaben im Bereich Business Intelligence reicht eine User Story allein meist nicht aus \u2013 eine detailliertere Strukturierung ist hier zwingend erforderlich. <\/span><\/p>\nInformationsanforderungen<\/span><\/h1>\n
\n<\/p>\n\n
Einleitung<\/span><\/h1>\n
Grafisches Mockup<\/span><\/h1>\n
\n
Detaillierte Erl\u00e4uterung<\/span><\/h1>\n
Liste der KPIs<\/span><\/h1>\n
\n<\/span>Nutzen Sie andere Ans\u00e4tze? Hinterlassen Sie uns gerne einen Kommentar, wenn Sie Erfahrungen mit kommerziellen oder Open-Source-L\u00f6sungen zur KPI-Definition teilen m\u00f6chten. <\/span><\/p>\nListe der Datenquellen<\/span><\/h1>\n
\n<\/span>Wenn Sie an diesem Aufbau interessiert sind, hinterlassen Sie uns gerne einen Kommentar <\/span>
\n<\/span>
\n<\/span>Bei entsprechendem Interesse widmen wir diesem Thema einen eigenen Blogartikel. Wir freuen uns auch \u00fcber Ihre Best Practices und Beispiele. <\/span><\/p>\nTestf\u00e4lle<\/span><\/h1>\n
Den Wert von Informationsanforderungen maximieren<\/span><\/h1>\n