Drei Gründe warum UML nur begrenzt als Anforderungswerkzeug einsetzbar ist [Requirements Engineering]

Bei den heutigen Softwareingenieuren scheint eine Sache unumstößlich klar zu sein: UML ist das wichtigste Werkzeug für Anforderungsspezifikation. Diese Sicht ist im Grundsatz richtig, allerdings mit einigen Einschränkungen und Korrekturen. Dabei fallen mir drei wesentliche Gründe ein, warum UML für die Verwendung im gesamten Anforderungsprozess lückenhaft oder zum Teil gänzlich ungeeignet ist.

1) Fehlende Möglichkeit Geschäftsziele einzubeziehen
UML zielt wesentlich auf die Beschreibung eines Systemdesigns ab, also der Phase im Anforderungsprozess, die ich „Scoping-Down“ nenne. Das ist das herkömmliche Vorgehen, bei dem ein vordefinierte Idee oder ein Systemkonzept verfeinert und im Detail konzipiert wird. Was im UML-Paradigma fehlt ist die Idee des „Scoping-Up“, der Verknüpfung eines IT-Konzepts mit Geschäftszielen. Damit fehlen UML auch die entsprechenden Werkzeuge, die eine solche Phase unterstützen. In meinem vorherigem Post beschreibe ich die Bedeutung eines ganzheitlichen Anforderungsprozesses, wobei ich im Detail darauf eingehe, wie Scoping-Down und Scoping-Up zusammenhängen. (Exkurs: Scoping-Up geht den umgekehrten Weg des Scoping-Down. Es knüpft das Systemkonzept an Geschäftsziele. Erst nachdem diese Richtung definiert ist, kann ein Scoping-Down, also das Verfeinern einer IT-Konzepts beginnen. Manchmal ist eine Neudefiniton des Konzepts notwendig). Damit deckt UML nur einen Teil des Anforderungsprozesses ab, einen anderen Teil lässt es schon im Ansatz ausser Betracht.

2) Begrenzter Nutzen als fachübergreifendes Kommunikationswerkzeug
Das führt uns direkt zum zweiten Manko, welches Folge des ersten ist: UML ist strikt für eine genaue Systemspezifikation konzipiert und deshalb als fachübergreifendes Kommunikationswerkzeug wenig geeignet. Genauer: UML ist als Unterstützung für die Konzeptionsbeschreibung einer Anforderung ausgelegt und nicht für die Konzeptionsfindung. Es hilft hervorragend dabei eine genaue Beschreibung einer IT-Struktur herzustellen, was notwendig ist, insbesondere wenn die Beschreibung im Softwareentwicklungsprozess auch vertragswirksam sein muss. Doch eine genaue (vertragliche) Beschreibung kann immer nur nach einer abgeschlossenen Konzeption stattfinden. Endgültig ist sie aber erst dann, wenn eine Lösung gefunden ist. (Kaum jemand würde anfangen einen formalisierten juristischen Vertrag zu schreiben, wenn die Klärung des Sachverhalts noch offen ist.)

Im Findungsprozess im Gegenteil muss die Lösung erst im Rahmen erfolgreicher Kommunikation gefunden werden. Dabei begrenzt sich der Anforderungsprozess nicht auf die Teilnahme der IT, sondern bringt ganz unterschiedliche Fachrichtungen zusammen. Insbesondere in einer Scoping-Up Phase, in der ganz andere Bereiche als IT (wie z.B. das Management, Legal oder Vertrieb) beteiligt sind, zeigt UML als Kommunikationswerkzeug seine Schwächen. Im Findungsprozess einer Lösung sind zwei Sachen für eine erfolgreiche Kommunikation ausschlaggebend: (a) eine visuelle und (b) eine einfache, flexible und sofort verständliche Symbolik. Das erstere bietet UML, das zweite nicht. In dieser Hinsicht führt UML viele Anforderungsingenieure in die Irre: sie ködert mit visuellen Werkzeugen, was viele glauben lässt, dass die Sprache für Kommunikation besonders geeignet ist, bietet aber gleichzeitig einen zu hohen komplexitäts- und formalisierungsgrad an, als dass sie bequem fachübergreifend zu nutzen wäre. Das ist der wesentliche Grund, warum UML in Großunternehmen Schwierigkeiten hat sich ausserhalb der IT durchzusetzen. Welches Bild wäre funktionsübergreifend wohl verständlicher?

UML.Blog

3) Fehlende Mögilchkeit das System aus Sicht des Nutzers darzustellen
UML sieht keine Werkzeuge zur Beschreibung von grafischen Benutzerschnittstellen vor. GUI-Anordungen und Maskenprototypen sind mit UML nativ nicht realisierbar. Maskenflüsse lassen sich zwar zum Beispiel mithilfe von Aktivitätsdiagrammen abbilden, doch bleibt das in (2) beschriebene Problem der fehlenden fachübergreifenden Verständlichkeit bestehen. Dass ein IT-fachmann mithilfe von solchen Diagrammen kommuniziert, steht ausser Frage, ob aber ein End-Benutzer das auch kann, waage ich zu bezweifeln.

Kurzinfo: This article points out three reasons why UML is not always the appropriate tool to use for requirements engineering.

Anton

Anton

Anton ist freiberuflicher Software-Ingenieur und Projektleiter mit den Schwerpunkten: Prozessdesign, strukturierte Business Analyse / Fachkonzeption sowie fachliche Entscheidungsunterstützung.

More Posts - Website