Le fasi del processo dell’ingegneria dei requisiti

Le fasi del processo dell’ingegneria dei requisiti

Le fasi del processo dell'ingegneria dei requisiti

Studio di fattibilità

Nell’ingegneria dei requisiti, l’azione da intraprendere prima di stabilire se un nuovo sistema sia sviluppabile è quello di operare uno studio di fattibilità.
Le informazioni preliminari di cui si dovrà disporre saranno, dunque, i requisiti aziendali, una descrizione di massima del sistema che dovrebbe essere sviluppato e un’indicazione di come esso contribuirà al raggiungimento degli obiettivi aziendali.
Lo studio di fattibilità consiste, fondamentalmente, nell’identificare e porre al committente una serie di quesiti in merito all’utilizzo che si vuole fare dello strumento commissionato, dall’impatto positivo che ci si aspetta abbia sull’organizzazione, di quante e quali risorse debbano essere profuse allo scopo.
Ed infatti, non di rado capita che un’organizzazione richieda un sistema che poi non riesca a contribuire ai processi aziendali. Ciò può capitare a causa di requisiti espressi in maniera confusa, oppure perchè vengono interposti ostacoli all’utilizzo proficuo dello strumento.

Dunque, i candidati a rispondere a tali domande dovrebbero essere: i manager dei dipartimenti in cui lo strumento sarebbe adoperato, gli ingegneri del software che mostreranno una certa conoscenza del tipo di sistema commissionato, nonchè gli utenti finali, ovvero tutte persone interessate, competenti e direttamente coinvolte nel progetto proposto.
Seguendo questa strada, l’azione dovrebbe condurre, passando per la raccolta e la valutazione delle risposte fornite, all’output: il report dello studio di fattibilità. Oltre all’esito dello studio, in esso potranno essere proposti cambiamenti negli scopi e nelle risorse allocate, nonchè nuovi spunti (eventuali requisiti di alto livello) su cui lavorare.

Elicitazione ed analisi dei requisiti

Nella prima parte di questo capitolo è stata rivolta particolare attenzione al concetto di obiettivo, come punto focale attorno al quale sviluppare tutta la successiva discussione.
Pertanto, si provi a ritornare su tali concetti per comprendere in che modo gli obiettivi del cliente vadano mano a mano a trasformarsi in un prodotto finito.
Il primo passo da compiere, in tal senso, è certamente l’apertura verso gli obiettivi che debbano essere raggiunti e la valutazione dei vincoli ai quali essi sono sottoposti.
L’attività di elicitazione dei requisiti mira a circoscrivere i confini del sistema da sviluppare. Pertanto, al fine di reperire le informazioni necessarie per la corretta ed esaustiva comprensione del problema al quale fornire la soluzione software, bisognerà innanzitutto identificare gli stakeholder del progetto.
Il ruolo che ciascuno stakeholder riveste in un progetto può essere molto diverso da quello di un altro e ciò proprio in considerazione del fatto che ogni persona, o gruppo, potrà essere influenzato in maniera differente dal sistema.
Di conseguenza, la fase di deduzione e comprensione dei requisiti può rivelarsi particolarmente impegnativa, poichè gli aspetti trattati saranno quelli specifici del dominio di applicazione, con il quale l’ingegnere del software potrebbe non avere familiarità.
Ancora, capita non di rado, che gli stakeholder non riescano ad esprimere in modo chiaro le proprie esigenze, che vi siano conflitti tra i requisiti dichiarati dalle diverse figure, oppure di trovarsi di fronte ad un ambiente dinamico.

Tutti gli aspetti sopraccitati convincono del fatto che, durante questa fase, sia indispendabile avvalersi del supporto dei committenti, con i quali potrebbero nascere incomprensioni dovute all’utilizzo da parte di questi ultimi di linguaggi troppo tecnici e punti di vista, a volte, divergenti.
D’altro canto, confrontarsi con un ambiente dinamico, in cui i requisiti cambiano rapidamente, non consente la definizione precisa del loro numero e delle funzionalità che esprimono.
L’evoluzione, così come una cattiva comunicazione tra l’ingegnere del software ed i committenti, può comportare una revisione nell’espressione e/o nel contenuto di un requisito; dunque, terminato lo studio di fattibilità, le successive fasi possono richiamarsi tra loro durante tutto il processo.
L’obiettivo di questa fase è, infatti, a fronte di una buona comprensione del dominio in cui sarà sviluppato un sistema software, la definizione dei requisiti che esso debba essere in grado di soddisfare.
In primo luogo, una profonda comprensione del dominio in cui il sistema opererà aiuterà anche a calarsi nei diversi scenari che possano verificarsi nell’interazione tra sistema software ed ambiente circostante. Inoltre, una definizione chiara ed inequivocabile dei requisiti è sicuramente decisiva per le successive fasi di specifica, progettazione ed, infine, realizzazione del sistema.
Questi due obiettivi possono essere raggiunti in vari modi, a seconda dei fattori che dovranno caratterizzare il prodotto finale, ma qualunqe metodo di analisi deve prevedere due azioni:

  • la costruzione di un glossario ai fini della definizione del dominio;
  • la redazione dei requisiti utente, relativi sia agli aspetti funzionali che non funzionali del sistema.

