Un documento dei requisiti aziendali (BRD) è il ponte tra gli stakeholder aziendali e i team tecnici: cattura ciò di cui l'azienda ha bisogno e lo traduce in requisiti che gli sviluppatori possono implementare. Con Trupeer, puoi risparmiare ore nella stesura dei BRD partendo da un modello di documento dei requisiti aziendali gratuito, personalizzandolo con le tue linee guida del brand e trasformando i lunghi BRD in video presentazioni che tutti possono effettivamente fruire.

I progetti falliscono raramente perché nessuno ha messo per iscritto i requisiti. Falliscono perché ciò che è stato scritto era troppo vago per poter essere contestato. Tutti firmano un documento in cui si afferma che il sistema dovrebbe essere "facile da usare e veloce" e quattro mesi dopo scoprono che intendevano tre cose diverse.

Un documento dei requisiti aziendali vale la pena di essere scritto quando rende possibile il disaccordo prima dell'inizio dello sviluppo, piuttosto che dopo. Questo modello è costruito per questo: ogni requisito è numerato, prioritizzato e dotato di criteri di accettazione abbastanza specifici da poter essere discussi fin da ora.

Scarica il modello di documento dei requisiti aziendali

Gratuito, modificabile, senza filigrana. La maggior parte dei team utilizza Word per il documento ed Excel per la tabella dei requisiti una volta che il conteggio supera la trentina.

Cos'è un documento dei requisiti aziendali?

Un documento dei requisiti aziendali, o BRD, stabilisce ciò di cui un'azienda ha bisogno da un progetto e perché, prima che si decida come realizzarlo. Definisce il problema, l'ambito, gli stakeholder, i requisiti stessi e i criteri in base ai quali verrà giudicato il risultato.

La sua vera funzione è l'accordo. Un BRD è l'elemento che tutti firmano per confermare di comprendere la stessa cosa, motivo per cui la prova dell'utilità di un BRD non è se si legge bene, ma se è abbastanza specifico da consentire a qualcuno di opporvisi.

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 visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente l'intero layout e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il 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 come tuo.

Passaggio 6: Visualizza l'anteprima e perfeziona il modello

Quando desideri vedere 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 aziendali puoi:

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

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

• Rimanere in linea con il brand: Applica il tuo logo, i font e i colori utilizzando il brand kit di Trupeer.

• Comunicare chiaramente: Converti BRD complessi in video presentazioni per le revisioni degli stakeholder.

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

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

Perché hai bisogno di un documento dei requisiti aziendali

• L'ambito diventa qualcosa di concreto a cui fare riferimento piuttosto che da ricordare. La maggior parte delle controversie sull'ambito sono fallimenti della documentazione, non malafede.

• I requisiti ottengono delle priorità, così quando il tempo stringe si effettuano tagli deliberati anziché tagliare ciò che è rimasto.

• Le ipotesi vengono messe per iscritto, ed è proprio in quel momento che qualcuno si accorge di quella errata.

• I criteri di accettazione esistono prima della fase di sviluppo, quindi il concetto di "fatto" non viene deciso da chi alza di più la voce alla fine.

• Il passaggio di consegne sopravvive all'uscita delle persone. I progetti che perdono il proprio business analyst a metà percorso sono quelli in cui un BRD si ripara da solo ampiamente del suo costo.

• I fornitori possono fare un preventivo basandosi su qualcosa di reale. Un BRD vago produce un preventivo ampio e un progetto ricco di richieste di modifica.

Cosa include un documento dei requisiti aziendali

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

• Sintesi esecutiva: che cos'è il progetto e perché, in un paragrafo.

• Obiettivi aziendali, espressi come risultati misurabili anziché come attività.

• Contesto e definizione del problema: cosa sta succedendo ora e quanto costa.

• Ambito: cosa è incluso ed esplicitamente cosa è escluso.

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

• Stato attuale, per come è effettivamente.

• Requisiti aziendali, numerati, prioritizzati, ciascuno con criteri di accettazione.

• Ipotesi, vincoli e dipendenze.

• Rischi, con relativi responsabili.

• Riepilogo dei costi e dei benefici e rendimento atteso.

• Cronologia e tappe fondamentali (milestones).

• Criteri di successo per il progetto nel suo complesso.

• Glossario, perché la metà di tutte le controversie sui requisiti sono controversie terminologiche.

• Blocco di firma per approvazione.

• Appendici: mappe dei processi, dati, schermate, analisi di supporto.

La struttura del modello

Da dieci a venti pagine è la norma per un progetto di medie dimensioni. Oltre le trenta, la tabella dei requisiti ha solitamente assorbito decisioni di progettazione che appartengono a una specifica funzionale.

Come scrivere un requisito che superi la revisione

Questa è l'abilità fondamentale. Un requisito è ben scritto quando due persone in disaccordo sanno entrambe di essere in disaccordo leggendolo.

Debole: Il sistema deve essere facile da usare.
Migliore: Un nuovo utente deve essere in grado di inviare una richiesta senza formazione, misurato da 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 generato entro 4 secondi per un set di dati fino a 50.000 righe.

Debole: I manager hanno bisogno di visibilità sulle approvazioni.
Migliore: Un manager deve essere in grado di vedere tutte le richieste in attesa della sua approvazione, ordinate per data di invio, su un'unica schermata senza filtri.

Debole: Il sistema deve integrarsi con l'amministrazione finanziaria.
Migliore: Le richieste approvate devono essere registrate nel sistema contabile entro 15 minuti, inclusi il centro di costo e il codice IVA, con gli errori registrati e riprovati automaticamente.

Il modello in ogni miglioramento è lo stesso. Identifica chi ne ha bisogno, cosa specificamente e la condizione in base alla quale concordi che sia stato raggiunto. Parole di cui diffidare nelle tue bozze: facile da usare, robusto, fluido, intuitivo, veloce, flessibile, scalabile, semplice. Ognuna di esse nasconde una decisione che qualcuno prenderà in seguito senza di te.

Prioritizzazione dei requisiti con MoSCoW

I requisiti senza priorità diventano tutti obbligatori per impostazione predefinita, e poi la prima pressione sulla tempistica costringe a tagli arbitrari.

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

La tabella dei requisiti

Ogni requisito ha bisogno di un ID, perché "il requisito di reportistica" è ambiguo nel momento in cui ce ne sono due. La fonte è importante perché al quarto mese qualcuno chiederà chi lo ha richiesto, e "l'azienda" non è una risposta valida.

Matrice di tracciabilità

La verifica che nulla sia stato silenziosamente tralasciato e che nulla venga sviluppato senza motivo.

Due errori emergono immediatamente. Un requisito senza caso di test non verrà verificato, e una voce di specifica funzionale che non rimanda a nessun requisito è qualcosa che viene sviluppato senza che nessuno lo abbia chiesto. Entrambi sono comuni ed entrambi sono facili ed economici da trovare in questo modo.

Esempio di documento dei requisiti aziendali

Un esempio pratico abbreviato, in modo da poter vedere il livello di specificità.

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

Obiettivi aziendali. Ridurre il tempo medio di rimborso delle spese da 24 giorni lavorativi a 10. Ridurre del 50% il tempo impiegato dal team finanziario per l'elaborazione dei rimborsi, attualmente pari a 14 ore settimanali. Raggiungere il 95% di conformità alle politiche sulle richieste inviate, attualmente al 71%.

Definizione del problema. Le richieste vengono inviate su un foglio di calcolo e spedite via e-mail. L'instradamento dell'approvazione è manuale, le ricevute arrivano separatamente e il 29% delle richieste viola la politica aziendale senza essere intercettato prima del pagamento. Il team finanziario impiega circa 14 ore alla settimana per i solleciti e il rimborso richiede in media 24 giorni lavorativi a fronte di un impegno di 10 giorni previsto dal manuale del personale.

In ambito. Invio della richiesta, acquisizione della ricevuta, convalida della politica aziendale, instradamento dell'approvazione, registrazione nel sistema contabile, notifica al dipendente.
Fuori ambito. Riconciliazione delle carte aziendali, definizione delle tariffe chilometriche, integrazione con le buste paga, migrazione delle richieste storiche oltre i 12 mesi.

Requisiti.

Ipotesi. L'attuale struttura organizzativa nel sistema delle risorse umane è accurata e aggiornata. Il sistema contabile espone un'API supportata. I limiti della politica aziendale non cambieranno durante l'implementazione.

Vincoli. Budget di £85.000. Deve essere operativo prima del nuovo anno finanziario. Nessun aumento dell'organico nell'amministrazione.

Riski. I dati relativi alle linee di riporto delle risorse umane si rivelano inaffidabili, di responsabilità del Direttore Risorse Umane, mitigati da un audit prima dello sviluppo. L'adozione da parte degli approvatori è lenta, di responsabilità del Direttore Finanziario, mitigata dalla formazione dei manager e da una fase di test parallela di due settimane.

Criteri di successo. Rimborso medio pari o inferiore a 10 giorni lavorativi entro un trimestre dalla messa in produzione. Tempo di elaborazione amministrativa pari o inferiore a 7 ore settimanali. Conformità alla politica aziendale pari o superiore al 95%.

Requisiti aziendali vs requisiti funzionali vs requisiti tecnici

La fonte più comune di confusione su questo argomento, e il motivo per cui molti BRD sono in realtà specifiche che indossano il titolo sbagliato.

Il test: se un requisito menziona uno schermo, un campo, un pulsante o un componente di sistema, è scivolato nel territorio funzionale. I requisiti aziendali dovrebbero sopravvivere a un cambiamento completo della soluzione. Se cambiassi fornitore e metà del tuo BRD diventasse non valido, quella metà non è mai stata un requisito aziendale.

Chi redige un documento dei requisiti aziendali e chi lo firma

