„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 eigentlich „schön essen gehen“?

Der eine Freund möchte zum Brasilianer, weil dort die Steaks besonders groß und saftig ist. Ein ander Kumpel 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 das alte Sprichwort „Schönheit liegt im Auge des Betrachters“. Und so ist es nicht nur beim Essen, sondern auch bei Software. Damit die angepeilten Ziele mit einer Software erreicht werden können, wird eine bestimmte Funktionalität benötigt. 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 mit unseren Stakeholdern auch über die Qualitätsanforderungen an eine Software sprechen. Hierzu möchte ich 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.

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 aus der internationalen Norm ISO 25010 für die System- und Softwareentwicklung. Die Norm definiert neun Qualitätsmerkmale, welche jeweils in weitere Untermerkmale unterteilt sind (siehe Abbildung 2: 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 (Unterkategorien aus Platzgründen nicht vollständig)

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. 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 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. Wir müssen also Kompromisse suchen.

Um abwägen zu können, welche Kompromisse 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“, andere Teilnehmer als „Low“). Die Szenarien mit unterschiedlicher Bewertung werden im nächsten Schritt ähnlich wie beim Planning Poker diskutiert und am Ende einigen sich alle 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

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 ist aus meiner Erfahrung jedoch auch der Austausch zwischen den Stakeholdern. Oft ist der Workshop der ersten Anlass, explizit über die eigenen Qualitätserwartungen an die Software zu sprechen.

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

Falls Ihr Fragen zum Vorgehen habt oder Unterstützung bei der Durchführung eines Qualitätsanforderungsworkshops benötigt, schreibt mir gerne.

---