Il glossario sarà un documento nel quale verranno definiti in maniera univoca tutti i termini significativi in relazione allo specifico contesto e che verranno adoperati nella descrizione degli obiettivi.
L’operazione attraverso la quale si perviene ad un documento siffatto consta di alcune fasi , in ciascuna delle quali viene attuata una operazione di ‘filtraggio’ su di un testo iniziale, fino a pervenire al glossario di dominio, poi al glossario dei dati ed, infine, ai requisiti del sistema software che rappresenteranno il documento di partenza per la fasi di specifica dei requisiti.
Si è parlato della disponibilità di un testo iniziale, cioè una descrizione del problema, delle esigenze e volontà del committente, ma, in alternativa, si potrebbe pensare di reperire le informazioni attraverso delle interviste tra committente ed analista. Si noti, infatti, che il glossario dovrà essere verificato ed approvato dal cliente.

L’analisi

Una volta raccolti, i requisiti dovranno essere analizzati, raffinati (descrivendoli ad un livello di astrazione più basso) e valutati.
L’analisi consente di ottenere requisiti descritti ad un opportuno livello di dettaglio e con caratteristiche adeguate di qualità, tali da consentire la formulazione di una o più possibili soluzioni al problema.

Definiti i confini del contesto, bisognerà individuandarne le interfacce con altri attori (eventualmente attraverso un protitipo delle interfacce utente), così da chiarire ulteriormente gli scenari di interazione, espressi mediante i casi d’uso, e gli altri requisiti.
Ancora, si dovranno stimare i costi, le prestazioni ed i rischi legati alla scelta di implementare i requisiti definiti.

Nel caso in cui la valutazione della fattibilità sia positiva, sarebbe opportuno invitare i committenti a classificare i requisiti da implementare secondo una scala di priorità70.
A questo punto, sarà possibile sviluppare i casi d’uso, individuati nella fase di elicitazione, e produrre modelli di analisi che consentiranno di esplorare in maniera più precisa le funzionalità che il sistema dovrà offrire ed individuare nei requisiti eventuali errori e/od omissioni.
L’ultimo passo da compiere consisterà nella creazione del glossario, già discusso precedentemente, attraverso il quale la terminologia adottata sarà di uso comune per il team di progetto, così come per gli stakeholder.

Specifica dei requisiti

L’attività di specifica dei requisiti rappresenta la descrizione formale di un sistema software, inteso come prodotto che soddisfi le esigenze mostrate dall’utente, sotto i vincoli posti dallo specifico dominio di applicazione. Tale attività confluisce in un documento di specifica dei requisiti software, appunto, per il quale vi è la possibilità di adoperare un linguaggio formale, oppure strutturato, come abbiamo precedentemente discusso. Esso potrà essere dotato di una semantica formale oppure convenzionale (dunque più intuitiva) e di una sintassi controllata.
L’operazione di specifica offre, innanzitutto, la possibilità di tradurre in frasi, cioè concetti concreti, quel che sino a poco prima era solo un’idea di come il sistema software dovesse comportarsi, poi di poter comunicare e condividere tali concetti con il team di progetto e, naturalmente, con il committente.
Il documento di specifica dei requisiti potrà essere eventualmente analizzato da uno strumento automatico.
È, pertanto, necessario adottare un metodo che consenta di svolgere questa attività in maniera logica e graduale, così da focalizzare la nostra attenzione sugli aspetti più significativi (e, spesso, più complicati da trattare).

