Come scrivere casi d'uso efficaci

Pubblicato: 2015-08-21

Come scrivere casi d'uso efficaci

I casi d'uso sono ampiamente utilizzati per documentare la logica aziendale e i processi di sistema. Ma ci sono molte opinioni sul fatto che siano utili e come dovrebbero essere strutturati. In alcuni progetti, gli sviluppatori non guardano mai i casi d'uso dicendo che sono dettagliati o che in realtà non ne capiscono molto. Cosa può fare un analista aziendale per rendere i casi d'uso davvero efficaci?

La maggior parte di noi è consapevole che i casi d'uso descrivono il processo aziendale e sono le specifiche per le interazioni tra il sistema e gli attori per obiettivi particolari. Un documento del caso d'uso è diverso da un documento dei requisiti e non è lo stesso di un documento di progettazione.

Esaminiamo i due esempi di casi d'uso per il requisito. Quale di loro pensi sia migliore.

Esempio 1

Usa i dettagli del caso Commenti

Nome caso d'uso – Ordina biglietti

Il nome è buono. Dà chiaramente un'indicazione di quale sia il caso d'uso

Obiettivo – Il cliente prenota con successo i biglietti per la partita di calcio sul sito web

Descrizione- L'attore visita il sito Web, visualizza il
programma, seleziona la partita
e sedili, libri il
biglietto ed effettua il pagamento della partita di calcio

L' obiettivo e la descrizione sono chiaramente indicati.
Questo aiuterà i designer
e gli sviluppatori capiscono cos'è il
obiettivo dei loro documenti di progettazione e codice

Attori: cliente, rappresentante del servizio clienti
Precondizioni – Il sistema è attivo e funzionante.
Trigger – L'attore ha effettuato l'accesso al sistema per prenotare i biglietti.
Post-condizione – L'attore è in grado di prenotare i biglietti. Il sistema aggiorna le informazioni.

Tutti gli altri dettagli del caso d'uso come attori,
precondizioni, post condizioni e
vengono menzionati i trigger che aiuteranno il
progettazione e sviluppo dell'applicazione più facile.

Flusso principale – Passi

  1. L'attore accede al sito Web e sceglie di prenotare i biglietti
  2. Il sistema visualizza le informazioni sulla prenotazione
  3. L'attore conferma i dettagli della partita (maggiori dettagli nelle specifiche dell'interfaccia utente)
  4. L'attore conferma i dettagli del posto (maggiori dettagli nelle specifiche dell'interfaccia utente)
  5. Il sistema conferma la disponibilità
  6. Il sistema presenta un modulo per ottenere informazioni sull'utente
  7. L'attore fornisce informazioni sull'utente (Dettagli in un altro caso d'uso)
  8. Il sistema presenta un modulo per le informazioni sul pagamento
  9. L'attore fornisce informazioni sul pagamento (Dettagli in un altro caso d'uso)
  10. Il sistema conferma i dettagli e fornisce un ID prenotazione
  11. L'attore salva il biglietto
  12. L'attore esce dal sistema.

Casi d'uso inclusi

- Fare un pagamento

– Genera ID prenotazione

Casi d'uso estesi

– Genera nota di mancato pagamento

– Stampa biglietto

I passaggi nel flusso principale sono chiari ma
I dettagli dell'interfaccia utente sono omessi. Dettagli dell'interfaccia utente nel caso d'uso
per quanto riguarda la scelta del posto e la partita
la selezione può rendere il caso d'uso ingombrante.
Il caso d'uso mostra chiaramente cosa deve fare l'attore e cosa farà il sistema
Il processo di pagamento è dettagliato in a
caso d'uso diverso in modo che le attività possano essere
facilmente scomponibile in diversi componenti del design.
I casi d'uso inclusi ed estesi sono denominati
in modo che uno possa
fare riferimento a loro per ulteriori dettagli.

Flusso alternativo

-cancella i biglietti

  1. L'attore annulla la transazione
  2. Il sistema annulla la transazione

Flusso d'eccezione

-Biglietti non disponibili per partite selezionate/posti selezionati

1. Il sistema visualizza un messaggio di errore

I flussi alternativi ed eccezionali sono descritti in dettaglio.

* Il caso d'uso può essere più dettagliato in termini di riferimenti e flussi alternativi ed eccezioni. Questo esempio serve a evidenziare cosa dovrebbe essere racchiuso in un caso d'uso ben scritto.

Esempio – 2

Usa i dettagli del caso Commenti

Nome caso d'uso – Ordinazione biglietti

Il nome non è dal punto di vista dell'utente e sembra una definizione di processo aziendale.

Descrizione – L'attore visita il sito web, visualizza il programma, seleziona la partita e i posti, prenota il biglietto ed effettua il pagamento della partita di calcio

Manca l'obiettivo del caso d'uso. Designer, analisti di test e sviluppatori non capiranno perché questa funzionalità debba essere sviluppata.

