Elenco di controllo: Caso d'uso
Questo elenco di controllo assiste nel verificare che tutti i casi d'uso siano stati descritti e strutturati correttamente.
Relazioni
Elementi correlati
Descrizione principale


Voci elenchi di operazioni
Ogni caso d'uso concreto ha utilizzato almeno un attore
In caso contrario, c'è un errore; un caso d'uso cui non è stato attribuito un attore è superfluo e deve essere rimosso. Per ulteriori informazioni, vedere Linea guida: Caso d'uso.
Ogni caso d'uso è indipendente dagli altri
Se due casi d'uso sono attivati sempre nella stessa sequenza, è probabile si debba unirli in unico caso d'uso.
Per un caso d'uso incluso
fa assunzioni sui casi d'uso che lo includono? Tali assunzioni devono essere evitate, così che le modifiche apportate ai casi d'uso che lo includono non incidano sul caso d'uso stesso.
Esistono casi d'uso con comportamenti o flussi di eventi molto simili
In questo caso - per conservare la similitudine della funzionalità in futuro - è necessario unirli in unico caso d'uso. Ciò semplifica l'introduzione di modifiche future. Nota: è necessario coinvolgere gli utenti se si decide di unire casi d'uso, in quanto gli stessi possono essere implicati, interagendo con il nuovo caso d'uso.
Parte del flusso di eventi è stato già modellato come un altro caso d'uso
In questo caso, è possibile consentire al nuovo caso d'uso di usare il vecchio.
Alcune parti del flusso di eventi fanno già parte di un altro caso d'uso
In questo caso, è necessario estrarre questo sottoflusso affinché possa essere utilizzato dai casi d'uso in questione. Nota: è necessario coinvolgere gli utenti se si decide di riutilizzare il sottoflusso, in quanto gli stessi possono essere implicati, interagendo con il nuovo caso d'uso.
È il caso di inserire il flusso di eventi di un caso d'uso in quello di un altro
In questo caso, modellarlo con una relazione di estensione per gli altri casi d'uso.
I nomi dei casi d'uso sono univoci, intuitivi ed esplicativi in modo da impedire confusione nello stadio successivo
In caso contrario, cambiare i nomi.
Clienti e utenti comprendono allo stesso modo i nomi e relative descrizioni dei casi d'uso
Tutti i nomi dei casi d'uso devono descrivere la funzionalità che supporta il relativo caso.
Il caso d'uso soddisfa tutti i requisiti che ne regolano le prestazioni
È necessario includere eventuali requisiti (non funzionali) da gestire nei modelli oggetto del caso d'uso Requisiti speciali.
La sequenza di comunicazione tra attori e caso d'uso è conforme alle aspettative
È chiaro come e quando il flusso del caso d'uso ha inizio e fine
Potrebbe esistere una funzionalità attivata solo quando una determinata condizione non viene soddisfatta
È stata inserita la descrizione delle conseguenze derivanti da una condizione non soddisfatta?
Sono presenti casi d'uso eccessivamente complessi
Per ottenere un modello del caso d'uso di facile comprensione, potrebbe essere necessario suddividere i casi d'uso più complessi.
Un caso d'uso contiene flussi di eventi diversi
In questo caso, conviene suddividerlo in due o più casi d'uso distinti. Un caso d'uso che contiene flussi di eventi diversi è molto difficile da comprendere e gestire.
Il sottoflusso corrisponde a un caso d'uso modellato correttamente
L'esecutore del caso d'uso è stato definito chiaramente
Lo scopo del caso d'uso è chiaro?
Le interazioni tra gli attori e lo scambio di informazioni è chiaro
La breve descrizione offre il quadro completo del caso d'uso