Esiste una definizione esatta, ma semplice e comprensibile della distinzione tra "caso d'uso", "User Story" e "Usage Scenario"?

ci sono molte spiegazioni, ma in questo momento non vedo nessuno che spieghi le differenze in una singola frase, o due ...

(ad es. http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison molto lungo e difficile da ottenere, pieno di discussioni)

Una User Story è una versione più informale, più amichevole e più piccola di un caso d'uso , meno il diagramma UML; viene generalmente utilizzato in scenari iterativi.

Uno scenario di utilizzo è un caso d'uso elaborato in una procedura dettagliata, talvolta accompagnata da un diagramma di flusso.

Per me, le maggiori differenze tra User Story e Use Case sono:

• Una user story è un documento leggero che può essere scritto su una carta (per, come, voglio). Una User Story non cattura tutti i dettagli, è un supporto informale per la discussione.
• Un caso d'uso è un documento pesante che necessita di un documento word. Descrive un "Flusso normale" di passaggi e / o azioni e "Flussi alternativi" che sono dettagliati. Un caso d'uso cattura tutti i dettagli, è una specifica formale.

Secondo Scott W. Ambler su Usage Scenarios , questi artefatti sembrano il flusso di un caso d'uso:

Uno scenario di utilizzo , o in breve uno scenario, descrive un esempio reale di come una o più persone o organizzazioni interagiscono con un sistema. Descrivono i passaggi, gli eventi e / o le azioni che si verificano durante l'interazione. Gli scenari di utilizzo possono essere molto dettagliati, indicando esattamente come qualcuno lavora con l'interfaccia utente o descrivendo ragionevolmente ad alto livello le azioni aziendali critiche ma non indicando come vengono eseguite.

Onestamente, le differenze con il flusso di un caso d'uso non sono cristalline, anche dopo aver letto questo paragrafo (l'ultima frase è forse la più importante):

Come puoi immaginare, ci sono diverse differenze tra casi d'uso e scenari. In primo luogo, un caso d'uso in genere si riferisce ad attori generici, come il Cliente, mentre gli scenari in genere si riferiscono ad esempi di attori come John Smith e Sally Jones. Non c'è nulla che ti impedisca di scrivere uno scenario generico, ma di solito è meglio personalizzare gli scenari per aumentarne la comprensibilità. In secondo luogo, gli scenari di utilizzo descrivono un singolo percorso logico, mentre i casi d'uso in genere descrivono diversi percorsi (il corso base più eventuali percorsi alternativi appropriati). Terzo, nei processi basati su UP i casi d'uso vengono spesso conservati come documentazione ufficiale, mentre gli scenari vengono spesso scartati dopo che non sono più necessari.

Potrei sbagliarmi, ma Usage Scenario suona davvero come flusso Use Case ma rinominato con un tocco Agile.

Non esiste una definizione esatta di nessuna di queste cose. Tutto varia un po '(o molto) da un'azienda all'altra e da un sistema all'altro.

La soluzione migliore è trovare un esempio già in atto per il tuo progetto attuale e seguirlo.

Se stai creando un nuovo sistema, puoi trovare definizioni di diversi tipi di casi d'uso per qualsiasi sistema tu preferisca - Basta scegliere il modello che sembra comunicare meglio le tue intenzioni.

Non rimanere incastrato nei nomi.

Una user story è sempre informale e descrive le esigenze di un utente. Un caso d'uso può essere formale o informale e descrive il comportamento del sistema.

È possibile avere storie utente "tecnologiche", lo stesso non è vero per i casi d'uso.

Una volta fatto, la user story viene in genere scartata. I casi d'uso possono essere mantenuti durante il ciclo di vita del prodotto.

Anche l'ambito è diverso. Le storie utente hanno in genere un ambito di applicazione più piccolo e, di conseguenza, un caso d'uso comprende diverse storie utente. Un requisito modificato per un sistema esistente è descritto in una nuova user story o in una versione aggiornata del caso d'uso.

La somiglianza tra user story e casi d'uso è che entrambi vengono utilizzati per la pianificazione e la pianificazione.

Una User Story quando scomposta in attività assegnabili individualmente agli sviluppatori può o meno essere più granulare e limitata nell'ambito di uno Scenario di casi d'uso. Una User Story parla della necessità dell'utente: un obiettivo o un risultato derivante dall'uso del sistema.

Esempi di storie utente sono:

1. Sono un cliente e desidero pagare il saldo del mio conto online, una visione di alto livello
2. Sono un cliente e desidero aggiornare l'anno di scadenza sulle informazioni di credito memorizzate, una visione piuttosto dettagliata.

Al massimo livello di astrazione un caso d'uso suona molto simile - Anno di scadenza della carta degli aggiornamenti del cliente - ma qui è una dichiarazione di funzione piuttosto che un obiettivo.

