Kolumne: Req4Arcs

Was Stakeholder wollen: Qualitätsanforderungen konkret formulieren

Peter Hruschka, Gernot Starke

In der letzten Folge hatten wir das Thema „Qualität“ top-down erklärt und Ihnen dazu das generische Qualitätsmodell von ISO 25010 vorgestellt – zur Erinnerung finden Sie in Abbildung 1 nochmal die obere Ebene der Qualitätseigenschaften zusammengefasst – das komplette Modell geht noch eine Stufe tiefer und umfasst insgesamt gut 45 solcher Eigenschaften. Das ergibt eine ziemlich breite Themenvielfalt rund um „Qualität“, ist aber als Grundlage für konkrete Architektur- oder Implementierungsentscheidungen viel zu abstrakt: Wir benötigen mehr Details, wir müssen genauer wissen und beschreiben, was Stakeholder denn nun wirklich von unseren Systemen erwarten oder benötigen. Abstrakte Begriffe wie „Performance“ genügen dazu nämlich nicht.

Wichtig: Entscheidbarkeit

In der letzten Folge hatten wir eine Anforderung an Anforderungen formuliert (also sozusagen eine Meta-Anforderung): Wie für funktionale Anforderungen fordern wir, dass auch Qualitätsanforderungen ganz explizit Abnahme- oder Erfüllungskriterien haben sollten. Sie sollten also zu Ihren Qualitätsanforderungen möglichst objektiv entscheiden können, ob und wann diese Anforderung erfüllt ist oder nicht. Bitte verwechseln Sie diese klaren Kriterien nicht mit automatisierten Tests: Es geht uns bei den Kriterien erstmal um die klare Entscheidbarkeit! Als Architekten sollten Sie genau wissen, wann und ob Ihr System die wichtigen Qualitätseigenschaften gut genug erfüllt, ob Sie im betroffenen Bereich Ihrer Arbeit fertig sind.

Abb. 1: ISO 25010 im Überblick

Abb. 1: ISO 25010 im Überblick

Eine Möglichkeit, dieses Level an Konkretheit oder Entscheidbarkeit zu erreichen, sind die so genannten Qualitätsszenarien, die das Software Engineering Institute in in vielen Publikationen ausführlich beschrieben hat.

Szenarien konkretisieren

Szenarien sind eine einfache Technik (Abb. 2): Sie beschreiben, wie ein System auf bestimmte Einflüsse (genannt Events oder Stimuli) reagiert, was beim Eintreffen eines Stimulus auf ein System in bestimmten Situationen geschieht. Dabei müssen wir zwei wesentliche Kategorien differenzieren, nämlich die Anwendungs- oder Nutzungsszenarien (beschreiben das Verhalten des Systems bei seiner Nutzung) und die Änderungsszenarien (beschreiben, wie das System auf irgendwelche Änderungen reagiert, beispielsweise geänderte Anforderungen oder auch Änderungen in Betriebs- oder Ablaufumgebung).

Abb. 2: Qualitätsszenarien – schematisch

Abb. 2: Qualitätsszenarien – schematisch

Ein paar kleine Beispiele für Anwendungsszenarien:

  • Die Antwort auf eine Angebotsanfrage muss Endbenutzern im Regelbetrieb in weniger als fünf Sekunden dargestellt werden. Im Betrieb unter hoher Last (z. B. Weihnachtsgeschäft) darf eine Antwort bis zu 15 Sekunden dauern.
  • Benutzer ohne Vorkenntnisse sollen bei der erstmaligen Verwendung des Systems innerhalb von 2 Minuten in der Lage sein, die gewünschte Funktionalität selbstständig zu finden und verwenden zu können.

Und noch einige Änderungsszenarien:

  • Die Implementierung eines neuen Versicherungstarifs muss in weniger als 30 Personentagen möglich sein.
  • Die Anbindung eines neuen CRM-Systems muss innerhalb von 10 Tagen möglich sein.

Sie sehen: Szenarien sind einfache Sätze, die normalerweise alle Beteiligten verstehen können. Das ist praktisch, weil die Einstiegshürde in die Konkretisierung von Qualitätsanforderungen bei Szenarien extrem niedrig liegt – es gibt keine Ausreden!

Wir sind jetzt also in der Lage, mithilfe solcher Szenarien die gewünschten Qualitätseigenschaften unserer Systeme ziemlich genau beschreiben zu können.

Wenn wir uns an das Schema aus Abbildung 1 halten und zu jedem Szenario stets eine „Metrik“ angeben, also einen Zahlenwert (etwa: Wie lange darf etwas dauern? Wie häufig oder wie selten darf etwas geschehen?), dann können wir damit auch ziemlich genau entscheiden, ob unser System bezüglich dieses Szenarios „gut genug“ ist. Unsere Meta-Anforderung ist damit erfüllt.

Quality-Workshops und Priorisierung

Sammeln Sie diese Szenarien in kleinen Workshops mit den wichtigen Stakeholdern, beispielsweise im Brainstormingmodus. Damit finden Sie schnell Dutzende bis zu Hunderten von Szenarien – also viele relevante Qualitätsanforderungen. Hängen Sie eine Kopie des ISO-Qualitätsbaums an die Wand, und erstellen Sie einige aus Ihrer persönlichen Sicht typische Beispiele für konkrete Szenarien Ihres Systems – damit sind Sie für solche Quality-Workshops schon rudimentär gerüstet.

Unserer Erfahrung in Dutzenden solcher Workshops zeigt, dass Sie problemlos eine dreistellige Zahl von Szenarien finden werden (sprich: ziemlich viele). Weiter unten zeigen wir Ihnen, wie ein Qualitätsbaum Ihnen bei dieser großen Anzahl hilft.

Zuerst aber ein pragmatischer Anfang: Konzentrieren Sie sich sehr früh in der Entwicklung auf Ihre Top-3-Qualitätsanforderungen. Nehmen Sie den ISO-Baum oder VOLERE als Checkliste und klären Sie, welche Kategorien von Qualitätsanforderungen (mit welchen konkreten Szenarien) für Ihre Anwendung absolute Killerkriterien sind. Damit meinen wir: Alle anderen Kategorien sind sicherlich auch wichtig, aber wenn die drei nicht erfüllt sind, kann das System nicht in Betrieb gehen.

Wir wollen diese Top 3 als Hitparade aufschreiben. Was ist Platz 1? Was ist Platz 2? Denn wir haben Ihnen noch nicht verraten, dass die Qualitäten oft unschöne Wechselwirkungen untereinander haben. Beispielweise gefährdet hochgradige Flexibilität (jeder kann an beliebigen Parametern des Systems drehen und schrauben) natürlich die Robustheit. Und die Modularität eines Systems wird durch Schichten sicherlich besser, aber zu viele Schichten gefährden die Performanz. Und zu allem Überfluss erhöhen alle Qualitätsanforderungen den Preis.

Wir meinen das sehr ernst mit „nur die Top 3“ (ausnahmsweise vielleicht einmal 4 – 5). Denn wenn Sie Ihrem Chef zehn Kriterien zur Reihung geben „Was ist dir am wichtigsten? Modularität, Benutzerfreundlichkeit, Ausbaubarkeit, Performanz, Sicherheit, …“, dann kennen Sie die Antwort: „Ja, alles davon!“. Das wollten Sie aber nicht hören. Sie wollten wissen, ob Sie in der Architektenrolle eher die Performanz steigern oder die Sicherheit erhöhen sollen. Beides zusammen geht nicht. Deshalb die Hitparade (oder neudeutsch: ein Ranking) der Qualitäten. Wenn Performanz nach Sicherheit steht, dann darf das Entwicklungsteam keinerlei Entscheidungen treffen, die die Performanz steigern, gleichzeitig aber das höhere Ziel „Sicherheit“ gefährden.

Spezifischer Qualitätsbaum

Von der Hitparade wieder zurück zu unseren Szenarien aus dem Quality-Workshop: In einer solchen Menge an Szenarien verlieren Sie schnell die Übersicht – darum sollten Sie Szenarien ordnen. Dazu eignen sich die oben erwähnten Qualitätsmodelle (etwa ISO-25010) hervorragend: Ordnen Sie die Szenarien den Oberbegriffen zu – damit erhalten Sie einen so genannten (spezifischen) Qualitätsbaum – ein Beispiel finden Sie in Abbildung 3.

Abb. 3: spezifischer Qualitätsbaum (Auszug)

Abb. 3: spezifischer Qualitätsbaum (Auszug)

Fazit

Funktionalität ist wichtig, aber nur die halbe Miete: Funktionen benötigen explizite Qualitätsanforderungen! Starten Sie frühzeitig mit einer Hitparade Ihrer Top-3-Qualitäten, die jeder im Entwicklungsteam als Hilfe für Architekturentscheidungen kennen muss. Bleiben Sie nicht auf der Schlagwortebene, sondern präzisieren Sie Qualitätsanforderungen (etwa über Szenarien) bis hin zu prüfbaren Abnahmekriterien. Organisieren Sie alle Qualitäten in Form eines (priorisierten) Qualitätsbaum, auf den Sie bei der Weiterentwicklung Ihrer Systeme immer einen Blick werfen, ob vielleicht ein neuer Ast im Baum hinzugekommen ist oder einen anderen Stellenwert erhalten sollte. Damit sind Sie dann hervorragend gerüstet, um dauerhaft fundierte Architekturentscheidungen zu treffen.

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: