Il capitolato tecnico è il documento che descrive in modo preciso cosa deve essere realizzato o fornito: caratteristiche, prestazioni richieste, modalità di esecuzione e controlli. Fa da riferimento per preventivo, contratto e collaudo, e si usa negli appalti pubblici, nei lavori edili e impiantistici e nei progetti privati, compresi software, siti e app.

In questa guida trovi prima la definizione generale e le differenze con capitolato speciale, capitolato d'oneri e disciplinare di gara. Poi ci concentriamo sul caso più utile per una piccola azienda: come scrivere un capitolato tecnico per un software, con un indice da copiare, un esempio compilato e gli errori da evitare.

Cos'è un capitolato tecnico: la definizione

Il nome viene da «capitoli»: un capitolato è un elenco ordinato di condizioni che regolano un lavoro o una fornitura. Quello tecnico si occupa della parte tecnica: non di prezzi e penali, ma di come deve essere fatta la cosa e di come si verifica che sia fatta bene.

Il termine si usa in tre contesti principali:

Appalti pubblici. È uno dei documenti con cui una pubblica amministrazione descrive cosa vuole acquistare. Per servizi e forniture, il Codice dei contratti pubblici (D.Lgs. 36/2023) lo indica tra i contenuti minimi del progetto, insieme alla relazione illustrativa e alla stima economica (Allegato I.7, art. 4-bis).
Edilizia e impianti. Descrive materiali, lavorazioni, finiture e norme da rispettare, per esempio nella costruzione di una casa o in una ristrutturazione. Nei lavori tra privati non è obbligatorio, ma è la base per contestare un lavoro fatto diversamente da come era stato promesso.
Software, siti e app. Descrive cosa deve fare il programma, per chi, con quali vincoli e come si verifica che funzioni. È il caso di cui parliamo da qui in avanti.

Negli atti di gara trovi spesso anche «capitolato tecnico prestazionale» o «descrittivo e prestazionale». «Descrittivo» indica cosa va fornito e come; «prestazionale» quali risultati, cioè quali prestazioni, deve garantire. Per un software conviene ragionare soprattutto in modo prestazionale: descrivi cosa deve fare, non con quale tecnologia.

Capitolato tecnico, speciale, d'oneri e disciplinare: le differenze

Chi arriva dal mondo delle gare li trova tutti insieme, ed è facile confonderli. Ecco a cosa serve ciascuno.

Documento	A cosa serve	Dove si usa
Capitolato tecnico	Descrive caratteristiche, prestazioni e controlli di ciò che va realizzato o fornito.	Gare di servizi e forniture, edilizia, progetti privati (anche software).
Capitolato speciale d'appalto	Definisce i contenuti del rapporto contrattuale del singolo appalto; spesso ha una parte amministrativa e una tecnica.	Appalti pubblici di lavori, servizi e forniture; usato anche tra privati.
Capitolato generale d'appalto	Le condizioni generali comuni ai contratti di lavori pubblici, che il capitolato speciale adatta al singolo appalto.	Lavori pubblici.
Capitolato d'oneri	Le condizioni amministrative e contrattuali che il fornitore deve rispettare. Sul MePA, il mercato elettronico della pubblica amministrazione, i capitolati tecnici delle singole categorie sono suoi allegati.	Gare di servizi e forniture, MePA.
Disciplinare di gara	Le regole della gara: chi può partecipare, quali documenti presentare, come vengono valutate le offerte.	Gare pubbliche.
Documento dei requisiti	L'elenco strutturato di cosa deve fare un software e di come deve comportarsi.	Progetti software, dove spesso è il cuore del capitolato tecnico.

Le definizioni di disciplinare e capitolato speciale sono scritte nel Codice: il disciplinare «fissa le regole per lo svolgimento del procedimento di selezione delle offerte», il capitolato speciale «definisce i contenuti del futuro rapporto contrattuale tra l'aggiudicatario e la stazione appaltante» (art. 87 del D.Lgs. 36/2023). Se i documenti di gara si contraddicono, per l'art. 82 prevale il bando.

