User Reviews as a Source for Usability Requirements: A Precursor Study on Using Large Language Models

Technisches Fazit: Nutzerbewertungen als Quelle für Usability-Anforderungen unter Verwendung von Large Language Models

Problemstellung
Moderne Softwareprodukte sehen sich einer zunehmenden funktionalen Komplexität gegenüber, die erhebliche Usability-Herausforderungen mit sich bringt. Zwar ist bekannt, dass nutzerzentrierte Requirements Engineering (RE) die Produktsuitability verbessert, doch die direkte Einbeziehung von Nutzern ist ressourcenintensiv und für Entwicklungsteams oft nicht durchführbar. Crowd-basiertes Requirements Engineering (CrowdRE) versucht, diese Lücke zu schließen, indem es öffentliches Nutzerfeedback (z. B. App-Store-Bewertungen) nutzt. Allerdings verlassen sich bestehende Ansätze zur Klassifizierung von Usability-Aspekten aus diesem Feedback stark auf Machine Learning (ML) oder Deep Learning (DL). Diese traditionellen Methoden erfordern umfangreiche, manuell gelabelte Trainingsdatensätze, was einen Engpass für schnelle Entwicklungszyklen darstellt. Darüber hinaus kämpfen Standard-ML-Modelle häufig mit kontextuellen Nuancen und informeller Sprache (z. B. Emojis, Idiome), die in Nutzerbewertungen üblich sind, und verlassen sich typischerweise auf einfache Keyword-Matching-Verfahren. Es besteht eine kritische Forschungslücke in der Kombination des fortschrittlichen natürlichen Sprachverständnisses von Large Language Models (LLMs) mit nutzerzentrierten Methoden des CrowdRE, um Usability-Anforderungen ohne den Bedarf an intensiven, aufgaben spezifischen Trainings zu extrahieren.

