Wertequadrat ein, das ist ein, ich hab's hier Modellierungsartifakt genannt, um eben auch mit Werten im Requirements Engineering umzugehen. Genau, meine Agenda, ich sag erst mal was, zum ersten Punkt, warum halte ich hier einen Vortrag über das Wertequadrat beim Menschen zentriert in der E, im Grunde hat das die Birgit gerade vollständig schon eingeführt,

da will ich ganz ganz schnell drüber hinweggehen, ich brauch das, ich will viel sagen. Der zweite Punkt, eine ausgehaltene Spannung von Werten, die war in Teilen bei der Birgit auch drin, aber da wird jetzt noch ein stärkerer Fokus drauf gelegt. Dann zeige ich ein Beispiel, den Friedemann Schulz von TUN, den kennt ihr so von den vier Seiten der Kommunikation,

miteinander reden, ist ein sehr bekannter Autor und über den kenne ich dieses Wertequadrat. Und dann zeige ich euch drei Beispiele, wie das anzuwenden ist. Genau, Werte sind was, was Menschen wichtig sind und als zweite Definition, Werte sind Maximen, die Handlung

von Menschen anleiten. Das war auch ein Stück bei der Birgit drin, hier aber auch noch mal fokussiert, also wenn ich einen Wert habe, dann handle ich auch nach diesem Wert. Das wird gleich beim Wertequadrat wichtig werden. Ich zitiere hier den Helwig, weil Friedemann Schulz von TUN auch auf den Helwig bezieht, auch in diesem Wertequadrat.

Genau, die ausgehaltene Spannung zwischen Werten, das ist von der Sprache her, ist das erstmal gewöhnungsbedürftig. Schulz von TUN sagt, ein Mensch kann nur nach einem Wert handeln, wenn der Wert sich in ausgehaltener Spannung zu einem positiven Gegenwert befindet.

Und ohne diese ausgehaltene Spannung vollkommt ein Wert zu einer entwertenden Übertreibung. Ich wollte das aus der akademischen Sicht drin haben, diesen Bedürf, dass man das nachher noch mal lesen kann. Ich zeige euch das jetzt aber bei einem Beispiel und dann, glaube ich, wird es auch ganz schnell verständlich. Also es gibt einen positiven Wert,

das ist die Sparsamkeit. Wir stimmen wahrscheinlich alle überein, sparsam zu sein ist gut, ist ein gutes Merkmal. Und es gibt einen Gegenwert dazu, Großzügigkeit. Wir stimmen wahrscheinlich auch alle überein, großzügig zu sein. Und diese Werte, die stehen in einer ausgehaltenen Spannung. Also ich kann sparsam sein und gleichzeitig großzügig sein und

alle Handlungen, die dazwischenliegen, sind eigentlich positiv. Also ich kann sparsamer Mensch sein, ich gebe nicht viel Geld aus, das heißt ich bin sehr sparsam. Aber wenn meine Verwandten zu Weihnachten kommen, dann stelle ich natürlich trotzdem alles voller Essen und

bin großzügig und so. Das heißt, das sind Handlungen, die liegen in einer ausgehaltenen Spannung. Aber, und jetzt kommt der Clou an der Sache, wenn ich nicht großzügig bin, dann verkommt die Sparsamkeit zu Geiz. Geizig will keiner sein. Wir wollen nicht geizig sein.

Ich habe das manchmal auch unwert genannt, den Geiz. Und genauso, wenn wir nur großzügig sind, ohne sparsam zu sein, dann verschwenden wir. Das ist auch wieder ein Unwert, ein negativer Wert. Ich glaube, das Beispiel, wir müssen jetzt nicht alle Begriffe hier

auswendig kennen, positiver Wert, Entwertenübertragung und so, aber ich glaube, das Beispiel ist hoffentlich gut verständlich gewesen. Ein Original Beispiel von Schulz von Thun, der redet im Grunde über Psychologie, wie Menschen handeln sollten. Das hat mit Software Engineering und Requirements Engineering noch gar nichts zu tun. Das ist erst mal

komplett weg. Ich habe damals im Forschungsprojekt auch versucht, das zu integrieren. Und zwar, ich mache das jetzt mal an, ein Beispiel. Sagen wir mal, wir wollten eine Software programmieren zur Finanzberatung. Ich will eine App haben, die mich berät, wie ich

besser mit Geld umgehe. Dann gibt es im Requirements Engineering sowas wie Szenarien. Ich kann Szenarien aufstellen, was die Software für mich machen möchte. Und genau das kann ich jetzt machen. Hier ist mein Angriffspunkt. Ich will jetzt eine App bauen, die diese

Werte unterstützt. Zum Beispiel, ich habe hier oben links ein Szenario, soll die App mir Hinweise geben, wie viel Geld noch verausgabt werden kann. Wir haben es jetzt Ende des Monats. Vier, fünf Tage haben wir in dem Monat noch. Wenn jetzt kein Geld mehr auf dem Konto ist, dann kann die App mir sagen, pass auf, kauft ihr jetzt am besten nichts Neues.

Oder wenn die App den Wert Großzügigkeit unterstützen soll und jetzt Ende des Monats ist und ich habe noch 500 Euro auf dem Konto, dann kann die App sagen, pass mal auf, Alex, die 500 Euro, die hast du noch nie in fünf Tagen ausgegeben. Wie wäre es mal was zu spenden? Das Kinderheim um die Ecke, das kann bestimmte Spende vertragen. Da kann

