Come scrivere i requisiti di un software gestionale prima di chiedere un preventivo
Un preventivo per un software gestionale è attendibile soltanto quanto lo sono le informazioni su cui viene costruito. Scrivere “gestione clienti, ordini e magazzino” non definisce un progetto: non chiarisce chi compie le operazioni, quali eccezioni esistono, quali sistemi forniscono i dati e quale risultato dimostra che la funzione è completa. Fornitori diversi interpreteranno la stessa frase in modi diversi e presenteranno offerte che sembrano confrontabili soltanto nel totale.
Il documento dei requisiti serve a ridurre questa ambiguità. Non deve anticipare ogni scelta tecnica e non richiede un linguaggio da programmatore. Deve descrivere il contesto aziendale, il flusso atteso, le regole che non possono essere ignorate e le condizioni con cui l’azienda accetterà il risultato. Il suo valore non dipende dal numero di pagine, ma dalla capacità di trasformare richieste generiche in comportamenti osservabili.
Prima di scriverlo occorre separare tre livelli. Il bisogno spiega perché intervenire, per esempio ridurre gli ordini incompleti. Il requisito descrive che cosa il sistema deve consentire o impedire. La soluzione tecnica indica come realizzarlo. Confondere questi livelli porta a imporre tecnologie non valutate oppure a presentare desideri generici che non possono essere stimati.
Questa guida propone una struttura operativa per raccogliere le informazioni e controllarle prima di inviarle a una software house. Il risultato non sarà un contratto automatico, ma una base comune per analisi, domande, stime e criteri di accettazione.
Apri il documento con il problema operativo, non con l’elenco delle schermate. Descrivi il processo interessato, gli errori o i tempi attuali e il risultato desiderato. “Ridurre da due giorni a quattro ore la preparazione delle offerte complete” è più utile di “digitalizzare i preventivi”, perché consente di discutere dati necessari, vincoli e misurazione.
Indica poi il perimetro. Elenca reparti, sedi, tipologie di pratica, lingue e canali compresi nel primo rilascio. Registra anche ciò che resta escluso. Se il progetto riguarda gli ordini italiani ma non quelli esteri, la distinzione evita che valute, fiscalità e traduzioni emergano a sviluppo iniziato. Le esclusioni non sono rinunce definitive: rendono leggibile la stima.
Identifica gli attori usando il ruolo operativo, non il nome della persona. Commerciale, responsabile, amministrazione, magazziniere, cliente e sistema esterno hanno obiettivi e permessi differenti. Per ciascun ruolo specifica quali informazioni vede, quali operazioni compie e quali decisioni può approvare. Se due persone con lo stesso ruolo lavorano diversamente, occorre capire se esiste un’eccezione valida o un processo non standardizzato.
Rappresenta il flusso attuale dall’evento iniziale al risultato finale. Segna passaggi manuali, attese, controlli, scambi email e file usati. Non serve un diagramma complesso: una sequenza numerata con input, responsabile e output è sufficiente. Aggiungi esempi reali anonimizzati, perché rivelano campi e condizioni che nelle interviste vengono dati per scontati.
Descrivi quindi il flusso futuro senza trasformarlo in un catalogo di pulsanti. Indica stati e passaggi: una richiesta nasce in bozza, viene verificata, approvata, inviata e chiusa. Per ogni transizione specifica chi la esegue, quali condizioni devono essere soddisfatte e che cosa deve accadere dopo. Questo schema permette di derivare schermate e notifiche senza imporle prima di aver compreso il processo.
Assegna infine un proprietario per ogni area del documento. È la persona autorizzata a risolvere dubbi e approvare i criteri. Un requisito senza responsabile resta esposto a interpretazioni contrastanti tra reparti.
Formula ogni requisito funzionale con soggetto, azione, oggetto e condizione. Per esempio: “Il responsabile commerciale può approvare un’offerta soltanto quando cliente, validità, righe, prezzo e margine sono presenti”. La frase identifica ruolo, operazione e vincolo. Evita parole come facile, completo, intuitivo o automatico se non vengono accompagnate da un comportamento osservabile.
Raccogli le regole di business separatamente dalle schermate. Soglie di sconto, listini, arrotondamenti, sequenze numeriche, calendari e autorizzazioni possono essere applicati in più punti. Per ogni regola indica fonte, formula, priorità ed esempi. Inserisci almeno un caso normale, un limite e un errore. Se due regole entrano in conflitto, stabilisci quale prevale.
Dedica una sezione alle eccezioni. Che cosa accade quando manca il codice cliente, l’articolo è esaurito, l’integrazione non risponde o un’approvazione scade? Specifica se l’operazione viene bloccata, messa in coda o consentita con motivazione. Un gestionale viene giudicato soprattutto nei casi non lineari; ignorarli produce procedure parallele dopo il rilascio.
Prepara il dizionario dei dati con nome, significato, formato, obbligatorietà, valori ammessi, origine e periodo di conservazione. Distingui i dati inseriti dagli utenti, calcolati dal sistema e ricevuti da fonti esterne. Indica quali campi possono cambiare e se serve mantenere lo storico. Allegare un file di esempio aiuta, ma non sostituisce la definizione.
Per ogni integrazione indica sistema, proprietario, informazioni scambiate, direzione, frequenza e comportamento in caso di errore. Specifica se esistono API e documentazione, senza presumere che contengano ciò che serve. Chiarisci come vengono riconciliati i dati e quale sistema è autorevole per ciascun oggetto. “Collegamento con ERP” non è stimabile se non si sa se riguarda anagrafiche, disponibilità, ordini o fatture.
Descrivi i permessi con una matrice tra ruoli e operazioni: visualizzare, creare, modificare, eliminare, esportare e approvare. Aggiungi le separazioni necessarie, come impedire che chi inserisce un pagamento lo approvi. Per le operazioni sensibili richiedi una cronologia con autore, data, valore precedente e nuovo valore.
I requisiti non funzionali descrivono come il sistema deve operare. Indica numero di utenti simultanei, volumi iniziali e crescita prevista, tempi di risposta per operazioni importanti, orari di disponibilità e dispositivi supportati. Usa scenari misurabili: “la ricerca restituisce i primi risultati entro due secondi con centomila pratiche” è verificabile; “il sistema deve essere veloce” non lo è.
Per sicurezza e continuità elenca autenticazione, ruoli, registri, cifratura dove necessaria, backup, obiettivi di ripristino e gestione degli incidenti. Non attribuire una conformità generica al software: identifica dati, obblighi e controlli di competenza dell’azienda e del fornitore. Se il servizio è critico, specifica procedure temporanee da usare durante un’interruzione.
Assegna una priorità con regole condivise. Una classificazione utile distingue ciò senza cui il processo non può essere completato, ciò che produce valore ma può essere rinviato e ciò che è desiderabile. Non etichettare tutto come obbligatorio. Collega ogni priorità all’obiettivo iniziale e alla fase di rilascio, così il perimetro può essere ridotto senza spezzare il flusso.
Scrivi i criteri di accettazione dal punto di vista del risultato. Per il requisito sull’offerta, prepara dati iniziali, azione e risultato atteso: un utente senza autorizzazione non approva; un’offerta incompleta mostra i campi mancanti; una valida cambia stato, registra autore e invia la notifica prevista. I criteri diventano base per demo, test e approvazione, non una formalità finale.
Inserisci vincoli e assunzioni. Scadenze normative, hardware esistente, browser, sedi con connettività limitata e periodi in cui non è possibile rilasciare influenzano architettura e stima. Dichiara anche ciò che deve fornire l’azienda: accessi, dati campione, referenti e disponibilità per i test.
Concludi con un registro delle questioni aperte e una versione del documento. Ogni modifica deve indicare data, autore e motivo. Prima di chiedere il preventivo organizza una revisione con utenti, responsabile di processo e referente tecnico. Verifica che termini e numeri siano coerenti e che ogni requisito importante abbia almeno un criterio di accettazione.
Procedura per preparare il documento dei requisiti
- Scrivi il problema e la misura. Indica situazione attuale, risultato atteso e indicatore da confrontare.
- Delimita il primo rilascio. Elenca processi, reparti, sedi, casi inclusi ed esclusioni.
- Mappa attori e responsabilità. Specifica operazioni, informazioni visibili e poteri di approvazione per ruolo.
- Descrivi il flusso attuale. Segui casi reali e registra input, passaggi, attese, controlli e output.
- Disegna stati e transizioni future. Associa a ogni passaggio condizioni, responsabile ed effetto.
- Scrivi funzioni e regole. Usa comportamenti verificabili ed esempi normali, limite ed errore.
- Definisci dati e integrazioni. Prepara dizionario, fonti autorevoli, frequenze e gestione degli errori.
- Aggiungi qualità e sicurezza. Indica volumi, prestazioni, disponibilità, accessi, registri e ripristino.
- Assegna priorità. Collega ogni requisito al valore e alla fase di rilascio.
- Scrivi i criteri di accettazione. Specifica dati iniziali, azione e risultato atteso.
- Revisiona e versiona. Risolvi contraddizioni e registra le questioni ancora aperte prima dell’invio.
Quando il perimetro è verificabile, il servizio di sviluppo software, app e programmi personalizzati può trasformarlo in architettura, stima e piano di rilascio coerenti.
Lunedì – Sabato : 9:30 am – 21:00 pm
Lunedì – Sabato : 9:30 am – 21:00 pm
Studierò la strategia più adeguata per le tue esigenze e insieme al mio staff individueremo la Buyer Personas migliore per trasformare il tuo processo commerciale offline nella più efficace macchina di vendita online, e la strategia di comunicazione più convincente per convincere il pubblico che il tuo prodotto è quello che stanno cercando, anche se costa di più della concorrenza.
Lunedì – Sabato : 9:30 am – 21:00 pm
