Ich möchte heute kurz darstellen welche Form der Gliederung ich für die fachliche Konzeption von Anwendungssystemen im Bereich Geschäftsprozess Management (BPM) bzw. Workfow Management (WFMS) anwende.
Im Grunde genommen geht es bei der Fachkonzeption um die Beschreibung des „was“. Es werden also Fragen beantwortet in der Form: „Was leistet das System?“, „Was können Anwender damit tun?“, „Was für Daten und Geschäftsabläufe sollen abgebildet werden?“
Dies gilt natürlich für den Bereich Geschäftsprozess Management ganz besonders. Gerade als Softwareentwickler ist man leider meist versucht zu schnell zu beschreiben „wie“ man die Probleme lösen möchte. Aber das „wie“ soll nicht Kern eines Fachkonzepts sein. Hierfür ist ein IT Konzept besser geeignet. Da ich aber selbst oft beide Fragestellungen in einem Dokument vereine ist die Gliederung umso wichtiger.Doch nun zu meinem konkreten Vorschlag einer Gliederung den ich für Fachkonzepte bei Softwareprojekte im Bereich BPM bwz. WFMS generell anwende.
Einführung – Überblick
Die Einführung stellt einen groben Überblick über das zu entwickelnde Softwaresystem bzw. den damit abzubildenden Geschäftsprozess dar. Ich denke man sollte hier nur in wenigen Sätzen das grobe Ziel formulieren und nicht zu sehr Dinge vorweg nehmen.
- Überblick
- Zielsetzung
- Anforderung an das System
Geschäftsprozesse
Nach der Einführung beschreibe ich die konkreten Geschäftsabläufe welche mit dem Softwaresystem abgebildet werden. Dazu benenne ich zunächst die Akteure. Also „wer“ eigentlich mit dem System arbeitet. Es ist erstaunlich wie oft man hier beim Kunden schon Diskussionen anregt, an die dieser zuvor gar nicht gedacht hat.
Als nächstes beschreibe ich dann in Form von Use-Case Diagrammen die einzelnen Anwendungsfälle. Ich bin der Meinung man kann hier gar nicht genug vereinfachen. Nur wen die einzelnen Anwendungsfälle wirklich in ihrer Grundfunktion dargestellt sind, kann man sicher sein, dass der Auftraggeber und Auftragnehmer vom selben sprechen. Leider ist dieser Teil eines Fachkonzepts stark davon gefährdet von Technikern vereinnahmt zu werden, was oft dazu führt das technische Details beschrieben werden die dann nicht wirklich zur Klarheit beitragen.
Nach den Anwendungsfällen beschreibe ich als nächstes die einzelnen Workflows. Also die konkreten Abläufe innerhalb eines Geschäftsprozesses. Auch hier wieder aus fachlicher Sicht: Was passiert wann? Wer bearbeitet einen Vorgang? Wer wird Informiert? Wer ist verantwortlich. Praktisch verbindet die Workflow Beschreibung die „Akteure“ mit den „Use Cases“.
- Geschäftsprozesse
- Akteure und Zuständigkeiten
- Anwendungsfälle (Use Case Diagramme)
- Workflow
Benutzermodell
Im Kapitel Benutzermodell beschreibe ich nun die einzelnen Anforderungen aus Sicht des Benutzers. Wer arbeitet mit dem System? Wer erhält welche Rolle? Und wie bedient man das System?
Wichtige Teilabschnitte sind hier „Dialogabläufe“ und „Oberflächengestaltung“. Es geht hier darum zu beschreiben welche Dialoge vom Anwender bearbeitet werden müssen um eine bestimmte Aufgabe zu erledigen. Die Oberflächengestaltung beschreibt – möglichst anhand von Screen-Dummies – wie die Anwendung aussehen wird.
- Benutzermodell
- Berechtigungskonzept
- Authentifizierung
- Dialogabläufe
- Oberflächengestaltung
Daten- und Funktionsmodell
Der letzte Gliederungspunkt meiner Fachkonzepte ist das Daten- und Funktionsmodell. Hier beschreibe ich welche Daten mit dem System verarbeitet werden. Auch steht ist die fachliche Sicht wieder im Vordergund. Es geht bei den Datenmodellen also zunächst nicht darum welche Datentypen einzelne Felder haben, sondern wie diese Felder in den Formularen eigentlich benannt werden und was für Daten damit erfasst werden können.
Das Funktionsmodell beschreibt dann häufig funktionelle Anforderungen die bisher so nicht dargestellt wurden. Z.B. Datenschnittstellen zu anderen Systemen, Archivierungskonzepte oder Fragen zur Migration. Wichtig ist auch hier: Die Technik kommt später, es geht um das „was“.
- Datenmodell
- Formular1
- Formular2
- ….
- Funktionsmodell
- Archivierung
- Emailbenachrichtigungen
- usw…
Auf Basis eines solchen Fachkonzepts ist die Umsetzung dann keine große Kunst mehr. Setzt man auf Workflow Management Komponenten wie dem Imixs JEE Workflow reduziert sich auch ein IT-Konzept auf wenige Details da man ja den Großteil der Business Logik als fertigen Baustein übernimmt 😉