La maggior parte dei progetti tecnologici che crollano non fallisce a causa di cattivi programmatori. Fallisce mesi prima che venga scritta una sola riga di codice — nella fase in cui nessuno si è preso la briga di definire che cosa il sistema debba fare, per chi e perché. È esattamente questo il ruolo dell’analisi e specifica dei sistemi informativi: trasformare un’idea vaga (“ci serve un sistema per gestire i clienti”) in un documento preciso su cui costruire, su cui fare un preventivo e con cui misurare i risultati.
Che cos’è la specifica dei sistemi informativi (e che cosa non è)
La specifica dei sistemi informativi è il processo con cui si mappano le esigenze di business, i processi di lavoro e gli utenti — e li si traduce in requisiti definiti: che cosa fa il sistema (requisiti funzionali), con quale velocità, sicurezza e disponibilità deve operare (requisiti non funzionali), che aspetto ha (specifica dell’interfaccia) e su quali tecnologie gira (architettura).
Che cosa non è: una specifica non è “un documento di 80 pagine che nessuno legge”. Una buona specifica è uno strumento di lavoro vivo — il più breve possibile, preciso quanto serve. E non è nemmeno una fase che si possa saltare perché “ci arrangeremo strada facendo”: i dati dimostrano che è la scommessa più costosa dell’intero progetto.
I numeri sul campo: due storie documentate
L’FBI ha bruciato 170 milioni di dollari per un sistema mai entrato in funzione
Tra il 2001 e il 2005 l’FBI sviluppò Virtual Case File — un sistema per la gestione dei fascicoli investigativi. Il progetto fu cancellato nel 2005 dopo una spesa di circa 170 milioni di dollari, senza che il sistema entrasse mai in servizio. Le indagini del Congresso che seguirono indicarono una causa centrale: requisiti mai definiti correttamente all’inizio e in continuo cambiamento — centinaia di modifiche ai requisiti durante lo sviluppo. Non è fallita la tecnologia. È fallita la specifica.
L’aeroporto di Denver: 16 mesi di ritardo per un sistema bagagli
Il sistema automatizzato di gestione bagagli dell’aeroporto internazionale di Denver è diventato un caso di studio classico: requisiti irrealistici mai messi a confronto con la realtà operativa ritardarono l’apertura dell’intero aeroporto di 16 mesi, con sforamenti di centinaia di milioni di dollari e un costo di circa un milione di dollari per ogni giorno di ritardo. Alla fine il sistema fu quasi del tutto abbandonato in favore di una soluzione più semplice — che si sarebbe potuta specificare fin dall’inizio.
E per chi pensa che accada solo ai giganti: uno studio del PMI ha rilevato che quasi la metà (47%) dei progetti che mancano i propri obiettivi fallisce per una cattiva gestione dei requisiti, e ricerche ormai storiche di IBM e NIST hanno mostrato che correggere un difetto in produzione costa da 30 a 100 volte più che correggerlo in fase di requisiti. Un’ora di specifica fa risparmiare una settimana di sviluppo.
Sei passi per una specifica dei sistemi informativi che funziona davvero
1. L’obiettivo di business prima di tutto
Non si parte da “quali schermate ci servono” ma da “quale problema di business stiamo risolvendo e come misureremo il successo”. Un CRM pensato per accorciare il tempo di risposta a un lead è una cosa molto diversa da uno pensato per aumentare le vendite ricorrenti. Una frase di obiettivo più due o tre indicatori di successo — prima di qualsiasi altra cosa.
2. Mappatura dei processi e degli utenti
Sedetevi con le persone che useranno davvero il sistema — non solo con i manager. Mappate il processo esistente passo per passo, comprese le eccezioni sgradevoli (un ordine annullato, un cliente che torna, il foglio di calcolo parallelo su cui tutti fanno silenziosamente affidamento). La maggior parte delle sorprese costose dello sviluppo si nasconde esattamente lì.
3. Requisiti funzionali: che cosa fa il sistema
Ogni requisito va formulato in modo da poter essere verificato: “il sistema invia un avviso al responsabile entro 5 minuti dall’apertura di una segnalazione” — sì. “Il sistema sarà facile da usare” — no. Date le priorità con il metodo MoSCoW (indispensabile / auspicabile / gradito / non ora), perché una prima versione che contiene tutto è una versione che non uscirà mai.
4. Requisiti non funzionali: prestazioni, sicurezza, disponibilità
Quanti utenti in contemporanea? Quali dati sono sensibili e chi è autorizzato a vederli? Che cosa succede quando il sistema cade? Sono le sezioni più facili da saltare in una specifica — e le più costose da scoprire dopo il rilascio in produzione.
5. Specifica dell’interfaccia e dell’esperienza utente
Wireframe delle schermate principali e percorso dell’utente dall’inizio alla fine. In questa fase non serve un design visivo completo — serve invece la certezza che l’utente arrivi dal punto A al punto B senza perdersi.
6. Architettura, integrazioni e documento di sintesi
A quali sistemi esistenti deve collegarsi (contabilità, pagamenti, messaggistica, ERP)? Costruire o comprare? Tutto converge in un documento di specifica (SRS) che comprende anche una stima dei costi e un calendario — e che diventa la base per confrontare i preventivi dei fornitori con lo stesso identico metro.
Quanto costa una specifica dei sistemi informativi
La specifica per un sistema di piccole o medie dimensioni (un’applicazione gestionale, un CRM su misura, un sistema operativo interno) si colloca di solito tra i 4.000 e i 16.000 dollari e, nei progetti più complessi, raggiunge le sei cifre. Una regola pratica diffusa: dal 10% al 15% del budget complessivo del progetto viene dedicato alla specifica. Sembra molto, finché non si ricorda che l’FBI ha pagato 170 milioni di dollari per la decisione di risparmiare proprio in questa fase. Altrettanto importante: una specifica indipendente e obiettiva, realizzata separatamente dalla software house che costruirà il sistema — così che chi fissa il prezzo non sia anche chi definisce ciò che serve.
Specificare sistemi di IA: che cosa cambia nel 2026
Quando si specifica un sistema basato sull’intelligenza artificiale — un chatbot di assistenza, un motore di raccomandazione, un’automazione intelligente — emergono domande che nella specifica classica non esistevano: quali dati avete realmente e qual è la loro qualità (un buon modello su dati scadenti dà un sistema scadente), qual è la soglia di accuratezza sotto la quale il sistema diventa dannoso, dove serve una persona nel ciclo decisionale e che cosa si fa quando il modello genera allucinazioni davanti a un cliente vero. In più, la specifica deve definire costi ricorrenti (token, chiamate API) che nel software tradizionale non esistono. È così che si evita di entrare nell’80% di progetti di IA che falliscono.
Domande frequenti
Quanto tempo richiede la specifica di un sistema informativo?
Per un sistema piccolo o medio: dalle tre alle otto settimane, a seconda del numero di processi e di sistemi da collegare. Un progetto aziendale ampio può richiedere dai due ai quattro mesi. Una specifica che si prolunga oltre è di solito il segnale che si sta cercando di specificare troppo in una volta sola.
Qual è la differenza tra specifica funzionale e specifica tecnica?
La specifica di business risponde al “che cosa e perché” — processi, utenti, requisiti e indicatori di successo, in un linguaggio comprensibile a qualsiasi manager. La specifica tecnica risponde al “come” — architettura, basi di dati, API. L’ordine conta: mettere il tecnico prima del business significa costruire la casa partendo dal tetto.
Si può saltare la specifica in un progetto piccolo?
Si accorcia — non si salta. Anche a un progetto di un mese basta un documento di 5-10 pagine con un obiettivo, i processi principali e un elenco di requisiti in ordine di priorità. La differenza tra questo e “ci arrangeremo strada facendo” è di solito la differenza tra uno sforamento del 10% e uno del 100%.
Chi dovrebbe scrivere la specifica: noi o un fornitore esterno?
La conoscenza del business ce l’avete solo voi, ma un analista esperto sa quali domande porre, come formulare requisiti verificabili e come tradurli nel linguaggio che i fornitori di sviluppo sanno quotare. La combinazione vincente: un analista esterno obiettivo che lavora a stretto contatto con le vostre persone chiave.