Un documento dei requisiti di business (BRD - Business Requirements Document) è il ponte tra gli stakeholder aziendali e i team tecnici: acquisisce le esigenze del business e le traduce in requisiti che gli sviluppatori possono realizzare. Con Trupeer, puoi risparmiare ore nella stesura dei BRD partendo da un modello gratuito di documento dei requisiti di business, personalizzandolo con le tue linee guida del brand e trasformando lunghi BRD in walkthrough video facilmente fruibili da tutti.

I progetti falliscono raramente perché nessuno ha messo per iscritto i requisiti. Falliscono perché ciò che è stato scritto era troppo vago per poter essere messo in discussione. Tutti hanno firmato un documento che dichiarava che il sistema doveva essere "intuitivo e veloce", e quattro mesi dopo scoprono di aver inteso tre cose diverse.

Vale la pena scrivere un documento dei requisiti di business quando rende possibile il disaccordo prima dell'inizio dello sviluppo, anziché dopo. Questo modello è concepito proprio per questo: ogni requisito è numerato, prioritizzato e dotato di criteri di accettazione abbastanza specifici su cui poter discutere subito.

Scarica il modello di documento dei requisiti di business

Gratuito, modificabile, senza watermark. La maggior parte dei team usa Word per il documento ed Excel per la tabella dei requisiti non appena il conteggio supera la trentina.

Che cos'è un documento dei requisiti di business?

Un documento dei requisiti di business, o BRD, stabilisce cosa un'azienda richiede da un progetto e perché, prima che qualcuno decida come realizzarlo. Definisce il problema, l'ambito, gli stakeholder, i requisiti stessi e i criteri in base ai quali verrà valutato il risultato.

La sua vera funzione è l'accordo. Un BRD è l'artefatto che tutti firmano per confermare di condividere la stessa visione; ecco perché il vero banco di prova per un BRD non è la scorrevolezza del testo, ma la sua specificità: deve essere abbastanza dettagliato da permettere a qualcuno di obiettare.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dal menu di navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la vista del modello

Se necessario, espandi la visualizzazione del modello per vederne chiaramente il layout completo e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare ad apportare modifiche al modello selezionato.

All'interno dell'editor puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le relative impostazioni

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato tra i tuoi file.

Passaggio 6: Visualizza in anteprima e perfeziona il modello

Quando desideri verificare l'aspetto del tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima puoi continuare ad apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di documento dei requisiti di business puoi:

• Risparmiare ore di scrittura: Evita la pagina bianca grazie a una struttura collaudata da Business Analyst e Project Manager esperti.

• Allineare business e tecnologia: Le sezioni integrate collegano gli obiettivi aziendali ai requisiti funzionali.

• Mantenere la coerenza del brand: Applica logo, caratteri e colori aziendali utilizzando il brand kit di Trupeer.

• Comunicare con chiarezza: Trasforma BRD complessi in walkthrough video per le revisioni con gli stakeholder.

• Standardizzare i progetti: Utilizza lo stesso modello di BRD per ogni iniziativa.

• Coinvolgere team globali: Traduci i BRD in oltre 65 lingue con un solo clic.

Perché hai bisogno di un documento dei requisiti di business

• L'ambito (scope) diventa qualcosa di tangibile a cui fare riferimento, anziché affidarsi alla memoria. La maggior parte delle controversie sull'ambito deriva da carenze di documentazione, non da malafede.

• I requisiti vengono prioritizzati, così quando il tempo stringe si effettuano tagli mirati e consapevoli anziché tagliare ciò che capita per ultimo.

• Le ipotesi vengono messe per iscritto, rendendo visibile se qualcuno ne ha formulata una errata.

• I criteri di accettazione sono definiti prima dello sviluppo, così la definizione di "completato" non spetta a chi alza di più la voce alla fine.

• Il passaggio di consegne resiste all'avvicendamento del personale. I progetti che perdono il proprio Business Analyst in corso d'opera sono quelli in cui un BRD ripaga ampiamente il proprio valore.

