Qualitätsanforderungen in (Online-) Workshops erheben

Qualität liegt im Auge des Betrachters

„Lasst uns doch endlich mal wieder mit der Clique richtig schön essen gehen!“ schlägt ein Freund vor. Gute Idee, aber was genau bedeutet für uns eigentlich „schön essen gehen“?

Der eine Freund möchte zum Brasilianer, weil dort die Steaks besonders groß und saftig ist. Jemand anders macht gerade eine Diät und möchte lieber zum Asiaten, weil es dort leichte Gerichte mit viel Gemüse gibt. Und die dritte Person möchte gerne zu dem kleinen Italiener ums Eck, weil es dort den besten Grappa der Stadt gibt.

Es bewahrheitet sich also mal wieder das alte Sprichwort „Schönheit liegt im Auge des Betrachters“.[1] Und so ist es nicht nur beim Essen, sondern auch bei Software. Damit die angepeilten Ziele mit einer Software erreicht werden können, ist auf der einen Seite eine bestimmte Funktionalität wichtig. Aber Softwarefunktionen sind nur die eine Seite der Medaille – die andere Seite sind die qualitativen Eigenschaften, wie zum Beispiel Benutzbarkeit, Sicherheit und Wartbarkeit. Fehlen diese ganz oder teilweise, führt dies in der Regel zu großer Unzufriedenheit bei Nutzern der Software und anderen Stakeholdern (siehe Abbildung 1: Unzufriedene Stakeholder).

Abbildung 1: Unzufriedene Stakeholder

Deshalb müssen wir in der Anforderungsanalyse mit Stakeholdern auch über die gewünschten Qualitätsanforderungen an eine Software sprechen. Oft fokussieren wir jedoch auf die benötigten Funktionen und verlieren diesen wichtigen Aspekt aus den Augen. Damit das nicht passiert, möchte ich hier ein praxiserprobtes Workshopvorgehen vorstellen, mit dem es gelingt, auch Stakeholder ohne technischen Hintergrund von Anfang an in die Definition von Qualitätsanforderungen einzubeziehen.

Workshopplanung

Für einen Workshop zur Ermittlung von Qualitätsanforderungen ist eine gute Teilnehmermischung wichtig, weil wir nur so unterschiedliche und vielleicht auch widersprüchliche Anforderungen sammeln können. Die Teilnehmer sollten verschiedene fachliche Hintergründe und Rollen im Projekt haben, um so vielfältige Blickwinkel abdecken zu können.

Die richtigen Teilnehmer auszuwählen, kann eine Herausforderung sein, da der Teilnehmerkreis gleichzeitig nicht zu groß werden sollte. Maximal zehn Teilnehmer sind meiner Erfahrung nach eine gute Größe. Falls der potenzielle Teilnehmerkreis größer ist, kann ich Euch die Liberating Structures ans Herz legen. Diese Moderationsmethoden sorgen auch in großen Gruppen dafür, dass sich alle gut einbringen können.

Für einen ersten „Aufschlag“ zum Thema Qualitätsanforderungen kann ein vierständiger Workshop ein guter Start sein. Falls Ihr den Workshop online durchführt, würde ich tendenziell ein noch kürzeres Zeitfenster von 2-3 Stunden einplanen und dafür mehr Zeit in die Vorbereitung investieren.

Die ISO-Norm 25010 für Softwarequalität

Um bei dem umfangreichen Thema Qualitätsanforderungen nicht den Überblick zu verlieren, verwende ich in Workshops das Qualitätsmodell für Produktqualität aus der internationalen Norm ISO 25010 für die System- und Softwareentwicklung. Die Norm definiert acht Qualitätsmerkmale, welche jeweils in weitere Untermerkmale unterteilt sind (siehe Abbildung 1: Qualitätsmerkmale nach ISO 25010). Abhängig von der Workshopdauer und meinem Vorwissen über das Projekt, verwende ich im Workshop entweder das komplette Modell oder relevante Teilausschnitte davon.

Abbildung 2: Qualitätsmerkmale nach ISO 25010

 

Manche Qualitätsmerkmale sind selbsterklärend, bei anderen brauchen die Workshopteilnehmer für die Arbeit mit dem Modell ein paar erläuternde Worte. Für eine Reihe von Präsenzworkshops habe ich für einen Kunden zu diesem Zweck vor einiger Zeit ein kleines Handout angefertigt, welches Ihr hier herunterladen könnt.

