Come scrivere i requisiti per un software su misura

Richiedere un software su misura partendo da una descrizione generica può rendere difficile sia la valutazione del progetto sia il confronto tra le proposte. Frasi come «ci serve un gestionale più semplice» o «vorremmo automatizzare alcune attività» indicano un problema, ma non spiegano ancora come dovrebbe funzionare la soluzione.

Scrivere i requisiti non significa redigere da soli una specifica tecnica completa. Significa mettere a disposizione del team di sviluppo una rappresentazione ordinata del lavoro da supportare: chi utilizzerà il software, quali attività dovrà svolgere, quali dati dovranno essere gestiti e quali risultati dovranno essere verificabili.

Questo lavoro è utile prima di chiedere un preventivo e anche nelle fasi successive, perché riduce ambiguità, omissioni e aspettative non condivise. In questa guida vediamo un metodo pratico per preparare requisiti utili per un progetto software custom. Per approfondire il percorso di sviluppo, puoi consultare la pagina software su misura di Indicaweb.

Parti dai processi, non dalle funzionalità

Il primo passo consiste nel descrivere come l’azienda lavora oggi. Prima di elencare schermate, pulsanti o automazioni, conviene ricostruire i processi coinvolti e individuare i punti in cui si verificano rallentamenti, errori o passaggi manuali.

Per ogni processo puoi rispondere a domande semplici:

• Qual è l’evento che avvia l’attività?
• Quali passaggi vengono eseguiti, e in quale ordine?
• Chi è responsabile di ciascun passaggio?
• Quali informazioni servono per procedere?
• Qual è l’output atteso?
• Quando il processo si considera concluso?

Un esempio, dichiarato come scenario ipotetico, può riguardare la gestione di una richiesta cliente: ricezione della richiesta, verifica dei dati, assegnazione a un responsabile, aggiornamento dello stato, comunicazione dell’esito e archiviazione. Descrivere questa sequenza è più utile che limitarsi a chiedere una funzione chiamata «gestione richieste».

Se il processo cambia in base al tipo di cliente, al reparto o allo stato della pratica, annota anche queste varianti. Sono dettagli che possono incidere sulla struttura dei flussi e sulle regole applicative.

Definisci utenti, ruoli e permessi

Un software non viene utilizzato nello stesso modo da tutte le persone dell’organizzazione. Un amministratore potrebbe configurare impostazioni e utenti, mentre un operatore potrebbe visualizzare solo le pratiche assegnate e modificarne alcuni campi.

Per ogni categoria di utilizzatore, indica:

• quali attività deve svolgere;
• quali informazioni deve visualizzare;
• quali dati può creare, modificare o eliminare;
• quali azioni richiedono un’approvazione;
• quali informazioni devono rimanere riservate;
• se può accedere da computer, tablet o altri dispositivi previsti dal progetto.

È preferibile descrivere i ruoli in base alle responsabilità, non soltanto in base ai nomi delle persone che oggi ricoprono un incarico. In questo modo i requisiti restano validi anche se l’organizzazione cambia.

Presta attenzione anche ai casi in cui più utenti lavorano sulla stessa informazione. Se una pratica può essere modificata da persone diverse, chiarisci se servono stati, assegnazioni, notifiche, storico delle modifiche o blocchi per evitare aggiornamenti incompatibili.

Raccogli dati, campi e regole

Ogni processo si appoggia a dati. Per evitare richieste vaghe, elenca le principali entità che il software dovrà gestire: ad esempio clienti, ordini, richieste, documenti, appuntamenti o prodotti. Per ciascuna entità, specifica quali informazioni sono necessarie e quali sono opzionali.

Un elenco utile può includere:

• nome del campo e significato;
• tipo di dato, come testo, numero, data o elenco;
• obbligatorietà;
• formato ammesso;
• valori predefiniti o alternative disponibili;
• relazioni con altre informazioni;
• eventuali vincoli di visibilità o modifica.