• I fornitori possono fare preventivi su basi concrete. Un BRD vago genera preventivi con ampi margini di incertezza e progetti carichi di richieste di modifica (change request).

Cosa include un documento dei requisiti di business

• Controllo del documento: versione, autore, data, distribuzione e stato di approvazione.

• Executive summary: cos'è il progetto e perché viene avviato, riassunto in un paragrafo.

• Obiettivi di business, espressi come risultati misurabili anziché come semplici attività.

• Contesto e definizione del problema: cosa sta accadendo attualmente e quanto costa.

• Ambito: cosa è incluso e, esplicitamente, cosa è escluso.

• Stakeholder: chi è coinvolto, chi decide, chi firma.

• Stato attuale (current state), descritto così com'è nella realtà.

• Requisiti di business, numerati, prioritizzati e ciascuno corredato da criteri di accettazione.

• Ipotesi, vincoli e dipendenze.

• Rischi, con i relativi responsabili (owner).

• Riepilogo di costi e benefici, e il ritorno atteso.

• Tempistiche e milestone principali.

• Criteri di successo per il progetto nel suo complesso.

• Glossario, poiché metà delle controversie sui requisiti sono in realtà controversie terminologiche.

• Blocco di approvazione e firma (sign-off).

• Appendici: mappe di processo, dati, schermate, analisi di supporto.

La struttura del modello

Una lunghezza compresa tra dieci e venti pagine è normale per un progetto di medie dimensioni. Oltre le trenta, la tabella dei requisiti ha solitamente assorbito decisioni di progettazione che dovrebbero appartenere a una specifica funzionale.

Come scrivere un requisito a prova di revisione

Tutto sta in questa competenza: un requisito è scritto bene quando due persone che non sono d'accordo si rendono conto del loro disaccordo semplicemente leggendolo.

Debole: Il sistema deve essere intuitivo.
Migliore: Un nuovo utente deve essere in grado di inviare una richiesta senza formazione preliminare, misurato attraverso 8 utenti di test su 10 che completano l'invio senza assistenza in meno di 3 minuti.

Debole: I report dovrebbero caricarsi rapidamente.
Migliore: Il report di riepilogo mensile deve essere visualizzato entro 4 secondi per un set di dati fino a 50.000 righe.

Debole: I manager necessitano di visibilità sulle approvazioni.
Migliore: Un manager deve poter visualizzare tutte le richieste in attesa di approvazione, ordinate per data di invio, in una singola schermata senza applicare filtri.

Debole: Il sistema deve integrarsi con l'amministrazione finanziaria.
Migliore: Le richieste approvate devono essere registrate nel sistema contabile entro 15 minuti, inclusi centro di costo e codice IVA, con registrazione degli errori e tentativi di invio automatici.

Lo schema di miglioramento è sempre lo stesso: specifica chi ne ha bisogno, che cosa esattamente e la condizione in base alla quale concordi che sia stato raggiunto. Termini di cui diffidare nelle tue bozze: intuitivo, robusto, fluido, veloce, flessibile, scalabile, facile. Ognuno di essi nasconde una decisione che qualcun altro prenderà più avanti senza di te.

Prioritizzare i requisiti con il metodo MoSCoW

Senza priorità, tutti i requisiti diventano obbligatori per impostazione predefinita, finché la prima pressione sulle scadenze non costringe a tagli arbitrari.

La regola fondamentale per far funzionare MoSCoW: non più del 60% circa dei requisiti dovrebbe essere "Must have". Se tutto è un Must, hai solo una lista dei desideri con una colonna di priorità. E l'elenco dei "Won't have" è il più prezioso di tutti, perché è la testimonianza scritta di ciò che è stato deliberatamente rimandato e non dimenticato.

La tabella dei requisiti

Ogni requisito ha bisogno di un ID univoco, perché l'espressione "il requisito di reporting" diventa ambigua non appena ce n'è più di uno. Indicare la fonte è essenziale: al quarto mese qualcuno chiederà chi lo ha richiesto, e "l'azienda" non è una risposta valida.

Matrice di tracciabilità