Für Online-Workshops bereite ich ein Online-Whiteboard (z. B. mit Miro oder Conceptboard) vor, welches eine Mindmap mit den relevanten Qualitätsmerkmale aus der ISO 25010 mit einer kurzen Erklärung enthält (Siehe Abbildung 3 für einen Auszug der entsprechenden Mindmap). Diese baumartige Strukturierung der Qualitätsmerkmale wird in der Fachliteratur auch oft als „Utility Tree“ oder „Qualitätsbaum“ bezeichnet. Damit später genug Platz auf dem Whiteboard ist, um die einzelnen Qualitätsmerkmale zu bearbeiten, lasse ich möglichst viel Freiraum rund um die einzelnen Mindmap-Elemente.

Qualitätsanforderungen mit Qualitätsszenarien konkretisieren

Nachdem ich das Qualitätsmodell und den Qualitätsbaum kurz erklärt habe, geht es im Workshop an die Analyse der Qualitätsanforderungen. Hierzu eignet sich die sogenannten Qualitätsszenarien – eine Technik, die oft auch zur Bewertung von Softarchitekturen verwendet wird.

Qualitätsszenarien beschreiben die Verwendung des Systems mit Fokus auf jeweils ein Qualitätsmerkmal und dienen dazu, die am Anfang oft schwammigen Qualitätsanforderungen zu konkretisieren.

Ganz allgemein lassen sich drei Arten von Szenarien unterscheiden:

Szenarioart Beschreibung Beispiel
Verwendungsszenario Beschreibt die normale tägliche Nutzung des Systems. Ein Webseiten-Benutzer führt eine Volltextsuche durch. Die Suchergebnisse werden in unter 5 Sekunden angezeigt. (Qualitätsmerkmal: Leistungseffizienz)
Änderungsszenario Beschreibt was passiert, wenn Dinge im System geändert werden (z. B. neue Funktionen, größere Nutzeranzahl etc.). Ein Webseiten-Manager möchte eine neue Sprache hinzufügen. Er kann dies ohne die Unterstützung eines Softwareentwicklers tun.
Fehlerszenario Beschreibt, wie das System auf Fehler oder unvorhergesehene Ereignisse (z.B. Netzwerk- oder Hardwareausfälle) reagiert. Ein Webseiten-Benutzer hat versehentlich eine Seite gelöscht. Ein Webseiten-Administrator kann die gelöschte Seite innerhalb kurzer Zeit wiederherstellen.
Tabelle 1: Arten von Qualitätsszenarien

Typischerweise enthält ein Qualitätsszenario immer eine Quelle (z. B. ein Webseiten-Benutzer, ein Webseiten-Manger), eine Interaktion mit dem System (z. B. eine neue Sprache hinzufügen) und ein Antwortmaß (z. B. „unter 5 Sekunden“, „ohne die Unterstützung eines Softwareentwicklers“). Hierdurch werden Qualitätsanforderungen greifbar und zumindest theoretisch überprüfbar.

Wenn ich einen Workshop vorbereite, bereite ich für jede Unterkategorie der relevanten Qualitätsmerkmale ein konkretes Beispielszenario vor. So fällt es den Teilnehmern leichter, später selbst Qualitätsszenarien zu formulieren.

Falls ich die Anforderungen an das System schon etwas besser kenne, verwende ich als Beispiele realistische Szenarien, die im Idealfall von den Stakeholdern direkt bestätigt werden können. Falls ich die Anforderungen noch nicht kenne, verwende ich fiktive Szenarien aus einem anderen Bereich (wie zum Beispiel die Szenarien in Tabelle 1: Arten von Qualitätsszenarien ).

Je nach Teilnehmeranzahl geht es nun entweder mit der gesamten Gruppe oder in Kleingruppen weiter und die Teilnehmer sammeln auf physikalischen oder virtuellen Post-Its Qualitätsszenarien zu den einzelnen Unterkategorien der ISO25010.

Abbildung 3: Sammeln von Qualitätsszenarien auf einem Miro-Bord

Priorisierung von Qualitätsmerkmalen

In kurzer Zeit kann so eine große Anzahl von Qualitätsszenarien zusammenkommen. Hierbei wird meist schnell deutlich, dass die Stakeholder einen unterschiedlichen Fokus darauf haben, welche Qualitätsmerkmale aus ihrer Sicht besonders wichtig sind. Der IT-Architekt achtet vielleicht vor allem auf Sicherheit und Wartbarkeit, während den Key-Usern die Benutzbarkeit am wichtigsten ist.

Wie schön wäre es, wenn wir ein System bauen könnten, dass die Qualitätswünsche aller Stakeholder vollkommen befriedigt! Leider ist dies in der Praxis jedoch meistens nicht möglich. Zum einen, weil dieses System unglaublich teuer zu realisieren wäre, zum anderen, weil es oft Konflikte zwischen Qualitätsmerkmalen gibt. Ein sehr sicheres System ist beispielsweise oft schlechter nutzbar und sehr performanter Quellcode kann schwierig wartbar sein. In der Architekturbewertungsmethode ATAM spricht man in diesem Zusammenhang auch von den sogenannten Tradeoffs zwischen Qualitätsmerkmalen.

Um abwägen zu können, welche Tradeoffs man am ehesten eingehen kann, ordnen die Workshopteilnehmer jedem Qualitätsszenario eine Priorität (High, medium oder low) zu. Für einen Online-Workshop mit Miro eignen sich hierzu die Labels, welche frei definiert und an Post-its geknüpft werden können.

Ich bitte zunächst alle Teilnehmer, die Prioritäten allein (sozusagen in „Stillarbeit“) zu vergeben. Wie in Abbildung 4 zu sehen, kommt es dabei normalerweise mehr oder weniger häufig vor, dass Teilnehmer dasselbe Qualitätsszenario unterschiedlich bewerten (z. B. ein Teil der Teilnehmer bewertet die Priorität als „High“, ein andere Teil als „Low“). Die Szenarien mit unterschiedlicher Bewertung werden im nächsten Schritt ähnlich wie beim Planning Poker diskutiert und am Ende einigen sich hoffentlich alle Teilnehmer auf eine gemeinsame Priorität. Hierbei entsteht in der Regel ein sehr guter Austausch zwischen den Stakeholdern, die offen darüber reden, was ihnen am System am wichtigsten ist.

Abbildung 4: Priorisierung von Qualitätsszenarien

Einen kleinen Spaßfaktor bieten in Miro die Emoticons, welche man auf einen Post-It setzen kann. Ich habe in einem Workshop mal die Teilnehmer gebeten, das wütende Emoticon zu nutzen, falls sie mit einem Szenario gar nicht einverstanden sind. Genauso können Teilnehmer einem für sie besonders wichtigen Szenario den Daumen nach oben oder ein anderes positives Emoticon geben.

Fazit

Das Erheben und Analysieren von Qualitätsanforderungen ist kein Hexenwerk und funktioniert mit Qualitätsszenarien und einem guten Online-Whiteboard auch remote sehr gut. Mindestens genauso wichtig wie die Szenariosammlung am Ende des Workshops ist aus meiner Erfahrung jedoch auch der Austausch zwischen den Stakeholdern. Oft ist der Workshop der ersten Anlass, endlich einmal explizit über die eigenen Qualitätserwartungen an die Software zu sprechen.

Die erarbeiteten Qualitätsanforderungen fließen im Nachgang als eigene Stories, Akzeptanzkriterien oder über die Definition of Done in den Entwicklungsprozess ein.

Welche Erfahrungen habt Ihr mit Qualitätsanforderungen gemacht? Habt ihr das Thema Qualitätsanforderungen auf dem Schirm und falls ja, wie erarbeitet Ihr sie mit den Stakeholdern? Schreibt es mir gerne in die Kommentare zu diesem Blogbeitrag.

Und falls Ihr Unterstützung bei der Vorbereitung und / oder Durchführung eines Qualitätsanforderungsworkshops benötigt (Präsenz oder remote), schreibt mir gerne:

 


[1] Manche behaupten auch, Schönheit sei eine Sache der Beleuchtung – aber diesem Thema wollen wir an dieser Stelle besser nicht weiter nachgehen. 😉

Als Product Owner die richtigen Fragen stellen

Wusstet Ihr, dass Kinder an die 500 Fragen pro Tag stellen?[1] Und dass sie – wenn sie mit dem Sprechen anfangen – zuerst nach dem „Was“ und „Wo“ und mit ungefähr drei Jahren auch nach dem „Warum“ fragen?[2] Deshalb behaupte ich in meinen Trainings manchmal scherzhaft, dass kleine Kinder vermutlich die besten Product Owner oder Requirements Engineers wären. 😉

