In breve: prima di sviluppare una web app aziendale bisogna definire problema, utenti, attività, dati, ruoli, integrazioni, dispositivi, requisiti di sicurezza e criteri di accettazione. Un elenco di schermate non basta: i requisiti devono descrivere che cosa deve accadere anche nei casi di errore, con dati incompleti o quando un servizio esterno non risponde.

Che cosa si intende per requisiti di una web app?

I requisiti descrivono il comportamento atteso del sistema e i vincoli entro cui deve funzionare. Comprendono funzioni visibili — come creare una pratica o approvare un ordine — e qualità trasversali come sicurezza, accessibilità, prestazioni, continuità e possibilità di esportare i dati.

Non devono trasformare il cliente in uno sviluppatore. Devono rendere condivise decisioni aziendali, responsabilità e risultati prima che il codice renda ogni cambiamento più costoso.

La mappa completa in dieci aree

Area Domanda da risolvere Output utile
Obiettivo Quale problema o risultato giustifica la web app? Baseline e metrica
Utenti Chi la usa e in quale contesto? Ruoli e attività
Flussi Come inizia, cambia e termina un caso? Mappa stati ed eccezioni
Dati Quali informazioni servono e chi ne è responsabile? Dizionario e fonte autorevole
Permessi Chi può vedere o compiere ogni azione? Matrice ruolo/azione
Integrazioni Quali sistemi devono dialogare? Contratti e scenari d’errore
Dispositivi Dove e con quale connessione viene usata? Contesti e browser supportati
Qualità Quanto deve essere veloce, accessibile e disponibile? Soglie verificabili
Conformità Quali dati, obblighi o regole si applicano? Vincoli e responsabilità
Accettazione Come dimostriamo che il risultato è corretto? Casi di prova

1. Definire problema, baseline e risultato

Una web app può ridurre reinserimenti, coordinare persone, offrire un portale ai clienti o rendere disponibili dati prima dispersi. L’obiettivo va espresso senza riferimenti alla soluzione: “ridurre il tempo tra richiesta e approvazione” è più utile di “creare una dashboard”.

La baseline non deve essere sofisticata. Possono bastare tempo medio, numero di passaggi manuali, errori mensili o richieste che richiedono un sollecito. Questi dati aiutano a decidere quale funzione entra nel primo rilascio.

2. Identificare utenti reali e contesto d’uso

“Dipendenti” o “clienti” sono gruppi troppo generici. Un operatore che inserisce dati ogni giorno, un responsabile che approva da telefono e un cliente che apre una pratica una volta l’anno hanno esigenze diverse.

Per ciascun gruppo è utile conoscere frequenza, competenza, dispositivo, luogo, qualità della connessione, volume di attività e conseguenze di un errore. Se l’app viene usata in magazzino, officina o durante un sopralluogo, progettare soltanto su un monitor da ufficio produce una specifica incompleta.

3. Mappare il ciclo di vita degli oggetti

Ogni oggetto centrale — ordine, commessa, ticket, documento — attraversa stati. Una pratica può essere bozza, inviata, da integrare, approvata, rifiutata o archiviata. Per ogni transizione bisogna definire:

  • chi può effettuarla;
  • quali dati sono obbligatori;
  • quali controlli avvengono;
  • quali notifiche o integrazioni vengono attivate;
  • se e come l’azione può essere annullata;
  • quale traccia rimane.

Le eccezioni devono entrare nella mappa: approvazione scaduta, allegato non valido, ordine duplicato, cliente bloccato o servizio esterno non disponibile.

4. Costruire un dizionario dei dati

Il dizionario non è un documento riservato agli sviluppatori. Spiega significato, formato, obbligatorietà, provenienza e proprietario delle informazioni. Evita che “cliente attivo”, “data consegna” o “totale ordine” abbiano definizioni diverse tra reparti.

Per i dati personali bisogna raccogliere soltanto ciò che serve, definire accessi e tempi di conservazione con le figure competenti. Il progetto tecnico deve rendere applicabili le decisioni, non inventarle.

5. Creare la matrice dei permessi

Per ogni ruolo e oggetto vanno distinte azioni come leggere, creare, modificare, approvare, esportare e cancellare. “Utente amministratore” non dovrebbe essere la soluzione universale alle eccezioni.

È utile verificare anche i confini: un responsabile vede una sede o tutte? Un fornitore vede soltanto le righe assegnate? Chi può scaricare dati in massa? I controlli devono valere sul server e non soltanto nell’interfaccia.

6. Specificare le integrazioni come contratti

Nome del sistema e logo non bastano. Per ogni integrazione servono dati scambiati, direzione, evento di avvio, frequenza, identificativi, autenticazione, ambiente di test, limiti, timeout, tentativi e gestione manuale degli errori.