Non fermarti ai nomi dei campi. Descrivi anche le regole che li collegano. Per esempio, in uno scenario ipotetico, una data di chiusura potrebbe essere obbligatoria solo quando una pratica passa allo stato «conclusa». Una modifica potrebbe invece essere consentita soltanto a un determinato ruolo.

Indica inoltre se i dati esistono già in file, archivi o applicazioni utilizzate dall’azienda. La presenza di dati storici può richiedere attività di pulizia, trasformazione, importazione o verifica, che è meglio considerare fin dall’inizio.

Descrivi integrazioni e flussi di informazione

Molti software su misura non lavorano in isolamento. Possono dover ricevere o inviare dati ad altri sistemi, come strumenti amministrativi, piattaforme di comunicazione, calendari, servizi di pagamento o archivi aziendali. Anche quando non conosci i dettagli tecnici, è importante indicare quali sistemi sono coinvolti e perché.

Per ogni integrazione, prova a chiarire:

• quale sistema è la fonte principale del dato;
• quali informazioni devono essere trasferite;
• in quale direzione avviene il trasferimento;
• quando deve avvenire: in tempo reale, a intervalli o su richiesta;
• cosa succede se il trasferimento non riesce;
• chi deve essere informato dell’errore;
• se esistono vincoli di accesso, formato o autorizzazione.

Dire semplicemente «deve integrarsi con il gestionale» non è sufficiente per definire il comportamento atteso. Se possibile, allega documentazione già disponibile, esempi di file, descrizioni dei flussi o riferimenti al fornitore del sistema esterno. Questi elementi aiutano a distinguere un’integrazione necessaria da una possibilità da valutare.

Esplicita vincoli, sicurezza e condizioni operative

I requisiti non riguardano soltanto ciò che il software deve fare. Comprendono anche le condizioni entro cui deve funzionare. Un vincolo può dipendere dall’organizzazione, dagli strumenti già presenti, dalle procedure interne o dal livello di accesso degli utenti.

Tra gli aspetti da annotare rientrano:

• dispositivi e ambienti da supportare;
• necessità di utilizzo da sedi o reti differenti;
• dipendenze da software già in uso;
• necessità di conservare uno storico;
• regole per backup, ripristino e gestione degli accessi;
• tempi o periodi in cui il sistema deve essere disponibile;
• eventuali scadenze operative del progetto.

Se il software gestisce informazioni riservate, descrivi con chiarezza chi può accedere ai dati e quali operazioni devono essere tracciate. Non è necessario trasformare il documento in una specifica legale o tecnica, ma è importante segnalare fin dall’inizio le esigenze di riservatezza, autorizzazione e conservazione delle informazioni.

Considera casi limite ed errori

Un requisito completo non descrive soltanto il percorso ideale. Spiega anche cosa deve succedere quando qualcosa non va secondo le attese. I casi limite spesso emergono durante l’uso quotidiano e, se non vengono discussi, possono creare interpretazioni diverse o attività aggiuntive.

Puoi cercare situazioni come:

• dati mancanti o inseriti in un formato non valido;
• duplicazione della stessa richiesta;
• utente senza autorizzazione;
• informazione già modificata da un altro operatore;
• servizio esterno non disponibile;
• annullamento di un’operazione già avviata;
• necessità di riaprire una pratica chiusa;
• importazione di dati incompleti o incoerenti.

Per ogni scenario, indica il comportamento desiderato: bloccare l’azione, mostrare un messaggio, salvare una bozza, permettere una correzione o inviare una notifica. Anche in questo caso, non serve anticipare la soluzione tecnica; serve chiarire il risultato che l’azienda considera corretto.

Separa requisiti essenziali e desiderata

Una lista molto lunga non è necessariamente una lista utile. Se tutte le funzioni hanno la stessa priorità, diventa difficile capire cosa sia indispensabile per avviare il progetto e cosa possa essere valutato in un secondo momento.

