Qualitätsmodelle im Requirements Engineering

6. März 2014Dr. Lutz Reder

Qualitätsanforderungen werden meist als mehr oder weniger strukturierte Liste erstellt. Qualitätsanforderungsthemen sind beispielsweise Performance, Verfügbarkeit, erwartetes Datenvolumen oder Aspekte, die den Entwicklungsprozess (Vorgehen, Programmiermodelle, Wart- und Erweiterbarkeit) betreffen.

Üblicherweise werden zur Erstellung der Anforderungen Templates ausgefüllt oder Qualitätsanforderungen 1 aus anderen Projekten übernommen und sinnvoll angepasst. Auf diese Weise kommt man schnell zu vorzeigbaren Ergebnissen. Diese werden aber meist nicht weiter diskutiert, weil sie nicht begründet, nur vage formuliert oder nicht operationalisiert, also nachprüfbar gemacht, werden. Entsprechend kümmert man sich im Projektverlauf nicht mehr darum.

Qualitätsmodelle sind ein Ansatz, um diese Mängel zu beheben und zu nachprüfbar hochqualitativer Software zu gelangen.

Vorgehen

Ausgangspunkt zur Entwicklung eines Qualitätsmodells kann tatsächlich die Themenliste der bekannten Templates oder Vorgängerdokumente sein. Jedes dieser Themen wird dann systematisch nach den folgenden Fragen erarbeitet:

  • Warum gibt es diese Anforderung?
  • Von wem kommt sie?
  • Welche messbaren Ausprägungen gibt es?
  • Wie wird die Erfüllung überprüft (Test-, Messverfahren)?
  • Welche Konsequenzen hat die Nichterfüllung dieser Qualitätsanforderung?
  • Wie sieht die Kosten-Nutzen-Relation aus, d.h. welchen Aufwand rechtfertigt die Erfüllung?

Häufig wird bei der Erarbeitung das Goal-Question-Metric-Verfahren angewandt:

  • Goal: Welches Ziel soll erreicht werden?
  • Question: Was soll gemessen werden?
  • Metric: Welche Metrik beschreibt die Eigenschaft?

Falls diese Fragen nicht beantwortet werden können (z.B. „wie wird ‚Performance‘ gemessen?“), ist eine Dekomposition des Zieles erforderlich: Antwortzeit, Durchsatz, Ressourcen etc. Die Dekomposition wird iterativ solange wiederholt, bis messbare Eigenschaften erreicht sind.

Beispiele

Eine Performance-Anforderung lautet häufig „Die Antwortzeit darf höchstens x Sekunden betragen“. Das ist weder nachvollziehbar noch messbar. Eine sinnvolle und nachprüfbare Performance-Anforderung lautet zum Beispiel „Für die Seite X muss die [durchschnittliche / perzentile] Antwortzeit [in der Hauptverwaltung / in Geschäftsstellen / für den Kunden im Internet] bis zur Benutzbarkeit höchstens x Sekunden sein. Die Benutzbarkeit umfasst die Server-Antwort und das Rendering der Seite“. Während die Dauer der Server-Antwort beispielsweise mit JMeter noch gut messbar ist, hängt das Rendering auch vom Rechner des Benutzers sowie vom verwendeten Browser und dessen Version ab. Nur wenige Tools (zum Beispiel Selenium) erlauben solche Messungen.

Man muss sich außerdem darüber im Klaren sein, dass ein abnahmerelevanter Test dieser Anforderung selbst schon einen erheblichen Aufwand an eine produktionsnahe Testumgebung (Anzahl der Benutzer, Datenvolumen, Schnittstellen zu Drittsystemen etc.) stellt. Daher gehört zur Anforderung auch die quantitative Definition der Testumgebung.

Schlussendlich muss noch die Frage beantwortet werden, welche Konsequenzen die Nichterfüllung hat. Wenn der Aufwand für die Spezifikation und den Test zu hoch ist, ist die Anforderung offensichtlich auch nicht wirklich wichtig.

Das Qualitätsmodell

Das Ergebnis ist ein Qualitätsmodell, das in der Regel eine baumartige Struktur hat; hier ein Ausschnitt zum Thema Performance:

adesso_Qualitätsmodelle

Zwischen den einzelnen Ästen und Blättern des Baums können weitere Abhängigkeiten bestehen, zum Beispiel höhere Performance durch mehr Ressourcen, längere Antwortzeit wegen höherer Sicherheit (Security) oder durch die Erweiterbarkeit durch Konfiguration.

Wie weit dieses Modell ausgearbeitet und verfeinert wird, hängt davon ab, wie wichtig die einzelnen Qualitätsaspekte sind. Der hohe Aufwand der Erarbeitung und Nachprüfung führt zu dem positiven Nebeneffekt, dass er nur für die wirklich wichtigen Qualitätsanforderungen betrieben wird. Nebensächliche Qualitätsanforderungen kann man tatsächlich auf oberer Ebene abhandeln, sie haben dann aber auch nur „nice-to-have“-Charakter.

Was halten Sie von diesem Ansatz?

  1. Quelle: Dr. Jörg Dörr, Fraunhofer IESE, Kaiserslautern: Kritische Qualitätsanforderungen vollständig spezifizieren? Und es geht doch… (Vortrag 2012 bei den Softwareforen Leipzig)
Dr. Lutz Reder Dr. Lutz Reder ist Senior Consultant und IREB-zertifizierter Requirements Engineer bei adesso. Er arbeitet in kundenspezifischen Entwicklungsprojekten mit den Schwerpunkten Requirements Engineering und UML.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: