heißt, ich werde heute jetzt in dem Vortrag ein bisschen rausstellen, was andere gemacht haben, und am Schluss meine Vision vorstellen, von dem ich mir vorstellen könnte, dass man das besser in den Requirements Engineering Prozess mit einbeziehen kann. Und da wird es dann auch ein bisschen interaktiv, weil ich natürlich gerne wissen wollte, wie diese Vision so ankommt. Und ganz kurze Frage, in dieser Fachgruppe sind wir per Sie oder per Du?

Wir sind per Du. Wir sind per Du, super. Okay, ich bin schon so lange professionell raus aus Deutschland, und ich weiß, dass, ja, gut, damit wäre das klar. Legen wir also mal los, dann bin ich sehr

gespannt, was ihr zu dieser Vision denkt. Wir fangen mal an mit Grady Butch, denn ich kriege oft die Frage, sag mal, Wohlbefinden, Werte, ich schreibe doch Software. Also wenn ich mit den Praktikern da spreche, dann komme ich immer wieder auf Grady Butch zurück,

weil ihn kennen die meisten, er ist einer der Vater der UML, und ich liebe dieses Twitter-Bild, weil er aussieht wie Gott. Und damit hoffentlich die gewichtige Wirkung seiner Worte besser einsenkt. Der hat gesagt, every line of code has an ethical and moral implication. Wir betten also unsere Werte in die Systeme ein, die wir kreieren, und zwar entweder bewusst

oder unbewusst. Und wenn wir das mal akzeptieren können, dass das eine Tatsache ist, dass wir unsere Werte sowieso einbetten in das, was wir designen, dann können wir sagen, okay, dann lass uns mal lieber Verantwortung dafür übernehmen, dass wir das auch bewusst tun, anstatt dass das irgendwie so im Hintergrund was ist, was mit abläuft,

wo wir uns nicht so wirklich bewusst sind. Und nun habe ich mir angeschaut, ja, was ist denn eigentlich ein Wert? Und dazu habe ich mir zu Hilfe genommen eine meiner Lieblingssozialforscherinnen, die Brandy Brown, die halt ihre Ausbildung in soziale Arbeit gemacht und beschäftigt sich seit fast 30 Jahren mit Werten und hat angefangen,

die unbequemen Werte zu studieren, sowas wie Charme. Und hat dann herausgefunden, dass diese unbequemen Werte ganz, ganz starken Einfluss auf die Businesswelt haben. Denn wenn ich so Gefühle wie Charme unterdrücke, dann heißt das, es ist schwierig,

Vertrauen aufzubauen. Und wir wissen, dass Vertrauen im Sinne der Zusammenarbeit in der Arbeit unglaublich wichtig ist. Und sie beschäftigt sich mittlerweile sehr stark mit Leadership-Themen. Und hier auf der Folie sehen wir ihre Definition von einem Wert. Und sie stellt einen Wert dar, als eine Art und Weise in etwas zu glauben, an etwas

zu glauben, das für uns sehr wichtig ist. Und wenn wir schaffen, unsere Werte in unserem täglichen Leben auszuleben, dann fühlen wir, dass wir Integrität haben. Das heißt, wenn ich so leben kann, dass meine Aktionen mit meinen Worten übereinstimmen und dass ich

mich an meinen Werten orientieren kann, dann kann ich die besten Beiträge in der Welt leisten. Was auch immer ich damit tue. Von dieser Definition aus gehen wir ein bisschen

und die meisten, die sich im Bereich RE mit dem Thema beschäftigen, basieren ihre Arbeit auf der Hofstädte Schwarz-Taxonomie. Die gibt es schon eine ganze Weile. Die bekannteren Publikationen dazu sind von 1992 und 2004, basiert aber auf noch etwas

ältere Arbeit. Die ältere Grafik dazu ist die von 92, in der in vier Abschnitte eingeteilt wird. Dieses Werte-Rad von zehn immer noch werte Gruppen wird unterteilt in Selbsttranszendenz, Offenheit gegenüber Veränderungen, Verbesserung des Selbst und

