Darstellungsformen für Daten, Bildschirmformulare und Prozesse

Zusammenfassung
Daten
Bildschirmformulare
Prozesse

Zusammenfassung

In diesem Kapitel werden die Grundlagen der Darstellung von Daten und Prozessen gezeigt, auf Bildschirmformulare wird am Rande eingegangen. Bei den Daten wird insbesondere die Datenrepräsentation für Tabelle und Schnittstellen aufgezeigt. Für Bildschirmforumlare werden die für grafische Oberflächen üblichen Steuerelemente und deren Verwendung aufgeführt. Die Prozess-Darstellung beschränkt sich auf Formen, die auch von nicht-IT-Spezialisen ohne großen Aufwand verstanden werden können; auf Sequenz-Diagramme der UML wird aus diesem Grunde verzichtet.

Daten

Dokumentation von Tabellen

Zwar bekommt ein Endanwender Schnittstellenbeschreibungen so gut wie nie zu Gesicht, der Business Analyst dafür aber regelmäßig. Im Rahmen einer Anforderungsanalyse definiert der Analytiker Schnittstellen. In seine Kompetenz fallen dabei lediglich die fachlichen Inhalte, jedoch wird er i.d.R. mit dem technischen Personal zusammen ein geeignetes Format definieren.

Der Datenteil einer Schnittstellenbeschreibung besteht in aller Regel aus Tabellen, die in Datenbanken oder in gewöhnlichen ASCII- oder Binärdateien abgebildet sind. Seltener ist der Fall, dass ein kontinuierlicher Datenstrom oder ein variables Datensatzformat vorliegt, der entweder durch einen Prozess erzeugt oder gelesen wird bzw. der auch in Dateien (stückweise) abgebildet werden kann. Verständliche Beispiele für Datenströme sind Kursversorgungen von Börsendaten, die mehrmals pro Sekunde Daten liefern, oder auch Verbindungsdaten aus der Telekommunikation, bei denen die Vermittlungseinheit dem Billingsystem Zeitpunkt, Dauer und Partner eines Telefongesprächs mitteilt.

Hier werden nur rein tabellarische Daten mit fester Satzbeschreibung besprochen.

Jede Tabelle enthält Zeilen, die gleichförmige Daten enthalten. Folgende Daten sind im Regelfall in einer Tabellenbeschreibung enthalten:

Kurzname (technischer Name, z.B. der Attributname in der Datenbanktabelle)
Langname bzw. Kurzbeschreibung der Information
Datenformat (Datentyp, Länge)
Wertebereich (Maximum, Minimum, Ausnahmen, Aufzählungen, Abhängigkeiten von anderen Daten)
Hinweise
Beispiele

Dazu kommen noch der Tabellenname und eine Beschreibung der Abhängigkeiten zwischen den Tabellen, falls mehrere Tabellen zu einem Export oder Import gehören.

Sofern es sich nicht um Datenbank-Tabellen handelt, bei denen die Datendarstellung nicht transparent ist, sondern um gewöhnliche Dateien, sind noch folgende Zusatzinformationen mindestens notwendig:

Gibt es neben Zeilen mit den Datensätzen noch zusätzliche Zeilen oder Metainformationen?

z.B. eine Kopfzeile, in der die Kurznamen aufgeführt sind
z.B. eine oder mehrere Fußzeilen, die Prüfsummen enthalten

Handelt es sich um feste oder variable Satzlängen?

Bei variablen Längen:

