L’attività di pianificazione di un progetto prende l’avvio dall’attività commerciale e non può prescindere dalla cosiddetta analisi, un punto focale che consente di evitare di incorrere in problemi nelle successive fasi di implementazione e test.
È noto, infatti, che nel ciclo di vita di un progetto, maggiore è il ritardo con cui si evidenziano i problemi maggiori saranno i costi da sostenere per ovviare agli errori di commessi.
Il fatto poi che tali costi non siano evidenti in fase di pianificazione – anzi non siano assolutamente presenti – ha come conseguenza l’erosione dell’utile atteso.
E’ evidente quindi la necessità di suddividere anche la fase di analisi in momenti che consentano di ridurre al minimo il rischio di incorrere in questo genere di errori.
La fase di analisi viene normalmente strutturata e definita attraverso una serie di documenti atti a focalizzare le esigenze del committente e validarne la comprensione avuta dal fornitore di quanto richiesto.
Un documento in particolare è basilare, quello destinato all’utente finale e che costituisce una sorta di capitolato, sul quale si basa l’offerta economica: questo documento raccoglie quelli che io chiamo “requisiti d’utente“.
Per sua natura, questo documento deve essere redatto in un linguaggio quanto più possibile lontano dal gergo tecnico, in modo da essere facilmente compreso anche da coloro che operano in un settore merceologico differente da quello relativo a progetti in divenire.
Un caso può essere quello di un’industria manifatturiera e la realizzazione di una intranet per la gestione, ad esempio, del magazzino.
In questa documentazione l’accento dovrà essere posto sull’insieme delle funzionalità richieste e sulla modalità di gestione dell’interfaccia, quindi di accessibilità ai servizi che l’applicazione dovrà offrire.
Gli unici riferimenti tecnici che solitamente inserisco nei requisiti utente sono relativi agli standard di riferimento che verranno utilizzati o resi disponibili.
Un equivoco che è fondamentale eliminare è che i “requisiti d’utente” siano immodificabili.
Infatti, è sistematico che i contenuti di un progetto si modifichino man mano che esso stesso evolve, e questo per un insieme di fattori che coinvolgono soprattutto il committente, come ho già descritto in un precedente articolo.