Konservierung dessen, was ist. Die eventuell bekanntere Grafik aus der Schwarz-Taxonomie ist diese hier und ich finde die ein bisschen besser verständlich. Die ist zwar weniger übersichtlich, aber man kann besser verstehen, was mit diesen Werten gemeint ist, wie

zum Beispiel Self-Direction, dass da so Sachen wie Kreativität und Freiheit dazu gehören. Und man sieht auch sehr gut, dass diese Werte zusammen nicht immer gleich wichtig sein können, weil die oft ein bisschen oppositioniert sind. Das heißt,

vielleicht kann ich mir vorstellen, dass in meinem Leben die Freiheit und die Kreativität und die Unabhängigkeit sehr wichtig sind. Wenn ich aber gleichzeitig ein Mensch bin, der sehr stark Gewicht auf Tradition legt und Konformität, dann kann das sich auch widersprechen in dem, wie sich das im Alltag ausdrückt. Das kann ich mir für

mein individuelles Leben vorstellen und das kann ich mir auch vorstellen, dass das so ist in Systemen, die ich vielleicht baue. Also wenn ich jetzt in einem sehr traditionellen Unternehmen arbeite, was sehr auf Konformität und Konservierung ausgelegt ist, dann habe ich da vielleicht nicht immer den Freiheitsgrad mit eingebettet in die Systeme, der vielleicht

auch erstrebenswert wäre. Das heißt, die zwei Sachen, die wir aus dieser Grafik mitnehmen wollen, sind zum einen die Unterteilung in diese ganzen Werte, dass es die generell gibt und da sind sehr viele Beispiele drin, die man gleich mitnehmen kann. Und auf der

anderen Seite, dass es da Werte, Paare gibt, die sich gegenüberliegen und wenn die sich in dieser Grafik gegenüberliegen, dann ist es schwierig, die gleichzeitig zu einem gleichen Grad mit zu berücksichtigen, weil die tendenziell ein bisschen einander oponieren. Ich entschuldige mich auch für das Denglisch zwischendurch, da es passiert und ich

bin seit dem mittlerweile vermutlich alle gewöhnt. Jetzt gibt es ein paar richtig coole Arbeiten zu diesem Themenbereich von Maria-Anchela Ferrario in der Arbeitsgruppe, in der John Whittle mit dabei war, bevor er nach Australien gegangen ist. Die arbeiten

auch immer noch zusammen und noch ein paar weitere Autoren. Wir haben jeweils einen unterschiedlichen Liedautor für die nächsten drei Folien. Maria-Anchela ist sehr stark im Participatory Design. Das heißt, die suchen sich in der Gruppe immer Nutzergruppen aus, die sehr interessante Anwendungsdomänen haben. In diesem Beispiel, in dem sie zum

ersten Mal zeigen, hier kann man Werte tatsächlich so runterschreiben, dass die richtig klar sind vor dem Design und dann sind wir mit den Usern zusammen durch diesen Participatory Design Prozess durchgegangen, haben mehrere Prototypen von Hand angefertigt

und dann kann man die hinterher reflektiert sehen, diese Werte in dem, was wir gebaut haben. Und zwar geht es da um ein Armband, das sie CLASP genannt haben. Und die Nutzergruppe, mit der sie gearbeitet haben, sind vor allem Jugendliche und junge Erwachsene,

die irgendwo auf dem Spektrum des Autismus sind. Und dieses Armband ist jetzt dazu gut, in Situationen, wo die sich unwohl fühlen, Feedback registrieren zu können. Und gleichzeitig wurde es so designt, dass sie quasi was zum Anfassen haben, so als eine Art Rückversicherung.

Und wir haben dazu mehrere Prototypen erarbeitet in Iterationen. Und wir sehen hier auf der rechten Seite der Folie eine der Figuren aus dem Papier mit den User Requirements. Und wenn wir uns jetzt noch mal ganz kurz vor Augen rufen, was wir auf der Folie davor gesehen hatten, mit den Werten der Schwarztaxonomie, dann sehen wir hier vier wiedergespiegelt.

Und zwar haben wir das Self-Enhancement gefunden, Openness to Change, Conservation and Self Transcendence. Also es war zwei Folien vorher, das waren die Abschnitte auf dem Rad, diese vier Unterteilungen, wie wir diese Werte kategorisieren können.