Il controllo necessario per verificare che nulla sia stato tralasciato silenziosamente e che nulla venga sviluppato senza una valida ragione.

Due tipi di errore emergono immediatamente: un requisito privo di caso di test non verrà mai verificato, mentre un elemento della specifica funzionale non riconducibile ad alcun requisito rappresenta qualcosa che si sta sviluppando senza che nessuno lo abbia richiesto. Entrambi sono frequenti ed entrambi sono economici da individuare con questo metodo.

Esempio di documento dei requisiti di business

Un esempio pratico e sintetico, per mostrare il livello di dettaglio richiesto.

Progetto: Sostituzione del sistema di rimborso spese. Versione: 1.2. Autore: Business Analyst. Approvatori: Direttore Finanziario, Direttore IT, Direttore Risorse Umane.

Obiettivi di business. Ridurre il tempo medio di rimborso delle note spese da 24 giorni lavorativi a 10. Ridurre del 50% il tempo impiegato dal team finance per l'elaborazione dei rimborsi (attualmente pari a 14 ore settimanali). Raggiungere il 95% di conformità alle policy sulle note spese inviate (attualmente al 71%).

Definizione del problema. Le note spese vengono inviate tramite fogli di calcolo inviati via email. Il flusso di approvazione è manuale, le ricevute vengono trasmesse separatamente e il 29% delle richieste viola le policy aziendali senza essere intercettato prima del pagamento. Il reparto finanziario impiega circa 14 ore alla settimana in solleciti, e il rimborso richiede in media 24 giorni lavorativi a fronte di un impegno di 10 giorni previsto dal manuale del dipendente.

In scope (Incluso). Invio delle note spese, acquisizione delle ricevute, convalida delle policy, instradamento dell'approvazione, registrazione nel sistema contabile, notifica ai dipendenti.
Out of scope (Escluso). Riconciliazione delle carte aziendali, definizione delle tariffe chilometriche, integrazione con il sistema paghe, migrazione dello storico note spese oltre i 12 mesi.

Requisiti.

Ipotesi. L'attuale struttura organizzativa nel sistema HR è accurata e aggiornata. Il sistema contabile espone un'API supportata. I limiti previsti dalle policy non subiranno variazioni durante l'implementazione.

Vincoli. Budget di 85.000 £. Il go-live deve avvenire prima del nuovo anno fiscale. Nessun incremento dell'organico nell'ufficio finance.

Riski. I dati sulla linea gerarchica HR si rivelano inaffidabili (Responsabile: Direttore HR; mitigazione: audit prima dello sviluppo). Bassa adozione da parte degli approvatori (Responsabile: Direttore Finanziario; mitigazione: formazione per i manager e due settimane di esecuzione parallela).

Criteri di successo. Tempo medio di rimborso pari o inferiore a 10 giorni lavorativi entro un trimestre dal rilascio. Tempo di elaborazione del reparto finance pari o inferiore a 7 ore settimanali. Conformità alle policy pari o superiore al 95%.

Requisiti di business vs requisiti funzionali vs requisiti tecnici

La più comune fonte di confusione su questo argomento, e la ragione per cui molti BRD sono in realtà specifiche tecniche sotto mentite spoglie.

La verifica pratica: se un requisito menziona una schermata, un campo, un pulsante o un componente di sistema, è scivolato nel territorio funzionale. I requisiti di business dovrebbero rimanere validi anche di fronte a un cambio radicale della soluzione tecnica. Se cambiando fornitore metà del tuo BRD perdesse di validità, significa che quella metà non era affatto composta da requisiti di business.

Chi redige un documento dei requisiti di business e chi lo firma

Viene redatto dal Business Analyst, oppure dal Product Owner o dal Project Manager nei contesti in cui non è presente un analista dedicato. Deve essere scritto con gli stakeholder e non per loro, perché un BRD redatto in isolamento finisce per essere firmato senza essere letto: il che è peggio che non avere alcun BRD.

