Un caso d'uso dettagliato ha delle sezioni ben definite:
Il preambolo è composto da tutto ciò che precede lo scenario principale e le estensioni. Contiene informazioni che è importante leggere prima degli scenari del caso d'uso.
La portata descrive i confini del sistema (o dei sistemi) in via di progettazione. Normalmente un caso d'uso descrive l'utilizzo di un sistema software (o di un sistema che comprende si hardware che software). In questo caso viene chiamato caso d'uso di sistema.
I casi d'uso vengono classificati con un livello, tra questi potrebbero esserci: livello obiettivo e il livello sottofunzione
Un caso d'uso a livello di obiettivo utente è il tipo più comune, che descrive gli scenari con cui un attore prima può portare a termine il suo lavoro, raggiungendo degli obiettivi.
Un caso d'uso a livello di sottofunzione descrive invece dei sotto-passi, richiesti come supporto al raggiungimento di un obiettivo dell'utente. Un esempio è un caso d'uso al livello di sottofuzione pagamento con carta di credito, che potrebbe essere condiviso da diversi casi d'uso a livello di obiettivo utente.
L'attore finale è l'attore che vuole raggiungere un obiettivo, e questo richiede l'esecuzione dei servizi del sistema. L'attore prima è l'attore che usa direttamente il sistema. Di solito coincidono.
Questo elenco è più importante e pratico di quanto non lo possa sembrare a prima vista. Infatti le parti interessate e i loro interessi suggeriscono e limitano ciò che il sistema deve fare.
Il [sistema] definisce un contratto tra le parti interessate, dove i casi d'uso descrivono nel dettaglio gli aspetti comportamentali di questo contratto... Il caso d'uso, come contratto per il comportamento, raccoglie tutti e solo i comportamenti ralativi alla soddisfazione degli interessi delle parti interessate
Ciò risponde alla domanda cosa va scritto nel caso d'uso?, la risposta è: ciò che serve a soddisfare tutti gli interessi delle parti interessate.
PARTI INTERESSATE E INTERESSI:
- Cassiere: vuole un inserimento dei dati preciso e rapido. Non vuole errore nei pagamenti, perchè gli ammanchi di cassa vengono detratti dal suo stipendio.
- Addetto alle vendite: vuole che le commissioni sulle vendite siano aggiorante.
- ...
Le pre-condizioni descrivono che cosa deve essere sempre vero prima di iniziare uno scenario del caso d'uso. Esse non vengono verificate all'interno del caso d'uso, si presume che siano vere. Spesso ci sono condizione che devono essere vere, ma che non vale la pena scrivere: il sistema deve essere acceso.
Le post-condizioni affermano che cosa deve essere vero quando è stato completato con successo il caso d'uso, ovvero lo scenario principale di successo o un percorso alternativo. La garanzia deve soddisfare le esigenze di tutte le parti interessate.
Pre-condizioni: il cassiere si è identificato e autenticato
Post-condizioni: la vendita viene registrata. Le imposte sono calcolate correttamente. La contabilità e l'inventario sono aggiornati. Le conmmissioni sono registrate. Le approvazioni alle autorizzazioni di pagamento sono registrate. Viene generata una ricevuta.
Lo scenario principale di successo viene anche chiamato happy path (percorso felice), o ancora flusso di base, o flusso tipico. Esso descrive un percorso di successo comune che soddisfa gli interessi delle parti interessate. Lo scenario principale è costituito da una sequenza di passi, che può contenere passi da ripetere più volte, ma che di solito non comprende alcuna condizione o diramazione. Infatti le alternative del percorso vengono in genere scritte nelle sezione delle estensioni.
Lo scenario principale è formato da un sequenza di passi che contiene:
Il primo passo di un caso d'uso non sempre rientra in questa classificazione, ma può indicare l'evento (trigger) che scatena l'esecuzione dello scenario. Talvolta nemmeno l'ultimo passo ricade in una di queste tre categorie, ma piuttosto può descrivere il fatto che l'attore ha effettivamente conseguito l'obiettivo che perseguiva.
NOTA: i nomi degli attori vengono scritti con la iniziale maiuscola per facilitarne l'identificazione.
Scenario principale di successo:
1. il Cliente arriva alla cassa POS con gli articoli da acquistare
2. il Cassiere inizia una nuova vendita
3. il Cassiere inserisce il codice identificativo dell'articolo
4. il Sistema ...
Il Cassiere ripete i passi 3-4 fino a che non indica che ha terminato
- ...
In genere un caso d'uso è composto da diversi scenari. Lo scenario principale è uno di questi. Le estensioni hanno lo scopo di descrivere tutti gli scenari, sia di successo che di fallimento. Per questo le estensioni comprendono normalmente la maggior parte del testo di un caso d'uso. Le estensioni descrivono le possibili diramazioni. Dunque la maggior parte degli scenari sono scritti come differenza da quello principale. Questo consente la scrittura di un caso d'uso compatto.
Per esempio, al passo 3 (vedi sopra), il Cassiere inserisce il codice identificativo dell'articolo, le estensioni a tal proposito sono:
Estensioni:
3a. Codice identificativo non valido (non trovato nel sistema):
1. Il Sistema segnala l'errore e rifiuta l'inserimento
3b. Ci sono più articoli della stessa categoria e non importante tenere traccia dell'identità univoca dell'articolo (per esempio, 5 confezioni di hamburger vegetariani)
1. Il Cassiere può inserie il codice identificati della categoria
dell'articolo e la quantità
Ciascuna estensione e formata da due parti:
Quando è possibile, la condizione va scritta come qualcosa che possa essere rilevato dal sistema o da un attore, si veda le seguenti condizioni:
3a. Il Sistema rileva un fallimento nella comunicazione con il servizio esterno di calcolo delle imposte
3a. Il servizio esterno di calcolo delle imposte non funziona.
Il primo stile è preferibile, poiché descrive qualcosa che il sistema può rilevare; il secondo formula semplicemente un'ipotesi.
Al termine di un'estensione, di solito, lo scenario si fonde nuovamente con lo scenario principale di successo. Talvolta un caso d'uso si dirama per eseguire un altro caso d'uso. Per esempi, Aiuto Ricerca Prodotto (che mostra i dettagli del prodotto, come: descrizione, prezzo, una foto o un video e così via) è un caso d'uso distinto, che viene talvolta eseguito all'interno di Elbaora Vendita (per esempio, quando non si riesce a trovare il codice identificativo di un articolo). Di solito, l'esecuzione di questo seconda caso d'uso è indicata da una sottolineatura, come mostra il seguente esempio:
3a. Codice identificati dell'articolo non valido (non trovato nel sistema)
1. Il Sistema segnale l'errore e rifiuta l'inserimento
2. Il Cassiere risponde all'errore:
...
2c. Il Cassiere esegue Aiuto Ricerca Prodotto per ottenere il vero codice
identificativo dell'articolo e il suo prezzo.
In effetti, i casi d'uso vengono scritti come ipertesti, e l'esecuzione di un altro caso d'uso viene rappresentata come un collegamento ipertestuale. In questo caso, facendo clic sul nome del caso d'uso sottolineato, ne verrà visualizzato il testo.
Per conclude le estensioni possono essere usate per gestire almeno tre tipi di situazioni principali.
Se un requisito non funzionale, un attributo di qualità o un vincolo si riferiscono in modo specifico a un caso d'uso, allora è bene scriverlo insieme al caso d'uso. Potrebbe trattarsi di qualità come prestazioni, affidabilità e usabilità, oppure vincoli di progettazione, che siano stati imposti o considerati probabili.
Requisiti speciali:
- Interfaccia utente di tipo touch screen su un monitor piatto grande. Il testo deve essere visibile da una distanza di un metro.
- Risposta all’autorizzazione di credito entro 30 secondi il 90% delle volte.
- In qualche modo si desidera un ripristino robusto quando non riesce l’accesso ai servizi remoti, come per esempio il sistema di inventario.
- Internazionalizzazione della lingua sul testo visualizzato.
- Regole di business inseribili nei passi da 3 a 7.
Registrare questi requisiti insieme ai casi d'uso è consigliato da UP. Tuttavia, molti professionisti trovano utile spostare e riunire, alla fine, tutti i requisiti non funzionali nelle Specifiche Supplementari.
Spesso ci sono variazioni tecnologiche nel modo in cui qualcosa deve essere fatto, ma non nella sostanza delle cose, è importante registrare tali varianti nel caso d'uso. Un esempio è un vincolo tecnico, imposto da una parte interessata, relativo alle tecnologie di input/output. Per esempio una parte interessata potrebbe dire "Il sistema POS deve consentire l'inserimento del numero di carta di credito tramite un lettore di scheda e la tastiera". Inoltre è necessario capire le varianti nel formato dei dati, per esempio, i codici identificativi degli articoli possono utilizzare gli schemi di codifica UPC o EAN, ed essere codificati mediante dei codici a barre.
Elenco delle varianti tecnologiche e dei dati:
3a. Codice identificativo dell’articolo inserito tramite lettore laser di codice a barre (se il codice a barre è presente) oppure tramite tastiera.
3b. Il codice identificativo dell’articolo può essere basato su uno tra gli schemi di codifica UPC, EAN, JAN o SKU.
7a. Le informazioni sulla carta di credito sono inserite tramite lettore di schede o tramite tastiera.
7b. Firma per il pagamento con carta di credito ottenuta su ricevuta cartacea oppure con una cattura digitale della firma.
Tra i formati descritti fino ad ora per descrivere i casi d'uso abbiamo anche il formato a due colonne dei casi d'uso, ad ogni modo non esiste un formato migliore; alcuni preferiscono lo stile a una sola colonna, altri quello a due colonne. Le sezioni possono essere aggiunte ed eliminate, i nomi delle intestazioni possono cambiare. Nessuno di questi aspetti riveste una particolare importanza.
Adesso vediamo come scrivere in uno stile essenziale, senza riferimento all'interfaccia utente.