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. 😉