Viene firmato dalle figure che possono esserne ritenute responsabili: lo sponsor di progetto, il titolare del budget e i responsabili di ogni funzione il cui lavoro subirà cambiamenti. Si aggiunge l'IT o il responsabile del delivery, per confermare che i requisiti siano stati compresi, non necessariamente che siano realizzabili.

La firma più importante è quella della persona a cui, al quarto mese, verrà chiesto se questo fosse stato effettivamente concordato.

Come scrivere un documento dei requisiti di business

1. Definisci innanzitutto l'obiettivo di business, espresso come valore numerico. Se nessuno è in grado di quantificare il risultato atteso, la raccolta dei requisiti produrrà un semplice elenco di funzionalità anziché un documento strutturato.

2. Individua gli stakeholder e le responsabilità decisionali prima di raccogliere qualsiasi dato. Sapere chi ha l'autorità di approvare previene la maggior parte dei ripensamenti tardivi.

3. Documenta lo stato attuale in modo trasparente, includendo le soluzioni di ripiego (workaround). È proprio lì che si nascondono i veri requisiti.

4. Raccogli i requisiti attraverso interviste e osservazione diretta, non solo tramite workshop. I workshop fanno emergere ciò che le persone dicono di volere; l'osservazione diretta mostra ciò che fanno realmente.

5. Scrivi ciascun requisito corredandolo subito dei relativi criteri di accettazione. Aggiungere i criteri in un secondo momento significa doverli ricostruire a memoria.

6. Prioritizza con il metodo MoSCoW e mantieni sotto controllo la percentuale di requisiti definiti "Must-have".

7. Registra esplicitamente ipotesi, vincoli e dipendenze. Le ipotesi non formalizzate si trasformano inevitabilmente in controversie.

8. Costruisci la matrice di tracciabilità man mano che procedi, anziché rimandarla alla fine.

9. Condividi il documento per la revisione indicando una scadenza e un revisore designato per ciascuna sezione. Una generica richiesta di feedback inviata a una mailing list genera solo silenzio.

10. Esponi il documento agli stakeholder in una sessione dedicata prima di richiedere le firme, quindi congela la versione (baseline) e gestisci qualsiasi modifica successiva in modo formale.

Varianti del modello di documento dei requisiti di business

I progetti regolamentati e le implementazioni ERP utilizzano versioni dedicate dello stesso documento:

• Life sciences: un modello di specifica dei requisiti utente (User Requirements Specification - URS) aggiunge requisiti verificabili a supporto dei processi di convalida.

• SAP blueprint: il BRD diventa parte integrante della documentazione di Business Blueprint per ciascun processo.

• SAP build: ciascun gap approvato confluisce in un documento di specifica funzionale da cui gli sviluppatori SAP partono per la realizzazione.

• Ambito di processo: un modello BPML elenca ogni processo incluso nell'ambito prima della stesura dei requisiti.

• Progettazione dei processi: un modello BPD descrive dettagliatamente come verrà eseguito ogni processo futuro (to-be), passaggio dopo passaggio.

Una precisazione sulla versione Agile: un BRD e un backlog non sono in competizione. Il BRD stabilisce il perché e le esigenze del business, che cambiano lentamente. Il backlog definisce ciò che viene sviluppato successivamente, elemento che evolve continuamente. I team che abbandonano del tutto il BRD tendono a perdere di vista il motivo originario delle scelte, ritrovandosi poi a discuterne animatamente.

Migliori pratiche

• Formula requisiti che qualcuno possa effettivamente rifiutare. La vaghezza viene scambiata per consenso e genera contrasti in seguito.

• Un solo requisito per riga. Qualsiasi frase che contenga la congiunzione "e" nasconde probabilmente due requisiti distinti.

• Definisci subito i criteri di accettazione, senza rimandarli a un secondo momento.

• Numera ogni elemento e non modificare mai la numerazione: piuttosto, dismetti gli ID non più validi.

• Traccia la fonte di provenienza di ciascun requisito.

• Non inserire dettagli tecnici o soluzioni. Nel momento in cui nomini una schermata o un campo, hai iniziato la fase di progettazione.

