Modelle statt Anforderungen? Acht Argumente für das Beste aus beiden Welten

Unter diesem – zugegebenermaßen provokanten Titel – lief neulich meine Session beim RE-Barcamp in Köln. Diese Frage wurde unter anderem durch das spannende World-Cafe beim SE Get Together bei oose angestoßen. Dort ging es um die Frage, was „Anforderungs-Modellierung“ eigentlich ist. Wir kamen zu dem Ergebnis, dass Modellierung in diesem Zusammenhang auf zweierlei Weise angewendet wird: Zum Einen, um das Schreiben von Anforderungen zu unterstützen; zum Anderen, um mit dem Modell einen Großteil der Anforderungen zu ersetzen. Aber können Anforderungen wirklich durch ein Modell ersetzt werden?

Schwarz oder Weiß?

Um es gleich vorwegzunehmen: Die Welt ist nicht schwarz oder weiß, und in den meisten Fällen ist ein Hybridmodell, also eine Mischung von Anforderungen und Modellen sinnvoll. Problematischer sind Redundanzen. Wenn also Anforderungen und Modelle gemischt werden, dann muss darauf geachtet werden, dass keine Dopplungen auftauchen. Und falls sich Dopplungen nicht vermeiden lassen, muss geklärt werden, wie diese synchron gehalten werden.

Wir müssen uns nicht zwischen Anforderungen und Modellen entscheiden, sinnvoll ist beides. Aber wir müssen Redundanzen vermeiden. Twittern

Die Barcamp-Session

Beim Barcamp geht es um die aktive Mitarbeit. In diesem Fall ging es mir darum, die Erfahrungen der circa zwanzig Anwesenden zu diesem Thema zu sammeln und zu strukturieren. Dazu reichte die Zeit gerade aus, wobei die Kommentare oft von der Gruppe aufgegriffen und diskutiert wurden. Hier nun die wichtigsten Ergebnisse:

Was ist überhaupt ein Modell? Zu Modellen gehören Mockups, Prototypen, Abstraktionen, physikalische Modelle (wie das Segelschiff oben), und vieles mehr. Auch natürliche Sprache ist eine Modellierungssprache, wenn auch normalerweise eine recht informelle. Auch diese kann in kleinen Schritten formalisiert werden. Das fängt schon mit einem Glossar an, und kann bpsw. mit Textschablonen weiter getrieben werden. Das erklärt sicher auch, warum das Mischen von Anforderungen und Modellen kein Problem darstellt, wenn es systematisch betrieben wird.

Durchgängigkeit und Nachverfolgbarkeit erfordern weniger Aufwand bei der Modellierung als bei natürlichsprachigen Anforderungen, da bei Modellen viele Beziehungen implizit beim Modellieren gesetzt und mitgepflegt werden. Noch wichtiger, in manchen Modellierungssprachen sind Beziehungen selbst Modellelemente mit einer klar definierten Semantik.

Anforderungen kann jeder lesen (mit Geduld), Modelle zu lesen muss jedoch gelernt sein. Daher müssen die Stakeholder beim Modellieren ganz anders abgeholt werden als bei traditionellen Anforderungen. Insbesondere kann eine Schulung zum Lesen von Modellen den Unterschied zwischen Erfolg und Misserfolg darstellen.

Aber auf der anderen Seite ermöglichen Modelle das generieren von spezialisierten Sichten, und sind damit traditionellen Anforderungen überlegen: Es ist leicht, das für den Leser unwichtige auszublenden. Ein Stichwort aus der Session war Dokumentengenerierung: Viele Stakeholder werden Modelle in der Form von generierten Dokumenten konsumieren. Diese können relativ leicht wiederum mit Anforderungen vermischt werden, oder das Modell sogar so geschickt generieren, dass der Leser kaum erkennt, dass es sich um ein generiertes Dokument handelt.

Sowohl bei Modellen als auch bei Anforderungen ist es wichtig, den richtigen Detaillierungsgrad zu wählen. Das ist gar nicht so einfach, und erfordert ein gewisses handwerkliches Geschick. Es ist kein Wunder, dass es viele Schulungen zum Thema „Anforderungen richtig formulieren“ gibt. Doch während es bei Anforderungen schon viel Wissen und Erfahrung gibt, ist die Systemmodellierung einer relativ junge Disziplin. (Das ist auch einer der Motivationen für das Modeling Craftsmanship Camp in Hannover).

Modellierung ist auch deswegen beliebt, weil sich manche Probleme viel besser visuell beschreiben lassen, zum Beispiel Abläufe. Das trifft aber nicht auf alle Anforderungen zu, und das ist auch wieder ein Argument dafür, Modelle und Anforderungen miteinander zu kombinieren. Bei einer auf Anforderungen ausgerichteten Methode ist es auch nicht ungewöhnlich, dass die Modelle genau das sind: Einfach nur Bilder. Erfahrene Modellierer runzeln hier die Stirn. Es ist aber völlig legitim, die Modelle nur als Bilder zu behandeln; solange das alle Beteiligten auch verstehen und diese Bilder systematisch pflegen.

Eine wichtige Klasse von Modellen sind Prototypen und Mockups – Modelle, die nach ihrem Gebrauch nicht weiter gepflegt werden. Diese haben lediglich eine unterstützende Rolle, können aber sehr wertvoll sein: Sie helfen, die Anforderungen präziser zu machen und Lücken zu entdecken. Die größte Gefahr hierbei ist, dass nichts länger hält, als ein Provisorium. Mit anderen Worten, manchmal werden Prototypen in das Produkt weiterentwickelt (besonders bei Software), was auf ein wackeliges Fundament hinauslaufen kann.

Bei der Diskussion stellte sich schnell heraus, dass es neben traditionellen Anforderungen und Modellen noch vieles andere gibt, was die Kundenwünsche beschreibt. Hier wurde das Wort „Artefakt“ vorgeschlagen. Danach sind Anforderungen und Modelle nur zwei Typen von Artefakten, zu denen dann noch viele andere hinzukommen, von Skizzen bis Powerpoint-Folien.

Sowohl Anforderungen als auch Modelle dienen der Kommunikation. Dementsprechend kann es auch sinnvoll sein, die Kommunikation in den Vordergrund zu stellen und das dafür passendste Artefakt zu suchen. Ziel sollte es sein, die Sprache der Stakeholder zu finden. Hier haben allerdings Modelle den Vorteil, dass unterschiedliche Sichten erzeugt werden können (Punkt 3), für jede Klasse von Stakeholdern die Richtige.

Schritt für Schritt mit dem SYSMOD Intensity Model

Laut SYSMOD gibt es das sogenannte Intensity Model: Bei Stufe 1 dient das Modell lediglich der Kommunikation, während in Stufe 3 das Modell in der Tat die Spezifikation (größtenteils) ersetzt. Die Kosten für SYSMOD 3 sind natürlich höher als bei SYSMOD 1 – aber auch der Nutzen.

Modelle statt Anforderungen? Nein: Modelle und Anforderungen!

Alle Teilnehmer waren sich einig, dass Modelle und Anforderungen sinnvoll miteinander kombiniert werden können und sollten. Modelle sind leistungsfähige Konstrukte, die eine Präzision und Durchgängigkeit ermöglichen, die mit traditionellen Anforderungen einfach nicht möglich ist. Andererseits kennen wir keine Modelle, die an die Ausdrucksstärke textueller Anforderungen herankommen und so universell angenommen werden. Wenn sauber auf die Vermeidung von Redundanzen geachtet wird, dann haben wir das Beste beider Welten.