In edilizia, infine, il capitolato si affianca al computo metrico: il capitolato dice come e con quali materiali, il computo metrico quante lavorazioni servono e quanto costano.

A cosa serve un capitolato tecnico in un progetto software

Prendi una richiesta comune: «Vorrei un sistema per le prenotazioni del ristorante». Un fornitore immagina un modulo con data, ora e numero di persone. Un altro immagina caparra con carta, pannello per il personale, promemoria via SMS e lista d'attesa. Ti arrivano due preventivi lontanissimi, ed entrambi sono corretti: descrivono due prodotti diversi.

Il capitolato tecnico serve a evitare proprio questo. In concreto:

Ti chiarisce le idee: scrivere costringe a decidere cosa serve davvero e cosa può aspettare.
Rende confrontabili i preventivi: tutti i fornitori quotano la stessa cosa.
Diventa la base del contratto: ciò che è scritto è incluso, il resto è una modifica.
Guida il collaudo: a fine lavoro si verifica il software voce per voce.
Resta come memoria del progetto: chi metterà mano al software dopo saprà cosa doveva fare e perché.

Con un documento chiaro in mano è anche più facile scegliere a chi affidare il lavoro: qui trovi cos'è una software house e come sceglierla.

Come scrivere un capitolato tecnico per un software: struttura ed esempio

Per i progetti privati non esiste un formato obbligatorio. La struttura qui sotto funziona per gestionali, app, web app ed e-commerce: copiala e togli le sezioni che non ti servono.

Indice-modello da copiare

Contesto e obiettivo: chi siete, che problema volete risolvere, come misurerete il risultato (per esempio «dimezzare le telefonate per prenotare»).
Utenti e ruoli: chi userà il software, da quale dispositivo, cosa può vedere e fare ciascuno.
Perimetro: cosa è incluso in questo progetto e, altrettanto importante, cosa è escluso.
Requisiti funzionali: cosa deve fare il software, diviso per aree, con una priorità per ogni voce.
Requisiti non funzionali: velocità, sicurezza e privacy, accessibilità, dispositivi e browser supportati, disponibilità.
Dati esistenti e migrazione: quali dati avete già (Excel, un vecchio gestionale) e vanno importati.
Integrazioni: con quali sistemi deve dialogare, come pagamenti, fatturazione elettronica, calendario o gestionale.
Contenuti e grafica: chi fornisce testi e foto, logo e colori, esempi di app o siti che vi piacciono.
Vincoli: scadenze, budget indicativo, tecnologie o fornitori già scelti, norme di settore.
Fasi e consegne: cosa entra nella prima versione e cosa nelle successive, con le date.
Criteri di accettazione e collaudo: come verificherete che ogni funzione è fatta, chi approva, in quanto tempo.
Dopo la messa online: garanzia, manutenzione, tempi di intervento, formazione del personale.
Proprietà e consegne finali: codice sorgente, accessi, documentazione, esportazione dei dati.
Allegati: bozze delle schermate (anche a mano), moduli cartacei in uso, descrizioni dei processi.

Le sezioni 4, 5 e 11 sono il cuore del documento: senza quelle, il resto è una presentazione.

Esempio di capitolato tecnico (versione breve)

Ecco come potrebbe essere compilato, in sintesi, per il sistema di prenotazioni di un ristorante.

Sezione	Contenuto di esempio
Obiettivo	Ricevere le prenotazioni dal sito senza telefonate durante il servizio; ridurre i tavoli vuoti per prenotazioni non disdette.
Utenti	Clienti (da smartphone), personale di sala (da tablet), titolare (pannello completo).
Incluso	Prenotazione online, conferma via email, promemoria il giorno prima, gestione dei tavoli, chiusure e festivi.
Escluso, per ora	Ordini da asporto, programma fedeltà, app da scaricare dagli store.
Requisito chiave	Il cliente sceglie data, fascia oraria e numero di persone e vede solo gli orari ancora disponibili.
Non funzionali	Prenotazione completabile da smartphone in meno di un minuto; dati dei clienti trattati secondo il GDPR; testi leggibili anche con caratteri ingranditi.
Integrazioni	Pulsante «Prenota» sul sito attuale; avviso al titolare per ogni nuova prenotazione.
Vincoli	Online prima dell'inizio della stagione; budget massimo dichiarato.
Accettazione	Dieci prenotazioni di prova da telefoni diversi, comprese due contemporanee sull'ultimo tavolo libero: solo una va a buon fine, l'altra riceve gli orari alternativi.
Dopo la messa online	Correzione gratuita dei difetti per un periodo concordato; manutenzione con tempi di intervento scritti.