• Chiarisci ogni termine ambiguo nel glossario. Parole come "richiesta", "utente" e "approvato" assumono significati diversi a seconda del reparto.

• Fissa la baseline della versione al momento della firma e gestisci le modifiche successive in modo formale.

• Mantieni ben visibile l'elenco di ciò che è escluso dall'ambito (out-of-scope): è lo strumento più efficace in assoluto contro lo scope creep.

Errori comuni

• Requisiti non verificabili. Termini come "intuitivo" e "robusto" non possono essere testati e finiscono per essere interpretati durante lo sviluppo da chiunque si trovi a implementarli.

• Assenza di priorità, per cui tutto risulta obbligatorio fino a quando le scadenze non impongono tagli indiscriminati.

• Soluzioni mascherate da requisiti, che vincolano il design prima che siano state valutate le diverse opzioni.

• Mancanza di criteri di accettazione, trasformando la definizione di "completato" in una trattativa.

• Omissione della sezione relativa all'ambito escluso (out-of-scope), il rimedio più economico per prevenire l'ampliamento incontrollato dei requisiti.

• Documento redatto per gli stakeholder anziché con loro, con il rischio che venga firmato senza essere letto.

• Ipotesi non documentate. Ogni progetto ne ha, e quelle non formalizzate sono proprio quelle che causano problemi.

• Mancato aggiornamento dopo l'approvazione iniziale. I requisiti evolvono e una baseline non manutenuta smette di essere il punto di riferimento affidabile per il team.

• Assenza di tracciabilità, con il risultato che i requisiti dimenticati vengono scoperti solo durante i test di accettazione utente (UAT).

Documenta lo stato attuale registrandolo

Apri il modello in Trupeer AI, applica il tuo brand kit in modo che il BRD sia allineato agli altri documenti di progetto e modifica direttamente qualsiasi sezione. Le istruzioni di configurazione sono disponibili nella guida ai modelli.

La sezione sullo stato attuale è spesso l'anello debole dei BRD: descrivere come funziona un processo oggi richiede più tempo del previsto e finisce sempre per trascurare le prassi non ufficiali. Registra invece il processo esistente una sola volta: Trupeer AI genererà la documentazione scritta dello stato attuale acquisendo automaticamente gli screenshot, insieme a un walkthrough video narrato da allegare come appendice. I fornitori chiamati a formulare un preventivo comprenderanno una registrazione di due minuti molto più rapidamente di quattro pagine di testo.

Registralo. Documentalo. Traducilo in oltre 65 lingue per i team di delivery distribuiti. Salvalo nella tua knowledge base. Fai tutto con Trupeer.

Domande frequenti

È disponibile un modello gratuito di documento dei requisiti di business in Word?

Sì. Word è il formato principale: include note guida in ogni sezione da eliminare man mano che scrivi, oltre alla tabella dei requisiti e al blocco di approvazione già preimpostati. Download gratuito, nessuna registrazione richiesta, nessun watermark.

Posso scaricare gratuitamente un modello di documento dei requisiti di business in formato Word?

Sì. Tutti i formati sono scaricabili gratuitamente e senza dover creare un account. Puoi utilizzarlo per tutti i progetti che desideri.

Esiste un modello di documento dei requisiti di business in formato Word .doc?

Sì, è inclusa una versione in formato .doc per i sistemi di gestione documentale più datati e gli archivi che non gestiscono in modo ottimale i file .docx.

È disponibile un modello gratuito di documento dei requisiti di business in PDF?

Sì. Il PDF rappresenta il formato baseline in sola lettura, ideale da distribuire dopo la firma per evitare che la versione approvata venga modificata accidentalmente.

È disponibile un esempio di documento dei requisiti di business in PDF?

Sì. L'esempio pratico relativo al sistema di gestione delle note spese illustrato sopra è disponibile come file PDF completo, corredato da dieci requisiti, criteri di accettazione, priorità MoSCoW, ipotesi e rischi. Consultare un BRD completo è il modo più rapido per comprendere quale livello di dettaglio sia necessario raggiungere.

Dove posso scaricare un modello di documento dei requisiti in Word?

