Che cos'è un caso d'uso? Come scriverne uno, esempi, + modello

La progettazione di un prodotto richiede molto di più che elencare le caratteristiche e gli obiettivi. Prima dell'uscita del primo smartphone, come descriveresti i modi in cui gli utenti interagiscono con esso? Definirlo un cellulare con cui navigare sul web è un buon inizio, ma non spiega la complessità dei suoi sistemi. Per mappare i modi in cui gli utenti interagiscono con un sistema, uno strumento o un prodotto, hai bisogno di un caso d'uso.

I casi d'uso sono descrizioni dei modi in cui gli utenti interagiscono con i sistemi per svolgere compiti o raggiungere obiettivi. La mappatura di queste interazioni può migliorare la pianificazione iniziale e garantire un ciclo di sviluppo senza intoppi. Per aiutarti a inserirli nella pianificazione del progetto, definiremo un caso d'uso, spiegheremo come scriverne uno e condivideremo degli esempi.

Che cos'è un caso d'uso

Un caso d'uso spiega come gli utenti interagiscono con un prodotto o un sistema. Delinea il flusso degli input degli utenti, stabilendo i percorsi riusciti e non per raggiungere gli obiettivi. Ciò consente ai team di prodotto di comprendere meglio cosa fa un sistema, come funziona e perché si verificano degli errori. Puoi scriverne uno o schematizzare un modello di caso d'uso per chi pensa in modo visivo.

I casi d'uso variano in complessità a seconda del pubblico o del sistema. Ma in generale, il caso d'uso dovrebbe identificare alcuni componenti chiave. I più importanti sono:

• Attore: qualsiasi entità che mostra un comportamento che interagisce con un sistema, come un singolo utente, un team o un altro software
• Sistema: il prodotto o il servizio con funzionalità definite
• Obiettivo: lo scopo o l'obiettivo che gli utenti raggiungono con le funzionalità di un sistema

Gli attori, i sistemi e gli obiettivi costituiscono le basi per un caso d'uso. Quando inizi a monitorare le interazioni del sistema, entrano in gioco alcuni nuovi elementi:

• Stakeholder: persona con un interesse nelle prestazioni di un sistema
• Attore primario: l'attore che avvia la funzione di un sistema per raggiungere un obiettivo
• Presupposti: fattori sottostanti necessari per il verificarsi del caso d'uso
• Attivazione: eventi che danno inizio a un caso d'uso
• Flussi di base: casi d'uso in cui i sistemi funzionano come previsto per raggiungere un obiettivo
• Flussi alternativi: risultati diversi in base a quando e come un sistema devia dal percorso prestabilito

Tipi di casi d'uso

I casi d'uso si presentano in due forme: aziendale e di sistema. Un caso d'uso del sistema è un'analisi dettagliata di come gli utenti interagiscono con ogni parte del sistema. Mette in evidenza come input e contesti unici portino il sistema a raggiungere risultati diversi. Questo livello di dettaglio evidenzia come le singole funzioni di un sistema operano in qualsiasi scenario.

I casi d'uso aziendali offrono una visione più generale di come un utente potrebbe interagire con la tua azienda per raggiungere i propri obiettivi. Invece di concentrarsi sui dettagli tecnici, è una descrizione di causa ed effetto di diversi input. Ad esempio, se gestisci una piattaforma di debug del codice, il caso d'uso aziendale spiega come gli utenti inseriscono il codice e ricevono notifiche di errore.

Alcuni team preferiscono redigere un caso d'uso aziendale per delineare i processi di un sistema prima dello sviluppo. Man mano che gli sviluppatori iniziano il loro lavoro, un manager delineerà casi d'uso del sistema più tecnici da seguire.

Scenario d'uso vs. caso d'uso

I casi d'uso mostrano tutti i modi in cui un sistema funziona per raggiungere gli obiettivi, ma uno scenario raffigura solo un esempio. In uno scenario, il sistema può riuscire o fallire nel raggiungere gli obiettivi dell'utente. In parole povere, più scenari di utilizzo costituiscono un caso d'uso.

Caso d'uso vs. storia utente

I casi d'uso descrivono come gli utenti interagiscono con un sistema, mentre le storie utente descrivono le caratteristiche dal punto di vista dell'utente. Di conseguenza, le storie utente sono molto più brevi dei casi d'uso, in genere costituite da brevi descrizioni che i team usano come punto di partenza nello sviluppo. Inoltre, i casi d'uso possono aiutare più team in un'organizzazione, mentre le storie utente aiutano i team di prodotto a creare il proprio strumento.

