Gestione dei requisiti: punto chiave per il successo dei progetti IT

Il budget è fissato, l’obiettivo è delineato e la tempistica è definita: a questo punto, le aziende spesso si precipitano direttamente nell’implementazione invece di prendersi tempo a sufficienza per raccogliere sistematicamente i requisiti di tutti gli stakeholder per il prodotto target e gestirne le specifiche. Il risultato: solo la metà dei requisiti originariamente definiti fa parte del prodotto finale la metà dei requisiti originariamente definiti fa parte del prodotto finale: è chiaramente una perdita di tempo e di budget. Grazie a una gestione strutturata dei requisiti potete però lavorare in modo più efficiente.

La gestione dei requisiti, nota anche come ingegneria dei requisiti o requirements management, è una componente elementare del project management nelle aziende. L’obiettivo è quello di garantire il rispetto delle esigenze dei clienti e degli stakeholder interni ed esterni per il prodotto da realizzare.

La disciplina comprende la definizione dei requisiti (analisi, specifica e approvazione dei requisiti) e la gestione dei requisiti (gestione del rischio, delle modifiche e dell’implementazione). Non si tratta quindi di un compito una tantum svolto all’inizio di un progetto, ma di una sequenza di processi ricorrenti che si estendono per tutta la durata del progetto. Un manager responsabile, il requirements engineer, supervisiona l’implementazione e l’integrazione dei requisiti, delle modifiche, nonché l’avanzamento del progetto.

La gestione dei requisiti è relativamente ben consolidata nel settore tecnologico. Non chiarire sin dall’inizio di un progetto informatico cosa deve riuscire a fare il software da sviluppare e quali processi deve supportare è una condanna sicura all’incontro di difficoltà nel corso della sua realizzazione. La pianificazione del tempo e delle risorse non può essere realistica su questa base ed è molto probabile che i clienti, con varie richieste di modifica, prolunghino il progetto e sforino eccessivamente il budget. Se le richieste di modifica non sono gestite in modo competente, i costi aumentano ulteriormente.

Il requirements management è utile e importante, indipendentemente dal settore. In particolare nei progetti di ampia portata con prodotti complessi, la gestione dei requisiti garantisce un elevato grado di efficienza per tutta la durata del progetto, prevenendo errori e divergenze tra i partner. Un requirements engineer può identificare per tempo i problemi derivanti dal cambiamento dei requisiti dei clienti e definire misure per attenuarne gli effetti negativi.

Anche se inizialmente una documentazione dettagliata dei requisiti comporta costi più elevati, la customer satisfaction aumenta se garantite una gestione strutturata.

Tuttavia, l’importanza della definizione e della gestione dei requisiti per il successo dei progetti delle aziende tende a essere sottovalutata, anche nei progetti tecnologici in cui la gestione dei requisiti IT è più diffusa. Altrimenti è difficile spiegare il motivo per cui il 52 per cento di tutti progetti IT, stando ai dati forniti nel CHAOS report 2015 di Standish Group, non riesca a stare nei tempi e rispettare il budget. Solo il 55 per cento degli intervistati ha ritenuto importante o molto importante la gestione dei requisiti. Il resto ha attribuito solo un’importanza media o bassa al requirements management per il successo del progetto. Un grave errore, come dimostra il numero di progetti completati nei tempi previsti.

• maggiore efficienza del progetto
• meno richieste di modifica nel corso del progetto
• meno errori e divergenze
• riconoscimento precoce dei problemi e delle modifiche da effettuare
• riduzione dei costi di progetto, in quanto si evitano i costi per la correzione degli errori
• completamento del progetto rispettando i tempi e il budget
• clienti più soddisfatti

I compiti più importanti della gestione dei requisiti comprendono la definizione, la specifica e l’analisi dei requisiti, nonché la gestione delle modifiche nel corso del progetto.

In primo luogo, devono essere definite le esigenze dei vari stakeholder. Il requirements engineer ha a disposizione diversi metodi per elaborare le esigenze e i desideri degli stakeholder e dei clienti e creare la specifica dei requisiti.