Und zum Beispiel haben sie hier gefunden, okay, im Bereich der Selbstverbesserungen kann mir dieses Armand helfen, mein eigenes Verhalten besser zu verstehen. Und es gibt mir eine Möglichkeit, manche meiner Schwierigkeiten zu adressieren. Zum Beispiel, wenn ich gerade

nervös werde, weil ich in einem Umfeld bin, was für mich zu viel Input hat, dann kann ich mit diesem Armand spielen, um mich selbst ein bisschen zu beruhigen. Gleichzeitig hat es eine gewisse Offenheit zur Veränderung. Und es dient mir dazu, Technologie als ein Hilfsmittel zu sehen. Im Bereich der Konservierung oder des Bestehens kann es mir helfen,

weil ich mich dann weniger verletzlich fühle oder es wird keine Unannehmlichkeiten für mich

und die Leute um mich herum geben. Und im Bereich der Selbst-Transcendenz wurde in diesem Team mit allen zusammengearbeitet, also sowohl den Usern, als auch den Designern, Psychologen, und jeder konnte da seine Fähigkeiten mit einbringen. Das war das

erste Beispiel, was ich dazu gefunden habe, was ich sehr gelungen finde im Sinne von, die haben tatsächlich die ganzen Nutzergruppen mit einbezogen und haben sehr klar gemacht, wo diese Werte herkamen. Das zweite Beispiel ist von Winter et al. und die Koa-Autoren

sind nun schon bekannt. Das heißt, es ist aus dem großen Sinn dieselbe Arbeitsgruppe. Und die haben sich angeschaut mit Software-Ingenieuren, was haben wir denn hier für Arten wie Werte, in deren Arbeit mit einbezogen werden. Und was sie dazu getan haben, ist, sie haben Karten sortiert mit diesen Software-Ingenieuren, wo sie Statements wie, it is important to me to be an

honest and trustworthy colleague sortiert haben. Und da hatten sie über 100 Karten dazu, die sortiert wurden und haben ein value skewsort angewandt, dazu angewendet, mit diesen ganzen Werten. Also diese Zitate haben dann einen Wert belegt,

der Wert hier war dependability und das Zitate dazu ist, it is important to me to be an honest and trustworthy colleague. Wir haben herausgefunden, dass es drei Level gibt, auf denen man diese Werte anwenden kann, im Arbeitsbereich eines Software-Ingenieurs und das sind system level,

personal level und instantiation level. Also ich kann es auf dem größeren Systemlevel anwenden, ich kann es in meiner persönlichen Arbeit und umgangsweise anwenden und ich kann es in der Instanz in einer gewissen Arbeitsaufgabe anwenden. Und sie haben dann drei Prototypen für

Profile gefunden, wie das in Software-Ingenieuren ausgelebt wird. Das eine ist der intrinsically driven socially concerned Software-Ingenieur. Also es ist jemand, der sich Gedanken macht um die Gesellschaft, in der er lebt und da gerne was verbessern möchte. Dann haben wir den

autonomen nichtkonformen Risiko freudigen. Also lass uns mal was anderes machen und das große Abenteuer und neue technologische Sachen ausprobieren, weil wir es können und weil wir neugierig sind, was dabei rauskommt. Und dann gibt es noch den fun loving extrinsically

driven Software-Ingenieur, für den die Technik eine großartige Möglichkeit ist, sich in der Welt kreativ auszudrücken und dabei auch noch eine Menge Spaß zu haben. Das waren so die drei Haupttypen, die wir gefunden haben. Das wäre im Vergleich zu der vorherigen Arbeit jetzt die rein Software-Ingenieur-Seite sichtweise auf

diese Value-Perspektive, wie das in der Arbeit umgesetzt werden kann. Und das dritte Beispiel, was ich habe, war aus Arbeiten, die andere gemacht haben, ist jetzt von John Whittle, der vorher der Head of Department war und der mittlerweile in Australien unterwegs

