1. Analisi accurata dei requisiti

Contenuti della pratica

E' noto a chiunque si occupi di sviluppo software l'importanza che riveste l'analisi dei requisiti per il buon esito di un progetto. E' altrettanto noto che i requisiti iniziali possono cambiare durante il progetto e che tali cambiamenti debbano essere gestiti opportunamente. E' meno noto, invece, che requisiti, anche ben definiti, assumono un significato diverso per noi che sviluppiamo il software e per gli utenti che tale software dovranno poi utilizzarlo. Il modello Servqual per la qualità dei servizi indica lo scostamento ("gap") tra il servizio atteso e quello percepito dall'utente finale come uno dei fattori di maggiore insoddisfazione. Risulta quindi di assoluta importanza "condividere" il significato dei requisiti con gli utenti finali e garantire una univocità di interpretazione. L'articolo pubblicato sulla rivista "Qualità on-line" da Aicq descrive  l'applicazione del modello Servqual ai progetti di sviluppo software.

L'interpretazione ed il grado di importanza che gli utenti danno ai requisiti dipende dal contesto nel quale essi operano: responsabilità loro assegnate, contenuti dei task da completare, modalità di svolgimento dei propri compiti, preferenze ed abitudini consolidate nel tempo, ambiente culturale ed organizzativo nel quale operano.

I requisiti assumono il loro corretto significato e la giusta importanza solo quando riferiti allo scenario operativo, organizzativo e culturale in cui nascono e sono percepiti.

Analogamente, la soluzione proposta a fronte dei requisiti definiti è valutata correttamente solo nel contesto in cui essa sarà utilizzata dagli utenti.

La pratica proposta per l'analisi dei requisiti prevede quanto segue:

1. Raccolta, analisi e documentazione dei requisiti;

2. Condivisione dei requisiti con il cliente;

3. Stima e pianificazione del progetto partendo dai requisiti;

4. Verifica che i requisiti siano indirizzati nella progettazione;

5. Progettazione dei test partendo dai requisiti;

6. Gestione delle modifiche dei requisiti durante l'intera durata del progetto.

Ciascuna attività risulta particolarmente efficace se svolta secondo le modalità descritte di seguito.

Ruolo svolto dal cliente nella gestione dei requisiti

Il cliente gioca un ruolo molto importante in questa pratica. In sintesi, il referente del cliente responsabile del progetto deve:

• Assicurare che le diverse esigenze di business e le varie caratteristiche tecniche delle soluzioni siano tutte correttamente interpretate dal fornitore. I requisiti funzionali devono descrivere di "cosa" hanno bisogno i diversi utenti delle varie organizzazioni interessate al progetto. Le caratteristiche tecniche devono descrivere "come" la soluzione deve essere realizzata in termini di prestazioni, facilità d'uso, robustezza, sicurezza, ecc.

• Tenere in debito conto i requisiti espressi dall'organizzazione responsabile della gestione applicativa nell'ambiente di esercizio. I requisiti relativi alla gestione operativa sono di tipo tecnico (coerenza con le architetture esistenti), di tipo operativo e gestionale (procedure operative) e di tipo prestazionale (tempi di completamento delle procedure, utilizzo delle risorse, ecc.). L'organizzazione responsabile della gestione applicativa deve esprimere i propri requisiti e questi devono essere opportunamente indirizzati nel progetto.

• Condividere i requisiti ed assicurare la loro correttezza effettuando la revisione dei documenti prodotti dal fornitore. E' bene che la revisione sia fatta  dalle varie unità organizzative che hanno espresso i requisiti.

• Verificare che le stime del progetto siano fatte basandosi sui requisiti condivisi e non in maniera astratta su modelli di progetto simili. Stime che non includano lo sviluppo di tutti i requisiti costituiscono un forte rischio per il progetto.

• Verificare che la pianificazione del progetto sia realistica, includa le attività necessarie per indirizzare tutti i requisiti condivisi e comprenda attività di controllo e verifica della qualità del lavoro svolto. In caso contrario, la pianificazione risulterà poco realistica e costituirà un forte rischio per il progetto.

• Assicurare che le eventuali modifiche ai requisiti originali siano gestite coerentemente e correttamente: siano cioè formalizzate, condivise e prese in considerazione per rivedere le strategie di sviluppo e di test, le stime, i piani.

Modalità di svolgimento della pratica