• Interviste: il requirements engineer può condurre colloqui personali o telefonici con gli stakeholder.
• Questionari: un’altra opzione è condurre un sondaggio scritto per raccogliere i requisiti in forma strutturata. Questo metodo permette di catturare le aspettative di un gran numero di stakeholder.
• Workshop: con l’aiuto delle tecniche di creatività, gli stakeholder possono essere guidati nei workshop per elaborare quegli aspetti che devono essere considerati nel progetto e che non sarebbero stati rilevati con un semplice brainstorming.
• Osservazioni sul campo: il requirements engineer osserva i processi di lavoro degli stakeholder e li documenta per iscritto o con registrazioni audio o video.
• Apprenticing: il requirements engineer apprende i compiti degli stakeholder, il che gli permette di capire a fondo le relative esigenze.
• Analisi del codice sorgente: Nel caso di infrastrutture IT che non sono o sono scarsamente documentate, il requirements engineer può iniziare analizzando e documentando il relativo sistema. La sua analisi può anche essere integrata con indagini sugli utenti di tale sistema.
• Analisi della documentazione esistente: se un sistema tecnico deve essere rinnovato, è probabile che vengano mantenuti i flussi di lavoro di base a cui gli utenti si sono abituati. Invece di elaborare tutti i requisiti da zero, si dovrebbe utilizzare la documentazione esistente.

La specifica dei requisiti forma la base del contratto di fornitura tra i partner di un progetto. Questo documento costituisce il primo passo nel requirements management e contiene tutte le richieste del committente relativamente al servizio e alla fornitura da parte dello sviluppatore. In altre parole, è il contratto tra le due parti. Nella successiva analisi dei requisiti invece, viene definita nel dettaglio l’implementazione e la realizzazione del progetto.

In molti casi è utile documentare i requisiti non solo sotto forma di testo ma anche graficamente, soprattutto se si vogliono descrivere sistemi, processi e casi d’uso. Qui di solito entrano in gioco i diagrammi UML.

Una volta che i requisiti sono stati definiti e rilevati, il requirements management passerà alla fase di analisi. I requisiti in conflitto tra loro devono essere identificati e chiariti con gli stakeholder. Il manager deve inoltre identificare e valutare i rischi (valutazione basata sull’entità potenziale del danno e sulla probabilità che si verifichino). Inoltre è necessario assegnare una priorità a ciascuno dei requisiti.

Nel passaggio successivo sarà presentata agli stakeholder la specifica dei requisiti da revisionare. Solo dopo aver raggiunto un accordo comune sulla specifica dei requisiti dovrebbe iniziare la fase di realizzazione del progetto.

Nel corso di (quasi) ogni progetto si verificheranno delle richieste di modifica. Per ridurre al minimo le discussioni sul lavoro aggiuntivo e poter tornare rapidamente allo stato di progetto precedente in caso di insoddisfazione del cliente un metodo collaudato è quello del versioning. Questo metodo deriva originariamente dallo sviluppo di software, ma è utilizzato anche nella gestione dei progetti. Gli stati del progetto sono documentati e gli stati attuali sono contrassegnati come nuovo scenario di riferimento. In questo modo è possibile confrontare facilmente i requisiti vecchi con quelli attuali.

Molte aziende sono erroneamente convinte che la gestione dei requisiti non serva nei progetti agili perché lo scopo cambia nel corso di questo tipo di progetti. Nei progetti agili gran parte dei compiti che appartengono alla gestione dei requisiti sono assunti dal Product Owner, che monitora e controlla il processo del progetto e quindi l’attuazione dei requisiti. Il Product Owner assegna inoltre le priorità ai requisiti e ne coordina le modifiche. Questi sono compiti classici di un gestore di requisiti.

Se il Product Owner non è in grado di gestire da solo tutti i compiti del requirements management, possono essere nominati altri collaboratori per garantire l’implementazione dei nuovi requisiti e l’aggiornamento della documentazione, ad esempio delle modifiche.

La gestione dei requisiti nei progetti agili è meno estesa, ma tanto importante quanto lo è nei progetti gestiti in modo classico secondo il modello a cascata.