Tool Set für Fachspezifikation: Alles von Anforderungen bis Aktivitäten
Aktualisiert: 27. Apr. 2021
Eine Fachspezifikation beschreibt die fachlichen Anforderungen und Probleme, die es in einem Projekt zu lösen gilt. Es ist nicht notwendigerweise ein einziges großes Dokument. Ganz im Gegenteil: Es ist sehr viel sinnvoller, die verschiedenen Aspekte in unterschiedlichen Dokumenten und Modellen zu beschreiben.
Im Folgenden möchte ich eine Werkzeugpalette vorstellen, die meines Erachtens alle Mittel bereitstellt, um auch komplexe Zusammenhänge verständlich zu beschreiben. Es ist eine Kombination aus Textdokumenten, BPMN und UML. Wenn ich sage “verständlich beschreiben”, meine ich, dass die Dokumentation von den Projektbeteiligten verstanden werden muss. Das schließt die Auftraggeber und Fachabteilung gleichermaßen ein wie Designer und IT-Architekten. Denn nur, was verstanden wird, kann auch umgesetzt werden. Fehlt es an einer breiten Verständnisbasis, sind einerseits die Ziele unklar. Andererseits wäre es somit purer Zufall, wenn die Projektergebnisse (z.B. eine Software-Lösung) die ursprünglich erhobenen Anforderungen erfüllen.
Die folgenden Modelle und Dokumente müssen nicht in der hier vorgestellten Reihenfolge erstellt werden. Sie entstehen häufig parallel. Bei der Arbeit an einem Teil ergeben sich Aspekte, die Auswirkungen auf andere Modelle / Dokumente haben. Und nicht immer braucht man in jedem Projekt alle hier beschriebenen Artefakte. Man muss also immer wieder prüfen, was wirklich erforderlich ist. Es gilt: So wenig wie möglich, so viel wie nötig.
Das Tool Set im Überblick
Schauen wir uns das mal im Groben an. Wir haben
Anforderungen
Stakeholder
Geschäftsprozesse
Geschäftsobjekte
Kernkonzepte und
Beschreibung der Aktivitäten.
Dafür stehen uns verschiedene Notationen und Werkzeuge zur Verfügung.
Nutzen zentrierte IT-Beratung: Die wichtigsten Aspekte einer Fachspezifikation
Die richtige Darstellung
Nicht immer ist ein langes Textdokument das geeignete Mittel. Und nicht immer ist ein grafisches Modell hinreichend. Es gibt so viele Möglichkeiten, die eigenen Ideen verständlich zu vermitteln. Denn schließlich geht es nur darum. Einige Mittel sind:
UML
BPMN
Freie Grafiken
Mind Maps
Text
Wählen Sie eine gesunde Mischung. In früheren Artikeln habe ich dargelegt, dass reine Textwüsten genauso unzureichend sind wie pure UML-Schlachten:
Anforderungen
Anforderungen müssen kurz, präzise, atomar, messbar und widerspruchsfrei formuliert sein.
Klare Anforderungen sind die Grundlage für den Projekterfolg! Dies scheint so selbstverständlich zu sein, dass man fragen mag, warum ich damit beginne. Leider kranken viele Projekte genau an diesem Punkt: Eine unklare Anforderungslage. Wie kommt es dazu?
Es werden nicht alle Beteiligten gefragt, die Anforderungen an das Projekt stellen.
Anforderungen werden vage formuliert.
Es mangelt an Abgrenzungen: Welche Anforderungen gilt es NICHT zu erfüllen.
Es werden nur die fachlichen Anforderungen erhoben. Die Nicht-funktionalen werden vernachlässigt.
Diese und weitere Gründe führen dazu, dass Projektergebnisse nicht gemessen werden können. Man kann also nicht genau sagen, ob man wirklich fertig ist und ob das Ergebnis abgenommen werden kann. Vielleicht kennen Sie auch Software-Lösungen, die zwar die fachlichen Funktionen bieten, aber unbedienbar und/oder extrem langsam sind. Da dürfte es an messbaren Nicht-fachlichen Anforderungen gefehlt haben.
Tipps zur Formulierung von Anforderungen
lohmeyer | Business UX: Übersicht Anforderungen
In einem größeren Projekt sammeln sich schnell mehrere hundert Anforderungen. Es können auch mal tausend und mehr werden. Kategorisieren Sie daher die Anforderungen und geben Sie an, woher die jeweilige Anforderung kommt. Quellen können Meetings sein. Viele Anforderungen ergeben sich aber auch aus Gesetzen und Normen.
Anforderungen an Anforderungen
Eindeutig
Widerspruchsfrei
Atomar
Messbar
Positiv formuliert
Inhalte einer Anforderung:
ID + Titel
Kategorie, Themenbereich
Typ: Fachlich, Nicht-funktional
Beschreibung
Quelle
Status: angenommen, in Abstimmung, abgelehnt
Anforderungen müssen nicht nur erhoben, sondern auch wieder gefunden werden. 100 Anforderungen kann man ggf. noch mit Postit’s an der Pinnwand sammeln. Für eine höhere Anzahl von Anforderungen empfiehlt sich der Einsatz von Datenbank gestützten Modellierungstools.
Sorgen Sie für eine klare Anforderungslage. So verhindern Sie weiche und sich verändernde Projektziele – die sogenannten Moving Targets. Denn denen kann auch die beste Entwicklungsabteilung nicht hinterher entwickeln.
Stakeholder
Stakeholder sind nicht nur die unmittelbar beteiligten sondern ggf. auch Dritte wie eine Finanzbehörde oder der Gesetzgeber.
Stakeholder sind Personen oder Gruppen, die an dem Gelingen Ihres Projektes ein Interesse haben. Das sind nicht notwendigerweise ausschließlich die Benutzer (User). Ein entscheidender Stakeholder ist in der Regel der Auftraggeber bzw. das Management. Dieser Personenkreis wird vermutlich nie mit der Softwarelösung arbeiten, ist aber nichtsdestotrotz -zumindest als Geldgeber- extrem wichtig. Weitere Stakeholder können der Gesetzgeber oder Berufsverbände sein. Sie stellen Regeln auf, die es einzuhalten gilt. Ignoriert das Projekt sie, kann das gesamte Projekt gestoppt werden, bzw. der Einsatz der Projektergebnisse nachträglich untersagt werden. Diese Stakeholder gilt es also, frühestmöglich in die Anforderungsanalyse einzubinden. Sie müssen nicht notwendigerweise mit dem Staatsanwalt sprechen. Die relevanten Gesetzestexte und Verordnungen sollten Sie aber schon hinsichtlich abzuleitender Anforderungen analysiert haben.
Nutzen zentrierte IT-Beratung: Stakeholder können auch über ein Organigramm ermittelt werden.
Zur Auflistung der Stakeholder können verschiedene Mittel dienen. Ein Organigramm ist immer hilfreich, um gerade in großen Unternehmen betroffene Abteilungen und Personen zu identifizieren. Ansonsten können Sie aber auch Aktoren-Diagramme in UML modellieren.
Wichtig an diesem Analyseschritt ist, dass Sie über die direkten Nutzer hinaus alle Personen und Organisationen, die auf das Projekt Einfluss nehmen, identifizieren.
Geschäftsprozesse
Unternehmen, ihre Bestandteile, externe Partner und Kunden treten nicht in strikt abgetrennten Aktivitäten in Interaktion sondern zumeist in Form ineinander übergreifender Prozesse. Diese werden Geschäftsprozesse genannt. Führt uns die Betrachtung einzelner Aktivitäten sehr schnell tief in die Details, ermöglicht uns die Geschäftsprozessanalyse den Blick aus der Vogelperspektive. Diese Perspektive ist sehr hilfreich, um sich der Problemlage zu nähern, globale Schwierigkeiten herauszuarbeiten und organisations-, abteilungsübergreifende Prozessoptimierungen zu formulieren. Dabei betrachten wir nicht nur die verschiedenen Prozessschritte sondern auch die Geschäftsobjekte, die dabei ausgetauscht werden.
Es gibt viele Möglichkeiten, Geschäftsprozesse zu modellieren. Ich persönlich bevorzuge BPMN, da diese Notation auch von Nicht-IT-Experten sehr gut verstanden wird. Und wie ich schon sagte, die Fachspezifikation ist nur so gut, wie sie verstanden wird.
Nutzen zentrierte IT-Beratung: Geschäftsprozesse lassen sich mit BPMN sehr gut darstellen.
Die Abbildung zeigt einen Prozess, der in Abhängigkeit bestimmter Ereignisse spezielle Subprozesse einbindet. Durch die Verlagerung der Details in Subprozesse gewinnt die Lesbarkeit. Und das wird man spätestens bei der Modellierung organisationsübergreifender Prozesse mit mehreren Pools zu schätzen wissen.
Geschäftsobjekte
Ein zentraler Bestandteil der Informationstechnologie sind verständlicherweise die Informationen. Diese Informationen gelangen häufig in Form realer Objekte wie Antragsformularen, Ausweisen etc. in unsere Geschäftsabläufe. Ebenso sind aber auch Telefonanrufe oder E-Mails Objekte des realen Lebens – wenngleich man sie nicht anfassen kann. Diese Informationen werden verarbeitet, und es entstehen neue Geschäftsobjekte. Beispielsweise könnte am Ende eines Geschäftsprozesses eine Versicherungspolice erstellt und verschickt werden.
Diese Geschäftsobjekte sollte man zentral sammeln, da sich hieraus die Datenstruktur unseres Systems später ableitet.
Nutzen zentrierte IT-Beratung: Reale Geschäftsobjekte und abstrahierte Fachobjekte
Die Abbildung zeigt an den Objekten der realen Welt eine 4 und bei der Zerlegung der Welt in Fachobjekte eine 9. Ich möchte damit sagen, dass die realen Objekte eben direkt bei der Geschäftsprozessmodellierung “anfallen”, wohingegen die Abstraktion in Fachobjekte später erfolgen kann.
Für Nicht-IT-Experten: Warum müssen die realen Objekte abstrahiert werden?
In der IT wird man versuchen, bestimmte Informationen nicht immer wieder an unterschiedlichen Orten erneut abzulegen. Viel angenehmer ist es, eine Information nur einmal zu speichern. Man spricht dann von Redundanzfreiheit.
Schauen wir uns nun das Antragsformular, den Personalausweis und die Versicherungspolice an. Alle drei Dokumente führen den Namen, Vornamen und Geburtsdatum der betreffenden Person. Wenn man diesen Sachverhalt nun abstrahiert, kann man ein Objekt Kunde modellieren. Dieses beinhaltet diese Informationen. Anschließend assoziiert man die Objekte Antrag, Ausweis und Police mit dem Kunden, ohne in den drei Objekten die Informationen zu wiederholen. Name, Vorname etc. können nun über die Assoziationen in den verknüpften Objekten abgefragt werden, obwohl sie gar nicht dort gespeichert sind. Einerseits vermeidet man so die Mehrfachspeicherung von Informationen, andererseits beschreibt man in solchen Domain Class Models (Fachklassenmodell) die Beziehungen zwischen solchen Objekten. Bspw. darf ein Kunde mehrere Versicherungen bei einem Unternehmen haben, aber nur eine vom Typ Hausrat pro versichertem Objekt.
Diese Abstraktion und die Beziehungen zwischen diesen Fachobjekten sind entscheidend für das fachliche Verständnis der zu entwickelnden Lösung. Dieses Modell entsteht normalerweise nicht zu Anfang der Analyse, sondern entwickelt sich langsam (daher die 9).
Alle Attribute in einem Modell
Das Domain Class Model ist die zentrale Sammelstelle für alle Attribute und deren Typ. Im Projektverlauf kann sich ein Attribut auch mal ändern. So muss bspw. ein Hinweistext statt bisher 100 Zeichen nun 200 aufnehmen. Das hat vermutlich Auswirkungen auf den Datentyp, der von Text_100 zu Text_200 wird. Letztendlich wird aber auch im User Interface ein größeres Feld von Nöten sein. Es sind also auch die Interaction Designer davon betroffen. Aber dort endet der Prozess nicht: Auch die Testteams müssen diese Änderung validieren.
Können Sie sich vorstellen, welchen Aufwand solche Änderungen nach sich ziehen, wenn Attribute nicht zentral sondern in jedem einzelnen Use Case beschrieben sind? Ich wette, dass bei einer Änderung die Hälfte der Nennungen in den verschiedenen Dokumenten übersehen wird.
Anmerkung: Ein solches Domain Class Model darf nicht 1 zu 1 in ein Datenbankmodell übernommen werden. Der / die DatenbankdesignerIn hat das unter Datenbankaspekten zu optimieren. Daher gibt ein Domain Class Model auch keine Auskünfte über Primär- oder Fremdschlüssel.
Kernkonzepte
Kernkonzepte sind eine formlose und verständliche Darstellung eines Themenbereichs, diesbezüglicher Fragestellungen und möglicher fachlicher Lösungsansätze.
Besonders in großen und komplexen Projekten haben mir Kernkonzepte sehr geholfen. Kernkonzepte sind eine formlose Annäherung an einen Problembereich. Sie beschreiben in kurzen Textdokumenten unterstützt von einfachen Grafiken, was das Problem ist und wie man es aus fachlicher Sicht zu lösen plant. Dabei legt man nicht dar, wie die Oberfläche aussehen soll. Hey, wir sind immer noch in der Analyse und nicht im Design! Stattdessen erklärt man bspw. ob das System sich auf Verträge oder auf Personen fokussiert. Was fordert der Datenschutz diesbezüglich? Wie sammelt man die Anträge einer Person, wenn man aus rechtlichen Gründen kein Personen-zentriertes System entwickeln darf? Spannende Fragen!
Nutzen zentrierte IT-Beratung: Kernkonzepte beschreiben in Text und Bild formlos die Problemlage
Kernkonzepte sind ein hervorragendes Mittel, um solche Fragen allgemeinverständlich zu formulieren, ohne sich in den Details der UML-Modellierung zu verlieren. Eine Sammlung von vielleicht zehn Dokumenten kann so auch ein sehr komplexes Projekt verständlich darstellen, ohne hunderte Seite studieren zu müssen. Ihr Auftraggeber und das Programm-Management werden Ihnen diese Dokumente gespannt aus den Händen reißen – und lesen.
Aktivitäten
Kommen wir zu den Aktivitäten. Endlich, werden Sie sagen. Hier steckt offensichtlich wirklich viel Diskussionsbedarf drin, was die anhaltenden Auseinandersetzungen über die “einzig wahre” Beschreibungsmöglichkeit ausdrücken. Ich möchte und kann diese Diskussion hier nicht abschließen.
Die einzelnen Aktivitäten sind die vom Geschäftsprozess wie an einer Perlenschnur aufgefädelten Teilschritte, die wir mit dem zu entwickelnden System abbilden möchten. Wir beschreiben nun die Aktivitäten, die ein Nutzer mit dem System ausführen möchte / soll. Auf Basis dieser Aktivitätsbeschreibungen extrahieren wir die technische Funktionalität und die fachliche Benutzerführung, die das System anbieten wird. Grund genug, sich damit etwas genauer zu beschäftigen.
Nutzen zentrierte IT-Beratung: Verschiedene Arten zur Beschreibung von Aktivitäten
Während das Use Case-Diagramm (7) eher dem Überblick dient, betrachten der Use Case in Textform (6) und das Aktivitätsdiagramm (8) eine Aktivität im Detail. Alistair Cockburn hat mit dieser textlichen Beschreibung von Use Cases eine sehr verständliche Methodik entwickelt, die auch sehr gut von nicht IT-Experten verstanden wird. Sie basiert auf einem einfachen Textformular und erfordert keine IT-Kenntnisse wie UML. So einfach diese Methodik auch erscheinen mag, erfordert die zielführende Beschreibung dieser textlichen Use Cases leider doch eine gewisse Erfahrung. Nur zu oft habe ich erlebt, wie sich hier Oberflächenbeschreibungen und das Festhalten an bekannten Software-Lösungen einschleichen. Diese Use Cases sind ein Mittel der Analyse und nicht des Designs. Sehen Sie hierzu auch meine Tipps zur Formulierung textlicher Use Cases:
Aktivitätsdiagramme (8) beschreiben den Ablauf nicht textlich sondern grafisch. Eine mögliche Notation ist UML, wie es auch in der Abbildung verwendet wird. Der Vorteil eines Aktivitätsdiagramms gegenüber einem Text-Use Case ist insbesondere die einfachere Darstellung von Alternativen und Ausnahmen. Diese können in textlichen Use Cases etwas schwerer nachvollziehbar sein. Das Aktivitätsdiagramm erfordert aber vom Leser eben auch eine rudimentäre UML-Kenntnis, was die Verständlichkeit für Nicht-IT-Fachleute erschweren mag. Nun muss ich natürlich zugeben, dass dasselbe auch für die zuvor erwähnte Prozessmodellierung mittels BPMN gilt. Das größere Problem beim UML-Aktivitätsdiagramm ist meiner Meinung nach, dass das “Malen” einer Blase (z.B. “Antragsteller suchen”) als Beschreibung dessen, was hier geschehen soll, nicht reicht. Leider belassen es viele Modellierer bei diesen Blasen, ohne die Inhalte genauer zu erklären. Es entsteht zwar ein hübsches Bild. Letztlich bleiben aber viele Fragen offen.
Alle mir bekannten UML-Werkzeuge bieten die Möglichkeit, die Blasen (Aktivitätssymbole) mit beschreibendem Text zu hinterlegen. Gewissenhafte Analytiker nutzen sie. Lässt sich das in dem Modellierungswerkzeug noch ganz gut lesen, springt man beim exportierten Textdokument permanent zwischen der Grafik und der jeweiligen Aktivitätsbeschreibung hin und her. Das erschwert die Lesbarkeit ebenfalls.
Wie so oft, liegt die “Wahrheit” vielleicht dazwischen. Entscheiden Sie selbst, welches Mittel Ihnen und Ihren “Stakeholdern” am meisten liegt. Eventuell ergänzen Sie ja auch einfach ein Aktivitätsdiagramm (Ablauf im Überblick) um einen textlichen Use Case (Details). So wäre beiden Seiten gedient.
Zusammenfassung
Die hier aufgeführten Tools / Ergebnistypen stellen eine Auswahl dar. Es gibt weitaus mehr Modelle und Analyse-Artefakte. Wie konnte ich z.B. das Statusdiagramm übergehen? Und ohne Sequenzdarstellung kann man ja gar nichts erreichen! Das möge man einwenden. Ich möchte es aber an dieser Stelle bei den beschriebenen belassen. Mir ist es persönlich wichtiger, Ergebnistypen zu entwickeln, die dem gemeinsamen Verständnis aller Projektbeteiligten dienen. Methodische Vollständigkeit mag wissenschaftliche Ehren ernten. Aber bringt sie auch das Projekt voran?
In Zeiten agiler Software-Entwicklung ist von User Stories statt von Anforderungen die Rede. Domain Class Models werden zumeist nicht eingesetzt, und Storyboards ersetzen Use Cases. Aber zu welchem Preis? In niederkomplexen Projekten mit klarem Fokus und wenigen Teilnehmern mag das prima funktionieren. Aber wie verhält sich das in 10.000-Tage Projekten? Ich denke, dass die hier beschriebenen “Tools” nach wie vor ihre Berechtigung haben. Und wer sagt eigentlich, dass man nicht auch eine Fachspezifikation super agil mit Scrum in iterativen Sprints entwickeln kann?
Mit dieser kleinen Provokation freue ich mich auf eine interessante Diskussion. Was fehlt Ihrer Meinung nach für eine gute Fachspezifikation? Was können wir getrost weglassen? Lassen Sie es mich wissen und kommentieren Sie fleißig drauf los.
Zum Abschluss finden Sie hier das Mindmap in ganzer Größe (1200*1038px, 324KB):
Nutzen zentrierte IT-Beratung: Bestandteile einer Fachspezifikation im Überblick
Das Artikelbild ist von elyob bereitgestellt (siehe flickr).