Come raccogliere i requisiti: analisi e user story

La parte difficile non è scrivere, ma capire cosa scrivere. Questo lavoro si chiama analisi dei requisiti: raccogliere, ordinare e verificare cosa deve fare il software prima di costruirlo. È la prima fase del ciclo di vita del software: un errore trovato qui si corregge con una riga di testo, dopo la messa online può voler dire rifare una parte del lavoro.

L'analisi dei requisiti in quattro passi

Parla con chi userà il software, non solo con chi lo paga: la receptionist, il magazziniere, il collaboratore di studio. Sono loro a conoscere le eccezioni.
Descrivi come lavorate oggi, passo per passo, e segna dove si perde tempo o si sbaglia.
Dai una priorità a ogni richiesta: indispensabile, importante, utile, non ora. Il metodo si chiama MoSCoW (Must, Should, Could, Won't), ma il nome conta poco.
Rileggi tutto con chi decide e con chi userà il software, e approvalo prima di chiedere i preventivi.

Una regola d'oro: ogni requisito deve essere verificabile. «Il software deve essere intuitivo» non si può verificare. «Un cliente nuovo completa la prenotazione da smartphone in meno di un minuto, senza aiuto» sì.

Requisiti funzionali e non funzionali: la differenza con esempi

I requisiti funzionali dicono cosa fa il software. I requisiti non funzionali dicono come deve comportarsi mentre lo fa. Un esempio per il gestionale di uno studio professionale:

Funzionali (cosa fa)	Non funzionali (come si comporta)
Il cliente carica i documenti da un'area riservata.	Per entrare servono password e un codice inviato al telefono (doppia verifica).
Lo studio vede le pratiche ordinate per scadenza.	L'elenco si apre in meno di 2 secondi anche con migliaia di pratiche.
Il software manda un promemoria prima di ogni scadenza.	Copia di sicurezza automatica ogni giorno, conservata in un luogo diverso dal server principale.
Il titolare esporta un report mensile in PDF.	Si usa da smartphone, tablet e computer, anche con un lettore di schermo.

I non funzionali sono quelli che si dimenticano più spesso, e spesso i più costosi da aggiungere dopo. Alcuni sono anche obblighi di legge: la protezione dei dati personali e, per diversi servizi online, l'accessibilità dei siti web.

User story: cosa sono, spiegate semplice

Una user story è un requisito scritto dal punto di vista di chi userà il software, in una frase. Il formato più diffuso, reso popolare da Mike Cohn, è: «Come [tipo di utente], voglio [fare qualcosa], così da [ottenere un beneficio]» (la sua guida, in inglese).

Il «così da» è la parte più importante: spiega il perché, e il perché cambia il modo in cui la funzione viene costruita. A ogni storia si accompagnano i criteri di accettazione, cioè le condizioni che devono essere vere perché la storia si consideri fatta. Due esempi:

Hotel. «Come receptionist, voglio vedere in una sola schermata gli arrivi del giorno con le richieste speciali, così da preparare le camere prima del check-in.»

Per ogni arrivo vedo nome, camera, orario previsto e note.
Le richieste speciali (culla, letto aggiunto, piano alto) sono evidenziate.
La schermata si aggiorna da sola quando arriva una nuova prenotazione.

Studio professionale. «Come cliente dello studio, voglio caricare le fatture del mese dal telefono, così da non doverle portare in ufficio.»

Posso caricare foto o PDF, anche più file insieme.
Lo studio riceve un avviso e trova i file nella mia cartella, divisi per mese.
Se un file non è leggibile, me lo segnala subito.

Due consigli pratici. Se una storia richiede settimane di lavoro, va spezzata: «gestire il mio account» diventa cambiare password, modificare l'email, eliminare l'account. E il «sistema» non è un utente: «come sistema voglio collegarmi al servizio di pagamento» è un compito tecnico, non una user story.

User story e capitolato non sono alternative. Le storie descrivono bene le singole funzioni; il capitolato le raccoglie e aggiunge perimetro, vincoli, requisiti non funzionali e regole di collaudo.

Criteri di accettazione e collaudo: quando il software è finito

Il collaudo, o test di accettazione, è il momento in cui verifichi che il software fa quello che era scritto. Le regole vanno decise prima di iniziare, non alla consegna. Nel capitolato scrivi:

Cosa si verifica: i criteri di accettazione di ogni funzione. Un formato semplice è «dato… quando… allora…»: dato un tavolo libero alle 20:30, quando due clienti lo prenotano nello stesso momento, allora uno riceve la conferma e l'altro gli orari alternativi.
Chi prova e su cosa: le persone che useranno davvero il software, sui dispositivi che usano ogni giorno.
Con quali dati: dati di prova realistici, non tre righe inventate al momento.
In quanto tempo: per esempio 10 giorni lavorativi dalla consegna di ogni fase.
Cosa succede se trovi errori: quelli bloccanti si correggono prima dell'approvazione, quelli minori in tempi concordati.
Come si chiude: con un'approvazione scritta, anche una email. Di solito da lì parte il periodo di garanzia.

I test che fa lo sviluppatore durante il lavoro sono un'altra cosa e non sostituiscono il tuo collaudo: trovi le differenze nella guida ai test del software.

Un caso reale: dal documento di specifiche al software

Nutrimi è un software gestionale per nutrizionisti che abbiamo sviluppato in Matech. Durante la visita l'intelligenza artificiale ascolta e compila la bozza dell'anamnesi, divisa in 14 sezioni. Il software calcola la composizione corporea con più metodi e il fabbisogno, ha un editor delle diete con un «semaforo» che mostra a colpo d'occhio se la dieta è in linea con l'obiettivo e produce report in PDF.

Il punto interessante, qui, è come è nato. Il cliente ci ha portato un documento di specifiche scritto da professionisti del settore: di fatto, un capitolato tecnico. Lo abbiamo trasformato in software voce per voce, e i numeri li abbiamo controllati a mano su pazienti di prova.

Tre lezioni utili anche per il tuo progetto:

In un settore specialistico, come sanità, fisco o sicurezza sul lavoro, le specifiche migliori le scrive chi conosce il mestiere. La software house le traduce in software.
Ogni voce del documento diventa una voce verificabile: in collaudo si spunta, non si discute.
Per i calcoli, il criterio di accettazione è un caso di prova: dati di partenza, risultato atteso calcolato a mano, confronto con quello del software.

Quanto deve essere dettagliato per una piccola azienda

Non serve un documento da cinquanta pagine per partire. Per avere un'idea dei costi bastano due righe: «Ho un ristorante da 60 coperti, voglio che i clienti prenotino dal sito e che io veda le prenotazioni sul telefono». Con questo un fornitore serio può già darti un ordine di grandezza.

Il dettaglio arriva dopo, ed è qui che il capitolato incontra il preventivo. Un buon preventivo per un progetto software non è una cifra: è un documento che fissa perimetro, voci di lavoro e data di consegna. In un progetto piccolo è il preventivo stesso a fare da capitolato: quello che c'è scritto è incluso, quello che manca no.

In Matech funziona così: ci dici cosa ti serve (due righe bastano), ricevi subito un range di prezzo, poi una persona ti porta il preventivo con perimetro, voci e data di consegna scritti. Quello che leggi è quello che firmi. Il rapporto tra i due documenti, in pratica:

Se hai un capitolato, il preventivo deve riprenderlo voce per voce. Se una voce manca, chiedi perché.
Se non ce l'hai, leggi il preventivo come se fosse un capitolato: ci sono tutte le funzioni? Cosa è escluso? C'è una data? Come si collauda? Cosa succede dopo la messa online?

Progetto	Dettaglio che di solito basta
Sito vetrina	Una pagina: obiettivo, sezioni del sito, chi fornisce testi e foto, esempi che ti piacciono.
E-commerce o prenotazioni	Poche pagine: catalogo o servizi, pagamenti, spedizioni o regole di prenotazione, integrazioni.
App o gestionale su misura	Un documento strutturato con requisiti, priorità e criteri di accettazione, come l'indice qui sopra.
Software con calcoli o regole di settore	Specifiche scritte o riviste da esperti del settore, con casi di prova, come per Nutrimi.

Errori tipici da evitare

Restare vaghi. «Moderno, veloce e intuitivo» non dice niente a nessuno. Scrivi cosa deve succedere, per chi, in quali casi.
Descrivere la soluzione invece del problema. «Voglio un menu a tendina» vincola il fornitore; «il magazziniere deve trovare un articolo in due tocchi, con i guanti» gli permette di trovare la soluzione migliore.
Dimenticare i requisiti non funzionali: privacy, velocità, accessibilità, copie di sicurezza.
Dimenticare i dati esistenti. Importare anni di clienti da un vecchio programma può pesare quanto una funzione intera.
Segnare tutto come indispensabile. Se tutto è prioritario, niente lo è.
Non scrivere cosa è escluso. Le aspettative non dette sono la prima fonte di discussioni.
Copiare un capitolato da gara pubblica. È pensato per altre regole: pesante e pieno di clausole inutili per un progetto tra privati.
Considerarlo immutabile. Durante il lavoro nasceranno idee nuove: prevedi come si gestiscono le modifiche, con stima scritta, approvazione e nuova data.

Domande frequenti sul capitolato tecnico

Chi redige il capitolato tecnico?

Negli appalti pubblici lo prepara la stazione appaltante, cioè l'ente che acquista: per servizi e forniture con il proprio personale, per i lavori di solito tramite il progettista dell'opera. Nei progetti privati lo scrive il committente, spesso con l'aiuto di un consulente o dello stesso fornitore. Anche se ti fai aiutare, obiettivi e priorità li decidi tu.

Il capitolato tecnico è obbligatorio?

Negli appalti pubblici fa parte dei documenti previsti dal Codice: per servizi e forniture è tra i contenuti minimi del progetto. Tra privati non è obbligatorio, ma senza un documento scritto, capitolato o preventivo dettagliato, è difficile dimostrare cosa era stato concordato.

Che differenza c'è tra capitolato tecnico e capitolato speciale d'appalto?

Il capitolato tecnico descrive cosa va realizzato o fornito e come verificarlo. Il capitolato speciale d'appalto regola l'intero rapporto contrattuale del singolo appalto e spesso contiene, oltre a una parte amministrativa, anche una parte tecnica. Il tecnico può quindi essere un documento a sé o un capitolo dello speciale.

Come si dice capitolato tecnico in inglese?

Di solito technical specification. Nei progetti software si usano anche software requirements specification (SRS), per il documento dei requisiti, e statement of work (SOW), per la descrizione del lavoro da svolgere.

Le user story sostituiscono il capitolato tecnico?

No, lo completano. Le user story descrivono le singole funzioni dal punto di vista di chi le usa; il capitolato aggiunge perimetro, vincoli, requisiti non funzionali, collaudo e regole per il dopo.

In sintesi

Il capitolato tecnico descrive cosa deve essere realizzato e come si verifica che sia fatto bene. Negli appalti pubblici è un documento di gara con regole precise; in un progetto software privato è lo strumento che rende confrontabili i preventivi e verificabile il risultato. Non deve essere lungo: deve essere chiaro su perimetro, requisiti, priorità e collaudo.

Se non hai ancora niente di scritto, parti da due righe: descrivi il progetto nella Stima in 2 minuti e ricevi subito un range di prezzo, senza lasciare l'email. Il dettaglio arriverà con il preventivo.

Capitolato tecnico: cos'è e come scriverlo (con esempio)