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

Il budget è fissato, l’obiettivo è delineato e la tem­pi­sti­ca è definita: a questo punto, le aziende spesso si pre­ci­pi­ta­no di­ret­ta­men­te nell’im­ple­men­ta­zio­ne invece di prendersi tempo a suf­fi­cien­za per rac­co­glie­re si­ste­ma­ti­ca­men­te i requisiti di tutti gli sta­ke­hol­der per il prodotto target e gestirne le spe­ci­fi­che. Il risultato: solo la metà dei requisiti ori­gi­na­ria­men­te definiti fa parte del prodotto finale la metà dei requisiti ori­gi­na­ria­men­te definiti fa parte del prodotto finale: è chia­ra­men­te una perdita di tempo e di budget. Grazie a una gestione strut­tu­ra­ta dei requisiti potete però lavorare in modo più ef­fi­cien­te.

La gestione dei requisiti, nota anche come in­ge­gne­ria dei requisiti o re­qui­re­men­ts ma­na­ge­ment, è una com­po­nen­te ele­men­ta­re del project ma­na­ge­ment nelle aziende. L’obiettivo è quello di garantire il rispetto delle esigenze dei clienti e degli sta­ke­hol­der interni ed esterni per il prodotto da rea­liz­za­re.

La di­sci­pli­na comprende la de­fi­ni­zio­ne dei requisiti (analisi, specifica e ap­pro­va­zio­ne dei requisiti) e la gestione dei requisiti (gestione del rischio, delle modifiche e dell’im­ple­men­ta­zio­ne). Non si tratta quindi di un compito una tantum svolto all’inizio di un progetto, ma di una sequenza di processi ri­cor­ren­ti che si estendono per tutta la durata del progetto. Un manager re­spon­sa­bi­le, il re­qui­re­men­ts engineer, su­per­vi­sio­na l’im­ple­men­ta­zio­ne e l’in­te­gra­zio­ne dei requisiti, delle modifiche, nonché l’avan­za­men­to del progetto.

La gestione dei requisiti è re­la­ti­va­men­te ben con­so­li­da­ta nel settore tec­no­lo­gi­co. Non chiarire sin dall’inizio di un progetto in­for­ma­ti­co cosa deve riuscire a fare il software da svi­lup­pa­re e quali processi deve sup­por­ta­re è una condanna sicura all’incontro di dif­fi­col­tà nel corso della sua rea­liz­za­zio­ne. La pia­ni­fi­ca­zio­ne del tempo e delle risorse non può essere rea­li­sti­ca su questa base ed è molto probabile che i clienti, con varie richieste di modifica, pro­lun­ghi­no il progetto e sforino ec­ces­si­va­men­te il budget. Se le richieste di modifica non sono gestite in modo com­pe­ten­te, i costi aumentano ul­te­rior­men­te.

Il re­qui­re­men­ts ma­na­ge­ment è utile e im­por­tan­te, in­di­pen­den­te­men­te dal settore. In par­ti­co­la­re nei progetti di ampia portata con prodotti complessi, la gestione dei requisiti ga­ran­ti­sce un elevato grado di ef­fi­cien­za per tutta la durata del progetto, pre­ve­nen­do errori e di­ver­gen­ze tra i partner. Un re­qui­re­men­ts engineer può iden­ti­fi­ca­re per tempo i problemi derivanti dal cam­bia­men­to dei requisiti dei clienti e definire misure per at­te­nuar­ne gli effetti negativi.

Anche se ini­zial­men­te una do­cu­men­ta­zio­ne det­ta­glia­ta dei requisiti comporta costi più elevati, la customer sa­ti­sfac­tion aumenta se garantite una gestione strut­tu­ra­ta.

Tuttavia, l’im­por­tan­za della de­fi­ni­zio­ne e della gestione dei requisiti per il successo dei progetti delle aziende tende a essere sot­to­va­lu­ta­ta, anche nei progetti tec­no­lo­gi­ci in cui la gestione dei requisiti IT è più diffusa. Al­tri­men­ti è 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 ri­spet­ta­re il budget. Solo il 55 per cento degli in­ter­vi­sta­ti ha ritenuto im­por­tan­te o molto im­por­tan­te la gestione dei requisiti. Il resto ha at­tri­bui­to solo un’im­por­tan­za media o bassa al re­qui­re­men­ts ma­na­ge­ment per il successo del progetto. Un grave errore, come dimostra il numero di progetti com­ple­ta­ti nei tempi previsti.

• maggiore ef­fi­cien­za del progetto
• meno richieste di modifica nel corso del progetto
• meno errori e di­ver­gen­ze
• ri­co­no­sci­men­to precoce dei problemi e delle modifiche da ef­fet­tua­re
• riduzione dei costi di progetto, in quanto si evitano i costi per la cor­re­zio­ne degli errori
• com­ple­ta­men­to del progetto ri­spet­tan­do i tempi e il budget
• clienti più sod­di­sfat­ti

