{"id":720,"date":"2016-11-10T08:00:10","date_gmt":"2016-11-10T07:00:10","guid":{"rendered":"https:\/\/se-trends.de\/?p=720"},"modified":"2023-09-13T11:40:08","modified_gmt":"2023-09-13T09:40:08","slug":"models-instead-of-requirements","status":"publish","type":"post","link":"https:\/\/www.se-trends.de\/en\/modelle-statt-anforderungen\/","title":{"rendered":"Models instead of requirements? Eight arguments for the best of both worlds"},"content":{"rendered":"\n

Unter diesem \u2013 zugegebenerma\u00dfen provokanten Titel \u2013 lief neulich meine Session beim RE-Barcamp in K\u00f6ln<\/a>. Diese Frage wurde unter anderem durch das spannende World-Cafe beim SE Get Together bei oose<\/a> angesto\u00dfen. 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\u00fctzen; zum Anderen, um mit dem Modell einen Gro\u00dfteil der Anforderungen zu ersetzen. Aber k\u00f6nnen Anforderungen wirklich durch ein Modell ersetzt werden?<\/p>\n\n\n\n

Terminerinnerung:<\/strong> Anmeldung zum Systems Engineering Barcamp<\/strong> am 3. Dezember in Hamburg l\u00e4uft. Jetzt anmelden >><\/a><\/div>\n\n\n\n

Schwarz oder Wei\u00df?<\/h2>\n\n\n\n

Um es gleich vorwegzunehmen: Die Welt ist nicht schwarz oder wei\u00df, und in den meisten F\u00e4llen 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\u00e4rt werden, wie diese synchron gehalten werden.<\/p>\n\n\n\n

\n

Wir m\u00fcssen uns nicht zwischen Anforderungen und Modellen entscheiden, sinnvoll ist beides. Aber wir m\u00fcssen Redundanzen vermeiden. [tweetthis]Wir m\u00fcssen uns nicht zwischen Anforderungen und Modellen entscheiden[\/tweetthis]<\/p>\n<\/blockquote>\n\n\n\n

Die Barcamp-Session<\/h2>\n\n\n\n

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:<\/p>\n\n\n\n

1.<\/span>Auch Anforderungen sind Modelle<\/div>\n\n\n\n

Was ist \u00fcberhaupt ein Modell? Zu Modellen geh\u00f6ren Mockups, Prototypen, Abstraktionen, physikalische Modelle (wie das Segelschiff oben), und vieles mehr. Auch nat\u00fcrliche Sprache ist eine Modellierungssprache, wenn auch normalerweise eine recht informelle. Auch diese kann in kleinen Schritten formalisiert werden. Das f\u00e4ngt schon mit einem Glossar an, und kann bpsw. mit Textschablonen weiter getrieben werden. Das erkl\u00e4rt sicher auch, warum das Mischen von Anforderungen und Modellen kein Problem darstellt, wenn es systematisch betrieben wird.<\/p>\n\n\n\n

2.<\/span>Modelle unterst\u00fctzen Durchg\u00e4ngigkeit und Nachverfolgbarkeit<\/div>\n\n\n\n

Durchg\u00e4ngigkeit und Nachverfolgbarkeit erfordern weniger Aufwand bei der Modellierung als bei nat\u00fcrlichsprachigen 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.<\/p>\n\n\n\n

3.<\/span>Lesen, Schreiben und Sichten<\/div>\n\n\n\n

Anforderungen kann jeder lesen (mit Geduld), Modelle zu lesen muss jedoch gelernt sein. Daher m\u00fcssen 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.<\/p>\n\n\n\n

Aber auf der anderen Seite erm\u00f6glichen Modelle das generieren von spezialisierten Sichten, und sind damit traditionellen Anforderungen \u00fcberlegen: Es ist leicht, das f\u00fcr den Leser unwichtige auszublenden. Ein Stichwort aus der Session war Dokumentengenerierung: Viele Stakeholder werden Modelle in der Form von generierten Dokumenten konsumieren. Diese k\u00f6nnen 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.<\/p>\n\n\n\n

4.<\/span>Auf den richtigen Detaillierungsgrad kommt es an!<\/div>\n\n\n\n

Sowohl bei Modellen als auch bei Anforderungen ist es wichtig, den richtigen Detaillierungsgrad zu w\u00e4hlen. 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\u00e4hrend es bei Anforderungen schon viel Wissen und Erfahrung gibt, ist die Systemmodellierung einer relativ junge Disziplin. (Das ist auch einer der Motivationen f\u00fcr das Modeling Craftsmanship Camp in Hannover<\/a>).<\/p>\n\n\n\n

5.<\/span>Ein Bild sagt mehr als 1000 Worte<\/div>\n\n\n\n

Modellierung ist auch deswegen beliebt, weil sich manche Probleme viel besser visuell beschreiben lassen, zum Beispiel Abl\u00e4ufe. Das trifft aber nicht auf alle Anforderungen zu, und das ist auch wieder ein Argument daf\u00fcr, Modelle und Anforderungen miteinander zu kombinieren. Bei einer auf Anforderungen ausgerichteten Methode ist es auch nicht ungew\u00f6hnlich, dass die Modelle genau das sind: Einfach nur Bilder. Erfahrene Modellierer runzeln hier die Stirn. Es ist aber v\u00f6llig legitim, die Modelle nur als Bilder zu behandeln; solange das alle Beteiligten auch verstehen und diese Bilder systematisch pflegen.<\/p>\n\n\n\n

6.<\/span>Wegwerf-Modelle zur Unterst\u00fctzung der Anforderungen<\/div>\n\n\n\n

Eine wichtige Klasse von Modellen sind Prototypen und Mockups \u2013 Modelle, die nach ihrem Gebrauch nicht weiter gepflegt werden. Diese haben lediglich eine unterst\u00fctzende Rolle, k\u00f6nnen aber sehr wertvoll sein: Sie helfen, die Anforderungen pr\u00e4ziser zu machen und L\u00fccken zu entdecken. Die gr\u00f6\u00dfte Gefahr hierbei ist, dass nichts l\u00e4nger h\u00e4lt, als ein Provisorium. Mit anderen Worten, manchmal werden Prototypen in das Produkt weiterentwickelt (besonders bei Software), was auf ein wackeliges Fundament hinauslaufen kann.<\/p>\n\n\n\n

7.<\/span>Artefakte statt Anforderungen und Modellen<\/div>\n\n\n\n

Bei der Diskussion stellte sich schnell heraus, dass es neben traditionellen Anforderungen und Modellen noch vieles andere gibt, was die Kundenw\u00fcnsche 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.<\/p>\n\n\n\n

8.<\/span>Modelle als Kommunikations-Starter<\/div>\n\n\n\n

Sowohl Anforderungen als auch Modelle dienen der Kommunikation. Dementsprechend kann es auch sinnvoll sein, die Kommunikation in den Vordergrund zu stellen und das daf\u00fcr 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\u00f6nnen (Punkt 3), f\u00fcr jede Klasse von Stakeholdern die Richtige.<\/p>\n\n\n\n

Schritt f\u00fcr Schritt mit dem SYSMOD Intensity Model<\/h2>\n\n\n\n

Laut SYSMOD<\/a> gibt es das sogenannte Intensity Model: Bei Stufe 1 dient das Modell lediglich der Kommunikation, w\u00e4hrend in Stufe 3 das Modell in der Tat die Spezifikation (gr\u00f6\u00dftenteils) ersetzt. Die Kosten f\u00fcr SYSMOD 3 sind nat\u00fcrlich h\u00f6her als bei SYSMOD 1 \u2013 aber auch der Nutzen.<\/p>\n\n\n\n

\"SYSMOD