← Neueste Arbeiten
💻 computer science

GitReq: A Gold Standard Dataset for Software Quality Requirements

Dieses Paper stellt GitReq vor, einen öffentlich verfügbaren Datensatz aus 6.302 Experten validierten GitHub-Issues, die in acht gemäß ISO/IEC 25010:2011 ausgerichteten Softwarequalitätsanforderungen kategorisiert sind, welcher als Goldstandard zur Förderung der automatisierten Anforderungsklassifizierung und Softwarequalitätsanalyse dient.

Ursprüngliche Autoren: Farha Kamal, Md Humaun Kabir, Md Rakibul Islam

Veröffentlicht 2026-06-23
📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

Ursprüngliche Autoren: Farha Kamal, Md Humaun Kabir, Md Rakibul Islam

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie betreten eine riesige, chaotische Bibliothek, in der Millionen von Menschen Haftnotizen in die Regale geklebt haben. Diese Notizen sind nicht einfach nur zufällige Beschwerden; sie sind die Entwickler der weltweiten Software, die flüstern (oder schreien), wie ihre Kreationen besser funktionieren sollten. Einige sagen: „Diese App ist zu langsam!“ (Performance). Andere sagen: „Wir brauchen ein besseres Schloss an der Tür!“ (Security). Wieder andere sagen: „Es sollte auch auf meinem alten Telefon funktionieren!“ (Portability).

Das Problem ist, dass diese Notizen ein Chaos sind. Sie sind vermischt, in Slang geschrieben und unter Millionen anderer Notizen über Bugs, Fragen und Feature-Anfragen vergraben. Bis jetzt hatte niemand diese spezifischen „Qualitäts“-Notizen in einer ordentlichen, beschrifteten Sammlung organisiert, die Forscher untersuchen konnten.

Hier kommt GitReq ins Spiel: Der Große Bibliothekar.

Die Autoren dieser Arbeit haben GitReq erschaffen, einen „Goldstandard“-Datensatz. Stellen Sie sich das wie ein akribisch organisiertes Archiv aus 6.302 dieser Entwicklernotizen vor, die aus über 4.000 verschiedenen Softwareprojekten auf GitHub stammen.

So haben sie es gemacht, unterteilt in einfache Schritte:

1. Die Schatzsuche (Mining)

Das Team hat nicht einfach wahllos Notizen gesammelt. Sie nutzten eine „Drei-Signale-Strategie“, um die richtigen zu finden. Stellen Sie sich vor, Sie suchen nach einer bestimmten Fischart in einem Teich:

  • Signal 1: Sie suchten nach der richtigen „Flagge“ (ein Label, das der Entwickler bereits auf die Notiz gesetzt hatte, wie zum Beispiel „Security“).
  • Signal 2: Sie prüften, ob die Notiz tatsächlich eine Anfrage für etwas Neues war (Labels wie „Feature Request“ oder „Enhancement“) und ignorierten Notizen, die lediglich Bug-Berichte oder Fragen waren.
  • Signal 3: Sie scannten den Text nach spezifischen Schlüsselwörtern (wie „slow“, „hack“ oder „crash“).

Sie starteten mit 55.588 potenziellen Notizen. Das ist ein riesiger Papierstapel!

2. Die Sortiermaschine (Preprocessing)

Bevor die Menschen sie lesen konnten, baute das Team zwei verschiedene „Sortiermaschinen“, da die Notizen in zwei sehr unterschiedlichen Geschmacksrichtungen vorlagen:

  • Die „NFR“-Maschine (Non-Functional Requirements): Dies sind Notizen darüber, wie sich das System verhält (Geschwindigkeit, Sicherheit, Zuverlässigkeit). Diese Notizen sind oft kurz, unordentlich und voller Slang (z. B. „Server stürzt ab, wenn 100 Leute einloggen“). Die Maschine bereinigte das Rauschen, behielt aber die unordentliche, reale Sprache bei.
  • Die „FR“-Maschine (Functional Requirements): Dies sind Notizen darüber, was das System tun soll (z. B. „Das System muss es dem Benutzer ermöglichen, Dateien zu speichern“). Diese müssen sehr spezifisch sein. Die Maschine war streng: Wenn die Notiz nicht wie eine formale Regel klang (unter Verwendung von Wörtern wie „muss“, „soll“ oder „User Story“), wurde sie aussortiert. Dies stellte sicher, dass sie nicht versehentlich vage Feature-Ideen aufnahmen.

3. Das Expertengremium (Human Annotation)

Nachdem die Maschinen ihre Arbeit getan hatten, blieben noch etwa 8.500 Notizen übrig. Hier geschah die menschliche Magie.

  • Die Richter: Sieben Experten für Software Engineering setzten sich hin, um diese Notizen zu lesen.
  • Das Training: Sie verbrachten Stunden damit, die Regeln zu erlernen, und nutzten dabei einen Standardleitfaden namens ISO/IEC 25010. Betrachten Sie dies als ein Regelwerk, das genau definiert, was „Security“ im Gegensatz zu „Scalability“ bedeutet.
  • Das Urteil: Sie etikettierten jede Notiz in eine von acht Kategorien: Performance, Security, Portability, Availability, Fault-tolerance, Scalability, Maintainability und Functional.
  • Die Übereinstimmung: Sie raten nicht einfach. Sie überprüften ihre Arbeit gegeneinander. Wenn sie uneins waren, diskutierten sie so lange, bis sie sich einig waren. Das Ergebnis war ein sehr hohes Maß an Übereinstimmung (ein Score von 0,72), was bedeutet, dass die Labels vertrauenswürdig sind.

4. Die finale Sammlung

Aus den ursprünglichen über 55.000 Kandidaten blieben 6.302 hochwertige, von Experten verifizierte Notizen übrig.

  • Die Mischung: Etwa die Hälfte handelt von Security und Performance (die häufigsten Sorgen).
  • Die Vielfalt: Sie decken alles ab, von Web-Frameworks über Mobile Apps bis hin zu Cloud-Systemen.
  • Der Beweis: Sie testeten diesen neuen Datensatz sogar gegen vier leistungsstarke KI-Modelle (wie GPT-5.2). Die KI-Modelle hatten Schwierigkeiten, insbesondere mit kniffligen Kategorien wie „Maintainability“, was beweist, dass dieser Datensatz ein harter, realistischer Test für zukünftige KI-Werkzeuge ist.

Warum ist das wichtig?

Vorher mussten Forscher, die versuchten, Computern beizubringen, Softwarequalität zu verstehen, winzige, alte Datensätze oder formale Dokumente verwenden, die nicht wie das echte Leben aussahen. Es war, als würde man versuchen, Autofahren zu lernen, indem man nur ein Lehrbuch liest, das aus dem Jahr 1990 stammt.

GitReq ist wie ein brandneuer, realer Fahrsimulator für Forscher. Er ermöglicht es ihnen, bessere KI-Werkzeuge zu bauen, die tatsächlich die unordentlichen, echten Gespräche verstehen können, die Entwickler jeden Tag führen, um so Qualitätsmängel schneller und genauer zu erkennen.

Kurz gesagt: Das Paper hat nicht nur eine Nadel im Heuhaufen gefunden; sie haben eine ganze neue Bibliothek von Nadeln gebaut, sie nach Typ sortiert und der Welt eine Karte gegeben, um sie zu finden.

Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?

Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.

Digest testen →