a) Raccolta, analisi e documentazione dei requisiti

La "raccolta dei requisiti" è svolta partendo da diverse fonti e con modalità diverse: analisi della documentazione fornita dal cliente o già in nostro possesso; interviste a persone del cliente direttamente coinvolte nel progetto o comunque direttamente interessate al successo del progetto; discussioni con il cliente in circostanze diverse ma attinenti al progetto ed ai suoi contenuti; ecc. E' bene prendere nota di tutte queste "fonti" e formalizzarne i contenuti.

L' "analisi dei requisiti" consiste nell'interpretare i requisiti raccolti, dare a ciascuno di essi un significato univoco (non ambiguo), chiaro e completo, consistente e coerente con gli altri requisiti e testabile; occorre anche definire la tipologia del requisito ("funzionale" o "non-funzionale"), l'importanza che il requisito riveste per il business (alta, media o bassa) ed assegnare una priorità (alta, media, bassa) che permetta di stabilire quando implementare il requisito nell'ambito del progetto (nel presente rilascio o in uno successivo). Mentre un requisito "funzionale" descrive la funzionalità richiesta (cosa deve fare), i requisiti "non funzionali" identificano le caratteristiche con cui la funzionalità dovrà essere resa disponibile (affidabile, veloce, sicura, facile, intuibile, ecc.). I requisiti non funzionali sono sempre presenti anche se spesso non sono esplicitamente espressi in quanto ritenuti ovvi oppure perché ci si è dimenticati di definirli. Per questo si dicono spesso impliciti ma sono ugualmente richiesti, attesi e quindi valutati in fase di accettazione della soluzione finale.

La norma ISO/IEC 9126 propone un modello della qualità del software secondo tre diversi punti di vista: "interno", "esterno" e "in uso". Le caratteristiche interne ed esterne del software sono: funzionalità, affidabilità, usabilità, efficienza, manutenibilità, portabilità. Ciascuna di esse ha a sua volta attributi specifici. Le caratteristiche in uso del software, cioè secondo il suo utilizzo, sono invece: efficacia, produttività, sicurezza e soddisfazione. Nel sito è riportato un manuale che descrive il modello ISO/IEC 9126 e le caratteristiche del software.

La "documentazione dei requisiti" può utilizzare uno schema che permetta di gestire nel corso del progetto i requisiti, la loro implementazione ed i possibili cambiamenti. Tale documento rappresenta il "Riferimento" più importante in tutto il progetto e ad esso si fa riferimento nelle altre best pratiche proposte. Il documento dei requisiti può essere anche un semplice foglio di calcolo con le seguenti colonne: Identificativo univoco del requisito, Titolo del requisito, Tipologia del requisito, Importanza del requisito, Priorità del requisito, Descrizione dettagliata del requisito, Stato del requisito, Data in cui è stato definito o cambiato, Condivisione del requisito, Data della condivisione, Fonte del requisito, Inclusione del requisito nella progettazione, Inclusione del requisito nelle prove e collaudi (casi di test), Nota informativa con dettagli che possano aiutare a gestire il requisito.

Una tabella così fatta è detta "Matrice di tracciabilità dei requisiti" (o anche "Matrice biunivoca dei requisiti") di cui si fornisce un esempio nella "Tabella dei requisiti".

Un modo concreto ed efficace di rappresentare l'interpretazione che diamo dei requisiti è quello di tradurli in scenari operativi, detti "casi d'uso" (in inglese "use case"). Essi descrivono le modalità con cui gli utenti interagiscono con il sistema per svolgere determinati compiti. La modellazione dei requisiti con la tecnica degli "use case" permette quindi di concentrare l'attenzione sugli utenti e le modalità operative. Una funzione è perciò descritta non in maniera astratta ma come essa sarà utilizzata da un particolare utente per svolgere un determinato compito.  

b) Condivisione dei requisiti con il cliente

La "condivisione dei requisiti" è fondamentale per garantire l'univocità della loro interpretazione e la loro completezza.

Consiste nel condividere con il cliente i requisiti e/o i casi d'uso. La descrizione dei requisiti, le tipologie, l'importanza e le priorità permettono di condividere l'interpretazione dei bisogni del cliente. La descrizione dei casi d'uso permette di condividere gli scenari operativi nei quali il software sarà utilizzato dagli utenti finali.

