Stefan Zörner
27.03.2026
Architekturziele mit unterschiedlichen Beteiligten eines Entwicklungsvorhabens abzustimmen, gilt als mühsames Unterfangen. Mit geeignetem Unterstützungsmaterial aus LASR lässt sich diese Aufgabe spielerisch angehen, ohne dabei an methodischer Substanz einzubüßen. Wie das gelingt, zeige ich in diesem Beitrag.
Auf Einstiegsseiten (englisch: Landing Pages) von Softwareprodukten springen euch neben zentralen Features (also funktionalen Eigenschaften) oft qualitative Besonderheiten ins Auge. Die Lösungen präsentieren sich zum Beispiel als effizient bedienbar, sehr zuverlässig oder flexibel anpassbar an eure Bedürfnisse. Beim mobilen Instant Messenger Threema steht Sicherheit ganz oben, wie die entsprechende Landingpage in Abb. 1 zeigt: “Privatsphäre ohne Kompromisse”.
Qualitätsmerkmale sind Eigenschaften, die Softwarelösungen zu einem gewissen Grad haben können oder umgekehrt mitunter vermissen lassen. Und die Qualitätsziele, also die wichtigsten dieser Eigenschaften für eure Software, prägen idealerweise den Entwurf der Lösung. Spätestens bei einem Architektur-Review sind sie als zentraler Teil des Bewertungsmaßstabes Dreh- und Angelpunkt.
Ganz ohne Kompromisse geht es bei der Erreichung der Ziele nicht vonstatten. Qualitätsmerkmale hängen oft voneinander ab. Maßnahmen zur Erhöhung der Sicherheit beispielsweise schmälern häufig die Benutzbarkeit, wie Mehrfaktorauthentifizierung (MFA) oder CAPTCHAs schön verdeutlichen. Wenn ihr als Threema-User eure ID inklusive Schlüsselpaar auf ein neues Smartphone umziehen wollt passiert das nicht von allein. In der Praxis balancieren wir die Ziele im Architekturentwurf eher aus, als das wir sie einfach alle perfekt erreichen.
Und schon bei der Festlegung der Ziele, etwa beim Erarbeiten des Bewertungsfokus im Rahmen eines Reviews, kommt es zu Diskussionen. Unterschiedlichen Beteiligten in einem Softwareentwicklungsvorhaben sind unterschiedliche Dinge wichtig.
LASR, der Lightweight Approach for Software-Reviews, trägt dem direkt Rechnung. Bei diesem Ansatz bewertet ein kleines Team von 3-5 Leuten in kurzer Zeit die eigene Softwarelösung. Mehr zur Methode als Ganzes findet ihr auf der LASR-Homepage. Mit diesem Beitrag möchte ich den Fokus auf den zweiten LASR-Schritt legen: Das Erarbeiten des Bewertungsmaßstabes mit den wichtigsten drei bis maximal fünf Qualitätszielen.
LASR sieht dafür einen spielerischen Mechanismus vor, der die Beteiligten zum Austausch untereinander über die wichtigsten Eigenschaften einlädt und in kurzer Zeit ein Ergebnis liefert. Hier direkt die Regeln dazu:
Ziel ist die Ermittlung der wichtigsten Qualitätsziele (auch: Architekturziele) eines Softwaresystems. Besonders gut funktioniert das in einer kleinen Gruppe (max. 5-6 Personen).
Material:
Vorbereitung:
Beispiel:
Einen “Challenger” nominieren
Beispiel nach 2 Runden:
Spielende
Wenn kein Mitglied der Gruppe einen Kandidaten mehr als Challenger auswählen möchte, endet diese Phase.
Wenn ihr Top-5-Challenger bei euch im Team einmal ausprobieren wollt: Die Karten erhaltet ihr in digitaler Form kostenlos über die LASR-Community in Deutsch, Englisch und Französisch. Als Formate stehen PNG für digitale Whiteboards wie Miro oder Mural und PDF zum selber Ausdrucken bereit. Wenn ihr professionell produzierte Spielkarten bevorzugt: Das LASR-Kartendeck mit Material für alle Review-Schritte verkaufen wir hier: LASR-Kartenset bestellen.
In der Praxis hat es sich bewährt, während der Diskussionen im Top-5-Challenger Notizen zu den Argumenten zu machen. Warum hat es ein Merkmal in die Ziele geschafft? Wieso konnte ein anderes seinen Platz behaupten? Wenn ihr mit physischen Karten spielt, schreibt ihr die Ziele am einfachsten auf Post-its und klebt sie direkt auf die Karten. Bei einem Top-5-Challenger auf einem digitalen Whiteboard ist es noch einfacher – Post-its für Notizen sind für alle Beteiligten nur einen Klick entfernt.
Die Top-3 bis maximal 5 Ziele sind Teil des Ergebnisses des zweiten Schrittes im LASR-Ansatz (“Bewertungsmaßstab”). Zuvor in Schritt 1 erarbeitet die Gruppe ein schlankes Mission Statement mit der Landingpage-Metapher. Landeseiten hatte ich bereits am Anfang dieses Beitrages als Motivation benutzt. In einem LASR-Workshop erarbeitet das Team Inhalte einer solchen imaginären Startseite. Leitfrage: Was sollte da auf jeden Fall draufstehen? Der Schritt bereitet insbesondere den in diesem Beitrag vorgestellten zweiten Schritt vor; die Gruppe hat ein gemeinsames Verständnis von der Aufgabenstellung.
Die Qualitätsziele bilden dann die Achsen der Spinnennetzgraphik, die am Ende des Reviews als Visualisierung des Ergebnisses dient. Hierzu wird am Ende des zweiten Schrittes noch der Ziellevel pro Qualitätsmerkmal abgeschätzt, so bildet sich die sogenannte Ziellinie. Details zum Ablauf findet ihr auf der LASR-Webseite (Schritte).
Ein Test, den ich gerne am Spielende von Top-5-Challenger mit dem Ergebnis mache, ist wie “bunt” die 3-5 Karten sind. Es ist euch vermutlich schon aufgefallen: Die Karten haben drei Farben. Sie spiegeln einen wichtigen Aspekt des Qualitätsmodells wider, die sogenannten Stakeholder-Perspektiven. Schauen wir das Modell etwas genauer an!
Die Spielkarten zeigen insgesamt 14 Qualitätsmerkmale aus drei Perspektiven. Hierbei handelt es sich um die unterschiedlichen Blickwinkel von Stakeholdern in Softwareentwicklungsvorhaben – also Interessierten am System. Menschen, welche die Software bauen oder betreiben, sind andere Dinge wichtig als jenen, welche sie direkt benutzen. Eine wiederum noch andere Perspektive nimmt das Unternehmen oder die Organisation ein, welche die Software baut oder verantwortet.
Die Zuordnung der Merkmale zu den drei Perspektiven ist eine Tendenz und nicht ganz trennscharf. Bei Sicherheit wollten wir uns trotzdem nicht festlegen. Das Wahren der Privatsphäre ist für Endanwenderinnen und -anwender interessant. Dass es nicht zu unschönen Vorkommnissen in diesem Bereich und damit zu Image-Schäden und/oder Strafzahlungen kommt ist eher für die Organisation spannend, welche die Software betreibt. Sicherheit ist das einzige Merkmal, das wir zwei Perspektiven zugeordnet haben.
Beim Top-5 Challenger können die Team-Mitglieder durch die unterschiedlichen Farben auf einen Blick sehen, welche Perspektiven das Ergebnis abdeckt. Und wenn beispielsweise nur grüne Karten aus der Umsetzungsperspektive in der Top-5 sind, sollte sich die Gruppe überlegen, ob das wirklich so passt. Oder ob nicht doch noch z.B. Aspekte aus der Nutzungsperspektive mit hineinspielen.
Kennern der Materie ist vielleicht aufgefallen, dass es in LASR mehr Merkmale sind, als die oberste Ebene der passenden ISO/IEC-Norm 25010 (“Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model”) vorgibt. Dort gibt es “nur” 9 Hauptmerkmale, die dann aber jeweils Untermerkmale besitzen. Erlernbarkeit steckt beispielsweise unterhalb von Benutzbarkeit, das Ganze ist ein Baum mit 9 Ästen und recht vielen Blättern.
In den Qualitätsmerkmalen von LASR finden sich die 9 Hauptäste leicht abgewandelt wieder. Wir haben aber auch Punkte aufgenommen, die sich in der Praxis beim Erheben von Qualitäts- oder Architekturzielen (die Begriffe verwende ich gerne synonym) in Workshops Teilnehmende regelmäßig wünschen, die aber nicht zu den 9 Oberbegriffen in der ISO 25010 zählen. Mein Lieblingsbeispiel hieraus ist Kosteneffizienz, was Leute aus dem Management häufig als Treiber für ein Entwicklungsvorhaben ansehen. Und das oft in Wechselwirkung zu Qualitätsmerkmalen steht. Schöne Dinge kosten Geld. Und da ist das natürlich prima, diesen Aspekt mit in den Abwägungen zu haben.
Auf den Spielkarten sind pointierte Beschreibungen für die Merkmale in Form von Fragen formuliert. Bei Kompatibilität ist es beispielsweise “Ist die Software konform zu Standards, arbeitet sie gut mit anderen zusammen?”. Das hat sich als sehr praktikabel in Workshops herausgestellt, wo die Teilnehmenden die Karten in die Hand nehmen und überlegen, ob dieser Aspekt eine Rolle für das betrachtete Softwarevorhaben spielt. Ebenso dienen die jeweils drei Untermerkmale auf den Karten, die das Merkmal etwas spezifischer beschreiben, im Top-5-Challenger ebenfalls als Ideengeber für Argumente. Bei Benutzbarkeit sind das beispielsweise Bedienbarkeit, Erlernbarkeit und Barrierefreiheit (siehe Abb. 9 links).
Allerdings enthalten die Karten für die Untermerkmale keine Erläuterung, was in Workshops mitunter zu Diskussionen führt. Wir haben dem Rechnung getragen, in dem wir auf der LASR-Seite Beschreibungen für die Untermerkmale veröffentlicht haben (siehe Abb. 10). Diese sind im gleichen Schema wie bei den Hauptmerkmalen als Fragen formuliert. Weiterhin enthalten sie jeweils zum Untermerkmal passend ein paar Schlagworte. Das können verwandte Konzepte, ausgewählte Lösungsansätze oder auch aktuelle Trend-Themen oder Buzzwords dazu sein. Sie erheben keinen Anspruch auf Vollständigkeit. Wenn euch wichtige Begriffe fehlen oder ihr welche unpassend findet, lasst es uns gerne wissen!
Wenn ihr das Qualitätsmodell mit den Erläuterungen im Detail anschauen wollt: Einfach unten auf den Button klicken! Die Seite hat eine schöne Navigation (siehe Abb. 11), strukturiert nach den drei Stakeholder-Perspektiven, die Beschreibungen sind auf Deutsch und Englisch verfügbar.