Warum sollten sich Softwareentwicklungsprojekte mit der Qualität ihrer Produkte hinsichtlich der nicht-funktionalen Anforderungen beschäftigen?
Thomas Rauch: Qualität und nicht-funktionale Anforderungen werden oft nur nebenläufig behandelt. Das kann zum einen damit zusammenhängen, dass nicht klar ist, was passende Qualitätsmerkmale sind. Zum anderen stehen oft die reinen Funktionalitäten zu sehr im Vordergrund. Ein Kunde sagte einmal: „Qualität ist egal. Hauptsache die Funktionen sind da!“ Diese Aussage ist insofern schwierig, da Qualität und Funktionen Hand in Hand gehen. Nicht-funktionale Anforderungen beschreiben neben den Rahmenbedingungen genau dies: Qualitätsanforderungen, die ergänzend zu den konkreten Funktionalitäten den Wert einer Anwendung für den Nutzer oder die innere Qualität einer Anwendung erhöhen. Diese werden in dem Standard für Softwarequalität ISO/IEC 25010 beschrieben.
Die ISO/IEC 25010 ist der Standard für Softwarequalität und beschreibt die Qualitätsmerkmale hinsichtlich „Qualität im Gebrauch“ und „Produktqualität“. Dabei meint „Qualität im Gebrauch“ die Qualitätsmerkmale, die den Wert einer Anwendung für den Nutzer ausmachen, z.B. dass er die Anwendung effektiv und effizient zur Erreichung seiner Ziele nutzen kann oder zufrieden mit der Anwendung ist. „Produktqualität“ beschreibt die innere Qualität einer Anwendung. Dazu gehören beispielsweise die Leistungseffizienz, eine angemessene Testabdeckung, Sicherheitsmerkmale oder die Verfügbarkeit. Aus Sicht der Produkt- oder Projektteams bietet die ISO/IEC 25010 eine Auflistung der Qualitätsmerkmale, über die es sich zumindest Gedanken machen sollte. In welcher Ausprägung die einzelnen Qualitätsmerkmale zu berücksichtigen sind, hängt vom Produkt oder Projekt ab.
Können Sie an einem Beispiel erläutern, welches Problem entstehen kann, wenn man ein Qualitätsmerkmal in der Entwicklung nicht berücksichtigt?
Thomas Rauch: Stellen Sie sich vor, Sie haben eine Anwendung, die minutenlang lädt oder bei der Sie die gewünschten Funktionalitäten nicht finden. Dann können zwar alle Funktionen da sein, aber für den Nutzer ist die Anwendung nur schwer oder gar nicht bedienbar. Oft werden die nicht-funktionalen Anforderungen auch nur unspezifisch definiert. „Die Anwendung muss schnell laden.“ ist ein solches Beispiel. Was bedeutet „schnell“? 0,1 Sekunde? 1 Sekunde? 10 Sekunden? 1 Minute? Hier ist viel Interpretationsspielraum und eine Fehlinterpretation kann die Qualität deutlich verringern. Zudem ist ein Test quasi unmöglich. Eine bessere Formulierung wäre „Die Antwortzeit der Anwendung muss höchstens 1 Sekunde betragen.“. Durch den konkreten Wert ist klar, wie lange die Anwendung laden darf. Ein weiteres, oft vernachlässigtes Qualitätsmerkmal beinhaltet die Fragestellung, ob die definierten Funktionen überhaupt diejenigen sind, die Anwendendene benötigen, um ihre Ziele zu erreichen. Oder ob die Funktionen, obwohl sie prinzipiell richtig sind, so umgesetzt wurden, dass sie die Anwendenden unterstützen können.
Warum werden diese wichtigen Aspekte übersehen und wie muss die Herangehensweise geändert werden, damit eine qualitativ hochwertige Software entwickelt wird?
Thomas Rauch: Im klassischen Projektmanagement wird der Projekterfolg durch das sogenannte „Magische Dreieck“ mit den drei Dimensionen Zeit, Budget und Funktionsumfang definiert. Nach dieser Definition ist ein Projekt erfolgreich und so gesehen qualitativ hochwertig, wenn es in der angestrebten Zeit, mit dem geplanten Budget und vor allem dem festgelegten Funktionsumfang der erstellten Software fertig gestellt wird. Nach dieser Maßgabe ist ein Projekt auch dann erfolgreich, wenn zwar alle drei Dimensionen eingehalten wurden, aber das umgesetzte Projekt zum Beispiel keinen Mehrwert für die Endnutzenden bietet und die Anwendung nicht verwendet oder nicht gekauft wird. Das agile Projektmanagement geht hier einen Schritt weiter und sieht den Funktionsumfang als variabel an. Dabei versucht man nicht den kompletten Funktionsumfang umzusetzen, sondern die wichtigsten Funktionen zuerst. Die Idee dahinter ist, dass man das vorgegebene Budget und die festgelegte Zeit nutzt, um die wichtigsten Funktionalitäten mit hoher Qualität umzusetzen, da die wichtigsten Funktionalitäten gut umgesetzt für den Nutzer wertvoller sind als alle Funktionalitäten mit geringer Qualität.
Ein weiterer Ansatz, der mir persönlich am besten gefällt, positioniert die Qualität im Gebrauch ganz oben, also die Frage, inwieweit das zu erstellende Produkt die Ziele des Anwendenden erreicht und ihm oder ihr einen Mehrwert bietet. Die Qualität des Produkts selbst bildet die zweite Spitze des Dreiecks. Die dritte Ecke wird als „Constraints“ bezeichnet und nimmt alle drei Spitzen der Projektmanagement-Dreiecke auf, also Funktionsumfang, Zeit und Kosten. Dieses Dreieck wurde von Jim Highsmith (2010) entwickelt, um die Bedeutung der Qualität herauszustellen: Denn ein Projekt ist nicht automatisch erfolgreich, nur weil es Zeit und Kosten einhält, und die erstellte Anwendung dabei den kompletten Funktionsumfang besitzt. Gleichzeitig ist es aber wichtig, diese drei Dimensionen zu berücksichtigen, um nicht zu viel Zeit und Budget in eine unverhältnismäßig hohe Qualität der Funktionen zu investieren. Wenn ein Projekt zwar diese drei Dimensionen einhält, aber die entwickelte Anwendung dem Anwendenden keinen Mehrwert liefert oder die innere Produktqualität mangelhaft ist, wird diese Anwendung wohl niemand benutzen.
Wie adressiert msg in ihren Beratungsprojekten diese Herausforderungen?
Thomas Rauch: msg legt großen Wert auf eine qualitätsgetriebene Softwareentwicklung und berücksichtigt von Anfang an Qualitätsmerkmale – in ausreichendem Maß und spezifisch. Im Idealfall beziehen wir daher (potentielle) Anwendende und andere Stakeholder mit ein und befragen sie nach ihren Wünschen und Anforderungen in Bezug auf Qualität. Nur so entsteht ein ganzheitliches Bild und kann eine Anwendung gebaut werden, die den Qualitätsmerkmalen der ISO/IEC 25010 genügt. Wenn im vorhin genannten Beispiel die Anwender früher einbezogen worden wären, hätte man deutlich früher feststellen können, dass die Qualität der Anwendung ungenügend war und wahrscheinlich einen Projektabbruch hätte verhindern können. Viele grundlegende Qualitätsanforderungen haben auch direkten Einfluss auf die Software-Architektur, was noch einmal unterstreicht, dass eine qualitätsgetriebene Vorgehensweise von Beginn an unabdingbar ist.
Was genau leistet dabei msg.TEN?
Thomas Rauch: msg.TEN ist eine Software zur Erfassung von nicht-funktionalen Anforderungen und beinhaltet einen Katalog von nicht-funktionalen Anforderungen, der Struktur der ISO/IEC 25010 entsprechend sortiert und vorformuliert. Zudem gibt es für jede nicht-funktionale Anforderung eine Frage, mit der in einem Workshop mit Anwendern und weiteren Stakeholdern ermittelt werden kann, ob diese nicht-funktionale Anforderung notwendig ist oder nicht. Daraufhin kann man die gewünschte nicht-funktionale Anforderung auswählen und mit produkt- oder projektspezifischen Parametern wie einen konkreten Wert versehen, also z.B. „1 Minute“. Sollte eine nicht-funktionale Anforderung nicht im Katalog enthalten sein, ist es auch möglich, sie zu ergänzen.
Darüber hinaus sind die nicht-funktionalen Anforderungen einer Metrik aus der ISO/IEC 25020 zugeordnet, mit deren Hilfe der Wert der nicht-funktionalen Anforderung beim Testen überprüft werden kann. Außerdem sind für jede nicht-funktionale Anforderung die zugehörigen Testverfahren der ISO/IEC 29119 zugeordnet und ausgeführt. Die ISO/IEC 29119 beschreibt die für die Qualitätsmerkmale der ISO/IEC 25010 spezifischen Testverfahren. Auf Grundlage dieser Zuordnung, nicht-funktionale Anforderungen – Qualitätsmerkmale – Testverfahren kann normgerecht getestet werden.
Zudem können die ausgewählten nicht-funktionalen Anforderungen in ein PDF oder in Jira exportiert werden und an die Stakeholder weitergegeben oder im Rahmen einer agilen Vorgehensweise beispielsweise für User Storys als Jira-Item verwendet werden.
Welche Optionen hat der Kunde, msg.TEN einzusetzen?
Thomas Rauch: Wir selbst setzen in unseren Entwicklungsprojekten msg.TEN ein. Aber es ist natürlich auch möglich , eine Nutzungslizenz zu erwerben. Das bedeutet, der Kunde erhält Nutzername und Passwort und kann msg.TEN über die Cloud von msg nutzen. Oder der Kunde betreibt msg.TEN in seiner eigenen Systemlandschaft. Hierfür stellen wir einen Container bereit, der nur hochgefahren werden muss.
Egal, wie sich der Kunde entscheidet, der Vorteil von msg.TEN ist die schnelle und einfache Erfassung der nicht-funktionalen Anforderungen. Durch die Strukturierung innerhalb der ISO/IEC 25010 ist zudem sichergestellt, dass alle notwendigen Qualitätsmerkmale berücksichtigt werden können.
Interviewpartner
Thomas Rauch ist Product Owner von msg.TEN und übernimmt diese Rolle in Kundenprojekten. Er legt dabei großen Wert auf eine nutzerzentrierte und qualitätsorientierte Erfassung von Anforderungen.