Caso d'uso vs. caso di test

Mentre un caso d'uso illustra come gli utenti e le funzionalità del sistema agiscono per raggiungere gli obiettivi, i casi di test verificano se una singola funzionalità funziona correttamente. A differenza dei casi d'uso, i casi di test esaminano le funzionalità in isolamento.

Ad esempio, un caso di test potrebbe comportare la convalida della funzionalità di accesso su una piattaforma di posta elettronica, garantendo che gli utenti possano accedere da qualsiasi browser in qualsiasi momento dopo aver creato il proprio account.

Come scrivere un caso d'uso

Scrivere un caso d'uso sembra complesso, ma richiede solo la comprensione del sistema e dei suoi utenti. È possibile scrivere un caso d'uso seguendo questi sei passaggi:

1. Descrivi il sistema

Inizia descrivendo il tuo sistema, o il prodotto o il servizio che tu e il tuo team realizzerete. Concentra la descrizione su ciò che il sistema fa per gli utenti. In un caso d'uso aziendale, puoi mantenere questo sfondo generale e spiegare quali obiettivi raggiunge. Se si tratta di un caso d'uso del sistema, fornisci una descrizione approfondita del funzionamento del prodotto.

Definisci il sistema chiedendo:

• Che forma assume: prodotto, servizio o software?
• Quali caratteristiche offre?
• Quali obiettivi è possibile raggiungere con esso?
• Come raggiunge questi obiettivi?
• Cosa è possibile imparare sul sistema da altri documenti come le carte di progetto?

2. Identifica gli attori

Gli attori si riferiscono generalmente a utenti e clienti, ma possono applicarsi a qualsiasi forza esterna che interagisce con il sistema. Il tuo attore ha bisogno di comportamenti ben definiti che spieghino come e perché gli attori usano il sistema.

Identifica gli attori chiedendo:

• Si tratta di individui, team, hardware o un altro sistema?
• Gli attori primari e secondari condivideranno lo stesso comportamento?
• Gli stakeholder assumeranno il ruolo di attori nel caso d'uso?

3. Definisci gli obiettivi degli attori

I casi d'uso evidenziano il risultato che gli attori vogliono da un sistema. Per capire perché gli utenti si rivolgono al tuo sistema, ricorda di concentrarti sui desideri dei tuoi attori piuttosto che sulle capacità del sistema. In alcuni casi, i clienti vogliono utilizzare i sistemi per più di un obiettivo. Elencando ciascuno di questi obiettivi si crea un caso d'uso più efficace.

4. Crea uno scenario

In un caso d'uso, gli scenari sono la sequenza di azioni che i clienti intraprendono quando utilizzano un sistema e il flusso di effetti di tale interazione. I tuoi flussi di base coprono scenari in cui un sistema funziona come previsto. Un utente si avvicina al sistema, inserisce gli input corretti e il tuo sistema li aiuta a raggiungere i propri obiettivi.

Inizia con questi flussi di base di successo per creare una linea di base. Puoi utilizzare le tecniche di mappatura dei processi per identificare potenziali problemi nei flussi successivi.

5. Considera i flussi alternativi

Dopo aver scritto uno scenario di successo, scrivi flussi alternativi che portano a risultati diversi. In genere, i flussi alternativi comportano l'uso improprio di un sistema che impedisce agli attori di raggiungere i propri obiettivi. Tuttavia, puoi anche annotare errori interni che causano il guasto di un sistema o modi non intenzionali in cui i sistemi possono raggiungere gli obiettivi.

I flussi alternati mostrano come i diversi attori utilizzano un sistema e hanno successo o falliscono. Offrono una visione più dettagliata di tutto ciò che il sistema può fare per aiutare a risolvere i problemi.

6. Ripeti i passaggi 2–5 per creare il tuo caso d'uso

Con una varietà sufficiente di attori, obiettivi e scenari, puoi mostrare come funziona il sistema. Mettendo insieme di questi flussi otterrai un caso d'uso, che può migliorare lo sviluppo e informare altri documenti come i rapporti sullo stato del progetto.

In caso di sistemi semplici, puoi cambiare pochi elementi per vedere tutti i potenziali risultati. I sistemi complessi, invece, possono avere troppi elementi per vedere ogni risultato. In casi come questo, concentrati sul test delle interazioni più comuni. È inoltre possibile progettare sistemi che impediscano risultati non testati.

Prova il modello di caso d'uso di Figma

Vuoi iniziare a fare brainstorming sui casi d'uso? Prova il modello di caso d'uso di Figma per scomporre i sistemi e trovare nuove soluzioni.