In questa pagina, nei formati Word, .doc, Google Docs, Excel e PDF. Tutti gratuiti. Se hai bisogno della specifica funzionale anziché dei requisiti di business, si tratta di un documento separato, la cui differenza è illustrata in dettaglio più sopra.

Che cos'è un BRD?

Un documento dei requisiti di business (Business Requirements Document). Definisce le esigenze dell'azienda rispetto a un progetto e le relative motivazioni, prima di stabilire le modalità di sviluppo, e costituisce il documento formale firmato dagli stakeholder a conferma di una visione condivisa.

Cosa dovrebbe includere un documento dei requisiti di business?

Controllo del documento, executive summary, obiettivi di business misurabili, definizione del problema, ambito con esclusioni esplicite, stakeholder, stato attuale, requisiti numerati con priorità e criteri di accettazione, ipotesi, vincoli, dipendenze, rischi, costi e benefici, tempistiche, criteri di successo, glossario e blocco di approvazione.

Qual è la differenza tra requisiti di business e requisiti funzionali?

I requisiti di business indicano cosa serve all'azienda e perché, a prescindere dalla soluzione specifica. I requisiti funzionali stabiliscono cosa deve fare il sistema per soddisfare tali necessità. "Le richieste devono essere rimborsate entro 10 giorni lavorativi" è un requisito di business. "Il sistema instrada le richieste all'approvatore indicato nella linea gerarchica HR" è funzionale. Un requisito di business deve rimanere valido anche in caso di cambio del fornitore.

Quanto dovrebbe essere lungo un documento dei requisiti di business?

Tra le dieci e le venti pagine per un progetto di medie dimensioni. I progetti più piccoli possono essere gestiti in cinque pagine. Se si superano le trenta, la sezione dei requisiti ha quasi certamente inglobato dettagli di progettazione funzionale che dovrebbero trovare spazio altrove.

Chi redige il documento dei requisiti di business?

Il Business Analyst, oppure il Product Owner o il Project Manager se non è presente un analista dedicato. Dovrebbe essere elaborato a stretto contatto con gli stakeholder e non per loro conto, poiché un BRD redatto senza confronto rischia di essere firmato senza essere letto.

Chi approva formalmente un BRD?

Lo sponsor aziendale, il titolare del budget e i responsabili di tutte le funzioni operative impattate dai cambiamenti, oltre al responsabile IT o di delivery che attesta la chiara comprensione dei requisiti. L'approvazione dovrebbe avvenire a seguito di una sessione di revisione congiunta e non tramite un semplice invio per email.

Quanti requisiti dovrebbe contenere un BRD?

Tutti quelli strettamente necessari per definire l'ambito. Tuttavia, se superi gli ottanta requisiti, è opportuno verificare che non siano stati inseriti dettagli funzionali superflui. Un valido indicatore è la percentuale dei requisiti "Must-have": se supera il 60% circa, significa che la prioritizzazione non è stata effettuata correttamente.

Che cos'è una matrice di tracciabilità?

Una tabella che collega ogni requisito all'obiettivo di business di riferimento, alla specifica funzionale che lo implementa e al caso di test che ne verifica il funzionamento. Consente di individuare requisiti che non verrebbero mai testati e funzionalità in fase di sviluppo non collegate ad alcuna richiesta di business.

Posso personalizzare questo modello di documento dei requisiti di business?

Sì, ciascuna versione è interamente modificabile. Elimina le sezioni non pertinenti anziché lasciare intestazioni vuote e adatta la tabella dei requisiti al tuo schema di priorità se non utilizzi il metodo MoSCoW. In Trupeer AI puoi inoltre applicare il tuo brand kit affinché il BRD risulti visivamente coerente con il resto della documentazione di progetto.

Modelli correlati

• Modello di piano di progetto

• Modello di piano di project management

• Modello di documentazione di progetto

• Modello di documentazione tecnica

• Modello di documentazione software

• Modelli di documentazione di test

• Modello di processo aziendale

• Modello di piano di change management

• Modello di business plan