Denn wenn es darum geht, die Bedürfnisse der Stakeholder an ein Produkt herauszufinden, sind Fragen ein wichtiges Arbeitsinstrument für Product Owner, Business Analysten, Requirements Engineers und überhaupt alle, die sich mit der Analyse von Anforderungen beschäftigen. Aber wie schaffe ich es, in Stakeholder-Interviews wirklich die richtigen Fragen zu stellen?

Da ich nach dem Abitur ursprünglich Journalistin werden wollte und auch eine Zeitlang nebenberuflich bei einer Zeitung gearbeitet habe, beschäftige ich mich schon lange damit, wie man erfolgreiche Interviews führt. Ein guter Anlass für mich, darüber nun einen Blogartikel zu schreiben!

Die innere Haltung ist entscheidend

„Ist das die richtige Frage?“ – damit beschäftigen sich Kinder gar nicht. Sie fragen einfach nach allem, was sie wissen wollen. Ich glaube, da können wir uns als Product Owner oder Requirements Engineers ein bisschen was abgucken. Denn wir können noch so schlaue Fragen stellen, wenn die Grundvoraussetzung für ein gutes Gespräch nicht gegeben ist: Ein ehrliches Interesse am Gegenüber und an dem, was er oder sie zu erzählen hat.

Hilfreich finde ich es, mich selbst als Interviewer in erster Linie als Lernende zu sehen und nicht zu versuchen, die Stakeholder mit vermeintlichem Fachwissen zu beeindrucken. „Ich bin hier, um zu lernen“, ist mein kleines Mantra, das ich mir manchmal im Geiste vorsage, wenn ich mich dabei erwische, wieder in die „Expertenfalle“ zu tappen.

Zu wissen und auch zu zeigen, dass man etwas nicht weißt, ist nicht immer leicht. „Sie sind doch hier die Experten!“ empörte sich vor ein paar Jahren ein Kunde, den ein Kollege und ich im Rahmen eines E-Commerce-Projektes interviewt hatten. Mein Kollege hat damals sehr souverän reagiert und dem Kunden ruhig und freundlich erklärt, dass wir zwar die Experten für E-Commerce-Software sind, jedoch nicht für seine Branche und Produkte. Daher wäre es für uns enorm wichtig, diese Themen mit ihm zu besprechen. Der Kunde hat daraufhin sofort mehr Verständnis für unsere – für ihn möglicherweise teilweise recht sonderbar anmutenden – Fragen gehabt und wir konnten ein konstruktives und informatives Interview führen.

Als Interviewerin muss ich mir außerdem bewusst sein, welche eigenen Annahmen ich mit in das Gespräch bringe. Diese sollte ich explizit machen, um zu überprüfen, ob diese auch der Weltsicht des Stakeholders entsprechen. Wir sind alle geprägt von Systemen, Websites und Apps, die wir gerne nutzen. Wenn ein System neu entwickelt wird, nutzen wir diese Erfahrungen häufig als Referenz, ohne entsprechende Punkte näher zu diskutieren. Blöd nur, wenn man am Ende merkt, dass der Kunde beispielsweise von einem an iOS angelehnten Bedienkonzept ausgegangen ist, während ich mich weitestgehend in der Android-Welt tummle.

Die Sesamstraßenstrategie

Offenheit und die geistige Klarheit über meine eigenen Annahmen sind für mich als Interviewerin also schon mal die halbe Miete. Bei der zweiten Hälfte hilft mir ein Ausflug zurück in meine Kindheit. Nein, damit meine ich nicht, die Stakeholder mit circa 500 „Warum“-Fragen am Tag zu terrorisieren!  Sondern ich meine die Sesamstraße! 😀

„Wer, wie, was, wieso, weshalb, warum“ – wer kennt sie nicht, die Sesamstraßen-Titelmelodie. Und damit hat man eigentlich auch schon die wichtigsten Fragen für die Anforderungsanalyse zusammen[3]. Der Vorteil von diesen W-Fragen ist, dass es sich bei ihnen um offene Fragen handelt. Diese sind bestens geeignet, um den Gesprächspartner ins Erzählen kommen zu lassen und so möglichst viele Informationen abgreifen zu können. Anders als bei der Sesamstraße, sollte am Anfang der Fokus allerdings noch nicht so sehr auf dem „Wie“ liegen, sondern eher auf dem „Warum“ bzw. dem „Wozu“.  Andernfalls besteht die Gefahr, dass man sich frühzeitig in unwichtigen Details oder technischen Lösungsdiskussionen verliert.

Psychoanalyse für Antworten

Falls Euer Frage-Ehrgeiz jetzt geweckt ist, lohnt sich außerdem ein Ausflug in die Welt des systemischen Coachings. Gute Coaches nutzen in ihren Gesprächen Fragetechniken der natürlichsprachlichen Analyse, um in den Antworten der Coachees verborgene Informationen ans Licht zu heben. Man spricht in diesem Zusammenhang von sprachlichen Effekten wie Tilgungen, Generalisierungen und Verzerrungen, die in Gesprächen häufig zu Missverständnissen führen.

In der folgenden Tabelle stelle ich euch einige dieser Sprachmuster vor:

Sprachmuster Beispiel Wie hinterfragen
Passivkonstruktionen „Die Meldung wird verworfen“. „Wer oder welches System macht das?“
Nominalisierungen „Der Kunde schließt seine Anmeldung ab“. „Wer genau ist der Kunde? Was ist mit Anmeldung gemeint?“
Nicht qualifizierte Adjektive oder Adverben „Das System muss einfach zu bedienen sein“. „Was verstehen Sie unter einfach? Haben Sie ein Beispiel für mich?“
Unspezifische Verben „Der Kunde erfasst die Daten.“ „Wie und wann erfasst der Kunde die Daten?“ (und siehe oben: Nominalisierungen)
Universalquantoren „Das System muss alle Datensätze exportieren“. „Wirklich alle Datensätze? Gibt es Ausnahmen?“

Es braucht etwas Übung, aber wenn ihr mit der Zeit feine Antennen für diese Sprachmuster entwickelt habt, hilft euch das dabei, möglichst wenige Informationen zu übersehen. Falls ihr Lust und Zeit habt, sucht euch zum Üben doch einfach mal eine beliebige Nachrichtensendung oder eine Talkshow raus und schaut, welche sprachlichen Effekte ihr dort entdeckt!

Fragenjoker für alle Fälle

Am Ende eines Interviews benutze ich dann gerne eine Fragetechnik, die ich in meiner Ausbildung zum systemischen Coach gelernt habe: Die sogenannte Jokerfrage.

Ich frage meinen Gesprächspartner dann, ob es noch irgendeine Frage gibt, die ich vergessen habe zu stellen. So nehme ich mein Gegenüber mit in die Pflicht, für sich noch einmal das Gespräch zu reflektieren und die Vollständigkeit der ausgetauschten Informationen zu überprüfen. Manchmal kommen hierdurch tatsächlich noch wichtige Punkte ans Tageslicht.

Fazit

Gute Stakeholder-Interviews zu führen ist gar nicht so schwer. Wenn die innere Haltung stimmt und ein gutes Gesprächsklima vorherrscht, braucht es nur noch ein wenig Handwerkzeug und Übung.

Letztendlich solltet ihr es allerdings entspannt angehen. Denn falls ihr aus irgendeinem Grund doch nicht die „richtigen“ Fragen gestellt haben solltet, ist das meiner Meinung nach gar nicht so dramatisch. Erstens könnt ihr die Stakeholder später immer noch mal kontaktieren, sollten euch nach dem Interview noch weitere Fragen einfallen (Besorgt euch während des Interviews schon das Einverständnis des Stakeholders hierzu und seine Kontaktdaten!).

Und zweitens merkt ihr in einem agilen Vorhaben letztendlich bei der Auslieferung des ersten Softwareinkrements an dem Feedback des Stakeholders, ob ihr seine oder ihre Bedürfnisse gut genug verstanden habt. Und könnt so mit jedem Inkrement immer bessere Fragen stellen und bessere Antworten erhalten.

Wie seht ihr das? Welche Tipps und vielleicht sogar „Lieblingsfragen“ habt ihr für Stakeholder-Interviews?


[1] https://www.schweizer-illustrierte.ch/family/alltag/wann-ihr-kinderfragen-besser-nicht-beantwortet

[2] https://www.spiegel.de/familie/warum-kinder-warum-fragen-brauchen-und-wie-eltern-damit-umgehen-sollten-a-992c6e63-6a2d-42c5-8aef-8bb61c62a0f2

[3] Das „Wann“ und „Wozu“ fehlen hier noch.

Beitragsbild: https://pixabay.com/de/photos/universal-studios-singapur-2413365/