← Ultimi articoli
💻 computer science

GitReq: A Gold Standard Dataset for Software Quality Requirements

Questo articolo introduce GitReq, un dataset pubblicamente disponibile di 6.302 issue di GitHub validate da esperti e categorizzate in otto requisiti di qualità del software allineati alla norma ISO/IEC 25010:2011, che funge da standard di riferimento per far avanzare la classificazione automatizzata dei requisiti e l'analisi della qualità del software.

Autori originali: Farha Kamal, Md Humaun Kabir, Md Rakibul Islam

Pubblicato 2026-06-23
📖 5 min di lettura🧠 Approfondimento

Autori originali: Farha Kamal, Md Humaun Kabir, Md Rakibul Islam

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di entrare in una biblioteca enorme e caotica dove milioni di persone hanno lasciato dei post-it sugli scaffali. Questi biglietti non sono semplici lamentele casuali; sono gli sviluppatori del software mondiale che sussurrano (o urlano) su come le loro creazioni dovrebbero funzionare meglio. Alcuni dicono: "Questa app è troppo lenta!" (Performance). Altri dicono: "Abbiamo bisogno di una serratura migliore sulla porta!" (Security). Altri ancora dicono: "Dovrebbe funzionare anche sul mio vecchio telefono!" (Portability).

Il problema è che questi biglietti sono un disastro. Sono mescolati insieme, scritti in gergo e sepolti sotto milioni di altri biglietti riguardanti bug, domande o richieste di nuove funzionalità. Fino ad ora, nessuno aveva organizzato questi specifici biglietti sulla "qualità" in una collezione ordinata e etichettata che i ricercatori potessero studiare.

Entra in scena GitReq: Il Grande Bibliotecario.

Gli autori di questo articolo hanno costruito GitReq, un dataset "Gold Standard". Immaginalo come un archivio meticolosamente organizzato di 6.302 di questi biglietti degli sviluppatori, estratti da oltre 4.000 diversi progetti software su GitHub.

Ecco come l'hanno fatto, suddiviso in semplici passaggi:

1. La Caccia al Tesoro (Mining)

Il team non ha semplicemente raccolto biglietti a caso. Hanno utilizzato una strategia a "tre segnali" per trovare quelli giusti. Immagina di cercare un tipo specifico di pesce in uno stagno:

  • Segnale 1: Hanno cercato il "flag" giusto (un'etichetta che lo sviluppatore ha già inserito sul biglietto, come "Security").
  • Segnale 2: Hanno controllato se il biglietto fosse effettivamente una richiesta di qualcosa di nuovo (etichette come "Feature Request" o "Enhancement"), ignorando i biglietti che erano solo segnalazioni di bug o domande.
  • Segnale 3: Hanno scansionato il testo alla ricerca di parole chiave specifiche (come "lento", "hack" o "crash").

Sono partiti da 55.588 potenziali biglietti. È una montagna di carta enorme!

2. La Macchina di Smistamento (Preprocessing)

Prima che gli umani potessero leggerli, il team ha costruito due diverse "macchine di smistamento" perché i biglietti provenivano da due tipologie molto diverse:

  • La macchina "NFR" (Requisiti Non Funzionali): Questi sono biglietti su come il sistema si comporta (velocità, sicurezza, affidabilità). Questi biglietti sono spesso brevi, disordinati e pieni di gergo (es. "Il server crasha quando 100 persone effettuano il login"). La macchina ha pulito il rumore ma ha mantenuto il linguaggio reale e disordinato.
  • La macchina "FR" (Requisiti Funzionali): Questi riguardano cosa il sistema deve fare (es. "Il sistema deve consentire agli utenti di salvare i file"). Questi devono essere molto specifici. La macchina è stata rigorosa: se il biglietto non suonava come una regola formale (usando parole come "deve", "dovrebbe" o "user story"), veniva scartato. Ciò ha garantito di non includere accidentalmente idee di funzionalità vaghe.

3. Il Panel di Esperti (Annotazione Umana)

Dopo che le macchine hanno fatto il loro lavoro, rimanevano ancora circa 8.500 biglietti. È qui che è avvenuta la magia umana.

  • I Giudici: Sette esperti di ingegneria del software si sono seduti per leggere questi biglietti.
  • L'Addestramento: Hanno trascorso ore imparando le regole, utilizzando una guida standard chiamata ISO/IEC 25010. Immaginala come un libro di regole che definisce esattamente cosa significa "Security" rispetto a "Scalability".
  • Il Verdetto: Hanno etichettato ogni biglietto in una delle otto categorie: Performance, Security, Portability, Availability, Fault-tolerance, Scalability, Maintainability e Functional.
  • L'Accordo: Non hanno solo tirato a indovinare. Hanno confrontato il proprio lavoro con quello degli altri. Quando erano in disaccordo, ne discutevano finché non raggiungevano un accordo. Il risultato è stato un livello di accordo molto alto (un punteggio di 0,72), il che significa che le etichette sono affidabili.

4. La Collezione Finale

Dagli oltre 55.000 candidati originali, sono finiti a 6.302 biglietti di alta qualità e verificati dagli esperti.

  • Il Mix: Circa la metà riguarda la Security e la Performance (le preoccupazioni più comuni).
  • La Varietà: Coprono tutto, dai framework web alle app mobili e ai sistemi cloud.
  • La Prova: Hanno persino testato questo nuovo dataset contro quattro potenti modelli di IA (come GPT-5.2). I modelli di IA hanno faticato un po', specialmente con categorie difficili come "Maintainability", dimostrando che questo dataset è un test duro e realistico per le future applicazioni di IA.

Perché questo è importante?

Prima di questo, i ricercatori che cercavano di insegnare ai computer a comprendere la qualità del software dovevano usare dataset minuscoli e obsoleti o documenti formali che non somigliavano alla vita reale. Era come cercare di imparare a guidare un'auto leggendo solo un manuale scritto nel 1990.

GitReq è come dare ai ricercatori un nuovissimo simulatore di guida del mondo reale. Permette loro di costruire strumenti di IA migliori che possano effettivamente comprendere le conversazioni disordinate che gli sviluppatori hanno ogni giorno, aiutando a individuare i problemi di qualità più velocemente e con maggiore precisione.

In breve: Questo articolo non ha solo trovato un ago in un pagliaio; ha costruito un intero nuovo archivio di aghi, li ha smistati per tipo e ha dato al mondo una mappa per trovarli.

Sommerso dagli articoli nel tuo campo?

Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.

Prova Digest →