User stories, use cases, job stories e dichiarazioni di requisiti sono quattro modi per scrivere cosa dovrebbe fare un software. Spesso vengono presentate come rivali, ma rispondono a domande diverse a diversi livelli di dettaglio. Una user story chiede chi vuole cosa e perché. Un use case percorre un'interazione passo dopo passo, incluso cosa va storto. Una job story parte dalla situazione in cui si trova l'utente. Un requisito stabilisce una regola che il sistema deve rispettare.
Questa guida confronta le quattro, mostra la stessa funzionalità scritta in ogni modo e spiega quando usarle. Per le basi della scrittura delle storie, consulta la nostra guida hub su come scrivere user stories.
Confronto rapido
| User story | Use case | Job story | Dichiarazione di requisito | |
|---|---|---|---|---|
| Formato | Come [utente], voglio [azione], in modo da [beneficio] | Attore, obiettivo, precondizioni, scenario di successo principale, estensioni, postcondizioni | Quando [situazione], voglio [motivazione], in modo da poter [risultato atteso] | Il sistema deve [comportamento o vincolo] |
| Centrato su | Un tipo di utente e il suo obiettivo | L'interazione tra un attore e il sistema | La situazione e la motivazione, non la persona | Il comportamento o la qualità del sistema |
| Lunghezza | Una frase più criteri di accettazione | Mezza pagina a diverse pagine | Una frase | Una frase per requisito, molte per documento |
| Origine | Extreme Programming; formato da Connextra (2001) | Ivar Jacobson (fine anni '80); stile basato su obiettivi di Alistair Cockburn (2000) | Paul Adams presso Intercom; sviluppato da Alan Klement (2013) | Ingegneria dei requisiti tradizionale (oggi ISO/IEC/IEEE 29148) |
| Ideale per | Backlog agili e pianificazione degli sprint | Flussi complessi, integrazioni, lavori regolamentati o contrattuali | Discovery e design, in particolare per utenti diversi nella stessa situazione | Esigenze non funzionali, conformità, contratti a portata fissa |
| Debole in | Mostrare l'intero flusso e i casi limite | Velocità; difficile restare aggiornati in un'iterazione rapida | Pianificazione e stime in autonomia | Spiegare il perché; facile scrivere liste non testabili |
User stories
Una user story è una breve descrizione di una funzionalità, raccontata dal punto di vista della persona che la desidera. Il formato usuale, “Come [tipo di utente], voglio [azione], in modo da [beneficio]”, è nato dal team di Connextra nel 2001 e si è diffuso attraverso il libro di Mike Cohn User Stories Applied. Le storie sono cresciute nell'Extreme Programming, dove erano deliberatamente brevi: Ron Jeffries descriveva ogni storia come una card, una conversazione e una conferma (le 3 C). La card non è la specifica; è nella conversazione che i dettagli vengono concordati, e i criteri di accettazione li confermano.
Punti di forza: le storie sono abbastanza piccole da essere stimate e completate in uno sprint, facili da leggere per gli stakeholder non tecnici e mantengono in vista il valore (“in modo da”). Mike Cohn espone il caso a loro favore in Vantaggi delle user stories per i requisiti.
Limiti: un backlog di storie individuali non mostra come si integrano in un flusso, e il formato rende facile trascurare i casi di errore. I team risolvono il primo con una user story map e il secondo con criteri di accettazione ben scritti (vedi il nostro modello di user story).
Use case
Un use case descrive come un attore (una persona o un altro sistema) utilizza il sistema per raggiungere un obiettivo, come una sequenza di passi, insieme ai modi in cui quella sequenza può diramarsi o fallire. Ivar Jacobson ha introdotto gli use case alla fine degli anni '80, e il libro di Alistair Cockburn Writing Effective Use Cases (2000) ha stabilito lo stile focalizzato sull'obiettivo e in testo semplice che la maggior parte dei team utilizza oggi (Il sito di Cockburn).
Un use case completo di solito include:
- Attore principale: chi avvia l'interazione.
- Obiettivo e ambito: cosa vuole l'attore e quale sistema viene descritto.
- Precondizioni: cosa deve già essere vero.
- Trigger: cosa avvia l'use case.
- Scenario di successo principale: i passi numerati quando tutto va bene.
- Estensioni: percorsi alternativi e di fallimento, ciascuno legato al passo in cui si diramano.
- Postcondizioni o garanzie: cosa è vero alla fine, in caso di successo e di fallimento.
Punti di forza: la sezione delle estensioni costringe a pensare a cosa può andare storto, e l'intero flusso è visibile in un unico posto, il che è prezioso per integrazioni, pagamenti e qualsiasi cosa soggetta ad audit. Limiti: gli use case richiedono più tempo per essere scritti e aggiornati, e un singolo use case è di solito troppo grande per essere costruito in uno sprint.
Gli use case si sono adattati al lavoro agile. In Use-Case 2.0, Jacobson e colleghi hanno suddiviso ogni use case in “fette”, ciascuna abbastanza piccola da essere pianificata e testata, che svolgono un ruolo molto simile a quello delle user stories.
Job stories (jobs to be done)
Una job story sostituisce la persona con la situazione: “Quando [situazione], voglio [motivazione], in modo da [risultato atteso].” L'idea è stata menzionata per la prima volta da Paul Adams sul blog di Intercom e sviluppata da Alan Klement, che l'ha spiegata in un post ospite su Intercom nel 2013, Usare le job stories per progettare funzionalità. Applica il pensiero jobs-to-be-done, associato a Clayton Christensen, alla progettazione delle funzionalità.
L'argomento a favore delle job stories è che “Come genitore occupato” porta con sé assunzioni che il team non può testare, mentre la situazione (“Quando sto per uscire di casa e mi rendo conto di aver dimenticato di ordinare la spesa”) spiega l'urgenza, i vincoli e come si sente il “completato” per l'utente. Due persona molto diverse nella stessa situazione hanno spesso bisogno della stessa cosa.
Punti di forza: le job stories sono buone in discovery e design, mantengono il team focalizzato sul contesto e producono domande migliori per le interviste con i clienti. Limiti: dicono poco su chi è autorizzato a fare cosa, il che è importante per permessi e ruoli, e la maggior parte dei team le trasforma ancora in user stories o task per la pianificazione.
Dichiarazioni di requisiti
Il formato tradizionale è una dichiarazione numerata: “Il sistema deve bloccare un account dopo cinque tentativi di accesso falliti.” Le specifiche dei requisiti sono ancora la norma nelle industrie regolamentate, nelle gare d'appalto governative e nei contratti a prezzo fisso, e lo standard internazionale attuale per scriverle è ISO/IEC/IEEE 29148.
I team agili utilizzano anche dichiarazioni di requisiti, soprattutto per i requisiti non funzionali (prestazioni, sicurezza, disponibilità, accessibilità) che si applicano a molte storie. Questi vengono spesso registrati una sola volta, nella definizione di fatto o in una breve pagina sugli attributi di qualità, anziché essere ripetuti su ogni storia.
La stessa funzionalità scritta in tre modi diversi
Funzionalità: in un'app per la gestione delle spese condivise tra coinquilini, una persona paga qualcosa e divide il costo con gli altri.
Come user story
Come coinquilino che ha pagato un acquisto condiviso, voglio dividere il costo con le persone per cui era destinato, in modo che il saldo di tutti mostri quanto mi devono.
- Posso scegliere quali membri del gruppo condividono il costo; io sono incluso di default.
- La divisione predefinita è equa; posso passare a importi esatti o percentuali.
- L'app non salverà una divisione le cui parti non corrispondono al totale e indicherà di quanto si discosta.
- Il saldo di ogni persona si aggiorna non appena la spesa viene salvata e ricevono una notifica.
Come caso d'uso
Caso d'uso: Dividere una spesa. Attore principale: Paga. Precondizione: il pagatore è autenticato e fa parte di un gruppo con almeno un altro membro. Innesco: il pagatore sceglie “Aggiungi spesa”.
- Il pagatore inserisce l'importo, una descrizione e la data.
- Il sistema mostra i membri del gruppo, con il pagatore selezionato.
- Il pagatore seleziona i membri che condividono il costo.
- Il sistema propone una divisione equa e mostra ogni quota.
- Il pagatore conferma.
- Il sistema salva la spesa, aggiorna ogni saldo e notifica i membri selezionati.
- 4a. Il pagatore passa a importi esatti o percentuali: il sistema ricalcola mentre ogni valore viene digitato.
- 5a. Le quote non corrispondono al totale: il sistema blocca il salvataggio e mostra la differenza.
- 6a. Il dispositivo è offline: il sistema salva la spesa localmente, la marca come in attesa e la sincronizza quando si è di nuovo online.
- Postcondizione in caso di successo: la spesa viene registrata una sola volta e ogni saldo la riflette. In caso di fallimento: nessun saldo viene modificato.
Come job story
Quando ho appena pagato qualcosa alla cassa che è in parte per i miei coinquilini, voglio registrarlo prima di dimenticare l'importo, così posso essere rimborsato senza dover rincorrere nessuno.
Come dichiarazioni di requisiti
- REQ-1: Il sistema deve consentire a un membro del gruppo di registrare una spesa con importo, descrizione, data e pagatore.
- REQ-2: Il sistema deve consentire al pagatore di dividere una spesa in modo equo, per importi esatti o per percentuale.
- REQ-3: Il sistema deve rifiutare una divisione le cui parti non sono uguali al totale.
- REQ-4: Il sistema deve aggiornare tutti i saldi interessati entro due secondi dal salvataggio.
Osserva cosa ha evidenziato ciascuna versione. La user story è la più facile da stimare e pianificare. Il caso d'uso è l'unico che ha sollevato il caso offline e ha dichiarato cosa deve essere vero se il salvataggio fallisce. La job story ha rivelato il vincolo reale, che è la velocità alla cassa; suggerisce che la prima schermata dovrebbe chiedere solo l'importo e nient'altro, qualcosa che nessuna delle altre versioni avrebbe suggerito. I requisiti hanno aggiunto un obiettivo di prestazioni misurabile che la storia lasciava implicito.
Quale dovresti usare?
| Situazione | Inizia con | Perché |
|---|---|---|
| Prima scoperta, interviste, decidere cosa costruire | Job stories | Mantengono il team nel contesto dell'utente e creano migliori domande per le interviste |
| Product backlog agile, pianificazione dello sprint | User stories con criteri di accettazione | Piccole, stimabili e leggibili da tutti |
| Un flusso complesso, un'integrazione, movimenti di denaro | Un caso d'uso, poi suddiviso in storie | Le estensioni espongono i percorsi di fallimento prima che diventino bug |
| Prodotto regolamentato, appalto pubblico, contratto a prezzo fisso | Enunciati di requisiti, spesso tracciati ai casi d'uso | Gli auditor e i contratti necessitano di enunciati numerati e verificabili |
| Obiettivi di prestazioni, sicurezza e accessibilità | Enunciati di requisiti o definizione di completato | Si applicano a molte storie, non a una sola |
| Un MVP con un team piccolo | Una mappa di storie utente, con un caso d'uso per il flusso più rischioso | Struttura sufficiente per definire lo scope e costruire rapidamente |
Si possono combinare?
Sì, e la maggior parte dei team maturi lo fa. Una sequenza fattibile è la seguente:
- Utilizza le job story durante la ricerca, per catturare situazioni e motivazioni dagli utenti reali.
- Organizza le capacità risultanti su una mappa di storie come storie utente, e scegli la prima fetta di rilascio.
- Per uno o due flussi in cui il fallimento è costoso (pagamenti, registrazione, sincronizzazione dati), scrivi un caso d'uso leggero per trovare le estensioni, poi trasforma ciascuna estensione nella propria storia o criterio di accettazione.
- Registra i requisiti trasversali (prestazioni, sicurezza, accessibilità, conformità) una volta sola, come enunciati numerati o nella definizione di completato.
La regola pratica: scrivi solo quanto serve al team per costruire la cosa giusta in sicurezza. Un team MVP di tre persone non ha bisogno di un documento di requisiti, e un'integrazione bancaria non dovrebbe basarsi su una singola frase.
Errori comuni
- Scrivere casi d'uso come script di interfaccia utente (“l'utente clicca sul pulsante blu”), che lega il requisito a un design che cambierà.
- Scrivere storie utente senza il “in modo che”, il che impedisce al team di suggerire una soluzione più semplice.
- Trattare una job story come una persona in incognito (“Quando sono una mamma occupata...”); la situazione dovrebbe essere un momento, non un'identità.
- Copiare un lungo elenco di requisiti in un backlog come una storia per riga, il che produce storie senza utente e senza valore.
- Utilizzare formati diversi nello stesso backlog senza un accordo su quale sia la fonte di verità.
Domande frequenti
Qual è la differenza principale tra una storia utente e un caso d'uso?
Una storia utente è una descrizione in una frase di chi desidera una capacità e perché, usata per pianificare e dare priorità al lavoro. Un caso d'uso è una descrizione passo-passo di un'interazione tra un attore e il sistema, inclusi percorsi alternativi e di fallimento. Le storie sono più piccole e meno dettagliate; i casi d'uso mostrano l'intero flusso.
Una storia utente è un requisito?
È un modo leggero per catturare un requisito, ma non una specifica completa. I dettagli risiedono nella conversazione e nei criteri di accettazione. I requisiti non funzionali come prestazioni e sicurezza sono spesso registrati separatamente.
I casi d'uso sono ancora usati nei team agili?
Sì, soprattutto per flussi complessi o ad alto rischio. Use-Case 2.0, di Ivar Jacobson e colleghi, suddivide i casi d'uso in fette che possono essere pianificate come storie utente, così i due possono coesistere nello stesso backlog.
Qual è la differenza tra una job story e una storia utente?
Una storia utente parte da un tipo di utente (“Come un...”). Una job story parte da una situazione (“Quando...”), e si concentra sulla motivazione e sul risultato atteso. Le job story derivano dal pensiero jobs-to-be-done e sono più utili nella scoperta e nel design.
Un caso d'uso può diventare diverse storie utente?
Sì. Lo scenario di successo principale spesso diventa una o due storie, e ciascuna estensione importante diventa la propria storia o criterio di accettazione. È un modo affidabile per suddividere una funzionalità grande senza perdere i casi limite.
Qual è la differenza tra un caso d'uso e un caso di test?
Un caso d'uso descrive come il sistema dovrebbe comportarsi per raggiungere l'obiettivo di un attore. Un caso di test verifica un percorso specifico attraverso quel comportamento con input specifici e risultati attesi. Un caso d'uso di solito produce diversi casi di test.
Non sei sicuro di quanta specifica il tuo prodotto necessiti? Aiutiamo i fondatori a trasformare le idee in un backlog definito e poi a costruirlo in sprint brevi. Vedi i nostri piani di sviluppo mensili.