Quando viene definita la granularità degli scenari di caso d'uso, essi diventano più incentrati sulla funzione e sulla procedura.

La Post-condizione di uno scenario principale relativo a un caso d'uso dovrebbe essere lo stesso risultato indicato nella User Story - L'anno di scadenza della carta di credito del cliente è aggiornato.

Gli scenari del caso d'uso descrivono passo per passo nel diagramma di flusso del testo o del processo (non necessariamente UML o BPM - Uso un diagramma di flusso interfunzionale standard per chiarezza e facilità d'uso da parte di utenti non addestrati del caso d'uso.

La linea di fondo è che le storie utente descrivono le esigenze e i risultati (cosa deve fornire il sistema) mentre i casi d'uso descrivono le interazioni tra gli attori necessari per raggiungere l'obiettivo - E cosa può andare storto (scenari di estensione, alternativa o di errore) (come interagisce l'utente con il sistema raggiunge questo risultato)

Per una discussione approfondita su questo argomento, suggerisco di leggere http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison sul sito Web di Alistair Cockburn. Dal momento che è un firmatario del Manifesto Agile, la persona che ha coniato User Stories ed è stato considerato un esperto di casi d'uso negli ultimi due decenni, penso che sia una fonte eccellente per ulteriori informazioni.

_{Breve nota temporanea : questo post necessita di miglioramenti per rispondere meglio alla domanda, come 1) ulteriori dettagli dovrebbero essere inclusi nei riferimenti 2) alcune citazioni forse 3) correttezza generale dell'inglese 4) qualità generale della narrativa 5) ecc. Sarò di nuovo ad esso. Sentiti libero di migliorarlo da solo.}

Dare un'occhiata ai loro modelli può fornire preziose informazioni sulle differenze tra questi termini.

Caso d'uso

Esistono più modelli per i casi d'uso. Ho trovato 3 dopo una rapida ricerca: 1 , 2 , 3 . Alcuni punti che (a volte vagamente) hanno in comune sono:

1. Nome del caso d'uso / titolo
2. Descrizione : un breve testo che descrive l'ambito.
3. Attore / i / attore primario - persona / e che interagiscono con questo caso d'uso specifico.
4. Prerequisito : tutto ciò che questo caso d'uso può assumere come vero prima di iniziare è il suo ciclo di vita.
5. Scenario di successo : una sequenza di passaggi che descrive il flusso corretto di eventi che si verificano.

6. Estensioni : flusso dell'applicazione quando si discosta dal flusso dello scenario di successo:

   1. Flussi alternativi - altre opzioni di flusso corretto
   2. Flussi di eccezione - flusso di eventi per quando le cose vanno male

7. Garanzia di successo (nota anche come condizione postale) - stato di applicazione dopo aver completato tutto

Alcuni punti aggiuntivi che possono essere inclusi sono Livello , Garanzie minime , Trigger , ecc.

Sopra c'è quello che viene chiamato caso d'uso completamente vestito . È possibile semplificare la creazione di casi d'uso utilizzando un caso d'uso casuale utilizzando solo i punti più vitali, ad esempio:

1. Titolo
2. Attore (s)
3. Sequenza di eventi

I casi d'uso sono stati creati e diffusi da Ivar Jacobson alla fine degli anni '80 e all'inizio degli anni '90. Successivamente anche altre persone hanno contribuito al suo lavoro (una di queste persone è Alistair Cockburn, autore di Writing Effective Use Cases ). Per parafrasare i casi d'uso di Martin Fowler possono utilizzare testi e diagrammi UML, ma il loro valore più grande risiede nel testo di esso. Sono i migliori quando non sono grandi e facili da leggere.

User story _{(aka. Feature)}

User story - una piccola storia che descrive una caratteristica particolare. C'è un modello comune su come scrivere una user story, che è:

Come un particolare tipo di utente
voglio fare qualcosa in
modo che qualche motivo .

Inoltre, la user story può avere criteri di accettazione .

Come puoi vedere questo modello è molto più piccolo di quello del caso d'uso. Le storie degli utenti sono comunemente associate alla regione di sviluppo software scrum / agile / xp. Sono pensati per essere scritti su piccole regioni di superficie, come post-it notes e / o su scrum board. Lì, essi sono (di solito) indicati i valori del punto che si avvicinano quanto bisogni sforzo da investire in quella storia utente ^rif .

Bill Wake ha sviluppato il mnemonico INVEST per descrivere le qualità che una buona storia utente dovrebbe avere, e prenderò in prestito il breve riassunto di Martin Fowler dal suo sito Web :

Indipendente : le storie possono essere consegnate in qualsiasi ordine
Negoziabile : i dettagli di ciò che è nella storia sono co-creati dai programmatori e dai clienti durante lo sviluppo.
Prezioso : la funzionalità è considerata preziosa dai clienti o dagli utenti del software.
Stimabile : i programmatori possono fornire una stima ragionevole per la costruzione della storia
Piccola : le storie dovrebbero essere costruite in un breve lasso di tempo, di solito una questione di giorni-persona. Certamente dovresti essere in grado di costruire diverse storie all'interno di una iterazione.
Testabile : dovresti essere in grado di scrivere test per verificare che il software per questa storia funzioni correttamente.

