Capitolato tecnico: cos'è, cosa contiene e come gestirlo
Più del 50% dei progetti software sforano i tempi o il budget. La causa principale non è il codice: è la mancanza di specifiche chiare prima che il progetto inizi. Il capitolato tecnico è il documento che evita questo scenario. Non è burocrazia. È la mappa condivisa tra chi commissiona e chi esegue.
In questo articolo trovi la struttura completa di un capitolato tecnico per progetti software, le sezioni che nessuno scrive ma che costano care in fase di collaudo, e il metodo con cui Nesso Digitale supporta PMI e project manager in questa fase.
Cos'è un capitolato tecnico e perché è importante
Un capitolato tecnico è il documento contrattuale allegato all'appalto che formalizza requisiti funzionali, prestazionali e criteri di accettazione di un sistema software. Senza di esso, ogni modifica al progetto diventa un negoziato e ogni funzionalità mancante rischia di trasformarsi in un contenzioso tra cliente e fornitore.
Capitolato significato: definizione e ruolo nel contratto d'appalto
Un capitolato tecnico è un documento allegato al contratto d'appalto che specifica in modo formale le caratteristiche tecniche, le prestazioni attese, i criteri di accettazione e le condizioni di esecuzione di una fornitura o di un servizio.
Nel contesto del software su misura, il capitolato tecnico formalizza:
- cosa deve fare il sistema (requisiti funzionali)
- come deve comportarsi sotto carico, in sicurezza e nel tempo (requisiti non funzionali)
- con quali sistemi deve integrarsi
- come si verifica che il lavoro sia stato fatto correttamente
Non è un preventivo. Non è un'offerta commerciale. Non è una lista di funzionalità scritte su un foglio di carta. È il documento che trasforma un'intenzione in un impegno verificabile da entrambe le parti.
Senza un capitolato strutturato, ogni modifica diventa un negoziato. Ogni ritardo diventa una colpa che nessuno sa a chi attribuire. Ogni funzionalità mancante diventa un contenzioso. Il rischio di vendor lock-in e di debito tecnico cresce in modo proporzionale alla vaghezza delle specifiche iniziali.
I progetti software privi di capitolato tecnico strutturato generano in media 8 richieste di chiarimento post-firma per gara, contro meno di 2 quando le specifiche seguono un processo di raccolta requisiti verificabile.
Differenza tra capitolato generale e capitolato speciale d'appalto
Nel diritto degli appalti pubblici, la distinzione è precisa. Il capitolato generale d'appalto contiene le norme di carattere amministrativo e contrattuale che si applicano a tutte le gare di una stazione appaltante. Il capitolato speciale d'appalto (CSA) è invece specifico per ogni singolo appalto e contiene le prescrizioni tecniche, le specifiche operative e le condizioni di esecuzione proprie di quel progetto.
Nel diritto degli appalti pubblici, la distinzione è precisa. Il capitolato generale d'appalto contiene le norme di carattere amministrativo e contrattuale che si applicano a tutte le gare di una stazione appaltante. Definisce le regole del gioco: come si presentano le offerte, come si gestiscono le controversie, quali garanzie sono richieste.
Il capitolato speciale d'appalto (spesso abbreviato come CSA) è invece specifico per ogni singolo appalto. Contiene le prescrizioni tecniche, le specifiche operative e le condizioni di esecuzione proprie di quel progetto. È qui che si trovano le misurazioni, i materiali, le tolleranze, le tempistiche di verifica.
Nel contesto del software, il capitolato speciale d'appalto è il documento più importante. Dice esattamente cosa deve essere consegnato, in quali condizioni, entro quando e con quali criteri di collaudo.
Per i progetti privati tra PMI e software house, la distinzione formale tra generale e speciale è meno rigida. Ma la logica resta la stessa: ci vuole un documento che descriva le regole generali del rapporto e un documento che descriva le specifiche tecniche del prodotto da realizzare.
Il Codice dei Contratti Pubblici (D.Lgs. 36/2023) disciplina il contenuto minimo del capitolato speciale d'appalto per gli enti pubblici italiani, ma le PMI private che adottano la stessa struttura riducono significativamente il rischio di contenziosi in fase di collaudo.
Cosa deve contenere un capitolato tecnico
Un capitolato tecnico completo include almeno cinque aree: specifiche tecniche e prestazionali misurabili, modalità di esecuzione con milestone verificabili, standard di qualità e conformità normativa, criteri di accettazione e procedure di collaudo, documentazione tecnica da consegnare a fine progetto. Ogni specifica deve essere testabile: se non puoi misurarla, non ha valore contrattuale.
Specifiche tecniche e prestazionali
Le specifiche tecniche descrivono il comportamento atteso del sistema in condizioni operative reali. Non basta scrivere "il sistema deve essere veloce". Serve scrivere: "il sistema deve rispondere alle richieste di consultazione dell'archivio ordini in meno di 2 secondi nel 95% dei casi, con 50 utenti connessi contemporaneamente".
Le specifiche prestazionali includono:
- tempi di risposta per le operazioni principali
- numero di utenti concorrenti supportati
- disponibilità (uptime minimo, finestre di manutenzione accettabili)
- volumi di dati gestibili (numero di record, dimensione degli allegati)
Ogni specifica deve essere misurabile e verificabile. Se non puoi testare una specifica, non ha valore nel capitolato. Una formula utile: "Il sistema deve permettere a [utente] di [azione] in [tempo massimo] con [carico definito]".
Modalità di esecuzione, verifiche e tempistiche
Il capitolato tecnico deve definire non solo cosa consegnare, ma come il lavoro viene eseguito e controllato nel tempo. Questo include:
Milestone intermedie. Non solo la data di go-live. Ogni fase verificabile deve avere una data e un criterio di accettazione: prototipo navigabile, ambiente di test popolato con dati reali, completamento del modulo di gestione ordini, collaudo UAT.
Modalità di consegna. Agile con sprint settimanali o bisettimanali, oppure consegna a fasi definite (waterfall). La scelta ha impatto diretto su come si gestiscono le variazioni di scope e su chi porta il rischio delle modifiche in corso d'opera. Un approccio agile per PMI richiede che il capitolato definisca il processo di gestione del backlog, non solo la lista delle funzionalità.
Procedure di verifica. Chi esegue i test di accettazione, in quali ambienti, con quali dataset. Chi approva i risultati e con quale procedura scritta.
Gestione delle anomalie. Come si classificano i bug (critici, bloccanti, minori), in quanto tempo devono essere risolti, come si traccia lo stato di avanzamento della correzione.
La metodologia UAT (User Acceptance Testing), definita dallo standard IEEE 829, richiede che i criteri di accettazione siano scritti nel capitolato prima dell'inizio dello sviluppo: aggiungerli a posteriori aumenta del 60% la probabilità di dispute sul collaudo finale.
Standard di qualità, conformità normativa e controlli
Un capitolato tecnico per software deve includere i riferimenti normativi applicabili al contesto del cliente. Nel 2026, i più rilevanti per le PMI italiane sono:
GDPR. I dati personali trattati dal sistema: quali sono, dove vengono archiviati, con quali misure di sicurezza. Chi è responsabile del trattamento, chi è l'eventuale responsabile esterno.
Accessibilità. Per i sistemi rivolti al pubblico o alla PA, i requisiti WAI-ARIA o EN 301 549.
Sicurezza applicativa. Standard di cifratura in transito (TLS 1.2 minimo), cifratura a riposo per i dati sensibili, policy di autenticazione (password complesse, 2FA dove necessario).
Documentazione. Il capitolato deve specificare quale documentazione tecnica deve essere consegnata insieme al software: manuale utente, runbook tecnico per il team IT del cliente, documentazione delle API esposte.
Senza questi requisiti nel capitolato, ottenere la documentazione dopo il go-live diventa una trattativa separata. Spesso va a vuoto.
Il Regolamento GDPR (UE) 2016/679 impone che le misure di sicurezza tecniche siano documentate prima del trattamento dei dati: un capitolato tecnico che non specifica cifratura, pseudonimizzazione e gestione degli accessi espone il committente a responsabilità diretta in caso di data breach.
Come si redige un capitolato speciale d'appalto per progetti software
La redazione di un capitolato speciale d'appalto per software parte dall'analisi del problema di business, non dalla lista delle funzionalità. Il processo segue tre fasi sequenziali: raccolta strutturata dei requisiti dagli utenti reali, traduzione in specifiche misurabili con criteri di accettazione, e validazione tecnica da parte di un profilo con esperienza implementativa diretta.
Raccolta dei requisiti e definizione dello scope
Il capitolato non si scrive partendo dal software. Si scrive partendo dal problema di business che il software deve risolvere.
Il primo passo è raccogliere i requisiti dal basso: chi usa oggi il processo che il software andrà a gestire? Quali sono i passaggi manuali più costosi in termini di tempo? Quali dati vengono persi o duplicati? Quali decisioni vengono ritardate perché le informazioni sono disperse?
Una PMI manifatturiera che gestisce gli ordini B2B via email e fogli Excel potrebbe scoprire che ogni operatore spende 6-8 ore a settimana in attività ridondanti: copiare dati da un sistema all'altro, rispondere a richieste di stato ordine, riconciliare i numeri tra il gestionale e i file del commerciale. Questo è il problema. Il software è la risposta.
La fase di analisi dei requisiti software è il momento in cui queste informazioni vengono strutturate in modo formale, verificate con gli utenti reali e tradotte in requisiti misurabili. Non è una formalità da completare in fretta per arrivare al preventivo.
Strumenti come Jira, Confluence o Notion permettono di tracciare ogni requisito raccolto durante i workshop di discovery, associandolo a un proprietario interno e a un criterio di accettazione verificabile prima ancora che il fornitore riceva il capitolato.
Scrittura delle specifiche tecniche in modo misurabile
Ogni requisito del capitolato deve rispettare tre criteri: deve essere univoco (una sola interpretazione possibile), misurabile (si può verificare oggettivamente), e realistico (raggiungibile con le risorse e il tempo previsti).
Esempi di requisiti mal scritti e versioni corrette:
| Requisito vago | Requisito misurabile |
|---|---|
| "Il sistema deve essere veloce" | "Tempo di risposta < 2s per il 95% delle richieste con 50 utenti concorrenti" |
| "Il sistema deve essere sicuro" | "Autenticazione a due fattori obbligatoria per tutti i profili amministratore; cifratura AES-256 per i dati a riposo" |
| "Il sistema deve integrarsi con il gestionale" | "Sincronizzazione bidirezionale via API REST con il gestionale ogni 15 minuti; riconciliazione automatica degli stock" |
| "Il sistema deve essere scalabile" | "L'architettura deve supportare un aumento del 300% del carico senza modifiche strutturali" |
Ogni requisito deve avere un proprietario (chi ha la responsabilità di verificarlo) e un criterio di accettazione (come si dimostra che il requisito è soddisfatto).
Errori comuni nei capitolati che generano contenziosi
Descrivere la soluzione invece del problema. Il capitolato dice "voglio un'app con queste schermate" invece di "voglio ridurre del 40% il tempo di gestione delle richieste di acquisto". Il risultato: il fornitore consegna le schermate richieste, ma il problema rimane.
Omettere i requisiti non funzionali. Nessuna specifica su performance, sicurezza, disponibilità. Tutto sembra funzionare in test, poi in produzione con dati reali e traffico reale il sistema è lento o instabile. Il retrofit è costoso.
Integrazioni descritte in modo vago. "Il sistema deve parlare con il gestionale" non è una specifica. Quale API? Quale protocollo? Con quale frequenza? In caso di errore, cosa succede? Senza questi dettagli, ogni integrazione diventa una voce di costo extra non prevista.
Nessun criterio di accettazione. Il progetto non ha una fine definita. Il cliente trova sempre qualcosa che non va. Il fornitore ritiene di aver consegnato tutto. Il contenzioso è inevitabile.
Capitolo manutenzione assente. Nessuno specifica SLA post go-live, tempi di risposta per i bug critici, modalità di handover della documentazione. Sei mesi dopo il lancio, il cliente è bloccato senza supporto e senza documentazione.
Caso d'uso reale - Una PMI di servizi IT che partecipava a 12 gare l'anno ha ridotto del 35% il tempo dedicato alla redazione dei capitolati tecnici dopo aver strutturato un processo di raccolta requisiti basato su template verificabili. Il numero di richieste di chiarimento post-firma si è ridotto da una media di 8 a meno di 2 per gara.
Secondo l'analisi dei casi di contenzioso nei contratti software, l'assenza di SLA post go-live nel capitolato tecnico è la causa più frequente di dispute legali tra PMI e software house nei primi 12 mesi successivi alla consegna.
Chi può supportarti nella gestione del capitolato tecnico: l'approccio Nesso Digitale
Nesso Digitale affianca PMI e project manager nella redazione e nella gestione del capitolato tecnico attraverso un modello di team on-demand con governance: ogni backend engineer viene affiancato da un referente tecnico italiano che partecipa attivamente alle sessioni di scoping e trasforma i requisiti vaghi in specifiche implementabili e verificabili.
Backend Engineer on-demand con governance: cosa cambia rispetto al body rental
Il body rental funziona così: ricevi un profilo, lo inserisci nel tuo team, gestisci tu tutto il resto. Nessun allineamento sulla qualità del codice, nessuna governance sulle decisioni architetturali, nessun referente che ti avvisa quando una scelta tecnica creerà problemi tra sei mesi.
Il team on-demand di Nesso Digitale funziona diversamente. Ogni backend engineer on-demand lavora con un referente tecnico italiano che segue attivamente il progetto: partecipa alle sessioni di scoping, verifica che i requisiti del capitolato siano traducibili in specifiche implementabili, e traccia le assunzioni che possono impattare il budget.
Questo è rilevante nella fase del capitolato perché le domande giuste non le fa un commerciale. Le fa chi sa che "sincronizzazione real-time con il gestionale" può significare due ore di lavoro o due settimane, a seconda di come è fatto il gestionale. Un tecnico nella fase di discovery trasforma un requisito vago in una specifica misurabile con un impatto prevedibile.
Il risultato: il capitolato diventa il presupposto dichiarato del range di prezzo, non una formalità da rivedere dopo la firma. Per un gestionale su misura in ambito manifatturiero, il range parte da €5.000-12.000 per un progetto light - ma solo se le specifiche sono chiare.
A differenza del modello body rental tradizionale, il framework di governance di Nesso Digitale prevede l'uso sistematico di Architecture Decision Records (ADR): ogni scelta tecnica rilevante viene documentata nel repository del progetto, rendendo il capitolato un documento vivo e tracciabile per tutta la durata dello sviluppo.
Come il team on-demand si integra nel tuo workflow (ticket, PR, code review)
L'integrazione avviene sui tuoi strumenti, non sui nostri. Jira, Linear, GitHub, GitLab, Notion: il backend engineer on-demand lavora nel tuo sistema di ticketing, apre pull request sul tuo repository, partecipa alle tue code review.
Questo ha un impatto diretto sulla qualità del capitolato tecnico in esecuzione. Ogni requisito funzionale diventa un ticket tracciabile. Ogni modifica rispetto alle specifiche originali diventa una change request documentata, non una decisione presa in una call informale. Il metodo di lavoro di Nesso Digitale prevede che ogni deliverable includa runbook e handover documentato: niente "fidati, funziona".
Per una PMI manifatturiera che ha specificato nel capitolato la sincronizzazione degli ordini via API con il gestionale, questo significa avere traccia di ogni decisione tecnica presa durante l'implementazione: perché è stata scelta quella frequenza di sync, quali casi limite sono stati gestiti, come si comporta il sistema in caso di timeout. Informazioni che normalmente scompaiono con il primo sviluppatore che lascia il progetto.
Costi, limiti e quando ha senso affidarsi a uno specialista esterno
Il costo di un backend engineer on-demand con governance si colloca tra €40 e €55 all'ora, con variazioni legate a seniority, continuità dell'impegno e complessità della fase progettuale. Il modello è adatto a progetti con specifiche definibili e un interlocutore tecnico interno: non è la scelta giusta se gli obiettivi di business non sono ancora chiari o se manca la capacità di coordinamento lato cliente.
Quanto costa un Backend Engineer on-demand: range e fattori che lo influenzano
Il costo di un backend engineer on-demand con Nesso Digitale è compreso tra €40 e €55 all'ora. Il range dipende da tre fattori principali:
Seniority e specializzazione. Un profilo senior con esperienza specifica su integrazioni ERP o architetture event-driven costa più di un profilo mid-level su stack generalista.
Continuità e volume. Impegni continuativi (20+ ore settimanali per più mesi) permettono di stabilizzare il costo verso il basso del range. Interventi spot su progetti urgenti si collocano nella parte alta.
Fase del progetto. La fase di discovery e scoping del capitolato richiede profili con forte capacità di analisi, non solo di sviluppo. Questo può influenzare la composizione del team.
Per capire dove si colloca il tuo progetto, serve una conversazione tecnica prima del preventivo. Non ha senso dare un numero definitivo senza conoscere le specifiche del capitolato.
Per progetti che coinvolgono integrazioni con ERP come SAP o Microsoft Dynamics, la fase di analisi e scoping del capitolato rappresenta mediamente il 15-20% del budget totale di progetto: un investimento che riduce il rischio di change request non previste nella fase di sviluppo.
Quando questo modello non è adatto al tuo progetto
Il modello team on-demand con governance funziona bene in progetti con specifiche definibili, requisiti verificabili e un interlocutore tecnico interno (anche parziale) che può approvare le decisioni architetturali.
Non è il modello adatto se:
Non hai ancora chiari gli obiettivi di business. Se non sai ancora cosa vuoi misurare come successo del progetto, prima viene la fase di discovery. Il modello a progetti su misura con discovery strutturata è il punto di partenza più appropriato.
Hai bisogno di un prodotto completo in tempi molto stretti. Se il tempo è il vincolo principale e non puoi permetterti iterazioni, un approccio end-to-end con scope fisso è più prevedibile.
Il tuo team interno non è in grado di gestire i ticket e le review. Il modello on-demand richiede una minima capacità di coordinamento da parte del cliente. Se manca, serve prima strutturare il processo interno.
Il progetto ha requisiti altamente regolamentati (sanità, fintech, pubblica amministrazione) senza che ci sia già un framework di compliance definito. In questi casi, la fase di analisi dei requisiti è molto più lunga e richiede competenze specifiche.
Per capire cosa valutare in un preventivo software e quale modello si adatta al tuo contesto, è utile fare un primo confronto tecnico prima di decidere.
Richiedi una valutazione per il tuo capitolato tecnico
Stai costruendo un capitolato tecnico per un progetto software e non sei sicuro di aver coperto tutte le sezioni critiche? O hai già un capitolato ma vuoi verificare che le specifiche siano davvero misurabili e non generino sorprese in fase di collaudo?
Il primo confronto tecnico con Nesso Digitale è gratuito e senza impegno. Non parlerai con un commerciale: parlerai con un tecnico che ha già visto decine di capitolati, sa dove si nascondono le vaghezze che diventano costi extra, e può aiutarti a trasformare una lista di intenzioni in specifiche verificabili.
Richiedi una valutazione - Backend Engineer On-Demand
Aggiornato a giugno 2026.
Autore: Riccardo Sabatti - Founder, Nesso Digitale
FAQ
Quanto costa inserire un backend engineer on-demand nel mio team?
Il costo del servizio Backend Engineer On-Demand di Nesso Digitale si colloca in un range tra €40 e €55 all'ora. La tariffa effettiva dipende da fattori specifici come la complessità dello stack tecnologico, il livello di seniority richiesto e la continuità oraria settimanale concordata. Per avere una stima precisa anziché indicativa, è utile avviare una breve fase di discovery che permette di definire scope e impegno reale prima di firmare qualsiasi accordo.
Come funziona concretamente l'integrazione del backend engineer nel mio team?
Il backend engineer di Nesso Digitale si inserisce direttamente nei processi operativi del cliente: lavora sul tuo sistema di ticketing (Jira, Linear o equivalente), apre e revisiona Pull Request nel repository esistente, e partecipa alle cerimonie di team come daily o sprint review. Non si tratta di body rental: il servizio include governance attiva con un referente tecnico italiano che monitora qualità del codice, allineamento agli obiettivi e crescita progressiva del team. Puoi approfondire il metodo di lavoro su nessodigitale.it.
Quali requisiti deve avere il mio progetto prima di poter coinvolgere un backend engineer on-demand?
È preferibile che il progetto abbia già un capitolato tecnico o almeno specifiche funzionali sufficienti a definire i task in modo chiaro, poiché senza una mappa condivisa dei requisiti i ticket diventano ambigui e il lavoro perde efficacia. Non è necessario avere un team strutturato: Nesso Digitale può operare anche come primo profilo tecnico esterno, ma è indispensabile che esista un referente interno (CTO, product owner o project manager) con cui sincronizzarsi. Se le specifiche non sono ancora pronte, una fase di discovery preliminare può colmare questo gap prima di attivare le ore operative.
