Raccolta dei Requisiti: Guida Completa & Modello
La raccolta dei requisiti è un processo che consente di definire e gestire le aspettative con gli stakeholder, prevenire l’ampliamento incontrollato dell’ambito e ridurre l’ambiguità su ciò che il progetto consegnerà effettivamente.
Più documentazione dei requisiti si possiede, minore sarà il margine di errore e di assunzioni. I controlli e gli equilibri favoriranno la comprensione reciproca del progetto all’interno del team e le aspettative del cliente sul prodotto finale.
Che cos’è la raccolta dei requisiti nella gestione dei progetti?
La raccolta dei requisiti è il processo di determinazione di ciò di cui gli sponsor del progetto e gli stakeholder chiave hanno bisogno dal progetto. I project manager lavorano per identificare le richieste e i dettagli relativi ad esse.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Queste richieste diventano l’elenco dei requisiti del progetto. Il rispetto dei requisiti determinerà se l’impresa sarà considerata un progetto di successo o meno.
I project manager utilizzano documenti dei requisiti e strumenti di gestione dei requisiti per tenere traccia di questi tipi di requisiti durante tutto il progetto:
- Requisiti funzionali
- Requisiti tecnici
- Requisiti non funzionali
- Requisiti di sistema
Perché la raccolta dei requisiti è importante?
La raccolta dei requisiti è importante per i seguenti motivi (così come lo è la documentazione degli stessi):
- Serve come punto di riferimento per documentare l’evoluzione di un progetto, i suoi elementi variabili e la sua implementazione
- Serve come modello di riferimento per gli stakeholder per comprendere meglio cosa aspettarsi dal progetto (il cosa, dove, quando e perché del progetto).
- Riduce il margine di errore e ambiguità, perché i requisiti sono chiaramente documentati e concordati prima dell’inizio dei lavori.
- Fornisce controlli e verifiche durante la produzione del progetto e il QA, permettendo a project manager e membri del team di farvi riferimento ogni qualvolta ci siano dubbi su come procedere.
Oltre a stabilire cosa aspettarsi, una pianificazione efficace della gestione dei requisiti dovrebbe anche indicare cosa non aspettarsi. Includere una sezione “Assunzioni” e/o “Esclusioni” è una scelta saggia per eliminare il rischio della temuta immaginazione del cliente.
Esempio di specifica dei requisiti software
Ecco un esempio di specifica dei requisiti per un progetto ecommerce:
- Cosa: Integrazione con PayPal
- Dove: Checkout
- Quando: Al terzo passaggio su quattro nell’esperienza di checkout (dopo il modulo di indirizzo di spedizione, prima della conferma)
- Perché: Un’integrazione già consolidata (ad esempio PayPal) è una soluzione migliore rispetto a una complessa integrazione personalizzata di un servizio di pagamento in questo caso perché soddisfa facilmente i requisiti aziendali.
- Assunzioni
- Tariffa fissa per tutte le spedizioni e la gestione
- Tutte le spedizioni avvengono negli Stati Uniti (esclusi Alaska e Hawaii)
- Non si applicano tasse
- Esclusioni
- Calcolo personalizzato di spedizione e gestione
- Spedizioni internazionali, in Alaska o Hawaii
- Regole fiscali
Ricorda: minore è la differenza tra le aspettative del cliente e la realtà del loro prodotto digitale, più il cliente sarà soddisfatto del risultato finale. La qualità della tua gestione dei requisiti è direttamente correlata alla tua capacità, come project manager, di ridurre ogni area grigia riguardo le aspettative del cliente.
Nella maggior parte dei casi, il cliente sarà disponibile ad accettare la limitazione del cambio di ambito se ciò significa preservare il proprio budget; se spieghi al cliente in modo chiaro perché una funzionalità verrà affrontata (o non affrontata) e poi documenti la logica dietro quell'approccio all'interno dei requisiti, il cliente sarà molto più propenso a collaborare.
Saranno più propensi ad approvare e, quando faranno i test di User Acceptance Testing (UAT), avranno già un punto di partenza per comprendere il "perché" dietro la soluzione del tuo team.
Processo di raccolta dei requisiti in 6 fasi
Anche se la raccolta dei requisiti dovrebbe iniziare non appena parte la collaborazione e continuare per tutto il ciclo di vita del progetto, non è mai troppo presto per iniziare a raccogliere e documentare i requisiti. Anzi, meglio partire ieri che oggi.
Ecco i passaggi su come raccogliere i requisiti.
1. Prendi appunti
In ogni riunione a cui partecipi—sia interna con il tuo team di progetto sia esterna con il cliente—prendi sempre appunti. Non dare mai per scontato che ci sia qualcun altro a farlo.
Nel momento stesso potrebbe sembrare facile pensare che tutto ciò di cui si discute verrà ricordato, ma dopo 3 mesi e 15 riunioni, il tuo team e il cliente ti ringrazieranno di avere una documentazione a cui fare riferimento.
Scopri alcune delle procedure che consiglio per prendere appunti sui requisiti qui:
- Prima di entrare in riunione, prepara il tuo documento di appunti secondo l'agenda in modo che l'organizzazione dei punti e delle azioni sarà più semplice. Così ricorderai ciò che serve mentre raccogli le informazioni correlate in modo ordinato.
- Dopo ogni riunione, programma 15-30 minuti per rivedere i tuoi appunti, assimilare ciò che è stato discusso, stabilire una priorità delle azioni da fare e individuare eventuali criticità, necessità di chiarimenti o riunioni supplementari.
- Invia i tuoi appunti al tuo team di progetto interno. Falli revisionare per verificare che le azioni, bandiere rosse, ecc. che hai identificato siano condivise.
- Quando il team avrà dato l'ok, manda i tuoi appunti al cliente.
- Infine, sfrutta i tuoi appunti come riferimento per creare le attività relative ad ogni punto d'azione. Aggiungi eventuali nuove informazioni nella documentazione dei requisiti e pianifica incontri necessari per approfondimenti o ulteriori discussioni.
2. Rivedi i requisiti creativi
Non lasciare le decisioni di design e stile ai singoli membri del team: codifica i requisiti creativi ogni volta che puoi. Le linee guida creative sono preziose per gli sviluppatori. Al minimo, assicurati di avere una guida di stile a portata di mano—anche se ridotta a tipografia e colori del brand.
Raccogli tutti i materiali creativi, come loghi o font del brand, e caricali in uno spazio condiviso (come un software di gestione delle risorse digitali) per garantire accesso e visibilità a tutto il team.
3. Redigi il documento dei requisiti
Mentre inizi la documentazione, ricorda: la prima volta che scrivi un documento di requisiti sarà la più difficile. Perché? Non hai un documento precedente da sfruttare (alias COPIA-INCOLLA). Fortunatamente, questo articolo include un modello di documentazione dei requisiti che può essere una base di partenza.
Come indicato in questo modello, io organizzo la documentazione dei requisiti in quattro parti:
- Annotazione: Include i numeri della tua progettazione annotata. Se il design della tua pagina ha 8 elementi, avrai 8 annotazioni, e la colonna dell'annotazione avrà 8 righe
- Elemento: Include i titoli degli elementi, in relazione a ciascuna annotazione
- Requisito funzionale: Include una definizione (i requisiti, esplicitati) per ciascun elemento
- Funzionalità Admin/CMS: Definisci qualsiasi funzionalità amministrativa e/o del CMS, in relazione all'elemento corrispondente
4. Esegui una revisione interna
In questa fase della raccolta dei requisiti, programma un altro incontro interno con il tuo team di progetto per revisionare la documentazione dei requisiti. Questa è una verifica interna finale per garantire la corretta comprensione dell’implementazione.
Se possibile, fai revisionare la documentazione dei requisiti prima della riunione in modo che il team possa arrivare preparato con domande e/o osservazioni. Utilizza la riunione per discutere eventuali domande o commenti sui requisiti.
Apporta le eventuali revisioni necessarie alla documentazione sulla base della discussione interna. Infine, invia nuovamente la documentazione aggiornata al team per l’ultima approvazione. Una volta che il team interno di progetto ha dato l’approvazione finale, salva il documento in PDF per garantire che resti in stato definitivo per la fase successiva: costruzione dei task.
5. Sviluppa i task
Fornisci la versione PDF della documentazione dei requisiti al tuo team di sviluppo. Idealmente, saranno gli sviluppatori o il responsabile dello sviluppo a suddividere i task per la realizzazione.
Mentre alcune organizzazioni seguono un processo in cui il project manager definisce tutti i task, preferisco che siano gli sviluppatori stessi a costruire i propri task; le poche ore necessarie valgono la pena.
Puoi comunque fornire delle linee guida utili al tuo team mentre sviluppano i task e i deliverable. Dopo la definizione dei task, potrai ottenere una stima finale delle ore.
Confronta quindi questa previsione con la tempistica di progetto già comunicata al cliente e gestiscila di conseguenza, se necessario. Per maggiori informazioni sulla stima dei progetti, consulta questa guida completa sull’estimazione dei progetti.
6. Conduci una revisione esterna
È il momento di presentare la documentazione dei requisiti al cliente. Fornisci il documento in PDF così che non possa essere modificato. Questo (1) dimostra il tuo impegno nell’assicurare la comprensione della soluzione digitale da parte del cliente e (2) ti servirà come "paracadute" in caso di ampliamento del perimetro del progetto (ma con maggiore eleganza).
Forma il tuo cliente. Guidali attraverso questa preziosa documentazione che hai preparato con tanta cura per loro. Ricorda: sono loro gli esperti del loro business. Tu sei l’esperto della soluzione digitale che offri. Ti stanno pagando per questa soluzione. Forma ed abilita il tuo cliente.
Una volta che il cliente ha confermato la comprensione della documentazione dei requisiti, è il momento di ricevere un’approvazione formale. Invia la documentazione dei requisiti firmata e approvata al tuo team e salvala in un archivio condiviso, così da avere una conferma ufficiale che lo sviluppo può iniziare.
Tecniche di raccolta dei requisiti
Ecco alcune tecniche che ti aiuteranno ad assicurarti di svolgere al meglio questo importante lavoro di raccolta dei requisiti:
1. Inizia subito
La documentazione dei requisiti dovrebbe partire non appena iniziano le conversazioni, prima ancora di definire esattamente il piano o gli obiettivi del progetto. Annota tutto ciò che puoi e poi riduci le informazioni. Ecco alcune strategie che puoi provare con il cliente:
- Manda un questionario su ciò che vorrebbero includere nel progetto
- Organizza una sessione di brainstorming
- Conduci un focus group
Anziché eliminare informazioni dal documento, categorizzale tra ciò che è incluso e ciò che è escluso—questo aiuta ad evitare presupposti da parte del cliente in seguito.
Potrai quindi riprendere la tua documentazione WIP (work in progress) dei requisiti e mostrare dove un’informazione è stata registrata, perché magari non è stata inclusa, la logica dietro la decisione e la data in cui è stata raccolta, rendendo tutto tracciabile.
2. Utilizza i modelli
Una volta che hai già diversi documenti dei requisiti preparati, inizia a sfruttarli e a crearne dei modelli per un utilizzo futuro su altri progetti. Soprattutto se ti concentri su progetti di e-commerce o applicazioni didattiche, inizierai a notare l’emergere di schemi funzionali. Identifica dove puoi riutilizzare quanto già fatto.
3. Il lavoro di squadra fa la forza
Se in un progetto ci sono diversi tipi di membri del team, i requisiti per ciascuna area di competenza possono essere redatti dagli esperti della rispettiva materia.
In molti casi il confronto sui requisiti è un percorso tortuoso tra telefonate, varie riunioni separate e conversazioni, ecc. Ecco perché è fondamentale assegnare la documentazione dei requisiti ai membri del team mentre procedi alla raccolta e alla compilazione degli stessi.
4. Non limitarti a registrare i requisiti—impara
Fai più che prendere appunti. Pretendi di più che semplici risorse che ti inviano un muro di testo con i loro requisiti. Prenditi del tempo per sederti insieme al tuo team di sviluppatori e capire quali soluzioni hanno in mente per l’implementazione. Discuti perché e come. Fai domande.
Prima di dire: "Ma abbiamo solo così tanto tempo durante la giornata—e il budget?", considera questo: se una soluzione su cui stai lavorando è applicabile a più di un progetto, allora questo tempo aggiuntivo per acquisire una maggiore comprensione non deve necessariamente essere fatturabile. Stai ampliando le tue competenze specifiche, migliorando direttamente il tuo lavoro quotidiano.
5. Tieni il cliente sempre aggiornato
Prevedi un documento requisiti interno e una versione, sempre in lavorazione, rivolta al cliente. Nel documento interno puoi essere meno preoccupato di inserire appunti più trasparenti.
Se non tratti dati sensibili, puoi creare questo spazio condiviso tramite un Google Doc, abilitando i permessi affinché il cliente possa commentare. Se invece hai a che fare con informazioni riservate, condividi una versione del documento dei requisiti settimanalmente per offrire al cliente un quadro di ciò che è stato raccolto.
6. Presumi che il tuo cliente voglia sempre saperne di più
Per evitare di presumere che il cliente sappia più di ciò che effettivamente sa (per poi doverne pagare le conseguenze), parti dall’idea che il cliente voglia sempre maggiori dettagli. Per ogni annotazione, chiediti “Perché?” cinque volte per assicurare la completezza di ogni requisito.
Ponendoti la domanda “Perché?” cinque volte su ogni requisito, ti stimoli a riflettere davvero sulla logica dietro ogni elemento e funzionalità dei diversi tipi di pagina. Potresti sorprenderti di quanto tu imparerai (o di quanto realizzerai di dover imparare).
3 consigli esperti per scrivere un documento dei requisiti di progetto
1. Scrivi i requisiti degli elementi globali separatamente
Per eliminare le ridondanze, raccogli tutti gli elementi globali in una sezione "Elementi globali" all’interno della documentazione dei requisiti. Questo vale per elementi globali come le voci del menu di navigazione, qualsiasi cosa nel tuo header globale oppure nel footer.
Dopo aver scritto i requisiti per questi elementi globali, non è necessario annotarli anche nelle altre pagine; annota solo gli elementi specifici di ciascuna pagina.
2. Copia e incolla le funzionalità identiche per garantire coerenza
Questo è solo un consiglio utile per mantenere la serenità tua (e del cliente). Lo noterai spesso con elementi comuni come immagini hero/banner, intestazioni o icone "indietro"—tra una quantità significativa di funzionalità ripetute tra i vari tipi di pagina (da non confondere con gli elementi globali).
3. Considera la presenza (o l’assenza) di amministrazione e CMS
Quando ci si concentra molto sulla funzionalità di ciascun elemento della pagina, è facile trascurare le funzionalità amministrative e/o del CMS. Se stai implementando una soluzione che offre funzionalità di amministrazione e/o CMS, assicurati di includerle come una colonna apposita nei tuoi requisiti. Ecco un esempio qui sotto:
Modello di documento dei requisiti [Download]
Le specifiche della definizione dei tuoi requisiti dipenderanno dalla tua relazione con il cliente, dall'esperienza del tuo team e da altri fattori.
Tuttavia, avrai comunque bisogno delle parti basilari di un documento dei requisiti di progetto che dia definizione alla funzionalità, ubicazione, design, ecc. di una caratteristica. Ecco il nostro modello di documento dei requisiti (devi essere un membro per accedervi):
Sblocca la Velocità con oltre 100 Template Premium
Diventa un membro DPM per accedere a un'infinità di template creati da esperti che ti aiutano a lavorare più velocemente ed efficientemente.