Esempio di caso d'uso

Supponiamo che tu sia un responsabile di prodotto che sviluppa un'app di mobile banking per la sua azienda. La piattaforma deve semplificare la registrazione degli utenti e la configurazione degli account. Ecco un esempio di formato del caso d'uso basato su questa app:

Informazioni di base:

• Sistema: un'app di mobile banking
• Attore principale: clienti che desiderano aprire un conto
• Attore secondario: sottoscrittori e strumenti automatizzati per il calcolo dei tassi di interesse e dei saldi massimi del capitale
• Obiettivi: risparmiare tempo nella registrazione del conto e nell'onboarding
• Stakeholder: l'amministratore delegato e il vicepresidente di prodotto della tua azienda
• Presupposti: gli utenti scaricano l'app e soddisfano i requisiti per l'apertura del conto
• Trigger: l'utente sceglie di creare un nuovo conto dall'app

Scenari:

• Flusso di base: gli utenti scaricano la tua app e scelgono di creare un nuovo conto. L'applicazione raccoglie informazioni sugli altri account e sull'affidabilità creditizia dell'utente. Da lì, condivide automaticamente i conti per i quali si è qualificati e i relativi tassi di interesse. L'utente trova un conto adatto alle proprie esigenze ed effettua la registrazione.
• Flusso alternativo 1: gli utenti inseriscono i propri dati finanziari e l'app genera rapidamente le opzioni di conti. Tuttavia, ogni conto ha come impostazione predefinita il tasso di interesse più alto consentito dalla loro situazione finanziaria. Quindi, gli utenti abbandonano l'app per trovare un tasso più basso.
• Flusso alternativo 2: il processo di onboarding funziona come previsto, ma l'app deve affrontare problemi di conformità come i requisiti Know Your Customer (KYC). Sebbene l'app possa fornire opzioni di conti, ulteriori passaggi di conformità rallentano il processo.
• Flusso alternativo 3: poiché l'app esamina solo altri conti e affidabilità creditizie, non può offrire una gamma completa di opzioni di conto. Ad esempio, può offrire solo carte di credito e linee di credito. Quindi, i clienti in cerca di mutui devono rivolgersi altrove.

Vantaggi dei casi d'uso

Nella fase di pianificazione, i casi d'uso definiscono l'ambito del progetto, i requisiti e la roadmap. I team possono anche discutere i migliori risultati per gli utenti e progettare un percorso per raggiungerli. Con i flussi alternativi, puoi anche anticipare i rischi prima che danneggino l'esperienza utente. Se queste motivazioni non sono sufficienti per scriverne uno, ecco alcuni altri vantaggi dei casi d'uso:

• Spiegano il valore: i casi d'uso spiegano le caratteristiche di un sistema in termini semplici. Quindi, quando presenti i piani agli stakeholder, un caso d'uso rende il sistema più facile da comprendere.
• Prevedono i costi: un caso d'uso delinea la complessità di un sistema. Una maggiore complessità può derivare da funzionalità o salvaguardie aggiuntive. Imparando a conoscere la complessità del sistema, puoi stimare i costi di sviluppo.
• Migliorano la pianificazione: senza un caso d'uso, i progettisti e gli sviluppatori si concentrano su cosa fa un sistema, non su come lo fa. Tuttavia, i casi d'uso aiutano i team a considerare tutti i modi per implementare funzionalità e misure di sicurezza.
• Condividono usi alternativi: non tutti i flussi alternativi in un sistema portano a risultati fallimentari. La mappatura di diversi scenari permette di trovare nuove soluzioni a vecchi problemi o di ampliare la comprensione di ciò che un sistema può realizzare.

Perfeziona i casi d'uso con FigJam

I casi d'uso vanno oltre la descrizione di cosa può fare il prodotto. Forniscono agli stakeholder e ai team un quadro chiaro delle interazioni utente e dei risultati di successo. Che si tratti di aggiungere una nuova funzionalità, creare prototipi rapidamente o riprogettare un sistema, la tua pianificazione dovrebbe iniziare con la scrittura di un caso d'uso.

Maggiori sono le informazioni utili sugli attori, sulle interazioni e sui risultati, meglio è, motivo per cui è importante collaborare sui casi d'uso con il team e gli stakeholder. Una lavagna online condivisa come FigJam semplifica la collaborazione tra i team remoti per sviluppare casi d'uso completi. La nostra galleria di oltre 300 modelli può unire i team in qualsiasi fase dello sviluppo.