Solo la condivisione può garantire che la nostra interpretazione delle esigenze del cliente coincida con la sua e che, in fase di sviluppo, andremo a realizzare una soluzione come quella descritta dai casi d'uso. Sarà perciò chiaro e pacifico ad entrambi che si andrà a sviluppare una soluzione che indirizzi i "requisiti condivisi" e non la "nostra interpretazione di essi" e nemmeno la "sua aspettativa più o meno nascosta".

Le caratteristiche del software (requisiti non funzionali) non sono generalizzabili all'intera applicazione ma legate alle specifiche funzionalità e alle modalità con cui gli utenti le utilizzeranno. La condivisione dei requisiti va fatta, quindi, con diversi utenti (o categorie di utenti) a seconda delle funzionalità in discussione.

L'assegnazione di una priorità (o importanza) ad ogni requisito permette di organizzare il progetto in fasi con rilasci successivi e contenenti i requisiti secondo le priorità condivise con il cliente.

Ogni modifica ai requisiti iniziali seguirà lo stesso processo descritto: la condivisione con il cliente garantisce la consistenza e la congruenza con quanto già condiviso e indirizzato nel progetto.

La tabella dei requisiti (indicata come "Riferimento") è aggiornata con quanto condiviso ed è mantenuta aggiornata durante l'intera durata del progetto come vedremo nel proseguo.

c) Stima e pianificazione del progetto partendo dai requisiti

La stima del progetto deve partire sempre dall'elenco dei requisiti condivisi.

La stima tiene conto sia delle caratteristiche funzionali che di quelle qualitative (cioè non funzionali). Lo sviluppo di una funzionalità può richiedere infatti tempi e costi diversi a seconda delle sue caratteristiche qualitative. Una soluzione senza requisiti di sicurezza, ad esempio, costerà meno di una in cui tale caratteristica sia critica per il business. Analogamente una funzionalità con alte prestazioni (es.: tempi di risposta inferiori ad un valore di soglia) avrà costi superiori ad un'analoga funzioni senza tali caratteristiche prestazionali, ecc.

Occorre dunque assicurare che le stime siano fatte basandosi sulla tabella dei requisiti (presa come "Riferimento") e che tutti i requisiti siano stati presi in considerazione.

Si comprende bene come ogni modifica ai requisiti iniziali possa influire sulle stime fatte e richiedere quindi che queste siano aggiornate ed approvate prima che la modifica sia inclusa nel progetto.

d) Verifica che i requisiti siano indirizzati nella progettazione

Il documento dei requisiti è la base per la progettazione. Il responsabile del design assicura che essi siano tutti correttamente indirizzati nella progettazione. La verifica tiene conto sia dei requisiti funzionali che di quelli qualitativi. La progettazione deve quindi garantire che le funzionalità sviluppate possano essere utilizzate dagli utenti finali nei loro contesti di lavoro: responsabilità loro assegnate, diversi compiti da svolgere, modalità di utilizzo, preferenze e criteri di valutazione.

Una funzione semplice come, ad esempio, l'inserimento di dati avrà caratteristiche diverse in termini di usabilità, prestazioni e sicurezza a seconda dello scenario nel quale l'utente finale la utilizzerà. Una funzione realizzata tramite una transazione batch richiederà tempi di lavorazione differenti rispetto alla stessa funzione svolta in modalità on-line da un operatore che abbia davanti al suo sportello una coda di utenti in attesa. Una transazione svolta da un utente remoto sul Web ha requisiti di sicurezza diversi dalla stessa transazione eseguita da un utente autorizzato nel sistema informativo aziendale interno, ecc.

La verifica della bontà della progettazione tiene conto, dunque, del fatto che essa indirizzi correttamente e completamente i requisiti condivisi con il cliente, sia quelli funzionali che quelli qualitativi, con le priorità e le criticità definite.

La verifica della progettazione include l'aggiornamento della tabella dei requisiti (indicata come "Riferimento") riportando per ogni requisito l'indicazione se esso sia stato correttamente e completamente indirizzato dalla progettazione in esame.

e) Progettazione dei test partendo dai requisiti

Il documento dei requisiti ("Riferimento") è la base di partenza per la progettazione dei test. Occorre garantire che ogni requisito, funzionale e qualitativo, sia indirizzato da almeno un caso di test. Così si garantisce che le funzionalità e le caratteristiche del software siano verificate nella loro completezza e correttezza.

Per assicurare la massima copertura dei requisiti da parte dei test è bene creare una matrice (detta "matrice di test") la quale riporta l'elenco dei requisiti e l'elenco dei casi di test. La casella di incrocio tra requisito e caso di test indica se la copertura è assicurata o meno. Una tale matrice permette di verificare il grado di copertura dei requisiti e consente allo stesso tempo di ottimizzare i test. Un requisito che sia coperto da più casi di test, per esempio, suggerisce di eliminare i casi di test duplicati che non aggiungono valore al test del requisito. Al contrario, la matrice può rilevare che alcuni requisiti non siano opportunamente indirizzati da casi di test.

Qui è fornito un esempio di "Matrice di test".

f) Gestione delle modifiche dei requisiti durante l'intero durata del progetto

L'importanza della gestione delle modifiche ai requisiti iniziali è ora chiara più che mai a tutti noi. Ogni modifica ai requisiti deve seguire tutte le fasi elencate e descritte in precedenza in quanto essa può avere influenza su vari aspetti del progetto: interpretazione del suo contenuto, progettazione della soluzione, stima dei tempi e dei costi, piano dei test. La modifica dei requisiti iniziali richiede l'approvazione dei responsabili del progetto, sia lato cliente che lato fornitore, prima della sua inclusione nel progetto stesso.

Risultati positivi conseguiti dall'adozione della pratica

Il risultato dell'adozione di tale pratica è importante ai fini del successo del progetto e consiste in:

• Progettazione di una soluzione che indirizzi esattamente le necessità del cliente e rispecchi il punto di vista dei vari utenti finali; riduzione drastica dei rifacimenti dovuti a ricicli in fase di design e codifica a seguito di interpretazioni dubbie o contestate dei requisiti (per esempio, a fronte di discussioni con gli utenti finali e con il gruppo di progetto);

• Stime più accurate e più realistiche con ricadute positive sulla pianificazione dei tempi e dei costi del progetto;

• Maggiore garanzia del rispetto dei tempi e dei costi del progetto tramite la pianificazione di rilasci successivi che includano lo sviluppo dei requisiti in base alle priorità per il business del cliente;

• Migliore progettazione dei casi di test che risulterà più completa, corretta ed ottimizzata; la pianificazione dei diversi tipi di test terrà conto delle funzionalità e delle varie caratteristiche del software (usabilità, performance, robustezza, sicurezza, operatività, ecc.);

• Esito positivo del collaudo di accettazione in quanto le funzionalità e le caratteristiche del software progettate, sviluppate e testate saranno basate sui requisiti condivisi con il cliente.

I benefici elencati sono stati personalmente verificati in molti progetti, sia semplici che complessi, in cui la "best practice" è stata adoperata.

L'adozione della pratica non richiede alcun costo aggiuntivo al progetto in quanto l'analisi dei requisiti sarà svolta "in maniera diversa" piuttosto che con attività aggiuntive.

La formazione iniziale del personale è da considerarsi un investimento dell'azienda e non un costo addebitabile al singolo progetto.

Potenziali problemi generati dalla mancata o errata adozione della pratica

I problemi derivanti da una errata analisi dei requisiti sono rilevanti, conosciuti da tutti noi e messi in luce dall'indagine in corso. I più importanti sono:

• Bassa qualità della progettazione, dello sviluppo e del test della soluzione che non rispecchia le reali esigenze degli utenti finali; le ripercussioni più gravi sono sui tempi di consegna, sui costi del progetto e sulla qualità della soluzione che risulterà basata sull'interpretazione unilaterale delle esigenze e senza garanzia di completezza;

• Stime poco accurate e pianificazione non realistica che non tengono conto delle numerose attività di rifacimento e dei ricicli dovuti alle modifiche ai requisiti non previsti o alla loro diversa interpretazione; le ripercussioni più evidenti sono sui tempi di consegna e sui costi di progetto;

• Mancato rispetto dei tempi di consegna e superamento del budget di progetto a causa dell'impatto negativo delle attività di rifacimento e di ricicli;

• Rischio di non accettazione della soluzione sviluppata da parte degli utenti finali a causa della contestazione sulla completezza e l'interpretazione delle loro esigenze.

L'analisi dei dati ricavati dall'indagine in corso e l'esperienza maturata in molti anni di lavoro e progetti diversi identifica nella mancata o scarsa adozione di tale "best practice" l'origine principale dei problemi evidenziati sopra.