Durante l’attività di specifica dei requisiti bisognerà assegnare a ciascun requisito un identificativo univoco, così da poter documentarne l’origine più agevolmente e gestirne la tracciabilità lungo tutto il suo ciclo di vita.
Bisognerà prevedere anche una gestione della versione di ciascun requisito, così da poter tracciare anche tutte le modifiche effettuate su di esso.
Un requisito può essere specificato, oltre che dall’indentificativo ed dalla descrizione, anche da un insieme di attributi che ne vanno a caratterizzare:

  1. la tipologia (funzionale o non funzionale ed, eventualmente, specificare a quele classe appartiene);
  2. chi lo ha richiesto, la data di richiesta e dell’ultima modifica apportata al requisito;
  3. il numero di versione, così da tener traccia dell’evoluzione subita;
  4. l’importanza secondo il punto di vista del committente (ad esempio: obbligatorio, desiderabile, opzionale);
  5. la priorità di implementazione del requisito, quindi rispetto al suo rilascio;
  6. lo stato che indichi, ad esempio, se il requisito sia stato approvato, implementato, verificato, eliminato;
  7. il criterio di accettazione;
  8. il livello di stabilità del requisito: infatti, la specifica e lo sviluppo di un sistema possono protrarsi per lungo tempo, durante il quale le esigenze degli stakeholder possono mutare, invalidando la presenza di alcuni requisiti.

Per questo motivo, nell’ambito della gestione dei requisiti, si potrebbe classificarli in duraturi72 o volatili in base al livello di stabilità che presentano.
La creazione di una matrice di tracciabilità dei requisiti è uno dei passi fondamentali di tutta l’attività. In essa dovranno essere riportati tutti i collegamenti tra i requisiti ed i casi d’uso da cui discendono ed i requisiti del documento di specifica. Successivamente, si dovranno riportare tutti i collegamenti tra i requisiti specificati e gli “artefatti” dello sviluppo, sino ad arrivare ai componenti fisici in cui essi sono implemetati ed, infine, con le specifiche di test che li verificano.

Verifica e validazione

La convalida consiste nel dimostrare che i requisiti specificati definiscano realmente il sistema richiesto dal cliente.
La sua importanza deriva dalla considerazione che correggere un errore od un’omissione in una fase avanzata dello sviluppo del sistema (o, ancor peggio, dopo la sua messa in esercizio) comporti costi molto elevati.

I requisiti documentati (nel documento dei requisiti) dovranno essere sottoposti al committente, così che possa valutarne l’aderenza alle sue aspettative ed, eventualmente, approvarli.
Durante il processo di convalida potranno essere effettuati diversi controlli sui requisiti per dimostrarne la validità, la consistenza, la completezza, il realismo/realizzabilità e la verificabilità.
Le tecniche di validazione più adoperate consistono nella revisione dei requisiti, nella prototipizzazione e nella generazione dei casi di test.
Tra esse, la revisione dei requisiti è la più diffusa, poichè consente di validare anche i requisiti non funzionali.
Alla base di essa vi è l’idea di riunire un gruppo di persone che dovranno leggere ed analizzare il docmento dei requisiti, per individuare eventuali errori od incongruenze che verranno discusse al fine di risolverle.

Il modello di revisione dei requisiti prende vita dalle considerazioni degli studiosi Gilb e Graham e, successivamente ampliata da Kotonya e Sommerville, consta delle seguenti attività:
1. Plan review: viene nominato il team, il luogo, il giorno in cui verrà operata la revisione;
2. Distribuite documents: il documento dei requisiti (ed eventuale altra documentazione) viene fornita al team di revisione;
3. Prepare for review: lettura individuale del documento, così da trovare conflitti e/o incongruenze.

In tal modo, ogni soggetto potrà operare senza subire l’influenza di un altro;

4. Hold review meeting: discussione di tutti i problemi riscontrati e decisione delle contromisure da adottare;
5. Follow-up actions: verifica delle contromisure decise da parte del coordinatore del team;
6. Revise document: ulteriore revisione delle sezioni evidenziate.

I problemi riscontrabili all’interno del documento possono venir fuori dalla mancanza di chiarezza nei requisiti: il requisito può essere espresso in maniera poco chiara, oppure si è omessa qualche informazione comunicata durante la fase di elicitazione;
Nel caso in cui il documento dei requisiti presenti informazioni mancanti, esse potranno essere reperite dagli utenti interessati. Va da sè che, nel caso di conflitti tra requisiti, sia necessario negoziare con i clienti una possibile soluzione alternativa.

La revisione dei requisiti, alla quale dovrebbero essere coinvolti tutti gli interessati al prodotto (committente e produttore), potrà essere svolta in maniera formale od informale I requisiti dovrebbero essere revisionati regolarmente durante tutta la fase di definizione, poichè servono ad affrontare problemi od errori di specifica nella fase iniziale del processo.
Una delle caratteristiche che dovrebbero mostrare i requisiti proposti è la verificabilità, pertanto bisogna scrivere un insieme di casi di test, attraverso i quali dimostrare che il sistema consegnato soddisferà ogni requisito specificato.
Una volta rilevate, tutte le incongruenze potranno essere risolte mediante tecniche di negoziazione.

Modello a spirale dell'Ingegneria dei Requisiti
Modello a spirale dell’Ingegneria dei Requisiti

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 *