die App Großzügigkeit von mir unterstützen. Oder die App will ja verhindern, dass ich geizig bin. Ich will ja nicht geizig werden. Ich will nicht in diese entwerten Übertreibungen rein. Wenn die App jetzt merkt, ich habe am Ende des Monats noch

kein Geld beim Blumenhändler ausgegeben, dann kann die App mir sagen, Alex, sei nicht so geizig, kaufe noch mal Blumen für deine Frau, dann freut ihr sich. Oder man könnte jetzt auch ein anderes Beispiel nehmen. Aber die App sagt mir, sei nicht geizig, weil das wäre im Geiz, wenn ich mich regelmäßig meine Frau was schenke.

Oder eben Verschwendung. Ich glaube, da ist das relativ klar. Wenn kein Geld mehr da ist oder wenn die App merkt, ich habe schon den ganzen Monat lang mir, weiß jetzt nicht was, ich war fünfmal im Kino, dann fängt sie ein und dann sagt die mir, gib am besten nichts mehr aus. Ich habe jetzt, das sind natürlich jetzt keine richtigen Szenarien. Ich habe jetzt hier vier

Sätze hingeschrieben, die für mich nachvollziehbar sind. Aber wenn wir diesen Szenariengedanken durchziehen, dann sind wir ja schon mitten im Requirements Engineering drin. Wenn wir Szenarien haben, dann können wir, wenn wir daraus Use Cases abstrahieren, dann können wir vielleicht

verschiedene User Stories ausbauen, welche Technik man dann auch immer ansetzt. Ich glaube, im nächsten Vortrag könnte ich mir auch vorstellen, dass Henning irgendwas zu Szenarien sagt, bin ich nicht ganz sicher, aber könnte ich sagen, auf jeden Fall, da können wir schon dran arbeiten. Und dann, also wenn man die Logik hat von Sparsamkeit, wird durch so eine

Handlung eben umgesetzt. Und Großzügigkeit wird durch so eine Handlung umgesetzt. Und diese Handlung können wir bewusst in unsere Software einbauen. Dann muss das eigentlich sein, dass unsere Software zu Sparsamkeit und zu Großzügigkeit Menschen anleitet und

Geiz und Verschwendung verhindert. Das ist natürlich ein hochgestecktes Ziel, ob das so hundertprozentig passt, das hat Birgit auch gerade schon angesprochen. Ob das dann beweisticher ist, weiß man nicht, aber zumindest ist es von der Logik her nachvollziehbar. Ich bin jetzt in der Zeit so mittelmäßig gut, darum gehe ich jetzt relativ schnell über

zwei anderen Beispiele. Das ist ein Beispiel, das ich schon vor einiger Zeit in der Forschungsarbeit gemacht habe. Da ging es um einen Sozialkonzern, der bietet Betreuungsleistungen in der Altenhilfe an. Da ging es darum, dass alte Menschen, die noch zu Hause, allein

zu Hause leben, dass sie betreut werden sollen. Da es aber wahnsinnig teuer ist, dass jeden Tag ein Betreuer rausfährt und guckt, ob die noch gesund sind. Und der hat sich eben überlegt, wie können wir Technologie einsetzen, um die Leute gut zu betreuen. Und einen positiven Wert, den die eben umsetzen wollen, ist Kontrolle. Geht es unseren Kunden

gut oder haben sie sich verletzt, sind sie gestört? Das ist immer gleichzeitig der zweite Wert. Wir wollen die Privatsphäre von unseren Kunden auch nicht verletzen. Wir

wollen die Leute nicht vernachlässigen. Ich gehe jetzt inhaltlich weniger rein, wie gesagt auf Zeit. Noch ein drittes Beispiel, das haben Studenten aus Utrecht gebaut. Da

ging es um eine Lernplattform, auch hier wieder mit positiven Werten und Werten, die wir nicht haben. Genau, wie geht es weiter? Mit der Uni Utrecht, mit dem Jens Gulden, bin ich dran immer. Wir versuchen, Experimente dazu aufzubauen, wie dieses

Wertquadrat eingesetzt werden kann. Wir sind nämlich noch relativ weit am Anfang. Das ist, ihr habt es gemerkt, das ist eine Methode aus einer Disziplin überführt in das Requirements Engineering, in das Software Engineering. Da gibt es noch viel konzeptuelle Arbeit, was da gut ist, was da schlecht läuft. Da sind wir eben mit dem Jens aus Utrecht

super dran, da empirische Erkenntnisse zu haben. Bisher haben wir nur eine vorläufige Annahme des Workshops. Wir sollten uns heute Abend eine Liste von Interessierten schicken. Dann kriegen wir oder uns wurde gesagt, wir werden angenommen, wenn wir viele Interessierte

für den Workshop haben. Ich würde mich sehr freuen, wenn ihr euch interessiert zeigt und mich euch auf der Liste benennen darf. Genau, in dem Workshop werden wir, das ist ein

Paperless-Workshop, das heißt, es gibt keine Einreichungen. Wir werden in dem Workshop eben diese Wertequadrate modellieren. Je nachdem, wie viele Leute teilnehmen, sagen wir mal, neun Leute nehmen teil, dann werden sich drei Leute jeweils ein Wertequadrat vornehmen, modellieren und gucken, was sind Werte und was sind Unwerte. Dann werden wir am Ende

vergleichen, was für Ergebnisse dabei rauskommen. Es wird ein sehr interaktives Format werden, einen halben Tag lang. Es wird hoffentlich sowohl inhaltliche Erkenntnisse erzeugen, also was sind gute Werte, die wir vertreten wollen, wie auch methodisch,

dass wir nachher sagen können, wir haben über diese Methode gelernt, wie wir sie besser anwenden können.