Attori : cliente, rappresentante del servizio clienti
Trigger – L'attore ha effettuato l'accesso al sistema per prenotare i biglietti.
Post-condizione – L'attore è in grado di prenotare i biglietti. Il sistema aggiorna le informazioni.

Mancano i presupposti.

Fasi principali del flusso

  1. Il cliente accede al sito e seleziona l'opzione 'Prenota Biglietti' 'per prenotare i biglietti
  2. Il sistema visualizza l'elenco delle corrispondenze in un menu a discesa.
  3. Il rappresentante del servizio clienti seleziona dal menu a discesa
  4. Il sistema visualizza i dettagli del posto in una mappa dei posti
  5. L'attore seleziona i posti. Se i posti non sono disponibili e viene visualizzato un messaggio di errore.
  6. L'attore fornisce i dettagli del pagamento
  7. L'attore prenota il biglietto altrimenti annulla il biglietto.
  8. Il sistema genera un ID prenotazione utilizzando il nome del cliente e un numero di 4 cifre generato casualmente

Casi d'uso inclusi
- Fare un pagamento

Nei passaggi del caso d'uso, ci sono alcuni riferimenti agli elementi dell'interfaccia utente effettivi che possono confondere il lettore. I flussi alternativi vengono scritti all'interno del flusso principale, il che rende difficile la comprensione dell'intero processo.
L'attore viene chiamato con molti nomi: 'Cliente, attore e rappresentante del servizio clienti, il che crea confusione.
La generazione dell'ID prenotazione è spiegata qui, sebbene non riguardi gli attori legati all'ordinazione dei biglietti.
Non ci sono flussi alternativi, flussi di eccezioni e nessuna menzione di tutti i casi d'uso correlati.

Questo caso d'uso manca di chiarezza e dettagli e non aiuterà il team a sviluppare correttamente la funzionalità.

Cosa dovrebbe essere in un caso d'uso Cosa non dovrebbe essere in un caso d'uso
  1. Nome
  2. Descrizione/Obiettivo
  3. Condizioni preliminari
  4. Grilletto
  5. Flusso di base e flussi alternativi
  6. Scenari di eccezione
  7. Poste condizioni
  8. Requisiti speciali se presenti
  9. Collegamento ai dettagli dell'interfaccia utente e ad altri modelli/diagrammi correlati
  1. Dettagli di attuazione
  2. Elaborazione interna
  3. Requisiti non funzionali
  4. I dettagli dell'interfaccia utente devono essere eseguiti contemporaneamente ai casi d'uso ma in un documento separato

.

Alcuni suggerimenti da seguire per scrivere casi d'uso utili:

  1. Scrivi i passaggi del caso d'uso dal punto di vista dell'attore.
  2. I casi d'uso non dovrebbero avere dettagli di progettazione e architettura. Dovrebbe concentrarsi sul processo aziendale.
  3. È meglio se i passaggi nel caso d'uso sono scritti in modo ordinato nel tempo
  4. A seconda dei requisiti e della complessità, decidere se le operazioni CRUD (Create, Read, Update and Delete) devono essere conservate in casi d'uso separati o se possono essere combinate in uno solo.
  5. È importante fornire riferimenti da e verso flussi alternativi, flussi di eccezioni, casi d'uso inclusi e casi d'uso estesi in modo che la progettazione aziendale sia completa.
  6. Scegli un modello (progetto definito, azienda definita o qualsiasi altro dettagliato) e segui la struttura per tutti i casi d'uso.
  7. È importante disporre di diagrammi di casi d'uso.
  8. In Agile, abbiamo storie di utenti per acquisire i requisiti. Le storie degli utenti possono essere dettagliate utilizzando casi d'uso snelli in modo iterativo.
  9. Le convalide dovrebbero essere dettagliate.

Dopo aver scritto un caso d'uso, poni queste domande ed è un caso d'uso efficace se la risposta è "Sì" a tutte le domande:

  1. L'utente saprà quando viene eseguito il flusso aziendale presente nel caso d'uso?
  2. È chiaro chi eseguirà quale passaggio del caso d'uso?
  3. La descrizione della logica aziendale è tale da fornire informazioni sufficienti per l'analisi, la progettazione, lo sviluppo e il test?
  4. Esistono riferimenti appropriati dal flusso principale ai flussi alternativi e di eccezione?
  5. È presente un diagramma del caso d'uso?

I casi d'uso sono un modo efficace per acquisire i requisiti e documentare formalmente i processi aziendali se sono scritti correttamente. L'intero team dovrebbe essere istruito a utilizzare i casi d'uso per svolgere i propri compiti. Casi d'uso e diagrammi di casi d'uso sono un ottimo modo per discutere i processi aziendali con i clienti. È meglio avere un modello di caso d'uso standard con linee guida sulla scrittura di casi d'uso. I casi d'uso scritti in questo modo saranno valutati da tutti i membri del team di progetto e dalle parti interessate.