Modello di documento dei requisiti di business (BRD)
Questo modello gratuito di business requirements document ti offre un BRD strutturato in due parti: una panoramica del BRD per obiettivi, scope, stakeholder e approvazione, e un registro dei requisiti in cui ogni requisito ha ID, tipo, motivazione, priorità MoSCoW, fonte, criteri di accettazione e stato. Scaricalo per Google Sheets, Excel o PDF, nella versione base, avanzata o esperta.
Punti chiave
- Un business requirements document (BRD) registra di cosa ha bisogno il business da un progetto e perché, e come saprai che ogni esigenza è stata soddisfatta. Descrive l'esigenza, non la soluzione.
- Il modello ha due schede: una panoramica del BRD in dieci sezioni e un registro dei requisiti con otto colonne e menu a tendina per tipo, priorità e stato.
- I buoni requisiti sono indipendenti dalla soluzione, verificabili, scritti uno per riga e collegati a un obiettivo di business e a una fonte.
- Prioritizza con MoSCoW e sii rigoroso: se tutto è un Must, niente lo è.
- Ottieni l'approvazione prima che inizino progettazione o approvvigionamento, poi controlla le modifiche tramite un processo di richiesta di modifica.
Download gratuito · senza registrazione
Scarica il modello di business requirements document
Scegli livello e formato: Google Sheets, Excel o un PDF pronto per la stampa. I fogli di calcolo includono menu a discesa, formule e righe di esempio che puoi sovrascrivere.
Il modello completo con tutte le schede, i menu a discesa e le formule.
Che cos'è un business requirements document?
A business requirements document (BRD) è un documento che definisce di cosa ha bisogno un'azienda da un progetto o da una soluzione, perché ne ha bisogno e come verrà misurato il successo. Comprende obiettivi, scope, stakeholder, vincoli e un elenco di requisiti prioritizzati con criteri di accettazione. Descrive cosa è necessario, non come verrà realizzato.
Un BRD viene di solito scritto nelle prime fasi di un progetto, dopo che l'idea è stata approvata in un business case o project charter e prima che inizino progettazione, sviluppo o approvvigionamento. Dà a chi realizzerà o acquisterà la soluzione un obiettivo chiaro e condiviso, e dà allo sponsor una base per accettare il risultato alla fine.
Di solito i BRD sono scritti dai business analyst, ma nei progetti più piccoli spesso se ne occupa il project manager o il product owner. Chiunque lo scriva, i contenuti provengono dagli stakeholder: il BRD è una registrazione delle loro esigenze, verificata e concordata.
Per un quadro più ampio dei requisiti di alto livello e dettagliati, consulta la nostra guida ai requisiti di progetto.
Anteprima del modello di BRD
La prima scheda è la panoramica del BRD. Ogni sezione ha un breve suggerimento nella colonna Indicazioni; le tue risposte vanno in Il tuo contenuto.
| Sezione | Indicazioni | Il tuo contenuto |
|---|---|---|
| Nome del progetto e responsabile | ||
| Executive summary | L'esigenza e il risultato proposto, in breve. | |
| Obiettivi di business | Obiettivi misurabili che il progetto supporta. | |
| Contesto / situazione attuale | Come funzionano le cose oggi e quali sono i problemi. | |
| Ambito | Nello scope e fuori scope. | |
| Stakeholder | Chi è coinvolto e chi approva. |
Le righe di esempio sono solo indicative: sostituiscile con le tue.
Cosa contiene il modello di BRD
Il modello è un foglio di calcolo con due schede che lavorano insieme. La panoramica del BRD definisce il contesto in dieci brevi sezioni; la scheda Requisiti elenca ogni requisito in un registro strutturato e filtrabile.
- panoramica del BRD: Sezione, Indicazioni, Il tuo contenuto
- Requisiti: ID, Requisito, Tipo, Motivazione, Priorità (MoSCoW), Fonte, Criteri di accettazione, Stato
Scheda Panoramica del BRD
Tre colonne (Sezione, Indicazioni, Il tuo contenuto) e dieci sezioni: nome del progetto e responsabile, executive summary, obiettivi di business, contesto / situazione attuale, scope, stakeholder, ipotesi e vincoli, requisiti (che rimanda alla scheda Requisiti), misure di successo e approvazione.
Scheda Requisiti
Otto colonne: ID, Requisito, Tipo, Motivazione, Priorità (MoSCoW), Provenienza, Criteri di accettazione e Stato. Nelle versioni avanzata ed esperta, tre colonne hanno menu a tendina:
- Tipo: Funzionale, Non funzionale, Vincolo, Dati, Reporting.
- Priorità (MoSCoW): Must, Should, Could, Won't.
- Stato: Bozza, In revisione, Approvato, Respinto, Rinviato.
Quattro requisiti di esempio per un progetto di portale clienti mostrano come compilare ogni colonna; sovrascrivili con i tuoi.
Quale versione dovresti scaricare?
| Versione | Cosa include | Ideale per |
|---|---|---|
| Principiante | Solo la scheda Panoramica del BRD: dieci sezioni con indicazioni, più righe vuote | Progetti piccoli in cui i requisiti stanno in pochi paragrafi |
| Avanzato | Entrambe le schede: la panoramica del BRD e il registro completo dei requisiti a otto colonne con i menu a tendina di Tipo, Priorità (MoSCoW) e Stato | La maggior parte dei progetti con un business analyst o con diversi gruppi di stakeholder |
| Esperto | Tutto ciò che c'è nella versione avanzata, più una scheda di istruzioni, una dashboard che conta automaticamente i requisiti per tipo, priorità MoSCoW e stato, stati con codici colore (approvato, in revisione, respinto) e una scheda di cronologia delle revisioni | Progetti più grandi, procedure di acquisto e PMO che rendicontano l'avanzamento dei requisiti |
Cosa includere in un business requirements document
Le dieci sezioni della panoramica danno ai lettori il contesto di cui hanno bisogno prima di arrivare ai requisiti veri e propri. Ecco cosa scrivere in ciascuna.
| Sezione | Cosa scrivere | Esempio |
|---|---|---|
| Nome del progetto e responsabile | Il progetto e il responsabile di business che risponde dei requisiti | Customer Portal; Responsabile del servizio clienti |
| Executive summary | L'esigenza e il risultato proposto in poche frasi. Scrivilo per ultimo | I clienti non possono visualizzare le fatture o reimpostare le password da soli, quindi chiamano l'assistenza. Un portale self-service ridurrà le chiamate. |
| Obiettivi di business | Obiettivi misurabili che il progetto supporta | Ridurre del 30% le chiamate relative all'account entro 6 mesi dal lancio |
| Contesto / situazione attuale | Come funzionano le cose oggi e quali sono i problemi | Tutte le modifiche all'account passano per il team di assistenza via telefono o email |
| Ambito | Cosa è nello scope e cosa è fuori scope | Dentro: vista dell'account, fatture, reimpostazione della password. Fuori: app mobile, pagamenti |
| Stakeholder | Chi è coinvolto e chi approva | Servizio clienti, IT, Finanza, Ufficio legale, clienti |
| Ipotesi e vincoli | Cosa dai per scontato e i limiti entro cui devi lavorare | API di fatturazione disponibile entro febbraio; i dati devono restare nell'UE |
| Requisiti | Un rimando alla scheda Requisiti | Vedi la scheda Requisiti (da BR-01 a BR-04) |
| Misure di successo | Come giudicherai il successo dopo la consegna | Volumi di chiamate, adozione del portale, soddisfazione dei clienti |
| Approvazione | Nomi, ruoli e date degli approvatori | Sponsor, Head of IT, Data Protection Officer |
Molti formati di BRD pubblicati includono anche una analisi costi-benefici. Se il tuo progetto ha già un business case, inserisci un link anziché ripetere i numeri; il BRD dovrebbe restare concentrato sulle esigenze. La nostra guida all' analisi costi-benefici spiega il metodo, se ne hai bisogno.
Come scrivere buoni requisiti di business
Il registro dei requisiti è il cuore del BRD. Un buon requisito è:
- Necessario: supporta un obiettivo di business. Se non sai dire quale, mettilo in discussione.
- Indipendente dalla soluzione: indica cosa serve, non come realizzarlo. "I clienti devono poter reimpostare la password senza contattare l'assistenza" lascia aperta la progettazione.
- Chiaro: una sola interpretazione ragionevole. Evita parole come "intuitivo", "veloce" o "flessibile" senza una misura.
- Verificabile: qualcuno può verificare che sia stato soddisfatto. È a questo che serve la colonna dei criteri di accettazione.
- Atomico: un requisito per riga. Suddividi tutto ciò che è unito da una "e".
- Tracciabile: ha un ID, una fonte (una persona, un documento, una normativa o dei dati) e una motivazione.
| Requisito debole | Requisito migliore | Perché è migliore |
|---|---|---|
| Il portale deve essere veloce | Le pagine devono caricarsi in meno di 2 secondi (95° percentile) | Misurabile e verificabile |
| Usare un link di reimpostazione della password inviato via email tramite il CRM | I clienti devono poter reimpostare la password senza contattare l'assistenza | Indica l'esigenza, non la soluzione |
| I clienti possono vedere le fatture e aggiornare il proprio indirizzo | Due righe: una per visualizzare le fatture, una per aggiornare l'indirizzo | Un requisito per riga, così che ciascuno possa essere prioritizzato e testato |
| Rispettare le regole sui dati | I dati dei clienti devono essere archiviati nell'UE | Specifico, con una fonte chiara (Ufficio legale / policy GDPR) |
Tipi di requisiti
Il menu a tendina Tipo del modello rende il registro facile da filtrare: Funzionali (cosa deve fare la soluzione), Non funzionali (quanto bene deve farlo, ad esempio prestazioni, disponibilità, sicurezza o usabilità), Vincolo (limiti come normative, tecnologia o budget), Dati e Reporting.
Se la tua organizzazione segue la BABOK Guide dell'IIBA, troverai una classificazione più ampia: requisiti di business (obiettivi e risultati), requisiti degli stakeholder (le esigenze di gruppi specifici), requisiti della soluzione (suddivisi in funzionali e non funzionali) e requisiti di transizione (ciò che serve per passare dallo stato attuale a quello futuro, come migrazione dei dati o formazione). Puoi aggiungerli come opzioni aggiuntive nell'elenco Tipo.
Prioritizzare con MoSCoW
MoSCoW suddivide i requisiti in quattro gruppi, che la colonna Priorità del modello utilizza:
| Priorità | Significato | Test |
|---|---|---|
| Must | Senza di esso, la soluzione fallisce o non è conforme alla legge o sicura | Annulleresti il lancio se mancasse? |
| Should | Importante, ma esiste una soluzione alternativa | Doloroso da escludere, ma la soluzione funziona comunque |
| Could | Auspicabile se tempi e budget lo consentono | Utile ma non essenziale; il primo a saltare sotto pressione |
| Won't (per questa volta) | Concordato come fuori scope per ora | Registrato così che la decisione sia visibile |
L'errore comune è contrassegnare quasi tutto come Must. Poni a ciascuno la domanda "annulleresti il lancio?". Registrare gli elementi Won't è altrettanto utile: evita che la stessa richiesta si ripresenti ogni mese.
Scrivere i criteri di accettazione
I criteri di accettazione descrivono come confermerai che un requisito è stato soddisfatto. Rendili specifici e osservabili: "reimpostazione completata in meno di 2 minuti", "tutte le fatture dal 2024 visibili", "regione di hosting confermata nell'UE". Diventano la base per i test e per l'accettazione da parte dello sponsor alla fine del progetto, e si collegano naturalmente al tuo approccio di gestione della qualità .
Come compilare il modello di BRD passo dopo passo
- Parti dalla charter o dal business case. Copia obiettivi e scope, così che il BRD resti coerente con quanto approvato.
- Individua gli stakeholder. Elenca tutti coloro che usano, gestiscono, pagano o regolamentano la soluzione. La nostra guida all' gestione degli stakeholder mostra come analizzarli.
- Descrivi la situazione attuale. Registra come funzionano le cose oggi e cosa non va. Evidenze come i dati sulle chiamate o i risultati dei sondaggi aiutano.
- Raccogli i requisiti. Usa interviste, workshop, osservazione, analisi documentale e dati. Annota man mano la fonte di ciascun requisito; i verbali di riunione dei workshop sono una registrazione utile.
- Scrivi ogni requisito su una riga dedicata. Assegnagli un ID, una formulazione chiara, un tipo e una motivazione collegata a un obiettivo.
- Prioritizza e aggiungi i criteri di accettazione. Concorda le priorità MoSCoW con il responsabile di business e scrivi un test per ogni requisito.
- Fai la review con gli stakeholder. Ripercorri il registro, risolvi i conflitti e aggiorna gli stati da Bozza a In revisione ad Approvato.
- Ottieni l'approvazione e fissa la baseline. Chiedi agli approvatori nominati di firmare la panoramica. Da quel momento, le modifiche passano per il controllo delle modifiche usando una richiesta di modifica.
Esempio di business requirements document
Le righe di esempio del modello descrivono un progetto di portale clienti. Ecco il registro dei requisiti così come viene fornito, con una nota sul perché ogni riga è scritta in quel modo.
| ID | Requisito | Tipo | Priorità | Criteri di accettazione | Stato |
|---|---|---|---|---|---|
| BR-01 | I clienti devono poter reimpostare la password senza contattare l'assistenza | Funzionali | Must | Reimpostazione completata in meno di 2 minuti | Approvato |
| BR-02 | Il portale deve mostrare le fatture degli ultimi 24 mesi | Funzionali | Must | Tutte le fatture dal 2024 visibili | Approvato |
| BR-03 | Le pagine devono caricarsi in meno di 2 secondi | Non funzionali | Should | 95° percentile sotto i 2 s | Bozza |
| BR-04 | I dati devono essere archiviati nell'UE | Vincolo | Must | Regione di hosting confermata | Approvato |
- BR-01 deriva dai dati dell'assistenza e serve direttamente l'obiettivo di ridurre le chiamate, quindi è un Must.
- BR-02 deriva da un sondaggio tra i clienti e ha un limite chiaro (24 mesi), che evita una migrazione dei dati senza confini.
- BR-03 è un requisito non funzionale emerso dalla ricerca UX. È ancora una Bozza perché l'obiettivo di 2 secondi non è stato ancora concordato con l'IT.
- BR-04 è un vincolo posto dall'Ufficio legale sulla base della policy GDPR. È un Must perché la soluzione non potrebbe andare live senza di esso.
Ogni riga è riconducibile a un obiettivo (meno chiamate), a una fonte e a una motivazione. È questa tracciabilità che ti permette di rispondere a "perché lo stiamo realizzando?" sei mesi dopo, e di eliminare per primi i requisiti giusti se il tempo stringe.
BRD, FRD, SRS, PRD e user story a confronto
I documenti dei requisiti si sovrappongono e i nomi variano da un'organizzazione all'altra. Questa tabella mostra le distinzioni abituali.
| Documento | Focus | Autore tipico | Lettori principali |
|---|---|---|---|
| Business requirements document (BRD) | Di cosa ha bisogno il business e perché; obiettivi, scope, requisiti di alto livello | Business analyst | Sponsor, stakeholder di business, team di delivery |
| Functional requirements document (FRD) / specifica funzionale | Come si comporterà la soluzione per soddisfare i requisiti di business | Business analyst o systems analyst | Designer, sviluppatori, tester |
| Software requirements specification (SRS) | Requisiti funzionali e non funzionali dettagliati per un sistema software | Systems analyst o architetto | Sviluppatori, tester, fornitori |
| Product requirements document (PRD) | Cosa dovrebbe fare un prodotto o una release per i suoi utenti, spesso funzionalità per funzionalità | Product manager | Team di prodotto, design e ingegneria |
| User story | Piccole porzioni di funzionalità orientate all'utente, con criteri di accettazione | Il Product Owner insieme al team | Team Scrum o Agile |
| Statement of work (SOW) | Cosa consegnerà un fornitore e a quali condizioni | Acquirente, spesso con l'ufficio acquisti | Fornitori |
Un BRD alimenta spesso una RFQ oppure un statement of work quando la soluzione verrà acquistata anziché realizzata internamente, e alimenta la dichiarazione dello scope in ogni progetto.
Usare un BRD nei progetti Agile
I team Agile raramente scrivono un lungo BRD all'inizio, ma il ragionamento che c'è dietro resta utile. Un BRD breve che registri obiettivi, confini dello scope, vincoli e principali requisiti di business dà al Product Owner e al team un obiettivo condiviso.
I dettagli si spostano poi nel Product Backlog sotto forma di user story, ciascuna riconducibile all'ID di un requisito di business. I requisiti non funzionali e i vincoli diventano spesso parte della Definition of Donedel team. La versione base del modello, cioè la sola scheda panoramica, è di solito sufficiente a questo scopo; abbinala al nostro modello di user story o modello di product backlog.
Errori comuni nel BRD
- Progettare la soluzione. Layout delle schermate e scelte tecnologiche appartengono alla progettazione, non al BRD.
- Parole vaghe. "Facile", "veloce" e "sicuro" hanno bisogno di una misura, altrimenti non si possono verificare.
- Tutto è un Must. Senza priorità reali, il team non può fare compromessi quando il tempo stringe.
- Stakeholder mancanti. I requisiti di Ufficio legale, Finanza, Sicurezza od operations emergono spesso tardi e causano rilavorazioni.
- Nessuna fonte o motivazione. I requisiti che nessuno sa spiegare sono difficili da difendere e facili da gonfiare oltre il necessario.
- Saltare l'approvazione. Senza approvazione, il BRD è una bozza e lo scope resta aperto. Vedi scope creep.
- Considerarlo fisso per sempre. I requisiti cambiano. Fissa la baseline del BRD approvato e gestisci le modifiche apertamente invece di modificarlo in silenzio.
Modelli e guide correlati
Un BRD si inserisce in una catena di documenti. Prima vengono il modello di business case e modello di project charter; insieme a esso, il modello di problem statement e modello di gap analysis inquadrano l'esigenza; dopo di esso, il modello di ambito di progetto, modello di user story e modello di richiesta di modifica portano i requisiti nella delivery. Una modello di matrice RACI ti aiuta a concordare chi li scrive, li rivede e li approva.
Modello di dichiarazione dell'ambito del progettoModello di ambito del progetto gratuito: obiettivi, deliverable, cosa rientra e cosa non rientra nell'ambito, accettazione…Principiante · Avanzato · Esperto
Modello di user storyModello di user story gratuito: Come / voglio / in modo da, criteri di accettazione, epic, stima…Principiante · Avanzato · Esperto
Modello di gap analysisModello di gap analysis gratuito che confronta stato attuale e futuro, assegna un punteggio a ogni divario e…Principiante · Avanzato · Esperto
Modello di dichiarazione del problemaModello di dichiarazione del problema gratuito: chi è coinvolto, cosa, dove e quando, impatto, evidenze,…Principiante · Avanzato · Esperto
Modello di analisi delle cause radice (5 perché)Modello di analisi delle cause radice gratuito con i 5 perché: dichiarazione del problema, catena dei perché, causa…Principiante · Avanzato · Esperto- Requisiti di progetto: requisiti di alto livello e tecnici
- Gestione degli stakeholder di progetto: identificare, analizzare, coinvolgere
- Ambito del progetto: definizione, dichiarazione dell'ambito ed esempi
- User story: come scriverle, con esempi
Per capire come si integrano i requisiti di alto livello e quelli dettagliati, leggi la nostra guida ai requisiti di progetto.
Domande frequenti
Che cos'è un modello di business requirements document?
Un modello di business requirements document è una struttura pronta per registrare obiettivi di business, scope, stakeholder, vincoli e requisiti di un progetto, ciascuno con priorità e criteri di accettazione. Questo ha una scheda di panoramica del BRD e un registro dei requisiti.
Questo modello di BRD è gratuito?
Sì. Il modello di business requirements document si scarica gratuitamente in Google Sheets, Excel e PDF, senza registrazione.
Cosa dovrebbe includere un business requirements document?
Un executive summary, obiettivi di business, contesto e situazione attuale, scope, stakeholder, ipotesi e vincoli, i requisiti veri e propri con priorità e criteri di accettazione, misure di successo e approvazione.
Chi scrive un business requirements document?
Di solito un business analyst, in collaborazione con gli stakeholder, lo sponsor e il project manager. Nei progetti più piccoli spesso lo scrive il project manager o il product owner.
Chi approva il BRD?
Lo approva lo sponsor o il responsabile di business, di solito insieme ai responsabili dei principali gruppi di stakeholder e agli eventuali specialisti, come Ufficio legale o Sicurezza, i cui requisiti vi sono contenuti.
Qual è la differenza tra un BRD e un FRD?
Un BRD indica di cosa ha bisogno il business e perché. Un functional requirements document (FRD) descrive come si comporterà la soluzione per soddisfare tali esigenze, con un livello di dettaglio sufficiente per designer, sviluppatori e tester.
Quali sono i tipi di requisiti di business?
Questo modello usa funzionale, non funzionale, vincolo, dati e reporting. La BABOK Guide dell'IIBA classifica i requisiti come requisiti di business, degli stakeholder, della soluzione (funzionali e non funzionali) e di transizione.
Quanto dovrebbe essere lungo un BRD?
Il più breve possibile pur restando chiaro. Un progetto piccolo può richiedere poche pagine; un grande sistema o una procedura di acquisto possono richiederne molte di più. Tieni il contesto nella panoramica e metti ogni requisito su una riga dedicata del registro.
Quando bisogna scrivere un BRD?
Dopo che il progetto è stato approvato in linea di principio tramite un business case o una charter, e prima che inizino progettazione, sviluppo o approvvigionamento.
Come si prioritizzano i requisiti di business?
Usa MoSCoW: Must, Should, Could e Won't have this time. Concorda le priorità con il responsabile di business e verifica ogni Must chiedendoti se annulleresti il lancio senza di esso.
I team Agile possono usare un business requirements document?
Sì, ad alto livello. Usa un BRD breve per obiettivi, scope, vincoli e requisiti di business principali, poi registra i dettagli come user story nel product backlog.
Cosa succede se i requisiti cambiano dopo l'approvazione?
Apri una richiesta di modifica, valuta l'impatto su scope, cronoprogramma e costi, e ottieni l'approvazione prima di aggiornare il BRD. Registra la modifica e la relativa decisione, così che la baseline resti chiara.
Posso usare il modello di BRD in Word?
Il download è un foglio di calcolo e un PDF. Puoi copiare le sezioni della panoramica in un documento Word se la tua organizzazione preferisce Word, e mantenere il registro dei requisiti nel foglio di calcolo, dove è più facile filtrarlo e ordinarlo.