Che cos’è, a cosa serve e problemi della tracciabilità dei requisiti

Che cos’è, a cosa serve e problemi della tracciabilità dei requisiti

La tracciabilità dei requisiti

La tracciabilità dei requisiti si pone nell’ottica di assicurare che il prodotto software soddisfi le aspettative del cliente che lo ha commissionato. Questo, in particolare, conduce ad un lavoro metodico congiunto tra fornitore e committente, nel quale è possibile dimostrare progressivamente che gli sviluppatori hanno compreso i requisiti, come ogni requisito è stato soddisfatto e viceversa come ogni componente del sistema soddisfa un requisiti, e infine che il prodotto non ha bisogno di caratteristiche non necessarie.

La tracciabilità dovrebbe inoltre dimostrare come si è giunti a questi requisiti corretti: si dovrebbero identificare non solo le decisioni che hanno portato ad essi, ma indicare anche le assunzioni e le motivazioni a supporto o a confutazione dietro tali decisioni, esplicitando il contesto nel quale sono state prese. Così facendo si facilita la comunicazione tra coloro che sono coinvolti nel progetto e di conseguenza l’intera gestione dei requisiti.

Che cos'è, a cosa serve e problemi della tracciabilità dei requisiti

Mediante le informazioni raccolte, i progettisti possono determinare facilmente gli effetti di cambiamenti prima di progettare il sistema, riuscendo così a formulare un’idea su eventuali costi da sostenere e a programmare le attività successive. Inoltre, le informazioni di tracciabilità possono essere usate da coloro che sviluppano ed eseguono i test per determinare quali di questi effettuare e per modificarli correttamente nel caso siano individuati degli errori.

Esistono tre tipi di tracciabilità delle informazioni:

  1. Tracciabilità della sorgente: definisce i collegamenti tra i requisiti, il loro fondamento logico e gli stakeholder che li hanno indicati. Queste informazioni saranno poi utilizzate per trovare e consultare gli stakeholder riguardo a specifici cambiamenti proposti;
  2. Tracciabilità dei requisiti: definisce i collegamenti tra i requisiti dipendenti all’interno del documento. Queste informazioni saranno poi utilizzate per valutare quanti e quali requisiti sarebbero influenzati da un cambiamento proposto e quindi quale sarebbe l’estensione delle conseguenti modifiche che potrebbero essere necessarie;
  3. Tracciabilità del progetto: definisce i collegamenti tra i requisiti e i moduli del progetto in cui sono implementati. Queste informazioni sono utilizzate per valutare l’impatto delle modifiche proposte sul progetto e sull’implementazione.

Il problema della tracciabilità

Il problema della tracciabilità resta, tuttora, una questione aperta. Difatti, nonostante il continuo aumento della diffusione di tool che presentano funzionali di tracciabilità, il loro utilizzo pratico non è tanto diffuso quanto l’importanza della tracciabilità richiederebbe. Inoltre questa tipologia di problematica sussiste anche laddove viene utilizzata la tracciabilità.
Nel corso degli anni è stato dimostrato, tramite degli studi, che il problema della tracciabilità non è percepito come uniforme, principalmente a causa della diversità delle definizioni.

Le definizioni di tracciabilità dei requisiti, utilizzate dagli sviluppatori e dalla letteratura, si possono classificare come:

  • Porpose – driven: definite in termini di cosa dovrebbe fare (come l‘abilità di aderire alla posizione di business, alla portata del progetto e ai requisiti chiave che sono stati sottoscritti);
  • Solution – driven: definite in termini di come dovrebbe farlo (come l’abilità di avere delle tracce da un’entità a un’altra basandosi su relazioni semantiche date);
  • Information – driven: enfatizza le informazioni di tracciabilità (come l’abilità di collegare insieme funzioni, dati e requisiti alle formulazioni testuali che vi si riferiscono);
  • Direction – driven: enfatizza la direzione della tracciabilità (come l’abilità di collegare uno specifico item all’inizio di una fase del ciclo di vita software ad un altro alla fine della stessa fase).

È possibile notare come le definizioni siano tutte differenti tra loto, infatti, nessuna riesce a coprire tutti gli aspetti. Tutto questo si ripercuote sull’utilizzo dei tool software a supporto della tracciabilità, poiché diventa difficile implementarla in modo coerente e consistente, proprio perché ogni individuo può presentare una concezione differente del termine tracciabilità.

Tracciabilità Pre-RS e Post-RS

È possibile distinguere due fasi della tracciabilità:

  1. Pre-Requirements Specification Traceability: che fa riferimento a tutti gli aspetti della vita di un requisito precedentemente alla sua inclusione nella specifica. Si considerano, quindi, i collegamenti ad un livello ancora alto di astrazione.
  2. Post-Requirements Specification Traceability: che si riferisce a tutti gli aspetti della vita di un requisito successivamente alla sua inclusione nella specifica. In questo caso si considerano i collegamenti ad un livello di maggior dettaglio.

Le principali differenze tra questi due tipi di tracciabilità coinvolgono le informazioni con cui hanno a che fare e i problemi che possono affrontare.
La tracciabilità Post-RS dipende dall’abilità di tracciare i requisiti da e verso la loro specifica, attraverso una successione di artefatti nei quali essi sono distribuiti. I cambiamenti alla specifica dei requisiti devono essere propagati attraverso questa catena. La tracciabilità Pre-RS, invece, dipende dall’abilità di tracciare i requisiti da e verso la loro formulazione originaria, attraverso il processo di produzione e raffinamento dei requisiti, nelle quali le formulazioni provenienti da diverse sorgenti sono prima o poi integrate in singoli requisiti all’interno della specifica.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *