Come scrivere un documento dei requisiti per un sito web
Un documento dei requisiti esiste perché tu e chi sviluppa stiate descrivendo lo stesso sito web. Non deve essere lungo. Un brief di quattro pagine che entrambe le parti hanno davvero letto evita più contenziosi di una specifica di cinquanta pagine che nessuna delle due ha finito.
Questa guida copre cosa metterci dentro, cosa lasciare fuori, e come scrivere la sezione che conta di più: cosa il progetto non è.
A cosa serve un documento dei requisiti#
Ha tre funzioni: permettere a più fornitori di quotare la stessa cosa perché i preventivi siano confrontabili, darti un riferimento quando c'è disaccordo sul perimetro, e costringerti a decidere finché decidere costa poco.
Non è un brief di design né una specifica tecnica. Dire «il sito deve caricare veloce» è un requisito; dire «usare Redis per la cache oggetti» è una soluzione, e sceglierla prima di aver ingaggiato qualcuno elimina la competenza che stai pagando.
- Enuncia risultati e vincoli, non implementazioni.
- Scrivilo in modo che qualcuno esterno alla tua organizzazione lo capisca senza una telefonata.
- Tienilo abbastanza breve da leggersi in una volta: quattro-otto pagine bastano per la maggior parte dei siti.
- Mettici data e versione, perché cambierà.
Le sezioni che valgono la pena#
Questa struttura copre la maggior parte dei progetti web. Salta ciò che non si applica invece di riempire.
| Sezione | Cosa ci va |
|---|---|
| Contesto | Cosa fa l'organizzazione e perché il sito viene creato o sostituito |
| Obiettivi | L'obiettivo primario, quelli secondari, e come si misura il successo |
| Pubblico | Due o tre gruppi di visitatori e la domanda con cui arriva ciascuno |
| Struttura delle pagine | Ogni pagina, raggruppata in sezioni, segnata come critica o successiva |
| Requisiti funzionali | Moduli, ricerca, account, filtri, prenotazione, checkout: cosa deve fare ciascuno |
| Integrazioni | Ogni sistema esterno, con un referente e il link alla documentazione API |
| Contenuti | Chi scrive ogni pagina, chi approva, per quando |
| Non funzionali | Prestazioni, accessibilità, browser e dispositivi, lingue, sicurezza |
| Fuori perimetro | Lavoro esplicitamente escluso: la sezione più preziosa |
| Vincoli | Fascia di budget, scadenza e ogni decisione già fissata (hosting attuale, CMS imposto) |
Scrivi requisiti verificabili#
Un requisito è utile quando entrambe le parti possono concordare a posteriori se è stato soddisfatto. «Il sito dovrebbe essere veloce» non è verificabile; «la pagina elenco prodotti raggiunge il Largest Contentful Paint sotto 2,5 secondi su un Android di fascia media in 4G» sì.
Lo stesso vale per le funzionalità. «Un modulo di contatto» lascia fuori ogni domanda che conta.
| Vago | Verificabile |
|---|---|
| Un modulo di contatto | Sei campi, protezione antispam, salvataggio in database, invio a due indirizzi, riga di consenso GDPR |
| Adatto al mobile | Usabile a 320 px, tutti i bersagli tattili almeno 44 px, nessuno scorrimento orizzontale |
| Veloce | LCP sotto 2,5 s e CLS sotto 0,1 sui quattro template principali, misurato in 4G |
| Accessibile | WCAG 2.2 AA sui template, verificato con passaggi da tastiera e screen reader |
| Adatto al SEO | Titoli e descrizioni modificabili, URL puliti, sitemap, dati strutturati sugli articoli |
| Multilingua | Tre lingue, URL tradotti, tag hreflang, selettore di lingua su ogni pagina |
L'elenco fuori perimetro#
È la sezione che si salta ed è quella che salva il progetto. Scrivi le cose che una persona ragionevole potrebbe dare per incluse, e di' chiaramente che non lo sono — oppure includile, se dovrebbero esserlo.
Farlo prima che arrivino i preventivi rende i preventivi confrontabili. Farlo dopo significa una discussione.
- Scrittura e revisione dei testi: dai per scontato che siano a tuo carico salvo diversa indicazione nel preventivo.
- Fotografia, illustrazione e licenze di banche immagini.
- Inserimento contenuti: chi digita 200 prodotti nel CMS?
- Configurazione e-mail, migrazione DNS e trasferimento dell'account di hosting.
- Attività SEO continuativa, distinta dall'impostazione tecnica al lancio.
- Formazione, documentazione e passaggio di consegne.
- Supporto dopo il lancio: cosa è coperto, per quanto, e cosa viene fatturato.
Un buon fornitore aggiungerà voci a questo elenco senza che glielo si chieda. Chi accetta tutto senza domande di solito non l'ha letto, e il disaccordo è semplicemente rinviato.
Domande frequenti
Quanto deve essere lungo un documento dei requisiti?
Quattro-otto pagine coprono la maggior parte dei siti aziendali. Negozi e applicazioni si allungano perché cresce la sezione funzionale, ma oltre le venti pagine chiediti cosa si stia descrivendo che una conversazione non risolverebbe. La misura è se entrambe le parti l'hanno letto, non se è esaustivo.
Devo specificare la tecnologia?
Solo dove hai un vincolo reale: un CMS che il tuo team conosce, un hosting su cui devi restare, un sistema da integrare. Altrimenti enuncia il risultato e lascia scegliere l'implementazione a chi ingaggi. Imporre uno stack che non capisci restringe le opzioni e ti dà una risposta peggiore.
Servono anche i wireframe?
Wireframe a bassa fedeltà per i tre o quattro template più importanti tolgono molta ambiguità con pochissimo sforzo, e sono molto meno costosi da cambiare di un design. Non sostituiscono i requisiti scritti — mostrano la disposizione, non il comportamento — ma insieme permettono di quotare molto più accuratamente di ciascuno da solo.
E se non conosco alcune risposte?
Scrivi «da decidere» e indica chi decide ed entro quando. Un vuoto onesto con un responsabile va bene; una risposta inventata no, perché il preventivo ci verrà costruito sopra. Gli sviluppatori quotano comunque l'incertezza, quindi renderla visibile di solito ti dà un numero migliore che nasconderla.
documento requisiti sito webbrief sito webspecifica sito webcapitolato sito webperimetro progetto webrequisiti sviluppo web