Preparato dal business analyst, o dal product owner o project manager in assenza di un analista. Scritto con gli stakeholder anziché per loro, perché un BRD prodotto in isolamento viene firmato senza essere letto, il che è peggio che non avere affatto un BRD.

Firmato dalle persone che possono esserne ritenute responsabili: lo sponsor aziendale, il titolare del budget e i responsabili di ogni funzione il cui lavoro cambia. Aggiungi l'IT o il responsabile della delivery, a conferma che i requisiti sono stati compresi, piuttosto che siano realizzabili.

La firma che conta di più è quella della persona a cui al quarto mese verrà chiesto se questo era stato concordato.

Come scrivere un documento dei requisiti aziendali

1. Stabilisci prima di tutto l'obiettivo aziendale, espresso come numero. Se nessuno è in grado di definire il risultato misurabile, la raccolta dei requisiti produrrà un elenco di funzionalità anziché un documento.

2. Identifica gli stakeholder e i diritti decisionali prima di raccogliere qualsiasi elemento. Sapere chi può dare il via libera evita la maggior parte dei ripensamenti tardivi.

3. Documenta lo stato attuale onestamente, incluse le soluzioni temporanee di ripiego. È qui che si nascondono i veri requisiti.

4. Raccogli i requisiti attraverso interviste e osservazione sul campo, non solo tramite workshop. I workshop fanno emergere ciò che le persone dicono di aver bisogno. L'osservazione fa emergere ciò che fanno realmente.

5. Scrivi ogni requisito con i relativi criteri di accettazione associati, nella stessa sessione di lavoro. Aggiungere i criteri in un secondo momento significa scriverli basandosi sulla memoria.

6. Attribuisci le priorità con il metodo MoSCoW e tieni sotto controllo la percentuale di requisiti classificati come Must-have.

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

8. Costruisci la matrice di tracciabilità man mano che procedi, piuttosto che alla fine.

9. Distribuisci per revisione impostando una scadenza e un revisore nominato per sezione. Un generico "Avete commenti?" inviato a una mailing list produce solo silenzio.

10. Guida gli stakeholder attraverso il documento in una sessione dedicata prima di chiedere le firme, quindi fissa la versione di riferimento e gestisci le modifiche in modo formale da quel momento in poi.

Varianti del modello di documento dei requisiti aziendali

Una nota sulla versione Agile: un BRD e un backlog non sono in competizione. Il BRD definisce il perché e il cosa serve all'azienda, aspetti che cambiano lentamente. Il backlog definisce cosa verrà sviluppato successivamente, aspetto che cambia continuamente. I team che abbandonano completamente il BRD tendono a perdere il filo del perché, per poi riscoprirlo in seguito sotto forma di discussione.

Best practice

• Scrivi requisiti che qualcuno potrebbe rifiutare. La vaghezza viene interpretata come accordo e produce controversie in seguito.

• Un requisito per riga. Qualsiasi cosa contenga la congiunzione "e" è probabilmente composta da due requisiti.

• Associa i criteri di accettazione immediatamente, mai in un secondo momento.

• Numera tutto e non rinumerare mai. Piuttosto, ritira gli ID non più validi.

• Registra la fonte di ogni requisito.

• Tieni le soluzioni fuori dal documento. Nel momento in cui nomini una schermata o un campo, hai iniziato a progettare.

• Definisci ogni termine ambiguo nel glossario. Parole come "richiesta", "utente" e "approvato" significano cose diverse per dipartimenti diversi.

• Fissa la versione di riferimento al momento dell'approvazione e gestisci le modifiche in modo formale in seguito.

• Mantieni visibile l'elenco degli elementi fuori ambito. Previene l'espansione incontrollata dell'ambito (scope creep) più di qualsiasi altra sezione.

Errori comuni

• Requisiti non verificabili. Termini come "intuitivo" e "robusto" non possono essere testati, quindi vengono interpretati in fase di sviluppo da chi si trova più vicino alla fase esecutiva.

• Nessuna priorità, per cui tutto risulta obbligatorio finché la scadenza non costringe a tagli arbitrari.

• Soluzioni travestite da requisiti. Questo vincola la progettazione prima che qualcuno abbia valutato le reali opzioni.

• Nessun criterio di accettazione, per cui la definizione di "fatto" diventa oggetto di negoziazione.

• Mancanza della sezione fuori ambito. È lo strumento di prevenzione dello scope creep più economico che esista.

• Scritto per gli stakeholder invece che insieme a loro. Viene firmato senza essere letto.

• Ipotesi lasciate non scritte. Ogni progetto ne ha e quelle non registrate sono quelle che lo faranno fallire.

• Mai aggiornato dopo la firma. I requisiti cambiano e una baseline non aggiornata smette di essere il punto di riferimento di cui tutti si fidano.

• Nessuna tracciabilità, per cui i requisiti tralasciati silenziosamente vengono scoperti solo durante i test di accettazione degli utenti.

Cattura lo stato attuale registrandolo

Apri il modello in Trupeer AI, applica il tuo