Qualità dei requisiti software

La qualità dei requisiti è oggetto di discussione tra i professionisti dei requisiti software. Ecco quattro punti di vista considerati sulla qualità dei requisiti software, ovvero ciò che costituisce un buon requisito O un buon insieme di requisiti.

Perché la qualità dei requisiti è importante?

Spesso è utile guardare le cose al contrario. Chiedersi: qual è l'impatto di avere requisiti scadenti? Questo grafico illustra il fatto che vi è un aumento non lineare delle rilavorazioni causato da requisiti scadenti.

Il costo dei requisiti software di scarsa qualità nella generazione di rilavorazioni
Un confronto di requisiti attributi di qualità secondo diverse fonti:

Il nostro punto di vista

Raccomandiamo qualcosa di molto vicino all'IIBA BABOK come segue

  • Chiaro: significato funzionale inequivocabile.
  • Conciso: non contiene contenuti estranei e non necessari.
  • Orientato all'utente: si concentra su ciò che l'utente deve ottenere.
  • Completare: sia completi internamente (tutti i passaggi funzionali all'interno di un requisito) che come insieme, tutti gli eventi CRUD coperti
  • Coerente: i nomi utente e oggetto sono coerenti in tutta una serie di requisiti
  • Misurabile: può essere dimensionato in punti funzione COSMIC
  • Testabile: Se è misurabile, solitamente è anche verificabile.
  • Prezioso : è necessario per fornire funzionalità utente essenziali.
  • Senza design: esclude “come” dovrebbe essere implementato.
  • Unico: nessuna funzionalità duplicata nell'insieme dei requisiti

E la panoramica dell’IIBA sulla qualità dei requisiti afferma quanto segue:

Mentre la qualità è in definitiva determinata dalle esigenze delle parti interessate che utilizzeranno i requisiti o i progetti, i requisiti di qualità accettabili presentano molte delle seguenti caratteristiche”

  • Atomico: autonomo e capace di essere compreso indipendentemente da altri requisiti o progetti.
  • Completare: sufficienti per orientare il lavoro successivo e con il livello di dettaglio appropriato affinché il lavoro possa continuare. Il livello di completezza richiesto varia in base alla prospettiva o alla metodologia, nonché al punto del ciclo di vita in cui il requisito viene esaminato o rappresentato.
  • Coerente: allineato con le esigenze identificate delle parti interessate e non in conflitto con altri requisiti.
  • Conciso: non contiene contenuti estranei e non necessari.
  • Fattibile: ragionevole e possibile entro il rischio, la pianificazione e il budget concordati, o considerato sufficientemente fattibile da poter effettuare ulteriori indagini attraverso esperimenti o prototipi.
  • Inequivocabile: il requisito deve essere chiaramente indicato in modo tale da rendere chiaro se una soluzione soddisfa o meno il bisogno associato.
  • Testabile: in grado di verificare che il requisito o il progetto sia stato soddisfatto. I livelli accettabili di verifica dell'adempimento dipendono dal livello di astrazione del requisito o della progettazione.
  • Priorità: classificato, raggruppato o negoziato in termini di importanza e valore rispetto a tutti gli altri requisiti.
  • Comprensibile: rappresentato utilizzando la terminologia comune del pubblico.

La sezione 4.3 di IEEE Std 830 fornisce un elenco di attributi di qualità desiderati di una specifica software, che sono:

“Un SRS dovrebbe essere:

  1.  Corretto;
  2. Inequivocabile;
  3. Completare;
  4. Coerente;
  5. Classificato per importanza e/o stabilità;
  6. Verificabile
  7.  Modificabile;
  8. Tracciabile."

Caratteristiche dei requisiti testabili Affinché i requisiti possano essere considerati testabili, idealmente dovrebbero avere tutte le seguenti caratteristiche: Panoramica del test basato sui requisiti 8

1. Deterministico: dato uno stato iniziale del sistema e un insieme di input, devi essere in grado di prevedere esattamente quali saranno gli output.

2. Inequivocabile: tutti i membri del progetto devono trarre lo stesso significato dai requisiti; altrimenti sono ambigui.

3. Corretto: le relazioni tra cause ed effetti sono descritte correttamente.

4. Completo: tutti i requisiti sono inclusi. Non ci sono omissioni.

5. Non ridondante: proprio come il modello dati fornisce un insieme di dati non ridondante, i requisiti dovrebbero fornire un insieme non ridondante di funzioni ed eventi.

6. Si presta al controllo del cambiamento: i requisiti, come tutti gli altri risultati finali di un progetto, dovrebbero essere posti sotto il controllo del cambiamento.

7. Tracciabile: i requisiti devono essere tracciabili gli uni dagli altri, dagli obiettivi, dalla progettazione, dai casi di test e dal codice.

8. Leggibile da tutti i membri del team di progetto: le parti interessate del progetto, inclusi utenti, sviluppatori e tester, devono arrivare ciascuno alla stessa comprensione dei requisiti.

9. Scritti in uno stile coerente: i requisiti dovrebbero essere scritti in uno stile coerente per renderli più facili da comprendere.

10. Le regole di trattamento riflettono standard coerenti: le regole di trattamento dovrebbero essere scritte in modo coerente per renderle più facili da comprendere.

11. Esplicito: i requisiti non devono mai essere impliciti.

12. Logicamente coerente: non dovrebbero esserci errori logici nelle relazioni tra cause ed effetti.

13. Si presta alla riutilizzabilità: i buoni requisiti possono essere riutilizzati in progetti futuri.

14. Conciso: i requisiti dovrebbero essere scritti in modo breve, con il minor numero di parole possibile.

15. Annotato per criticità: non tutti i requisiti sono critici. Ciascun requisito dovrebbe indicare il grado di impatto che un difetto avrebbe sulla produzione. In questo modo è possibile determinare la priorità di ciascun requisito e la giusta quantità di enfasi posta sullo sviluppo e sul test di ciascun requisito. Non abbiamo bisogno di zero difetti nella maggior parte dei sistemi. Abbiamo bisogno di test sufficientemente validi.

16. Fattibile: se la progettazione del software non è in grado di soddisfare i requisiti, allora i requisiti non sono fattibili.

Estratto dalla panoramica del processo di test basato sui requisiti

L’acronimo “INVEST” può ricordarti che le buone storie sono:

  • IO – Indipendente
  • N – Negoziabile
  • V - Prezioso
  • E – Stimabile
  • S - Piccolo
  • T – Testabile

Non esiste uno standard unico per ciò che costituisce un requisito software di buona qualità. Inoltre, quello che può essere considerato un buon requisito per software applicativo probabilmente differirà da un bene software di sistema Requisiti.

Attributi di qualità dei requisiti

Garanzia di qualità automatizzata dei requisiti

ScopeMaster verifica i requisiti. Come SonarQube per quanto riguarda i requisiti, ScopeMaster esamina ciascun requisito (o user story) per rilevare l'intento funzionale e valuta ciascun requisito rispetto ai criteri di qualità sopra elencati. Non è in grado di rilevare tutti i guasti, ma ne può trovare circa 50%. Dopo aver analizzato i requisiti individualmente, li esamina nel contesto dell'insieme di requisiti. Ciò fornisce informazioni che semplicemente non sono possibili con strumenti come Jira E Azure DevOps, ScopeMaster interpreta e analizza requisiti, non si limita a memorizzarli. In questo modo avrai più tempo per considerare altri aspetti importanti delle tue esigenze. Rende il tuo lavoro di miglioramento della qualità dei requisiti più veloce e più semplice. Fa il duro lavoro per te.

Requisiti La qualità in sintesi
Verifica i risultati della storia utente di accesso

Nella tabella mostrata le colonne significano:

  1. IL punteggio di qualità del requisito individuale (con qualche considerazione per il contesto) test per oltre 350 parole, frasi e modelli linguistici per chiarezza.
  2. Chiaro e funzionale Contiene dichiarazioni inequivocabili di funzionalità (descrizione dei movimenti di dati).
  3. Orientato all'utente Un utente viene identificato come soggetto all'interno del requisito, eseguendo un'azione con i dati.
  4. Conciso il rapporto tra le parole e la dimensione funzionale, entro limiti ragionevoli
  5. Misurabile e verificabile Se viene rilevato un intento funzionale, allora è misurabile e verificabile, ancora una volta stiamo determinando se c'era un chiaro intento funzionale.
  6. Completo (all'interno del set) indica i tipi di oggetti identificati all'interno di questo requisito che presentano azioni CRUD complementari per garantire una serie completa di attività di manutenzione nell'insieme dei requisiti.
  7. Completo (funzionalità nascosta) funzionalità rilevata nelle note/criteri di accettazione che avrebbero dovuto essere presenti nel requisito stesso.
  8. Benefici È stato fatto uno sforzo per descrivere i vantaggi o il valore di questo requisito.

Punteggio di qualità

ScopeMaster riconosce che i requisiti non esistono da soli. Esso comprende il contesto di un insieme di requisiti e quindi determina i punteggi di qualità a due livelli:

  1. Punteggio di qualità per ciascuno requisito individuale
  2. Punteggio di qualità per a insieme di requisiti

ScopeMaster esegue centinaia di test statici e potenzialmente migliaia di test dinamici su ciascun requisito e fornisce all'autore un feedback immediato. Quindi tu imparare a scrivere requisiti migliori Appena vai.

Punteggio di qualità dei requisiti