Die Frage, wie Dokumente spezifiziert werden können, die ein System später drucken soll, stellt den einen oder anderen sicherlich vor eine Herausforderung. Wir haben praktische Erfahrungen in mehreren Kundenprojekten gesammelt, die wir Ihnen hier vorstellen möchten.
Je nach Projekt(randbedingungen) sind mehrere Stakeholder nötig, um alle Informationen in die Dokumentenspezifikation einfließen zu lassen (siehe Abbildung 1). In unseren Projekten waren die Ansprechpartner der Fachbereiche, die mit den Dokumenten arbeiten werden, die Hauptinformationsquelle. Neben dem Fachbereich gibt es noch eine Vielzahl weiterer Stakeholder, die wichtige Informationen liefern können.
Abbildung 1: Stakeholder zur AnforderungsermittlungGibt es strenge Layoutvorgaben bzw. einen Style Guide?
Die Ansprechpartner, die für die corporate identity und das corporate design verantwortlich sind, können Fragen zum Layout der Dokumente beantworten, oder sie geben sogar strenge Vorgaben in Form von Style Guides bzw. Layoutvorgaben vor. Diese Vorgaben müssen an die Entwickler, die das Layout eines Dokumentes implementieren weitergegeben werden.Müssen die Dokumente mehrsprachig zur Verfügung stehen?
Viele Systeme werden international genutzt. Häufig steht die grafische Benutzeroberfläche in Englisch, Deutsch und anderen Sprachen zur Verfügung. Sollte das für die Dokumente auch zutreffen, werden Fachexperten benötigt, die helfen, die Dokumente in mehrere Sprachen zu überführen. In größeren Unternehmen gibt es häufig interne oder externe Übersetzungsdienste auf die zurückgegriffen werden kann. Die Praxis hat gezeigt, dass je nach Branche Fachtermini benötigt werden. Es ist also ratsam, auf diese Übersetzungsdienste zurückzugreifen.
Wird ein Altsystem (welcher Art auch immer) abgelöst?
In diesem Fall kann und muss auf die Dokumente des Altsystems zurück gegriffen werden. Diese bieten wichtige Informationen über die vorherigen Inhalte der Dokumente und damit eine Diskussionsbasis mit dem Fachbereich für die neuen Dokumente.
Gibt es ein Datenmodell des Systems aus dem gedruckt werden soll?
Dieses Modell, möglicherweise ein Klassendiagramm, liefert einen Großteil der Daten, die gedruckt werden müssen. Erfahrungen aus den bisherigen Projekten, in denen ich Dokumente spezifiziert hatte, haben gezeigt, dass über 90% aller variablen Daten auf einem Dokument aus dem Klassenmodell entnommen werden können.
Sind die Dokumente rechtsverbindliche Unterlagen in Form von Verträgen für den Empfänger?
Sollte das der Fall sein, ist es notwendig die Dokumente von einem internen Rechtsdienst oder einem externen Beratungsdienst prüfen zu lassen.
Vorgehen zur Erhebung von Anforderungen
Sollte mit der Spezifikation von Dokumenten nicht auf der grünen Wiese gestartet werden müssen, hat man sich schon ein bisschen Arbeit erspart, da in der Regel Dokumente aus den Altsystemen vorliegen. Mit diesen Dokumenten kann man mit dem Fachbereich Workshops halten, um den Aufbau des neuen Dokumentes festzulegen.
Zu Ermittlung der Anforderungen bei komplexen Dokumenten hat sich die Idee der Paper Mock-Ups, bewährt. Man geht mit ausgedruckten Altdokumenten und zusätzlich mit Schere, Filzstift und Klebestreifen bewaffnet in die Workshops. Aus den Ausdrucken der alten Dokumente lassen sich so am schnellsten neue Dokumente „basteln“. Zusätzlich benötigte Dokumentteile können on-demand in einer Textverarbeitung erstellt, ausgedruckt und dazu geklebt werden. Bei weniger komplexen Dokumenten kann auch in einem Textprogramm gearbeitet werden.
Sollte man doch auf der grünen Wiese starten, sind zur Erhebung der Anforderungen ein paar Runden mehr nötig. Ein enges Zusammenarbeiten mit dem Fachbereich ist hierbei immens wichtig. Für Dokumente, die komplett neu aus dem Boden gestampft werden müssen, sollte sich der Fachbereich vor dem Workshop Gedanken machen und diese als Draft in ein Dokument gießen. Dieses bildet dann die Basis für die weitere Anforderungserhebung.
In unseren Projekten haben wir Schritt für Schritt, oder bezogen auf ein Klassenmodell Attribut für Attribut festgelegt, welche Teile eines Dokuments automatisch aus dem System gezogen werden können oder sollen. Danach musste noch geklärt werden, woher die verbleibenden Inhalte auf dem Dokument kommen. Gibt diese der Nutzer ein? Bleiben diese immer gleich? Auf diese Weise erhält man eine erste Struktur des Dokuments mit seinen Inhalten.
Die Beschreibung von Regeln, also unter welchen Bedingungen gedruckt wird, ist für eine weitere Runde mit dem Fachbereich zu empfehlen, um die Übersichtlichkeit des ersten Wurfes nicht zu gefährden.
Dokumentation der gesammelten Anforderungen
Die gesammelten Anforderungen haben wir in einer Dokumentenmaske abgelegt. Es gibt verschiedene CASE-Tools, die für solche Arbeiten genutzt oder zweckentfremdet werden können. Gute Erfahrungen haben wir u.a. mit ARIS Business Designer gemacht. Ein grobes Beispiel einer Dokumentenmaske gibt Abbildung 2. Die Dokumentenmaske unterscheidet zwischen Struktur, Inhalten und Steuerung. Die Struktur gibt den Aufbau eines Dokuments wieder, dient aber auch der Erstellung wiederverwendbarer Teile, wie z.B. Adressblöcke. Die Inhalte sind in fixe Textteile, Variablen und Metainformationen aufgeteilt.
Abbildung 2: Beispiel einer Dokumentenmaske
Die Regeln beschreiben genau, was wann wie wo gedruckt werden muss. Diese Festlegungen wurden zusammen mit dem Fachbereich in weiteren Workshops durchgeführt. Dazu wurden die Forderungen direkt in das Modell aufgenommen und später ausformuliert. Als wichtigste Regeltypen sind hier die Datenherleitung, die Druckentscheidung und Strukturregeln zu nennen.
Die Datenherleitung beschreibt, wie die zu druckenden Daten ermittelt werden; die Druckentscheidung, unter welchen Bedingungen Daten gedruckt werden; und die Strukturregeln, wie z.B. Daten in Tabellen sortiert werden.
Wo ich gerade bei Tabellen bin. Sicherlich ist Ihnen die „Gruppe Tabelle“ in Abbildung 2 aufgefallen, die eine Tabelle mit Tabellenkopf, Datenbereich und abschließenden Tabellenfuß darstellt. Die Blöcke „Absender“ und „Empfänger“ sind generisch an anderer Stelle durch eine Dokumentenmaske beschrieben und können in allen Dokumenten wiederverwendet werden. Das spart Zeit und Pflegeaufwand, sowohl für die Analyse-, Design-, Implementierungs- als auch Testphase.
Sollte durch die CD/CI-Abteilung keine strengen Vorgaben z.B. zu Tabellen, Querlinien, etc. gemacht worden sein, ist es empfehlenswert zusätzlich zu der Dokumentenmaske ein konkretes Dokument in einer Textverarbeitung zu erstellen und dies mit dem Fachbereich zu besprechen. Dieses Dokument soll dann als Referenz für die layoutseitige Implementierung herangezogen werden.
Welche Methoden haben Sie bisher angewandt und welche Erfahrungen haben Sie dabei gemacht? Ich freue mich auf eine gute Diskussion und reichhaltigen Erfahrungsaustausch.