Una classificazione semplice può distinguere:

• essenziale: senza questa funzione il processo principale non può essere gestito;
• importante: migliora il lavoro o riduce attività manuali, ma non impedisce l’avvio;
• desiderata: aggiunge valore, ma può essere rinviata o approfondita successivamente;
• da valutare: idea ancora da validare con il team o con gli utenti.

Per ogni requisito, aggiungi una breve motivazione. Dire che una funzione è essenziale è più utile se spieghi quale attività abilita o quale problema evita. Questa distinzione non serve a discutere il tema dei costi, ma a costruire un perimetro comprensibile e a facilitare le decisioni durante il progetto.

Scrivi criteri di accettazione verificabili

Un requisito dovrebbe permettere di stabilire, alla fine del lavoro, se il comportamento richiesto è stato realizzato. Per questo è utile associare a ogni funzione uno o più criteri di accettazione.

Un criterio efficace descrive una condizione osservabile. Per esempio, in uno scenario ipotetico: «Quando l’operatore completa tutti i campi obbligatori e salva la pratica, il sistema la registra e la mostra nello stato previsto». Il criterio non definisce il codice o la tecnologia utilizzata, ma chiarisce il risultato che deve essere verificato.

Puoi strutturare ogni requisito con questi elementi:

• obiettivo dell’utente;
• condizioni iniziali;
• azione da eseguire;
• risultato atteso;
• eventuali eccezioni;
• criterio con cui verificare il completamento.

Evita formule generiche come «interfaccia intuitiva», «sistema veloce» o «report completi» se non sono accompagnate da una descrizione concreta. Puoi invece indicare quali attività devono essere eseguite, quali informazioni devono apparire e quali filtri o esportazioni sono necessari.

Organizza il documento e preparati al confronto

Il documento dei requisiti può essere un testo strutturato, un foglio organizzato per categorie o una combinazione di diagrammi, esempi e allegati. Non esiste un unico formato valido: l’importante è che sia leggibile, aggiornabile e condivisibile con chi conosce i processi e con chi dovrà sviluppare la soluzione.

Una struttura pratica può essere:

1. obiettivi del progetto;
2. processi coinvolti;
3. utenti e ruoli;
4. dati e regole;
5. integrazioni;
6. vincoli operativi;
7. casi limite;
8. priorità;
9. criteri di accettazione;
10. domande ancora aperte.

Prima di inviarlo, coinvolgi le persone che svolgono concretamente le attività descritte. Chi usa ogni giorno procedure e strumenti può segnalare passaggi non documentati, eccezioni ricorrenti e informazioni che non devono andare perse.

Considera il documento come una base di confronto, non come un testo immutabile. Un confronto tecnico può far emergere requisiti mancanti, dipendenze o alternative organizzative. L’obiettivo è arrivare a una comprensione condivisa del problema e del risultato atteso.

Checklist finale prima di chiedere una valutazione

Prima di contattare un fornitore, verifica di aver risposto almeno a queste domande:

• Quale processo deve migliorare il software?
• Chi lo utilizzerà e con quali permessi?
• Quali dati devono essere inseriti, consultati o importati?
• Quali sistemi devono comunicare con la soluzione?
• Quali vincoli non possono essere ignorati?
• Cosa succede nei casi di errore o di eccezione?
• Quali requisiti sono essenziali e quali possono attendere?
• Come verificherai che ogni funzione sia stata realizzata correttamente?

Più queste risposte sono chiare, più sarà semplice trasformare l’esigenza aziendale in un progetto discutibile, stimabile e verificabile. La definizione dei requisiti non elimina il confronto con il team tecnico: lo rende più concreto e produttivo.

Se hai bisogno di trasformare i processi della tua azienda in una soluzione digitale coerente con le tue esigenze, puoi partire dalla pagina software su misura e presentare il contesto, gli obiettivi e i requisiti già raccolti.