Da prototipo a portale richieste: cosa chiedere prima dello sviluppo

Descrivi una richiesta che arriva a conclusione

Usiamo un ufficio inventato. Una persona segnala un proiettore guasto, il coordinatore assegna l’intervento e un tecnico registra l’esito. Il richiedente deve poter capire se qualcuno se ne sta occupando e che cosa è stato fatto. Scrivi questa sequenza prima di discutere filtri, dashboard e notifiche.

Per aprire la richiesta bastano, in questo esempio, luogo, oggetto e descrizione del problema. Il coordinatore definisce la priorità e il responsabile. Concorda anche il caso in cui manchino informazioni: chi le chiede, a chi e dove rimane la risposta.

Stabilisci chi vede e modifica ogni elemento

Un accesso con password identifica l’utente; occorre poi decidere quali richieste può consultare o modificare. La raccomandazione OWASP è verificare i permessi per ogni operazione, anche sul sistema che la riceve. Nascondere un pulsante nell’interfaccia non basta.

Questa matrice è una proposta per l’esempio, da adattare alla tua organizzazione. Nel preventivo chiedi anche come si assegnano e si revocano gli accessi.

Chiarisci cosa significa «salvato»

Dopo l’invio, la richiesta dovrebbe avere un riferimento riconoscibile e restare disponibile quando la pagina viene riaperta. Chiedi al fornitore di mostrarlo con due account di prova: ciò che crea il richiedente deve comparire nell’ambito corretto del coordinatore.

Decidi anche quali cambiamenti conservare nello storico: assegnazione, stato, autore e momento dell’operazione, per esempio. Se due persone aprono la stessa richiesta, una modifica basata su dati vecchi deve produrre l’esito concordato, come un avviso e la rilettura dell’elemento. Evita aggiornamenti silenziosi che cancellino una decisione precedente.

Fai capire come rimediare a un errore

Un campo obbligatorio mancante richiede un’indicazione testuale vicino al problema. Il criterio W3C sull’identificazione degli errori richiede di identificare l’elemento errato e descrivere l’errore in testo; il colore da solo non fornisce questa informazione.

Per un invio interrotto serve un messaggio diverso: l’utente deve distinguere richiesta salvata, invio non completato ed esito da verificare. Concorda come recuperare la situazione senza creare duplicati. Anche la sessione scaduta va provata: la persona deve sapere cosa può recuperare e se deve autenticarsi di nuovo.

Trasforma la presentazione in un collaudo

Prepara richieste sintetiche e assegna a una persona del team la verifica finale. Per ciascuna prova scrivi situazione iniziale, azione ed esito atteso. Nel nostro esempio, il collaudo comprende questi passaggi:

• Inviare una richiesta e ritrovarla dopo la riapertura della pagina.
• Assegnarla, registrare l’intervento e rendere visibile l’esito al richiedente.
• Provare con un altro account che le richieste fuori ambito restino inaccessibili.
• Ripetere un invio interrotto e verificare che esista una sola richiesta.
• Correggere un campo mancante senza perdere le informazioni già inserite.

Porta al preventivo anche le esclusioni

Allegati, avvisi email, collegamenti ai gestionali e uso senza rete richiedono decisioni proprie. Inseriscili quando servono al primo flusso. Chiedi che la proposta specifichi dati iniziali, responsabilità, istruzioni per l’amministratore e assistenza dopo la consegna. Porta a Ospivia il processo e due richieste di esempio per discuterne il perimetro.

Esplora un esempio

ServiceBot mostra un flusso di richieste con dati sintetici. È una prova interna utile per discutere stati ed esiti; non dimostra un portale cliente operativo o tutte le funzioni descritte.

Riferimenti tecnici

• OWASP: autorizzazione e verifica dei permessi
• W3C: identificazione degli errori di inserimento