I compiti più im­por­tan­ti della gestione dei requisiti com­pren­do­no la de­fi­ni­zio­ne, 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 sta­ke­hol­der. Il re­qui­re­men­ts engineer ha a di­spo­si­zio­ne diversi metodi per elaborare le esigenze e i desideri degli sta­ke­hol­der e dei clienti e creare la specifica dei requisiti.

• In­ter­vi­ste: il re­qui­re­men­ts engineer può condurre colloqui personali o te­le­fo­ni­ci con gli sta­ke­hol­der.
• Que­stio­na­ri: un’altra opzione è condurre un sondaggio scritto per rac­co­glie­re i requisiti in forma strut­tu­ra­ta. Questo metodo permette di catturare le aspet­ta­ti­ve di un gran numero di sta­ke­hol­der.
• Workshop: con l’aiuto delle tecniche di crea­ti­vi­tà, gli sta­ke­hol­der possono essere guidati nei workshop per elaborare quegli aspetti che devono essere con­si­de­ra­ti nel progetto e che non sarebbero stati rilevati con un semplice brain­stor­ming.
• Os­ser­va­zio­ni sul campo: il re­qui­re­men­ts engineer osserva i processi di lavoro degli sta­ke­hol­der e li documenta per iscritto o con re­gi­stra­zio­ni audio o video.
• Ap­pren­ti­cing: il re­qui­re­men­ts engineer apprende i compiti degli sta­ke­hol­der, il che gli permette di capire a fondo le relative esigenze.
• Analisi del codice sorgente: Nel caso di in­fra­strut­tu­re IT che non sono o sono scar­sa­men­te do­cu­men­ta­te, il re­qui­re­men­ts engineer può iniziare ana­liz­zan­do e do­cu­men­tan­do il relativo sistema. La sua analisi può anche essere integrata con indagini sugli utenti di tale sistema.
• Analisi della do­cu­men­ta­zio­ne 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 uti­liz­za­re la do­cu­men­ta­zio­ne esistente.

La specifica dei requisiti forma la base del contratto di fornitura tra i partner di un progetto. Questo documento co­sti­tui­sce il primo passo nel re­qui­re­men­ts ma­na­ge­ment e contiene tutte le richieste del com­mit­ten­te re­la­ti­va­men­te al servizio e alla fornitura da parte dello svi­lup­pa­to­re. In altre parole, è il contratto tra le due parti. Nella suc­ces­si­va analisi dei requisiti invece, viene definita nel dettaglio l’im­ple­men­ta­zio­ne e la rea­liz­za­zio­ne del progetto.

In molti casi è utile do­cu­men­ta­re i requisiti non solo sotto forma di testo ma anche gra­fi­ca­men­te, so­prat­tut­to se si vogliono de­scri­ve­re 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 re­qui­re­men­ts ma­na­ge­ment passerà alla fase di analisi. I requisiti in conflitto tra loro devono essere iden­ti­fi­ca­ti e chiariti con gli sta­ke­hol­der. Il manager deve inoltre iden­ti­fi­ca­re e valutare i rischi (va­lu­ta­zio­ne basata sull’entità po­ten­zia­le del danno e sulla pro­ba­bi­li­tà che si ve­ri­fi­chi­no). Inoltre è ne­ces­sa­rio assegnare una priorità a ciascuno dei requisiti.

Nel passaggio suc­ces­si­vo sarà pre­sen­ta­ta agli sta­ke­hol­der la specifica dei requisiti da re­vi­sio­na­re. Solo dopo aver raggiunto un accordo comune sulla specifica dei requisiti dovrebbe iniziare la fase di rea­liz­za­zio­ne del progetto.

Nel corso di (quasi) ogni progetto si ve­ri­fi­che­ran­no delle richieste di modifica. Per ridurre al minimo le di­scus­sio­ni sul lavoro ag­giun­ti­vo e poter tornare ra­pi­da­men­te allo stato di progetto pre­ce­den­te in caso di in­sod­di­sfa­zio­ne del cliente un metodo col­lau­da­to è quello del ver­sio­ning. Questo metodo deriva ori­gi­na­ria­men­te dallo sviluppo di software, ma è uti­liz­za­to anche nella gestione dei progetti. Gli stati del progetto sono do­cu­men­ta­ti e gli stati attuali sono con­tras­se­gna­ti come nuovo scenario di ri­fe­ri­men­to. In questo modo è possibile con­fron­ta­re fa­cil­men­te i requisiti vecchi con quelli attuali.

Molte aziende sono er­ro­nea­men­te 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 ap­par­ten­go­no alla gestione dei requisiti sono assunti dal Product Owner, che monitora e controlla il processo del progetto e quindi l’at­tua­zio­ne 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 re­qui­re­men­ts ma­na­ge­ment, possono essere nominati altri col­la­bo­ra­to­ri per garantire l’im­ple­men­ta­zio­ne dei nuovi requisiti e l’ag­gior­na­men­to della do­cu­men­ta­zio­ne, ad esempio delle modifiche.

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