Come analizzare, scrivere e rappresentare i requisiti software

L’analisi dei requisiti

Terminata la raccolta dei requisiti, questi dovranno essere sottoposti ad analisi, raffinamenti e valutazione. Difatti, attraverso un’accurata analisi si riesce ad ottenere requisiti di qualità e descritti a un opportuno livello di dettaglio, permettendo così la formulazione diverse possibili soluzioni al problema.

Ci si preoccupa, poi, di stimare i costi, le prestazioni e i rischi legati all’implementazione dei requisiti definiti. Inoltre, nel momento in cui si riscontra esito positivo da parte dell’analisi di fattibilità, sarebbe opportuno chiedere ai committenti di stilare una classifica dei requisiti secondo una scala di priorità.

Giunti a questo punto, gli ingegneri possono passare allo sviluppo dei casi d’uso individuati in precedenza, creando modelli di analisi che consentiranno di esplorare con maggiore precisione le diverse funzionalità che il sistema dovrà offrire, preoccupandosi anche di individuare eventuali errori e/o omissioni nei requisiti.

Al termine di questa fase sarà prodotto il glossario che, così come discusso in precedenza, renderà la terminologia adottata di uso comune sia per il team di progetto che per gli stakeholder.

La specifica dei requisiti

La specifica dei requisiti è quella fase durante la quale si definisce una descrizione formale del sistema software, inteso in termini di prodotto che soddisfi le esigenze esposte dall’utente, operando sotto i vincoli posti dallo specifico dominio applicativo. Al termine di questa fase sarà, quindi, prodotto il documento di specifica dei requisiti software o SRS, che come visto nel capitolo precedente di questa tesi, può essere definito adoperando un linguaggio formale, oppure strutturato.

Tutti i concetti e le idee esposte in precedenza, che specificano come il sistema dovrà comportarsi, in questa fase sono tradotti in concetti concreti che saranno poi comunicati e condivisi sia con il team di progetto che, ovviamente, con il committente.
La specifica dei requisiti assegnerà a ogni requisito un identificativo univoco, in modo da semplificare l’individuazione dell’origine e la gestione della tracciabilità lungo tutto il suo ciclo di vita.

In particolare, ogni requisito può prevedere, oltre all’identificativo e alla descrizione, anche una serie di altri attributi che ne caratterizzano:

• La tipologia, sia essa funzionale o non funzionale;
• Il numero di versione, che permette di tracciare tutti gli aggiornamenti e le modifiche apportate nel tempo;
• La provenienza, intesa in termini di chi ha richiesto il requisito, la data di richiesta e dell’ultima modifica apportata;
• L’importanza secondo il punto di vista del committente: obbligatorio, desiderabile, opzionale;
• La priorità d’implementazione;
• Lo stato in cui si trova: implementato, approvato, verificato o eliminato;
• Il livello di stabilità: duraturi o volatili. Infatti, durante la specifica e lo sviluppo del sistema, le esigenze degli stakeholder potrebbero cambiare.

Uno degli aspetti principali di quest’attività, riguarda la creazione di una matrice di tracciabilità, nella quale saranno riportati tutti i collegamenti tra ogni coppia di requisiti che presentano una relazione molti a molti con altri requisiti, rappresentando così tutte le relazioni nella loro completezza. Essa è solitamente utilizzata per tracciare i collegamenti tra i requisiti di alto livello e i requisiti di dettaglio del prodotto verso le corrispondenti parti del design di alto livello, design di dettaglio, piano di test e casi di test.