Scenario di utilizzo

Lo scenario di utilizzo segue il modello GWT che sta per Given-When-Then, in questo modo:

Scenario : titolo
Dato : un fatto particolare
E : un altro fatto particolare (può essere facoltativo)
Quando : accade un evento
Quindi : accade un altro evento

Gli scenari di utilizzo sono associati allo sviluppo guidato dal comportamento. Sembra molto simile a un test. Martin Fowler nel suo post sul blog offre un po 'di storia e di ragionamenti dietro gli scenari di utilizzo. Ecco la parte importante:

La parte data descrive lo stato del mondo prima di iniziare il comportamento che stai specificando in questo scenario. Puoi considerarlo come le pre-condizioni per il test.
La sezione quando è quel comportamento che stai specificando.
Infine, la sezione allora descrive le modifiche che ti aspetti a causa del comportamento specificato.

Gli scenari di utilizzo possono essere utilizzati per scrivere test per l'applicazione. Per citare l'ultimo paragrafo del post di Martin:

Sebbene lo stile Given-When-Then sia sintomatico del BDD, l'idea di base è piuttosto comune quando si scrivono test o specifiche per esempio. Meszaros descrive il modello come test a quattro fasi. Le sue quattro fasi sono Impostazione (Dato), Esercizio (Quando), Verifica (Quindi) e Smontaggio. Bill Wake ha elaborato la formulazione come Arrange, Act, Assert.

Riferimenti per ulteriori studi:

Pagine di Wikipedia per casi d'uso , storie utente , scenari di utilizzo
Blog di Martin Fowler su casi d'uso , storie utente , scenari di utilizzo

Non ho familiarità con User Story, ma quando ho esaminato questo diversi anni fa:

Un caso d'uso è un compito importante.
Gli scenari utente sono i vari modi in cui l'attività può essere eseguita. Quindi, ogni caso d'uso ha uno o più scenari. Il caso d'uso è l'abstract, gli scenari utente sono un catalogo di tutte le possibili istanze di quell'attività astratta.

Quindi:
utilizzare il caso A: l'utente esegue l'autenticazione con ID e password.

Scenari:
1. L'ID è riconosciuto, la password è corretta. (scenario "giornata di sole")
2. L'ID è riconosciuto, la password non è corretta.
3. L'ID è riconosciuto, la password non è corretta per la terza volta.
4. ID non riconosciuto.

Ho sempre pensato ai casi d'uso come un modo per definire i requisiti in modo narrativo per il cliente nei loro termini. w / r / t quanto sopra, se il client dice "Ma cosa succede se provano ad accedere tra mezzanotte e uno quando il sistema è inattivo?", abbiamo scoperto un altro scenario per l'attività di autenticazione e alcuni requisiti aggiuntivi.

Una user story è dal punto di vista del cliente, a volte è errata o incompleta. Potrebbe non tenere in considerazione le prestazioni, la gestione degli errori o nulla sul back-end.

Un caso d'uso è dal punto di vista dello sviluppatore. È preciso e completo. Dovrebbe rispondere a tutti i requisiti dei clienti.

"Caso d'uso" e "user story" sono gli stessi nel senso che rappresentano i "requisiti" del cliente.

Il caso d'uso è il modo in cui il sistema viene utilizzato in ciascun caso, normalmente rappresentato come interazione tra attore e sistema o tra sistemi.

La User story è il punto di partenza nel viaggio per creare uno strumento assistito da computer che consentirà all'utente finale di svolgere qualcosa e normalmente inizia con una semplice frase usando chi, cosa, perché ("Come utente che chiude l'applicazione, voglio essere invitato a salvare tutto ciò che è cambiato dall'ultimo salvataggio in modo che io possa conservare il lavoro utile e scartare il lavoro errato. "). Quella user story deve quindi essere trasformata in un caso d'uso che gli sviluppatori impiegano per creare un'applicazione e tester per condurre test.

Dal punto di vista di un QA Tester, non stanno testando "user story", ma piuttosto "casi d'uso", nel senso che stanno testando le funzionalità del software.

Lo scopo dello Scenario di utilizzo è quello di catturare l'essenza dell'interazione dell'utente con il proprio sistema per raggiungere un obiettivo, senza immergersi nei dettagli delle azioni del sistema o della progettazione effettiva. L'attenzione si concentra sull'utente, non sul sistema.

... Use Case include anche dichiarazioni su cosa farà il sistema, mentre lo Scenario di utilizzo eviterà questa discussione.

Non hai ancora deciso come implementarlo.

Dal sito delle arti del prodotto .