Wie werden die einzelnen Spalten voneinander getrennt (Trennzeichen)?
Was passiert, wenn das Trennzeichen (z.B. Tabulator) in einem normalen String auftritt?
Bei Strings: Wie lange kann der String maximal werden?
Bei Strings: Wie wird mit einem String-Begrenzungszeichen (z.B. ") verfahren, wenn es innerhalb des Strings auftritt?
Wie sieht der Satztrenner aus?

Bei festen Längen:

Woran wird die tatsächliche Länge von Strings erkannt?
Wie werden leere Felder erkannt?
Gibt es einen Satztrenner? Wie sieht der Satztrenner aus?

Wodurch wird das Dateiende identifiziert? Gibt es vor dem Dateiende noch einen letzten Satztrenner, oder nicht, oder ist er optional?
Können leere Datensätze vorkommen?
Gibt es evtl. Ausnahmen, z.B. Kommentarzeilen? Wie werden sie von regulären Datensätzen unterschieden?

Beispiel aus der Praxis

Ein Entwickler ignorierte im Rahmen einer Importroutine die Kopfzeile einer ASCII-Datei, in der die Feldnamen aufgelistet waren, indem er die Laderoutine die erste Zeile überlesen ließ. Irgendwann wurde die Reihenfolge der Datenfelder geändert, was sich in der Kopfzeile widerspiegelte. Die Routine las jedoch in der üblichen festen Reihenfolge und stürzte ab.

In einer Schnittstellenbeschreibung wurde ein boolscher Wert (ja/nein-Wert) als j und n codiert und so dokumentiert. Im Rahmen des Exports wurde lediglich ein String aus einer DB-Tabelle gelesen und in eine ASCII-File geschrieben, weitere Prüfungen fanden nicht statt. Beim Lesen fiel auf, dass das j und n auch manchmal groß geschrieben war, und dass auch leere Spalten geliefert wurden. Es stellte sich heraus, dass der Export-Vorgang korrekt war. Jedoch wurde im Rahmen der Verarbeitung im Vorfeld nicht beachtet, dass eine Vereinheitlichung der Schreibweise vor dem Speichern des Zeichens in der Datenbank notwendig war. Außerdem war nirgendwo dokumentiert, dass das Datenfeld, das aus einem Fragebogen erfasst wurde, gelegentlich nicht lesbar oder nicht ausgefüllt war, und daher frei gelassen wurde.

Schnittstellen

Allgemeines

Gemeint sind hier ausschließlich Datenschnittstellen, also Ausgaben in Einlesen von Tabellen oder Dateien oder von kontinuierlichen Datenströmen. Nicht gemeint sind Benutzerschnittstellen oder Geräteschnittstellen.

Schnittstellen bestehen prinzipiell aus Daten und einem zugehörigen Protokoll. Sie stellen den Übergang von einem Prozess zu einem anderen dar, sind also die bzw. eine Ausgabe des Vorläuferprozesses und die bzw. eine Eingabe des Nachfolgerprozesses. Schnittstellen sind nicht Anfang oder Ende einer Prozesskette. Es kann lediglich sein, dass die Interna des Vorgängerprozesses oder Nachfolgeprozesses selbst nicht transparent sind. Das ist auch weiter nicht schlimm oder kann sogar erwünscht sein, die ganze objektorientierte Programmierung basiert auf diesem Prinzip.

Bei rein manuellen Prozessen kann man sich eine Exportschnittstelle etwa so vorstellen, dass ein Mitarbeiter die Ergebnisse seiner Arbeit in ein Kuvert steckt, dann verschickt und nie wieder etwas davon hört. Umgekehrt kann eine Importschnittstelle als der Empfang des Kuverts verstanden werden. Wurde der falsche Inhalt kuvertiert oder unzureichend vorgearbeitet, kann der Empfänger nicht weiter arbeiten.

Exportschnittstellen

Im Sinne von EVA handelt es sich hier um die Ausgabe aus einem Prozess, also um das Ergebnis, und, rudimentär, um die notwendigen Verarbeitungsschritte, um die Ausgabe zu vollziehen. Die genauen Arbeitsschritte sind in der Beschreibung des Exportprozesses zu dokumentieren.

Der Export enthält Daten, die in einer definierten Menge von Tabellen oder Dateien enthalten sind. Zusätzlich zu den Datenformaten muss noch definiert werden:

der Prozess (Name, Version, Lokation), der die Daten erzeugt.
der Prozess (Name, Version, Lokation), der die Daten benötigt.
die Menge der Daten
der Auslöser des Exports. Dies kann ein Zeitpunkt oder die Frequenz oder das definierte Ende eines Verarbeitungsprozesses sein, aber auch ein manueller Start.
die Dauer des Exportlaufes bzw. sein voraussichtliches Ende.
der Ort, an dem die Daten abgelegt werden. Ist der Ort variabel (z.B. weil ein Dateiname dynamisch generiert wird), so sind die Verarbeitungsschritte zu definieren, mit denen der Ort festgelegt wird.
die Vorbedingungen, die erfüllt sein müssen, damit der Export erfolgreich durchgeführt werden kann. Z.B. kann gefordert sein, dass genügend Plattenplatz vorhanden sein muss oder dass der Dateiname für eine Ausgabedatei nicht schon vergeben ist.
die Nachbedingungen, die das definierte Ende des Exports markieren.
die Ausnahmebehandlungen, also Verarbeitungsschritte und Ausgaben (Benachrichtigungen), die im Fehlerfall ablaufen und erzeugt werden sollen. Der Business Analyst sollte es hier nicht der Versuchung erliegen, technischen Vorgaben zu machen. Es reicht z.B. die Forderung, dass der Fehler zu protokollieren oder ein bestimmter Anwender (z.B. durch eine automatische Email) zu benachrichtigen ist, wenn der Export gescheitert ist.
Zusätzliche Daten und Informationen, z.B. ein ausgedrucktes Protokoll oder die verwendete Kodieren
Verfahrensschritte, was mit den Daten nach erfolgtem Export zu geschehen hat (z.B. Aufspielen auf Datenträger und Versand mit Kurier)

Beispiel aus der Praxis

Entgegen den Fachanforderungen, die einen Datenexport an ein konkretes Ereignis gebunden hatten, wurde eine Exportroutine zeitgesteuert implementiert. Die Routine lief um 3:00 morgens unter der Annahme, dass die für den Export relevanten Daten i.d.R. gegen 21:00 des Vortages bereitstehen sollten, und dass der Zeitpuffer von ca. sechs Stunden ausreicht. Zudem waren keinerlei Kontroll- oder Benachrichtigungsmechanismen für Folgeprozesse vorgesehen, für den Fall dass der Export scheitern sollte. Die Folgeprozesse verließen sich wiederum darauf, dass der Vorgängerprozess die Daten rechtzeitig und vollständig bereit gestellt hatte, eine Datenprüfung beim Import fand nur sehr rudimentär statt. Gelegentlich kam es nun vor, dass die Daten nicht eintrafen, worauf die Folgeprozesse abstürzten. Einmal startete der Export, als der Vorgängerprozess noch nicht vollständig abgeschlossen war. Der unvollständige Export ging als Import in den Folgeprozesses ein. Es war sehr viel Handarbeit notwendig, um die durch die unvollständigen Daten ausgelösten Fehler zu korrigieren.

Importschnittstellen

Im Sinne von EVA handelt es sich hier um die Eingabe in einen Prozess und, rudimentär, um die notwendigen Verarbeitungsschritte, um das Einlesen der Daten zu vollziehen. Die genauen Arbeitsschritte sind in der Beschreibung des Importprozesses zu dokumentieren.

Der Import enthält Daten, die in einer definierten Menge von Tabellen oder Dateien enthalten sind. Zusätzlich zu den Datenformaten muss noch definiert werden:

der Prozess (Name, Version, Lokation), der den Import verarbeitet.
der Prozess (Name, Version, Lokation), der die Daten erzeugt hat.
die Menge der Daten.
der Auslöser des Imports. Dies kann ein Zeitpunkt oder die Frequenz oder die Benachrichtigung durch den Vorgängerprozess sein, aber auch ein manueller Start.
die Dauer des Importlaufes bzw. sein voraussichtliches Ende.
der Ort, an dem die Daten zu suchen sind. Ist der Ort variabel (z.B. weil die Daten wochentagabhängig in verschiedenen Verzeichnissen zu finden sind), so sind die Verabreitungsschritte zu definieren, mit denen der Ort gefunden werden kann.
die Vorbedingungen, die erfüllt sein müssen, damit der Import erfolgreich durchgeführt werden kann.
die Nachbedingungen, die das Ende des Imports markieren.
die Ausnahmebehandlungen, also Verarbeitungsschritte und Ausgaben (Benachrichtigungen), die im Fehlerfall ablaufen und erzeugt werden sollen. Hierzu gehört auch die Beschreibung, inwieweit ein Rücksetzen (roll back) der Anwendung notwendig ist, oder ob bei teilweise erfolgreichen Import zumindest diese Daten weiter verarbeitet werden können.
Zusätzliche Daten und Informationen, z.B. das ausgedruckte Protokoll des Exports oder die verwendete Kodierung

Beispiel aus der Praxis

Eine zentrale Stelle war für die Verarbeitung von Daten für ein Bundesland zuständig. Die von einem Großrechner erzeugten Daten wurden auf etwa ein Dutzend Institutionen im Land verteilt. Manche der Ladeprozesse stürzten ab. Wie sich zeigte, konnten nicht alle Plattformen die Umlaute wie generiert verarbeiten. Aus diesem Grund wurde eine Datenkonvertierung eingeführt, die Umlaute und ß in gewöhnliche Buchstaben umsetzten. ä wurde aeaeae, ö oeoeoe usw. Beim nächsten Versuch stellte sich heraus, dass die expandierten Umlaute zu große Feldlängen zur Folge hatten, sodass das Stringformat ebenfalls angepasst werden musste.

Bildschirmformulare

Allgemeines

Auf Bildschirmformularen gibt es eine Reihe von Darstellungsmöglichkeiten für Datenelemente. Die interne Datenrepräsentation ist natürlich immer nur in Bits und Bytes. Als es noch keine graphischen Oberflächen gab, waren die Eingabe prinzipiell nur mit der Tastatur möglich und auf strings beschränkt und man konnte dennoch alle Funktionalitäten anbieten, die es heute gibt.

Während eine Spezifikation geschrieben wird, muss auch jedes Bildschirmformular und die Abfolge der Formulare im Story Board definiert werden (vgl. hierzu auch den Inhalt eines Anforderungsdokuments). Es kommt auf den Einzelfall an, ob dies zusammen mit dem Fachanwender im Detail erledigt werden muss, oder ob sich der Fachanwender damit begnügt, lediglich die abzubildenden Geschäftsprozesse zu definieren und die Oberflächengestaltung anderen Leute überlässt. Um Überraschungen zu vermeiden, sollte sich der Anwender am Oberflächendesign beteiligen. Tut er das nicht, hat er auch kein Recht, wegen einer umständlichen Oberfläche die Abnahme zu verweigern, so lange die Funktionalität stimmt.

Für jedes Bildschirmelement sind zu definieren:

Welcher Wert ist voreingestellt, der bei der Initialisierung des Formulars bei der ersten Anzeige gesetzt werden soll?
Muss ein Wert eingetragen oder muss ein oder mehrere Werte ausgewählt werden?
Wie beeinflusst die Eingabe oder Auswahl dynamisch die anderen Datenelemente?

Bei voreingestellten Werten wird gerne übersehen, dass es außer den Überlegungen und Zielen der Fachanwender auch rechtliche Vorgaben gibt. So darf z.B. eine Zustimmung zur Speicherung und Verwertung persönlicher Daten bei Internetanwendungen nicht voreingestellt auf ja stehen. Häufig weiß ein erfahrender Business Analyst so etwas, es ist aber nicht seine Aufgabe, derartige Dinge zu klären. Jedoch sollte er die beteiligten Parteien (Fachanwender, Software-Abteilung) explizit auf das Datenschutzgesetz ansprechen.

Entwurf und Darstellung von Bildschirmformularen

Natürlich soll ein Bildschirmformular auch realitätsnah dargestellt werden, z.B. mit graphischen Entwürfen oder Templates, aber ein Rohentwurf mit einem Textverarbeitungssystem tut es auch. Der Entwurf von Bildschirmformularen ist nicht Aufgabe von Business Analysten. Der Analytiker beschränkt sich darauf, eine Liste von Daten zusammen zu stellen, die als Eingabe in einen Prozess bzw. als Ausgabe eines Prozesses notwendig sind.

Dem Anzeigen eines Bildschirmformulars geht das Erzeugen der notwendigen Daten voraus, und diese zu benennen ist Aufgabe des Analytikers. Eingaben werden nach dem Versenden eines Formulars normalerweise geprüft und im Fehlerfall wird ein Fehlerzustand im Sinne des hinter jedem Story Board steckenden finiten Automaten erreicht. Diese Tatsache wird in weniger professionellen Umgebungen gerne vergessen. Wie die Fehlerzustände dargestellt werden, wird i.d.R. vom Screendesigner nach Rücksprache mit dem Kunden entschieden. Die beiden Standardwege sind (a) die Ausgabe der Fehlermeldung ein einem Fehlerformular, von dem dann zurück zum Eingabeformular gegangen werden muss, und (b) das Hineinschreiben von Fehlermeldungen in das ursprüngliche Formular, das dann meist mit den falsch eingegebenen Daten neu angezeigt wird.

Beispiel aus der Praxis

Eine Webagentur war in einem mittelgroßen Projekt zu Gange. Weder wurden die graphischen Entwürfe der Bildschirme versioniert, noch später die Templates, sodass der Projektleiter oder Entwickler die Entwürfe jedes mal selbst auf Änderungen prüfen musste. Nachdem die Webagentur schlichtweg vergessen hatte, Platzhalter für Fehlermeldungen vorzusehen, einigte man sich unter Zeitdruck darauf, lediglich ein einheitliches Fehlerformular einzuführen. Ein Template hierfür wurde niemals geliefert, einer der Entwickler erarbeitete selbst eine Lösung.

Bei größeren Webanwendungen werden zum Entwurf von optisch brauchbaren Oberflächen Webagenturen benutzt, sonst macht das der Applikationsdesigner oder Entwickler häufig nebenbei. Meistens ergibt sich ein Henne-Ei-Problem: Der Analytiker kann keine vollständigen Vorgaben machen, da die Fachanwender sich die Formulare und deren Bedienung und Abfolge nicht vorstellen können, wenn sie sie nicht sehen, oder, was sehr häufig der Fall ist, sich nicht die Zeit nehmen, die Eingaben und Ausgaben gründlich zu studieren. Die Kreativ-Agenturen wollen jedoch keine Entwürfe machen, wenn keine vollständigen und abgenommenen Vorgaben vorhanden sind. Somit wird der Schwarze Peter gerne im Kreise herum geschoben, wobei lediglich die Frage ist, wer sein Budget höher belastet. Diese Auseinandersetzung wird letztendlich zu Lasten des Projekts statt finden.

Bildschirmformulare unterliegen ergonomischen Einschränkungen und die Größe eines Monitors ist begrenzt. Prozesse müssen also aus diesen Gründen an Oberflächen angepasst werden. Ein mit Datenelementen überfrachtetes Formular ist nicht mehr bedienbar oder lesbar. Die Erfahrung zeigt, dass Webagenturen sparsam bei für Business Analysten verwertbaren Vorgaben sind. Das ist auch keine besondere Überraschung, denn die graphische Gestaltung von Oberflächen lässt einerseits nach dem Plazieren von Teasern, Werbung oder einfach nur verschönernden Elementen häufig nicht mehr viel Platz für Navigation und Datenelemente. Ein hohes Projektrisiko entsteht, wenn eine Webagentur aus optischen Gründen ein prinzipielles Widerspruchsrecht zur Modellierung von Prozessen hat, jedoch die Konsequenzen ihrer Handlungen nicht fühlt. Untragbar wird es immer dann, wenn eine Webagentur keinen eigenen Business Analysten hat, der die Materie hinreichend tief versteht, und der Analytiker des Entwicklungsteams bzw. der Fachabteilung in Anspruch genommen wird, ohne dass das Budget der Webagentur belastet werden kann.

Beispiele aus der Praxis

Ein zweistufiger Prozess, bei dem zunächst ein Datenobjekt in einer ersten komplexeren und vom Anwender zu parametrisierenden Suche auszuwählen war und das dann in einen Folgeprozess mit zusätzlichen neuen anwenderdefinierten Parametern einging, erschien einer Webagentur zu komplex. Man beharrte darauf, einen Mausklick und ein Formular einzusparen, was fachlich nicht möglich war. Der Business Analyst verlor über zwei Tage wegen vollkommen unnützer Diskussionen und verweigerte die Abnahme der Oberfläche, da sie den zugehörigen Prozess nicht mit den passenden Daten versorgen konnte. Die Webagentur ging ein Jahr später pleite.

Screenentwürfe für eine Webanwendung aus dem Finanzbereich enthielten für Edelmetalle und Währungen trotz mehrfacher Reklamationen in Reviews immer wieder eine Wertpapierkennnummer, obwohl diese Instrumente keine WKN haben. Als Grund wurde eine einheitliche Optik angegeben, man wollte alle Instrumente von der Aktie bis zum Edelmetall einheitlich darstellen.

Zu DOS-Zeiten konnten nur 24 Zeilen mit ja 80 Zeichen auf einem Monitor dargestellt werden. Ein Fachanwender hatte mehrere Screenentwürfe abgelehnt und verlangte, dass noch mehr Informationen auf einem Bildschirm dargestellt werden sollten. Der Analytiker rechnete ihm vor, dass die Menge der darzustellenden Zeichen größer als die 24 * 80 Zeichen waren. Der Fachanwender schlug daraufhin vor, doch größere Monitore zu kaufen.

Es kann sinnvoll sein, dass ein Analytiker einen Screen-Designer bzw. Graphiker hinzu zieht, sobald er den Eindruck gewinnt, dass der Fachanwender sich nicht mehr auf abstrakten Niveau bewegen kann. Spätestens aber, wenn die Eingangs- und Ausgangsdaten der Prozesse einigermaßen stehen, sollte der Screen Designer konsultiert werden, und er muss hinzu gezogen werden, wenn ein Prototyp gebaut werden soll.

Bildschirmelemente

Checkbox

Dieses Datenelement wird für binäre Werte (ja/nein) benutzt. Es hat immer einen Wert.

Radiobutton

Radiobuttons werden benutzt, wenn aus einer kleinen Menge von definierten Werten einer ausgewählt werden soll. Unter kleine Menge versteht man i.d.R. zwei oder drei, vielleicht vier Alternativen.

Zu definieren ist:

Voreinstellung: kein Wert oder genau ein Wert
Kein Wert voreingestellt:

Definition des Anwendungsverhaltens, wenn das Formular ohne Auswahl verlassen wird.
Klärung der Frage wie der Weg zurück ist, wenn der Anwender versehentlich einen Radiobutton ausgewählt hat und kein ausgewählter Wert ein sinnvoller Systemzustand ist.

Listbox

Listboxen werden i.d.R. nur zur Anzeige benutzt. Jedoch können auch eines oder mehrere Listenelemente ausgewählt werden. Listenelemente sind strings.

Zu definieren ist:

Voreinstellung: Kein Listenelement, genau ein Listenelement oder eine definierte Menge ausgewählt.
Pflichtauswahl: Muss kein / ein / eine nach Regeln zu definierende Menge ausgewählt werden?

Die Auswahl von mehr als einem Listenelement als Eingabemöglichkeit ist erfahrungsgemäss für durchschnittliche Endanwender nicht handhabbar.

Wenn aus einer großen Menge von Werten, vielleicht mehr als 30, einer ausgewählt werden soll, kann eine Listbox als Eingabemedium interessant sein.

Combobox

Comboboxen werden zur Auswahl von genau einem Wert aus einer mittleren oder großen Menge von Werten benutzt. Die Elemente der Combobox sind strings.

Zu definieren ist analog zu Radiobuttons:

Voreinstellung: kein Wert oder genau ein Wert.
Kein Wert voreingestellt:

Definition des Anwendungsverhaltens, wenn das Formular ohne Auswahl verlassen wird.
Klärung der Frage wie der Weg zurück ist, wenn der Anwender versehentlich ein Element ausgewählt hat und keine Auswahl einen sinnvollen Systemzustand darstellt.

String

Strings werden für beliebige Benutzereingaben verwendet.

Zu definieren ist:

Voreinstellung: Ein leerer String oder ein definierter string.
Der Wertebereich und das Format (z.B. beliebige Texte, aber höchstens 20 Zeichen; ganze Zahlen zwischen 0 und 100)
Das Anwendungsverhaltens, wenn das Formular ohne einen eingetippten gültigen Wert verlassen wird.
Der Umgang mit "nicht ganz richtigen Werten", insbesondere mit unerwünschten Leerzeichen.

Beispiele aus der Praxis

Eine Webanwendung reklamierte, dass "keine Zahl aus dem erlaubten Wertebereich" in einem Editfeld stehen würde, als vor oder hinter der Zahl versehentlich noch ein Leerzeichen stand. - Ein typischer Effekt, wenn man Werte mit copy and paste in die Editfelder einträgt. - Dieselbe Fehlermeldung kam, wenn gar nichts oder einfach nur Buchstaben eingetragen wurden.

Bei der Vergabe von Namen für bestimmte zu speichernde Datenobjekte wurden ausschließlich Leerzeichen ebenso ohne weiteres akzeptiert, wie Namen mit Leerzeichen vor oder nach dem eigentlichen Text. Bei der Anzeige ließen sich die Leerzeichen allerdings nicht mehr erkennen und die untrerschiedlichen Eingaben waren nicht zu unterscheiden.

Eine Testumgebung schnitt numerische Eingaben kurzerhand ab, wenn als Dezimalpunkt ein Komma benutzt worden war, sodass die Nachkommastellen verloren gingen. Nach einer Reklamation wurden nur noch syntaktisch korrekte Eingaben gespeichert, bei Syntaxfehlern beliebiger Art erfolgte jedoch keine Fehlermeldung, sondern es wurde ohne weiteren Kommentar 0 in die Datenbank geschrieben.

Selbst definierte graphische Elemente

Eingaben über graphische Elemente funktionieren nur über Mausklicks. Für die Graphik muss also eine Art Landkarte definiert werden, bei der zu jeder Koordinatenmenge eine Aktion zu definieren ist. HTML sieht so etwas als Standard vor, Sie sehen ein Beispiel in der Übersicht dieser Seiten über Business Analysis. Solche Elemente werden nicht von allen graphischen Oberflächen unterstützt oder können u.U. nur mit sehr hohem Aufwand in Dialoge eingebunden werden.

Prozesse

Allgemeines zur Beschreibung von Prozessen - Was kann man einem Fachanwender zumuten?

Jedes Anforderungsdokument hat drei kritische Prüfungen zu bestehen:

Wird das Dokument vom Fachanwender verstanden?
Wird das Dokument vom Software-Designer und Software-Entwickler verstanden?
Sind einzelne Passagen des Dokuments interpretierbar?

Prozessbeschreibungen dürfen nicht interpretierbar sein und müssen den Prozess wiedergeben, den der Fachanwender umgesetzt sehen will. Die Uninterpretierbarkeit ist lediglich Theorie, der Analytiker kann nur eine möglichst gute Annäherung versuchen.

Beispiel aus der Praxis

Ein Projektmanager reklamierte im Rahmen verschiedener interner Durchsichten die Interpretierbarkeit eines Anforderungsdokuments. Es stellte sich jedoch heraus, dass er nur das erste Drittel des Dokuments gelesen hatte (ca. 60 Seiten), hauptsächlich Tippfehler fand und auf den 60 Seiten lediglich zwei interpretierbare Stellen nachweisen konnte, die nicht zu fatalen Problemen geführt hätten; alle anderen Reklamationen konnten ihm erklärt werden. Dabei zeigte sich, dass er die im Projekt benutzte Fachsprache nicht verstand. Der Projektmanager hatte keine IT-Kompetenz und kannte sich auch im zu untersuchenden Fach nicht aus. Seine Stelle wurde wenige Monate später eingespart.

Um sicher zu stellen, dass der Prozess den Forderungen des Fachanwenders entspricht, muss der Fachanwender den spezifizierten Prozess nachvollziehen. Dies geschieht durch das Studium der Spezifikation, Walkthroughs mit dem Analytiker und das Durchspielen von Beispielen. Somit ist es hinsichtlich der Darstellung des Geschäftsprozesses in der Spezifikation nicht so sehr die Frage, wie man den Geschäftsprozess optimal im Sinne der IT darstellt, sondern dass man ihn in einer Form beschreibt, sodass ihn der Fachanwender auch versteht.

Als Mitarbeiter der Fachabteilung sollten Sie allerdings nicht davon ausgehen, dass Ihnen Ihr Analytiker alles auf einem Silbertablett liefert und Anforderungen für Sie erfindet. So, wie sich Ihr Analytiker die Grundlagen Ihres Faches aneignet, ist es an Ihnen, sich die Grundlagen der IT und der Geschäftsprozessanalyse anzueignen. Weder müssen Sie programmieren noch Programmcode verstehen, aber Sie müssen verstehen, dass ein Verfahren im Computer nur funktionieren kann, wenn es auf dem Papier funktioniert. Die wesentlichen Darstellungselemente dazu sind:

Eingabe vom Bildschirm, lesen von Daten aus anderen Datenquellen
Ausgabe auf den Bildschirm, Ausgaben auf andere Medien (Drucker), schreiben von Daten in eine Datei oder Datenbank
der Arbeitsschritt - z.B. errechne den Bruttopreis = Nettopreis zzgl. Mehrwertsteuer; speichere die Information;
die Entscheidung bzw. Verzweigung bzw. Alternative: wenn... dann... sonst... - z.B. wenn die Stückzahl > 10 dann reduziere den Preis um 10% Rabatt; wenn Stückzahl leer dann Fehlermeldung "Stückzahl ist eine Pflichteingabe" sonst speichere Stückzahl;
der Subprozess: ein Prozess startet einen anderen Prozess und wartet auf dessen Ergebnisse. Subprozesse bestehen wiederum nur aus Eingaben, Ausgaben, Arbeitsschritten und Entscheidungen.

Die in den Prozessen verwendeten Daten müssen klar und eindeutig darstellbar sein. Z.B. ist die Beschreibung der Verzweigung "wenn es sich noch nicht um einen Kunden handelt, dann wird in der Bildschirmmaske 'noch kein Kunde' angeklickt" für das Software-Design vollkommen unbrauchbar und wird vom Analytiker nur vorübergehend geduldet sein, so lange der Fachanwender noch nicht entschieden hat, auf welche Weise er feststellt, dass es sich bei einer Person noch nicht um einen Kunden handelt. Noch nicht Kunde sein ist kein Datum, sondern eine vage Information, vielleicht auch nur eine Meinung oder das erratene Resultat des Anwenders. Irgendwie und irgendwoher wird es der Fachanwender wohl wissen, aber woher? Die Irgendwie-Funktion gibt es nicht und auch nicht die Vielleicht-Funktion. Woran erkennt man, dass es sich noch nicht um einen Kunden handelt? Woran erkennt es der Fachanwender, woran der Analytiker, woran das Programm? Was wird überhaupt angeklickt? "Wenn der Kunde auf dem Fragebogen das Feld 'ich bin bereits Kunde' nicht angekreuzt hat, dann wird die Checkbox 'noch kein Kunde' angeklickt" ist klar, denn die abgebildete Arbeitsanweisung wird transparent. - Natürlich kann ein Software-Designer einfach die Checkbox im guten Glauben vorsehen, dass der Analytiker mit dem Kunden mündlich oder sonst wie geklärt hat, dass dies seine Richtigkeit hat und der Scree-Designer dies auch so sieht, aber nachfragen sollte er allemal, sofern keine anderen Vereinbarungen zur Vorgehensweise explizit getroffen worden sind. Der Business Analyst würde jedoch unverantwortlich handeln, wenn er sich vom Kunden nicht explizit nachweisen läßt, woher er weiß, dass jemand noch kein Kunde ist.

Wird ein fertiges Anforderungsdokument erstmals dem technischen Team vorgelegt, so werden i.d.R. auch erstmals die Prozesse von Leuten durchleuchtet, die die Vollständigkeit und Interpretationsfreiheit im Sinne der IT tatsächlich prüfen können. Sie können nicht die Informationen finden, die der Fachanwender dem Analytiker vorenthalten hat. Dafür finden Sie logische Widersprüche und Abläufe, die interpretierbar sind und sowohl vom Analytiker als auch vom Fachanwender übersehen wurden. Die Interpretierbarkeit wird dadurch festgestellt, dass der Techniker im Laufe des Designs oder später der Entwicklung mehrere Abläufe herleiten kann, die zu verschiedenen Ergebnissen führen. Nach einer ersten Durchsicht im stillen Kämmerlein erhält der Analytiker im Normalfall einen schriftlichen Fragenkatalog. Ein Software-Designer sagte mir einmal, dass er mit einem großen Telekommunikations-Ausrüster gearbeitet hatte, der als Richtwert für eine gute Spezifikation 2 Fehler je Seite und 1 fatalen Fehler je 10 Seiten angesetzt hat. Ich halte solche Zahlen für pessimistisch, wenn dem Analyseprozess genügend Zeit und Stellenwert eingeräumt wird und die Fachanwender aktiv mitarbeiten. Die Zahl wird jedoch realistisch, wenn die Spezifikationsphase unter Zeitdruck voran getrieben wird und eine Abnahme erzwungen wird, nur, damit ein Resultat geliefert wird.

Beispiel aus der Praxis

Eine halbfertige Spezifikation wurde mit der Bitte um einen interne Durchsicht auf Korrektheit der bisher spezifizierten Anforderungen an den Auftraggeber geliefert. Der Analytiker rechnete mit einer Dauer von einer Woche und setzte dem Kunden einen Termin von zwei Wochen. Nach zehn Wochen kam endlich der Rücklauf, Fehler wurden nur wenige gefunden. In der Zwischenzeit wurde am Anforderungsdokument weiter gearbeitet und am Ende wurden die Ergebnisse abgeglichen. Der Liefertermin des Produkts wurde zunächst auf unbestimmte Zeit verschoben, da nicht abzusehen war, wie schnell die Fachanwender in Zukunft reagieren würden. Später im Projekt trat dennoch Zeitdruck auf. Das technische Team reklamierte etwa einen Fehler auf zwei Seiten, wovon zwei Drittel ohne Rückfrage beim Kunden ad hoc geklärt werden konnten, und einen fatalen Fehler auf 40 Seiten. Der Business Analyst war von dem Ergebnis ebenso positiv überrascht wie die Projektleitung.

Darstellungsformen für Prozessschritte

Prosa

Prosa kann langatmig sein, sie ist unstrukturiert und hat den Nachteil, dass der Fachanwender dazu tendiert, sie eigenmächtig zu korrigieren, ohne sich der Konsequenzen seiner Änderungen bewußt zu sein. Die Herleitung von Testfällen kann das Lesen der Spezifikation ebenfalls zur Qual werden lassen. Der Vorteil ist: Lesen kann jeder Fachanwender und IT-Spezialist.

Bei Prosa wird der Prozess i.d.R. in Form eines Fliesstextes dargestellt, wobei andere Darstellungsformen eingestreut werden. Eine feste Struktur für die Darstellung eines einzelnen Prozesses ist nicht vorgegeben.. Das Lesen des Dokuments fällt leicht, wenn es kurz ist, und wird zäh, wenn es lang ist.

Beispiel aus der Praxis

Ein Business Analyst hatte nach mehreren Personenmonaten ein Analysedokument erstellt, das über 150 Seiten stark war. Er hatte zunächst Prosa und strukturiertes Deutsch und einige Programmablaufpläne als Form gewählt, von der er sicher war, dass die Fachanwender die Darstellung auch versteht. Im Laufe mehrerer Durchsichten des Dokuments hatte der Kunde Einträge vorgenommen, die in einer Spezifikation nichts zu tun hatten; er insistierte jedoch auf diese Einträge, um sie als Vertragsbestandteil unterzubringen. Alternativabläufe und Randbedingungen waren noch nicht strukturiert heraus gearbeitet und teilweise in Nebensätzen in der Prosa versteckt. Das Dokument wandelte sich von einer prozessgetriebenen Beschreibung in eine oberflächengetriebene Beschreibung, da die prozessgetriebene Beschreibung wegen inflationär wachsender alternativer Abläufe nicht mehr durchzuhalten war. Der Projektmanager setzte eine Woche für das Design an, wogegen der Analytiker meinte, dass alleine das erstmalige Lesen des Dokuments zwei Tage dauern würde.

In einem anderen Fall spezifizierte derselbe Analytiker ein kleineres Produkt im Laufe von eineinhalb Personenwochen. Der Fachanwender hatte selbst hohe IT-Kompetenz und arbeitete sehr zielorientiert, vollzog das Dokument in mehreren Durchläufen selbst vollständig nach und suchte bei Änderungen stets den Konsens mit dem Analytiker. Das Produkt wurde erst nach seinem Ausscheiden aus dem Unternehmen implementiert. Der Kunde bekam das, was er wollte.

Fachanwender begrüßen häufig Prosa, da sie sie verstehen. Die Fallbeispiele zeigen aber recht klar, dass man einen sachlichen Fachanwender benötigt, um mit Prosa arbeiten zu können. Prosa hat den Nachteil, dass die fehlende feste Form dem Kunden erlaubt, alles mögliche zu ergänzen, ohne die Form zu verletzen.

Dank Eric und Stilzi nutze ich Prosa nur noch ausnahmsweise.

Strukturiertes Deutsch

Strukturiertes Deutsch findet man nicht nur in der IT, Kochbücher oder OP-Berichte von Ärzten sind sehr ähnlich. Strukturiertes Deutsch bzw. eine strukturierte Verwendung einer anderen natürlichen Sprache kann als Vorstufe zum Pseudocode betrachtet werden. Beim strukturierten Deutsch benutzt man eine einfache Sprache, die bestimmte Begriffe immer in einem eindeutigen Kontext verwendet. Es ist nicht falsch, diese Begriffe besonders hervor zu heben, z.B. durch Unterstreichung. Verschiedene Hervorhebungen können auf unterschiedliche Bedeutungen hinweisen, z.B. die Unterscheidung in algorithmische Entscheidungen und Standard-Funktionalitäten (z.B. Wenn dann, Eingabe, Ausgabe) und systemspezifische Funktionalitäten, die im Kontext jedoch klar sind (z.B. suche, gefunden). Bewährt hat es sich, dass man die einzelnen Prozessschritte durchnumeriert und lediglich den Geradeausflug darstellt. Im Geradeausflug werden zwar die Bedingungen (wenn... dann...) dargestellt, jedoch werden die Alternativen in einem eigenen Abschnitt dargestellt. Man befindet sich hier schon auf halben Weg zum Anwendungsfall.

Strukturiertes Deutsch kann etwa so aussehen:

Der Anwender wählt die Suchmaske-Kundennummer aus.
Das System zeigt die Suchmaske-Kundennummer an.
Eingabe: Der Anwender tippt die Kundennummer ein und löst die Suchfunktion aus.
Das System sucht den Kundenstammdatensatz.
Wenn der Kundenstammdatensatz gefunden wird, dann...
Das System zeigt den Kundenstammdatensatz an.

Alternative zu Schritt 5:

5. Wenn der Kundenstammdatensatz nicht gefunden wird dann
5.1 Ausgabe einer Fehlermeldung
5.2 Weiter bei Schritt 2 im Originalablauf

Diese Beschreibung ist noch nicht tauglich für einen Software-Entwickler (wie wird die Suchmaske ausgewählt, wo wird die Kundennummer eingetippt, wie wird die Suchfunktion ausgelöst?) und noch dazu unvollständig, reicht aber vorübergehend als Prozessbeschreibung aus hoher Sicht aus. In einem technischen Review würde sie auf jeden Fall durchfallen.

Selbst ein Anfänger kann hier sehen, dass eine Lücke in der Prozessbeschreibung ist: Wie kommt der Anwender aus der Suchmaske, wenn er keine gültige Kundennummer hat? Man wird also noch einen alternativen Ablauf zu Schritt 3 definieren müsse, in dem die Suchmaske verlassen und zur nächst höheren Funktion zurück gekehrt wird.

Oder haben Sie die Lücke nicht gesehen? Dann haben Sie ein typisches Problem einer Anforderungsanalyse erfahren: Man muss den Ablauf genau nachvollziehen und wirklich verstehen, um Fehler zu entdecken. Ein einfaches Überfliegen reicht nicht.

Vorsicht bei logischen Ausdrücken: Fachanwender unterscheiden selten zwischen exklusivem oder (XOR) und inklusiven oder (OR)!

Fachanwender neigen dazu, bei strukturiertem Deutsch eher auf grammatikalische als auf inhaltliche Fehler zu achten. Aber im Gegensatz zur Prosa sind die einzelnen Arbeitsschritte und Entscheidungen klar erkennbar und der Anwender wird nicht ohne weiteres einen Schritt modifizieren, ohne über die Konsequenzen wenigstens innerhalb dieses Ablaufs nachzudenken.

Flussdiagramme

Flussdiagramme werden für Programmablaufpläne (PAP), Datenflüsse und Prozessflüsse benutzt. Die Idee des Flussdiagramms ist schon ziemlich alt und daher auch bekannt. Aufgrund des Alters gibt es noch eine Reihe von Darstellungselementen, die man heute beim besten Willen nicht mehr braucht, z.B. die Karte. Einem Fachanwender den Unterschied zwischen standardisiertem Prozess, Alternativprozess, Subprozess, Eingabe (als Prozessteil) etc. auseinander zu setzten macht nur wenig Sinn. In einem Anforderungsdokument sollte man die Darstellungselemente großzügig interpretieren und sich auf die Darstellung von Start/Ende, Prozess (für alles mögliche), Entscheidung und Zusammenführung beschränken (im Bild der kleine Kreis, in dem nichts steht). Fallabhängig können noch ein oder zwei weitere Darstellungselemente hinzugenommen werden (z.B. für manuelle Verarbeitung oder für das Speichern von Daten), aber recht viel mehr sollte man einem durchschnittlichen Fachanwender nicht mehr zumuten.

Ein Bild sagt mehr, als tausend Worte. Zumindest manche Bilder. Der Prozessfluss ist jedenfalls sofort sichtbar und man muss nicht unbedingt mehrere Kapitel für alternative Abläufe schreiben, wie dies beim strukturierten Deutsch der Fall ist. Ein großer Vorteil ist, dass man nicht versehentlich unvollständige Prozesse darstellt: Im Bild würde eine fehlenden nein-Verzweigung bei der Entscheidung selbst bei oberflächlicher Betrachtung sofort auffallen und hinterfragt werden, wie der Prozess dann fortgesetzt wird.

Wenn Fachanwender zum ersten Mal ein Flussdiagramm sehen, kriegen sie meist einen Schreck. Der Analytiker sollte sich also zuerst erkundigen und dann wenn nötig die Darstellungselemente erklären und einen exemplarisch Prozess zusammen mit dem Fachanwender durchspielen.

Flussdiagramme sollten auch nicht überfrachtet werden. Hat man mehr als drei Entscheidungen in einem Ablauf, dann wird das Bild unübersichtlich und passt wahrscheinlich nur noch schwer auf eine Seite.

Im Rahmen eines Anforderungsdokuments sollte das Flussdiagramm auch nur für die Darstellung einer abstrakten Sicht auf den Prozess benutzt werden und nicht für einzelne Abläufe auf dem Niveau, das ein Programmierer anstrebt. Ein Prozess kann also einfach nur "Prüfung der Eingabe" heißen, und die anschließende Entscheidung "Eingabe korrekt?". Die Prüfung selbst muss natürlich außerhalb des Flussdiagramms dargestellt werden, z.B. durch strukturiertes Deutsch.

Pseudocode

Pseudocode beschreibt einen Algorithmus in einer Weise, die einer Programmiersprache sehr ähnelt. Der im Abschnitt über strukturiertes Deutsch einige Absätze weiter oben dargestellte Prozess könnte etwa so aussehen:

Beginn Prozess
Der Anwender wählt die Suchmaske-Kundennummer aus.
Wiederhole unendlich (Schleife1):
    Das System zeigt die Suchmaske-Kundennummer an.
    Wenn der Andwender in der Suchmaske-Kundennummer Abbruch wählt
        dann: verlasse Prozess
    Eingabe: Der Anwender tippt die Kundennummer ein und löst die Suchfunktion aus.
    Das System sucht den Kundenstammdatensatz.
    Wenn der Kundenstammdatensatz gefunden wird,
      dann:
            Das System zeigt den Kundenstammdatensatz an.
            verlasse Prozess (nach Rückkehr aus der Anzeige des Kundenstammdatensatzes)
        sonst:
              Ausgabe einer Fehlermeldung
Ende (Schleife1)
Ende Prozess

Diese Form ist geschwätziger als strukturiertes Deutsch, aber genauer. Ob sie leichter lesbar ist, ist Geschmacksfrage. In der numerierten Darstellung beim Abschnitt über strukturiertes Deutsch ist offensichtlich, dass nach der Anzeige des Kundenstammdatensatzes das eigentliche erfolgreiche Prozessende (Ende des Geradeausfluges) erreicht ist, im Pseudocode "versteckt" sich das Prozessende in einer Schleife. Diese Schleife ist noch dazu eine Unterstellung, denn der Entwickler kann eine Reihe von Wegen einschlagen, um die geforderte Funktionalität umzusetzen. Da auf das Schleifendende das Prozessende folgt, kann genau genommen überall, wo "verlasse Schleife 1" steht, auch "verlasse Prozess" stehen, und umgekehrt; ein Fachanwender, der ohnehin nicht programmieren kann, kann schwerlich einem Entwickler solche Entscheidungen aufzwingen.

Entwickler verwenden Pseudocode gerne im Rahmen eines high level designs, dann allerdings exakter als im Beispiel. Pseudocode in einem Anforderungsdokument zu benutzten, ist dagegen eine zweischneidige Angelegenheit: Versteht ihn der Anwender? Was macht der Entwickler damit? Ein Business Analyst darf dem technischen Design nicht vorgreifen. M.E. sollte Pseudocode bzw. auch eine Pseudocode-ähnliche Darstellungsform nur benutzt werden, wenn man einen guten Grund hat, denn sie unterstellt Abläufe, die zur Erzielung der Ergebnisse und zur Beschreibung der Prozesse nicht notwendig sind.

Meine Erfahrung ist, dass Entwickler unter bestimmten Umständen Pseudocode begrüßen, Anwender ihn jedoch nicht verstehen oder missverstehen. Pseudocode kann am ehesten dort benutzt werden, wo das Zusammenspiel verschiedener Prozesse dargestellt werden soll, oder wo Details komplexer Prozesse transparent gemacht werden sollen. Dabei sollte jedoch stets der Hinweis vorhanden sein, dass es sich dabei lediglich um eine Anregung zur Umsetzung handelt, nicht jedoch um eine Vorgabe. Entwickler nutzen den Pseudocode dann, um ein tieferes Verständnis für den Prozess zu bekommen. Da unverbindliche Teile jedoch in einem Anforderungsdokument nichts zu suchen haben, fährt man am besten damit, Pseudocode in einem getrennten Dokument zu verwalten, das dann als interne Anlage zur Spezifikation verwendet wird. Da ein Fachanwender Pseudocode ohnehin nicht versteht, macht es auch nur wenig Sinn, Pseudocode zur Abnahme vorzulegen. Die Abnahme würde außerdem eine Forderung nach Verbindlichkeit bedeuten und somit würden Fachanwender und Business Analyst ins Software-Design eingreifen.

Pseudocode schließt eine entscheidende Gefahr ein: Der dargestellte Algorithmus ist nur auf dem Papier getestet, eine Umsetzung eins zu eins führt in den seltensten Fällen sofort zu einem funktionierenden Programm. Z.B. enthielt der Code oben einen Fehler (genau genommen einen überflüssigen Code-Teil), der von keinem Leser, auch nicht von den Probelesern, reklamiert worden ist (und wahrscheinlich auch von kaum einem bemerkt worden ist), und von mir erst zwei Monate nach Life-Stellung dieser Seite im Rahmen einer Überarbeitung entdeckt und behoben wurde. - Review passed, Anforderungsdokument abgenommen, kostenpflichtiger Change Request. Da haben wir es! - Wird Pseudocode als verbindliche Vorgabe benutzt und der Entwickler weist Lücken oder Fehler nach, so bleibt ihm formal nichts anderes, als die Fehler zu implementieren und auf einem kostenpflichtigen Change Request zu beharren. Auch aus dieser Sicht heraus ist es günstiger, lediglich den logischen Prozessablauf aus Sicht des Fachanwenders darzustellen und nicht zu versuchen, auf die physikalische Umsetzung vorzugreifen.

Pseudocode sollte nur in begründeten Ausnahmefällen in einem Anforderungsdokument verwendet werden.