Methodik
Die Studie untersucht, ob ein speziell promptierter LLM (OpenAI's gpt-4.1) nutzerrelevante Bewertungen effektiv identifizieren kann, die mit menschlichen Bewertern vergleichbar sind. Die Forschung ist um zwei Forschungsfragen (RQs) strukturiert:

1. Ist die Leistung eines maßgeschneiderten LLMs beim Identifizieren von Usability-bezogenen Bewertungen mit der menschlicher Kodierer vergleichbar?
2. Wie zuverlässig ist der LLM beim Identifizieren dieser Bewertungen innerhalb eines zufälligen Datensatzes?

Datenerhebung und -aufbereitung:

• Datensatz: Ein Datensatz von 300 Nutzerbewertungen wurde aus dem Google Play Store gesammelt und gleichmäßig auf drei verschiedene Anwendungstypen verteilt, um Vielfalt zu gewährleisten: BlitzerDE (Karten/Navigation), Lidl Plus (E-Commerce) und FL Studio (Musikkomposition).
• Menschliche Labeling (Ground Truth): Zwei erfahrene Bewerter labelten den Datensatz basierend auf den 10 Nielsen Usability-Heuristiken. Bewertungen wurden als „wahr" (usability-relevant) kodiert, wenn sie mindestens eine Aussage enthielten, die sich auf eine Heuristik bezog, andernfalls als „falsch".
  • Ausschlüsse: Feature-Anfragen, sich überschneidende nicht-funktionale Anforderungen (z. B. Barrierefreiheit, Kompatibilität), vage Aussagen, Bug-Reports und Probleme, die aus externen Kontexten (z. B. Betriebssystem oder Hardware) resultieren, wurden ausgeschlossen.
  • Prozess: Ein iterativer Kodierungsprozess wurde angewendet. Eine Vorkodierungsrunde bei 20 Bewertungen identifizierte Unklarheiten in den Richtlinien, was zu einer verbesserten Kodierungsrichtlinie führte. Eine zweite Runde deckte die gesamten 300 Bewertungen ab. Die Inter-Rater-Reliabilität wurde unter Verwendung von Cohens Kappa ($\kappa$) berechnet und zeigte eine substantielle Übereinstimmung über alle drei Apps hinweg ($\kappa$ im Bereich von 0,61 bis 0,76).
• LLM-Prompt-Engineering: Ein initialer Prompt wurde basierend auf den verbesserten Kodierungsrichtlinien unter Verwendung von Chain-of-Thought-Prompting entwickelt, um den LLM über Zwischenschritte des reasoning zu instruieren. Der Prompt wurde durch drei Iterationen unter Verwendung einer Teststichprobe von 30 Bewertungen (10 pro App) verfeinert. Die Autoren vermieden Few-Shot-Prompting explizit, um Overfitting zu verhindern, und verfeinerten stattdessen die Anweisungen und Ziele innerhalb des Prompts.

Hauptbeiträge
Die Arbeit liefert drei primäre Beiträge:

1. Ein kodierter Datensatz: Ein vollständig gelabelter Datensatz von 300 Nutzerbewertungen aus drei diversen App-Kategorien, gelabelt von zwei menschlichen Bewertern und einem LLM, verfügbar im ergänzenden Material.
2. Prompt-Engineering-Framework: Ein initialer Prompt und Kodierungsrichtlinien, die spezifisch aus den 10 Nielsen Usability-Heuristiken abgeleitet wurden, um usability-relevante Bewertungen zu filtern, entwickelt durch iterative Verfeinerung.
3. Leistungsanalyse: Eine empirische Bestimmung der Fähigkeit des LLM, Usability als nicht-funktionale Anforderung im Vergleich zur menschlichen Leistung zu erkennen.

Ergebnisse

• Menschliche Basislinie: Die beiden menschlichen Bewerter identifizierten 148 (49,3 %) der 300 Bewertungen als usability-relevant. Die Inter-Rater-Reliabilität war substantiell ($\kappa$ 0,61–0,76).
• LLM-Leistung (Metriken): Unter Verwendung des finalen optimierten Prompts identifizierte der LLM 173 (58 %) Bewertungen als usability-relevant.
  • Precision/Recall: Der LLM zeigte eine hohe Recall (0,84–0,93 über die Apps hinweg), aber eine etwas niedrigere Precision (0,73–0,79), was darauf hindeutet, dass er toleranter ist als menschliche Bewerter (mehr potenzielle Usability-Probleme identifiziert, von denen einige von Menschen abgelehnt wurden).
  • F-Score: Der LLM erreichte F1-Scores zwischen 0,78 und 0,82 über die verschiedenen Apps hinweg.
• Zuverlässigkeit (Inter-Rater-Übereinstimmung): Beim Vergleich der Labels des LLMs mit dem finalen menschlichen Konsens:
  • BlitzerDE: Geringe Übereinstimmung ($\kappa = 0,34$).
  • Lidl Plus: Moderate Übereinstimmung ($\kappa = 0,55$).
  • FL Studio: Substantielle Übereinstimmung ($\kappa = 0,63$).
• Statistische Signifikanz: Ein Chi-Quadrat-Test zur Korrelation zwischen der Gewissheit der Bewerter und der Richtigkeit des LLMs ergab einen p-Wert von 0,35, was auf keine statistisch signifikante Korrelation hindeutet. Der LLM reproduziert das menschliche mentale Modell nicht zuverlässig und macht Fehler an anderen, unerwarteten Stellen.

Bedeutung und Behauptungen
Die Arbeit kommt zu dem Schluss, dass LLMs zwar aufgrund geringerer Zuverlässigkeit und Übereinstimmungsniveaus noch keine perfekten Ersatz für menschliche Bewerter sind, aber eine machbare und ressourceneffiziente Option für das Requirements Engineering darstellen.

• Kompromiss: Die Autoren argumentieren, dass der Ressourcen-Overhead für das Training traditioneller ML/DL-Modelle für die meisten Teams unpraktisch ist. Im Gegensatz dazu erzielen LLMs mit deutlich geringerem Overhead akzeptable Ergebnisse.
• Toleranz: Die Tendenz des LLMs, etwas toleranter zu sein (höherer Recall), wird als praktischer Vorteil betrachtet; in einem realen Szenario ist das Sammeln einer begrenzten Menge irrelevanter Bewertungen vorzuziehen, als relevante Usability-Anforderungen zu verpassen.
• Zukünftige Richtung: Die Studie dient als Vorläufer und legt nahe, dass weitere Forschung sich auf ausgefeiltes Prompt-Engineering (z. B. Few-Shot-Prompting) und den Vergleich optimierter LLMs mit traditionellen ML/DL-Ansätzen konzentrieren sollte, um die optimale Technologie für spezifische CrowdRE-Aufgaben zu bestimmen. Die Autoren betonen, dass der Erfolg des Ansatzes stark von der Qualität des maßgeschneiderten Prompts abhängt.