ist. Es ist eine Übersicht über die Projekte, die die zusammen gemacht haben. Da ist das nochmal mit dabei. Das war dieses Armband. Und das andere Beispiel, was sie bringen, war das Patchwork-Projekt. Das ist ein Foto hier aus dem Patchwork-Projekt auf der rechten Seite. Und das war eine Zusammenarbeit mit Obdachlosen, die die gemacht haben.

Und hier sehen wir auch nochmal diese selben Werte und die Requirements, die sie dazu herausgefunden hatten. In diesem IEEE-Software-Artikel stellen sie vier Haupteinsichten heraus. Der erste war, es ist wichtig, tatsächlich diese Werte

ganz klar sichtbar zu machen. Denn wenn wir uns die Zeit nehmen, diese Werte vorher zusammen zu sammeln, dann können wir die auch mehr anfassbar machen im Sinne von uns wird klar, wie wir die in dieses System einbauen können und wie die dann sich dort nachher ausdrücken. Die zweite Einsicht war, es ist wichtig, diese Werte dann tatsächlich auch als

rationale zu dokumentieren in den Anforderungen. Denn wie immer mit der rationale, sonst weiß ich nicht, wo diese Anforderungen ursprünglich mal herkamen. Und die dritte Einsicht war, es ist durchaus machbar, in einem participatory agilen Prozess diese Werte mit einzubauen,

dass die tatsächlich berücksichtigt werden. Und die vierte Einsicht war, natürlich gibt es ja auch Konflikte zwischen den einzelnen Werten und deswegen muss man zwischendurch immer einen Schritt zurücktreten und sich nochmal das größere Bild angucken. Das ist

jetzt quasi der Input. Natürlich haben auch noch andere Leute da tolle Arbeit dazu geleistet, zu dem Themenbereich. Und es schien mir die bessere Idee, hier einen kurzen präzisen Bogen zu schlagen, sodass wir uns jetzt überlegen können, was würden wir denn da gerne draus machen. Und wenn ich mir jetzt überlege, wie das idealerweise aussehen könnte,

wenn wir Werte im requirements engineering mit anwenden, dann kann ich jetzt hier ein kleines Stück von meiner eigenen Wohlbefindungsforschung mit einbauen. Und zwar ist das eine Aktivität,

die ich von der Brandy Brown übernommen habe, die wir am Anfang in diese Werte-Definition gesehen haben. Und in Brandy Browns Leadership-Forschung hat sich herausgestellt, dass es für Manager in jeglicher Position, ob ich jetzt mich selber manage oder ein kleines Team oder ein großes

Team oder ob ich ein CEO bin, das ist absolut fundamental zu wissen, was sind denn die wichtigsten Werte, die ich in meiner Arbeit vertreten möchte. Und was sind die Werte, für die diese Firma steht, für die ich arbeite oder die ich leite. Und dazu hat sie eine

Übung entwickelt, in der sie eine relativ große Liste von möglichen Werten vorschlägt. Und sie sagt auch, könnte auch sein, dass es noch irgendwelche anderen gibt, aber das ist mal eine gute Referenzliste. Und mit denen dann sagt, jetzt setze ich mal damit hin und bringe das erstmal auf 10 runter, die dir wichtig sind. Und dann in einem zweiten Schritt bringt man

diese 10 nochmal auf 3 zusammen, die tatsächlich jetzt im Vordergrund stehen sollen. Und das heißt natürlich nicht, dass diese 10 Werte über den kompletten Verlauf meines Lebens gleich bleiben. Es heißt, dass die für einen gewissen Zeitraum mal gültig sind oder vielleicht auch für einen gewissen Kontext. Das kann sein, dass in meinem Arbeitsumfeld ich andere

Leitwerte habe, als privat zu Hause, wenn ich in meiner Familie zusammen bin. Und ich habe diese Übung in mehreren Kontexten ausprobiert, mit Masterstudenten und auch mit Praktikern, um zu sagen, was ist denn hier wirklich der Kernpunkt. Und diese drei Leitwerte sind

3, weil man muss diese Liste klein halten, sonst wird es zu kompliziert. Und 3 ist eine arbiträre Nummer auf der einen Seite und auf der anderen Seite quasi ein Best Practice. Das ist eine Rule of thumb. Das heißt, wenn ich am Anfang in so einer Requirements Engineering Session zusammensitze, dann könnte ich mir vorstellen, dass man

entweder die Werte einfach nochmal auf den Tisch legt, wenn die eh schon klar sind oder wenn die nicht klar sind, dann wäre es wirklich wichtig, über die zu diskutieren und dann zu sagen, was sind denn unsere drei Leitwerte hier. Viele Unternehmen haben die festgeschrieben in einer Vision. Und es kann sein, dass das dann nochmal Anpassungen bedarf, um zu sagen, was bedeutet denn dieser Wert

jetzt im Kontext des Systems, das wir hier gerade entwickeln wollen und im Kontext dessen, wie wir hier gerade Anforderungen aufschreiben wollen. Also nach diesem Recap oder einer Citation dieser Values kann man dann die Anforderungen zusammentragen und sagen, ok, nachdem uns die jetzt alle wieder quasi im Vordergrund vom Kopf sitzen, können wir

jetzt uns überlegen, wie kommt denn das in die Anforderungen rein. Und damit haben wir dann auch die Rationale jedes Mal klar dokumentiert, um zu sagen, die wurden von diesem Wert abgeleitet. Und dann können wir hinterher sagen, ok, diese Werte sind jetzt tatsächlich embedded in dem Design, was wir uns hier ausgedacht haben. Und mit diesem Einbettungsprozess

ersetzt die Frage, wie können wir das nachweisen? Wir haben ja im requirements engineering seit schon immer die Herausforderung zu zeigen, dass das, was wir am Anfang in

dieser Phase machen, dann später eine tatsächliche Auswirkung hat. Und das ist der Teil, wo ich noch so ein bisschen am knabbern bin und wo ich auch sehr gespannt bin auf die Diskussion. Wenn ich jetzt hier sage, am Ende, ok, die Werte sind jetzt eingebettet und die sind klar dokumentiert, wie kann ich denn sowas dann am Ende zeigen? Und da kann ich

natürlich sagen, ok, ich kann es auf die Nutzertests zurückführen. Und wenn ich mit meinen Nutzern zusammen am Anfang diese Werte festgeschrieben habe, dann können wir die auch Feedback darauf geben, ob das dann tatsächlich so umgesetzt ist. Abgesehen davon, bin ich mir sicher, gibt es noch ein paar andere Denkanstöße in der Richtung und ich bin noch nicht drauf gekommen. Da wäre ich sehr neugierig, was ihr zu sagen habt dazu.

Und wie Andreas schon angezeigt hatte, ist, dass auch das Thema der RevSküDiots dann nächstes Jahr kommt. Wenn jetzt jemand unter euch sagt, oje, oje, der Andreas hat

gesagt, heute war die deadline und ich habe noch kein Paper. Es gibt auch einen Workshop dieses Jahr, der nennt sich Viva RE, Virtues and Values and Requirements Engineering. Und ich wollte dem Alexander noch 30 Sekunden Pitch Time geben und jetzt habe ich gesehen, der hat tatsächlich direkt nach mir den nächsten Vortrag, insofern glaube ich, können wir das dann auch da machen und dann halten wir genau unseren zeitlichen Rahmen ein.

Der Workshop wird auf jeden Fall mit der RevSküDiots zusammen stattfinden und da hat er noch bis zum 10. Februar Zeit. Damit bin ich auch bei meiner letzten Folie angekommen und diese Illustration wird auch von Brandy Brownfield verwendet, stellt so ein bisschen

die Schwierigkeit raus, die wir haben, das in der Ehe umzusetzen. Das eine ist, die Klarheit zu haben über meine Vision und meine Werte und dann der andere Kontext, den wir haben, ist im Entwicklungsumfeld die Zeit und Energie und das wird das dann tatsächlich auch zusammenbringen. Selbst wenn das heißt, dass wir in unserem Requirements Elicitation Meeting

am Anfang diese fünf Minuten nehmen, um diese Werte wieder beieinander zu haben, da wird halt manchmal geknapst und ich glaube, dass das wirklich wichtig ist, dass man da sehr wenig Zeit, mit sehr wenig Zeit schon sehr weit kommt.