Progettazione software: come definire i requisiti prima di sviluppare
Come si progetta un software su misura partendo dai requisiti: i cinque passi per raccoglierli in una PMI, la differenza fra requisiti funzionali e non funzionali, chi possiede codice e documenti e gli errori di progettazione che costano di più dopo.
Progettazione software: come definire i requisiti prima di sviluppare
La progettazione di un software traduce i processi di un'azienda in requisiti verificabili, prima di scrivere una riga di codice. AraLith, software house in provincia di Roma attiva dal 2007, li raccoglie in un confronto tecnico diretto con chi quei processi li usa ogni giorno.
La progettazione software è la fase in cui si decide cosa deve fare il programma, per chi e con quali vincoli, e si scrive tutto in un documento dei requisiti che precede lo sviluppo. In una PMI questa fase vale più del codice: un requisito sbagliato si corregge in un'ora sulla carta e in settimane nel software già scritto.
Questa guida spiega come si raccolgono i requisiti in un'azienda piccola, quali sono funzionali e quali no, chi possiede il codice e i documenti alla fine, e quali errori di progettazione si pagano di più dopo. Se devi ancora capire cosa fa una software house o come scegliere una software house italiana, parti da lì.
In sintesi
- La progettazione di un software viene prima dello sviluppo e produce il documento dei requisiti, che è la base del preventivo e del contratto.
- I requisiti funzionali dicono cosa fa il software; quelli non funzionali dicono come deve farlo: tempi di risposta, sicurezza, conformità, volumi.
- In una PMI i requisiti si raccolgono in cinque passi: processi, problemi, flussi, integrazioni, dati.
- Partecipano chi usa i processi ogni giorno e chi scriverà il codice, senza intermediari commerciali.
- Codice, documento dei requisiti e modello dei dati restano di proprietà del cliente, e il contratto lo dice per iscritto.
Che cos'è la progettazione di un software?
La progettazione di un software è l'attività che trasforma un bisogno aziendale in una descrizione precisa e verificabile di ciò che il programma farà: funzioni, dati, regole, integrazioni e vincoli. Il risultato è un documento dei requisiti condiviso fra cliente e sviluppatore, da cui derivano la stima delle ore, il preventivo e il piano di rilascio.
Il documento non è un elenco di desideri. Contiene il modello dei dati (quali entità esistono e come si legano), le regole di calcolo, i ruoli e i permessi, le integrazioni con i sistemi già in uso e i criteri con cui si dirà che una funzione è finita. Da qui partono le fasi dello sviluppo dopo la progettazione, che senza questo documento restano stime a occhio.
Perché la progettazione parte dai requisiti?
La progettazione parte dai requisiti perché il software deve adattarsi ai processi dell'azienda, non il contrario: senza una mappa dei processi reali si costruisce un programma che funziona in demo e si inceppa il primo giorno in ufficio. In un progetto su misura i requisiti sono la mappatura di:
- processi operativi da digitalizzare, così come si svolgono oggi;
- problemi concreti che il software deve togliere di mezzo;
- flussi di lavoro e passaggi di mano fra le persone;
- integrazioni con gestionali, fatturazione elettronica e banche dati esistenti;
- dati da gestire, trasformare e conservare.
In AraLith la raccolta è un confronto tecnico diretto: al tavolo ci sono chi conosce i processi e chi progetterà e scriverà il codice, senza intermediazione commerciale. È il modo più rapido per scoprire i casi limite prima che diventino costi.
Su quali quattro pilastri si costruiscono i requisiti di un software?
Come si raccolgono i requisiti in una PMI?
In una PMI i requisiti si raccolgono in cinque passi, in uno o più incontri con chi usa i processi ogni giorno: si mappano i processi, si elencano i problemi, si disegnano i flussi, si censiscono le integrazioni e si definiscono i dati. Ogni passo produce una parte del documento dei requisiti, che il cliente legge e approva prima del preventivo.
Mappare i processi
Come si lavora oggi
Si segue ogni processo dall'inizio alla fine con le persone che lo eseguono: chi fa cosa, con quali strumenti, quali fogli di calcolo e quali email girano. Si annota anche ciò che si fa a mano per aggirare un limite.
Elencare i problemi
Cosa deve sparire
Per ogni processo si scrivono i problemi concreti: doppi inserimenti, dati che non tornano, attese, errori ricorrenti. Il software si giustifica solo se toglie di mezzo almeno uno di questi.
Disegnare i flussi
Chi passa cosa a chi
I processi diventano flussi con stati, passaggi di mano e regole di calcolo. Qui emergono i casi limite: la fattura stornata, l'ordine parziale, il cliente con due anagrafiche.
Censire le integrazioni
Con cosa deve parlare
Si elencano i sistemi già in uso con cui il software dovrà scambiare dati (gestionale, fatturazione elettronica, banca, e-commerce) e per ciascuno si verifica come: file, API o accesso diretto.
Definire i dati
Cosa entra e cosa resta
Si scrive il modello dei dati: entità, campi, relazioni, chi può vedere e modificare cosa, e cosa va migrato dal sistema precedente. È la parte che più di tutte evita rifacimenti.
Requisiti funzionali e non funzionali: che differenza c'è?
Un requisito funzionale descrive cosa fa il software: «genera la fattura elettronica dall'ordine confermato». Un requisito non funzionale descrive come deve farlo: entro quanti secondi, per quanti utenti insieme, con quali protezioni dei dati e quali norme da rispettare. I primi si verificano con un test di funzione; i secondi con una misura o con un controllo documentale.
| Aspetto | Requisito funzionale | Requisito non funzionale |
|---|---|---|
| Cosa descrive | Le funzioni: cosa fa il software e con quali regole | La qualità: prestazioni, sicurezza, conformità, disponibilità |
| Esempio in un gestionale | Calcola i riparti e genera il sollecito dal piano di pagamento | Risponde in pochi secondi con tutti gli utenti collegati; cifra i dati personali a riposo |
| Come si verifica | Con un caso di prova: dato questo input, esce questo risultato | Con una misura (tempi, carichi) o con un controllo documentale |
| Chi lo decide | Chi usa il processo, insieme a chi sviluppa | Chi risponde di dati, sicurezza e contratti, insieme a chi sviluppa |
Nessun dato da mostrare.
Chi possiede il codice e i documenti di progetto?
Il codice sorgente, il documento dei requisiti, il modello dei dati e la documentazione tecnica appartengono al cliente: va scritto nel contratto, con la consegna del repository e delle credenziali alla fine di ogni rilascio. È il criterio che distingue un software su misura da una licenza: se domani cambi fornitore, il lavoro resta tuo e chi subentra parte dai documenti, non da zero.
Per questo in AraLith il documento dei requisiti è il primo consegnabile del progetto, prima del preventivo definitivo, ed è il punto di partenza della progettazione e sviluppo di software su misura che segue.
Quali errori di progettazione costano di più dopo?
Gli errori di progettazione che costano di più sono quelli che si scoprono quando il software è già in uso, perché toccano i dati e i flussi su cui tutto il resto è costruito:
- Modello dei dati sbagliato: un'anagrafica che non prevede due sedi o un ordine che non ammette consegne parziali obbliga a rifare tabelle e maschere.
- Processo idealizzato: il flusso disegnato come dovrebbe essere, non come è, produce un programma che le persone aggirano con i fogli di calcolo.
- Integrazioni rimandate: scoprire alla fine che il gestionale esistente esporta solo file manuali cambia architettura e tempi.
- Ruoli e permessi non scritti: chi vede cosa si decide dopo e si incastra male con ciò che è già stato costruito.
- Nessun criterio di accettazione: senza una definizione di «finito» ogni funzione resta aperta e il preventivo non regge.
Alla raccolta dei requisiti partecipano le persone che eseguono i processi ogni giorno, il responsabile che risponde dei dati e dei contratti e chi progetterà e scriverà il codice. Il confronto è diretto e tecnico: un intermediario commerciale in mezzo perde proprio i dettagli che poi costano.
La raccolta dei requisiti dura quanto serve a coprire tutti i processi coinvolti: pochi incontri per un flusso lineare, più giri per un gestionale con molte integrazioni. La durata si concorda nel primo colloquio e la fase si chiude quando il cliente approva il documento, non a una data fissata a priori.
I requisiti si possono cambiare durante lo sviluppo, ma ogni modifica va scritta come richiesta di cambiamento con l'impatto su tempi e costo prima di farla. Lavorare per rilasci brevi riduce il problema: si ridiscute la priorità a ogni rilascio, con il cliente disponibile a decidere.
Si può progettare un software senza sapere tutto, ed è la norma: il documento dei requisiti fissa ciò che è certo, segna le parti ancora aperte e le risolve nei primi rilasci. Quello che non si può lasciare aperto sono il modello dei dati e le integrazioni, perché sono le parti che costano di più da cambiare dopo.
La progettazione di un software si paga a ore, con le tariffe di AraLith per tipo di lavoro da 50 a 180 € l'ora IVA esclusa: le tariffe per tipo di lavoro sono pubbliche e il numero di ore si stima nel primo colloquio tecnico, che è gratuito. Il documento dei requisiti resta al cliente anche se poi lo sviluppo lo fa qualcun altro.
Vuoi progettare un software partendo dai tuoi processi?
Nel primo colloquio tecnico, gratuito, leggiamo insieme i tuoi processi e ti diciamo cosa va scritto nei requisiti prima di qualsiasi preventivo.