Le API esterne non sono automaticamente affidabili. OWASP richiama il rischio del consumo non sicuro di API: risposte esterne devono essere validate, limitate e gestite come input non fidati.

7. Definire dispositivi e condizioni operative

I requisiti dovrebbero indicare browser e dispositivi supportati, dimensioni minime, uso da tastiera, necessità di fotocamera o stampa, sessioni condivise, timeout, disponibilità offline e gestione delle connessioni lente.

“Responsive” significa che l’interfaccia si adatta; non garantisce che un flusso complesso sia davvero pratico su telefono. Alcune attività possono richiedere una versione semplificata o essere esplicitamente destinate al desktop.

8. Rendere verificabili i requisiti non funzionali

Parole come veloce, sicuro e intuitivo non sono criteri. Devono diventare condizioni osservabili.

Qualità Requisito generico Forma verificabile
Prestazioni La pagina deve essere veloce Operazione critica entro una soglia, con volume definito
Disponibilità Deve essere sempre online Finestra di servizio, manutenzione e obiettivo concordati
Sicurezza Accesso protetto Ruoli, MFA dove necessario, log e test delle autorizzazioni
Accessibilità Interfaccia accessibile Perimetro e livello WCAG concordati, test da tastiera
Recupero Esistono backup Frequenza, conservazione e prova di ripristino
Portabilità I dati sono del cliente Formati, procedura e tempi di esportazione

9. Progettare sicurezza e accessibilità dall’inizio

Il NIST SSDF propone pratiche integrate nel ciclo di sviluppo: preparare organizzazione e ambienti, proteggere software e componenti, produrre rilasci più sicuri e rispondere alle vulnerabilità. Per il cliente questo si traduce in domande su repository, dipendenze, segreti, ambienti, revisioni, aggiornamenti e incidenti.

Le WCAG 2.2 rendono verificabili molti aspetti dell’uso: alternative testuali, struttura, contrasto, tastiera, ordine del focus, messaggi e autenticazione accessibile. Correggere questi elementi dopo aver costruito l’interfaccia può richiedere di riprogettare componenti centrali.

10. Scrivere scenari e criteri di accettazione

Un requisito funzionale efficace può seguire questa struttura:

  1. contesto: dati e stato iniziale;
  2. attore: ruolo e permessi;
  3. azione: ciò che la persona o il sistema esegue;
  4. risultato: cambiamento atteso;
  5. errore: comportamento con dati o servizi non validi;
  6. evidenza: schermata, record, notifica o log da controllare.

Come scegliere il primo rilascio

Un MVP aziendale non è una demo pubblicata in fretta. Deve consentire a un gruppo reale di completare un risultato in modo sicuro e supportabile. Per selezionare il perimetro, assegna a ogni funzione:

  • valore sul risultato;
  • rischio ridotto;
  • dipendenze tecniche;
  • incertezza da verificare;
  • costo operativo introdotto;
  • possibilità di rinvio senza bloccare il flusso.

Le parti più rischiose vanno verificate presto, anche se non sono le più visibili. Un prototipo può validare l’interfaccia; una prova tecnica può verificare API, prestazioni o migrazione.

Checklist da portare al primo incontro

  • un caso reale completo e uno eccezionale;
  • elenco di ruoli e persone coinvolte;
  • documenti e file utilizzati;
  • sistemi esistenti e relativi referenti;
  • dati sensibili o vincoli di conservazione;
  • dispositivi e luoghi d’uso;
  • problemi attuali con esempi;
  • risultato e metrica desiderata;
  • scadenze motivate e dipendenze;
  • funzioni che possono attendere.

Domande frequenti

Serve un documento di cento pagine?

No. Serve un livello di dettaglio proporzionato al rischio. Un prodotto semplice può usare mappe, prototipi e casi di accettazione brevi; processi regolati o molte integrazioni richiedono più formalizzazione.

Possiamo definire i requisiti durante lo sviluppo?

Sì, il dettaglio evolve. Prima di iniziare devono però essere chiari obiettivo, primo perimetro, rischi, responsabilità e modalità con cui le nuove decisioni modificano costi e tempi.

Prototipo e web app sono la stessa cosa?

No. Il prototipo verifica flussi e comprensione, ma può non avere dati reali, sicurezza, prestazioni, integrazioni, backup e gestione degli errori necessari a un sistema operativo.

Chi approva i requisiti?

Serve un referente aziendale capace di raccogliere il contributo degli utenti e prendere decisioni. L’approvazione non dovrebbe dipendere soltanto dall’IT o dalla direzione se il processo è svolto da altri ruoli.

Dal requisito al progetto

Consulta la pagina dedicata a web app e software su misura, la guida su come valutare una software house e il nostro metodo di analisi e sviluppo.

Definiamo il primo perimetro della web app

Fonti tecniche