Errori nella definizione dei requisiti

La definizione dei requisiti di progetto richiede un approccio di elaborazione progressiva e sistematica.

Questo approccio inizia con la definizione ad alto livello dell’ambito del progetto, che stabilisce i prodotti del progetto e le loro caratteristiche.

Il team espande la descrizione dell’ambito scoprendo in modo collaborativo le aspettative degli stakeholder del progetto e trasformandole in specifiche di ciò che dovrà essere realizzato.

Infine, il team deve sviluppare un approfondimento tecnico finalizzato ad individuare soluzioni adeguate che soddisfino le esigenze raccolte.

Questa prassi può sembrare semplice, ma può essere ostacolata da uno scarso coinvolgimento dell’utente finale/cliente (stakeholder) oppure da una descrizione dei requisiti poco chiara.

Inoltre, molti responsabili di progetto lamentano il fatto di non disporre di strumenti, tecniche o processi praticabili per consentire alle parti interessate del progetto di definire chiaramente le loro esigenze e i risultati attesi per il progetto.

Però, prima di parlare di strumenti, può essere utile esaminare i principali errori e carenze che spesso si riscontrano nella raccolta, analisi e documentazione dei requisiti. Come si vedrà si tratta prevalentemente di errori legati all’assenza di un approccio metodologico strutturato:

1. Assenza di un piano di gestione dei requisiti. Il project manager dovrebbe definire l’approccio che si intende seguire per la definizione e gestione dei requisiti e concordare con i principali stakeholder il livello di dettaglio che si intende raggiungere.
2. Mancata identificazione delle parti interessate al processo di definizione dei requisiti. Se sospettiamo che ci siano requisiti non espressi, occorre essere proattivi per coinvolgere gli individui, i gruppi e le organizzazioni che devono ancora essere coinvolti (compresi i fornitori).
3. Requisiti definiti in modo ambiguo. Requisiti definiti in modo vago portano a interpretazioni errate. Le persone vedono i requisiti in modi diversi. Quando è possibile, il progettista dovrebbe avere conversazioni faccia a faccia (anche se virtuali) con gli stakeholder.
4. Requisiti fuori dall’ambito del progetto. Devono essere tenuti sotto controllo. Se sono necessari possono portare ad una estensione del lavoro ma deve essere specificato l’onere aggiuntivo e chi dovrà sostenerlo.
5. Processo di modifica dei requisiti scadente. Deve essere chiarito come verranno gestite le modifiche ai requisiti espressi. Si possono adottare procedure strutturate e formalizzate per la gestione delle modifiche (ed il controllo di versione nei progetti che implicano sviluppo di software).
6. Mancata analisi delle opzioni. Un determinato requisito può essere ottenuto in vari modi. E’ importante esaminarli tutti per individuare l’approccio migliore e coinvolgere nell’analisi gli stakeholder interessati.
7. Nessuna approvazione formale. Una volta definito l’ambito del lavoro e i prodotti attesi, è opportuno che i requisiti espressi dagli stakeholder vengano formalizzati e approvati dagli stakeholder per evitare contenziosi.