Il caso d'uso in informatica è una tecnica usata nei processi di ingegneria del software per effettuare in maniera esaustiva e non ambigua, la raccolta dei requisiti al fine di produrre software di qualità.
Essa consiste nel valutare ogni requisito focalizzandosi sugli attori che interagiscono col sistema, valutandone le varie interazioni. In UML sono rappresentati dagli Use Case Diagram.
Il documento dei casi d'uso individua e descrive gli scenari elementari di utilizzo del sistema da parte degli attori che si interfacciano con esso (esseri umani oppure da sistemi informativi esterni).
Un caso d'uso correttamente individuato deve avere un senso compiuto per gli attori principali (quelli che avviano il caso d'uso) nel senso che deve consentirgli di raggiungere un obiettivo per lui significativo. Un'operazione di INSERT o UPDATE all'interno di un database, ad esempio, è chiaramente un'operazione tecnica che non può essere considerata un caso d'uso, mentre l'inserimento o la modifica dei dati personali di un cliente possono essere considerati casi d'uso.
D'altra parte, un caso d'uso deve essere elementare, cioè non scomponibile in casi d'uso più semplici che abbiano ancora senso compiuto per gli attori coinvolti. Ad esempio “Gestione anagrafica” non avrebbe molto senso come caso d'uso, in quanto appunto scomponibile nei casi d'uso di inserimento, modifica e cancellazione di una voce dell'anagrafica.
La specifica di un caso d'uso dovrebbe includere almeno un nome, gli attori principali e secondari, un obiettivo (il motivo per il quale gli attori principali avviano il caso d'uso), la precondizione nella quale è eseguibile, la sequenza delle azioni svolte dagli attori e dal sistema (considerato come una scatola nera, quindi senza entrare nel dettaglio del suo funzionamento interno), le eventuali eccezioni e come esse devono essere gestite.
In generale conviene mantenere la sequenza delle azioni di un caso d'uso il più lineare possibile (con pochi salti condizionali), eventualmente scomponendo la sequenza in casi d'uso diversi, uno per ciascun ramo del flusso di esecuzione.
All'interno del documento, i casi d'uso possono essere raggruppati per area funzionale e per pre-condizioni generali comuni. Ad esempio una sezione del documento può essere dedicata ai casi d'uso possibili quando il sistema si trova in un certo stato, il che può evitare di ripetere la pre-condizione in ciascun caso d'uso riportato all'interno della sezione.
Le relazioni fra casi d'uso e attori possono essere rappresentate in un apposito diagramma UML. Inoltre le relazioni fra casi d'uso e requisiti possono essere mantenute attraverso un'apposita matrice di tracciamento, che riporta la mappatura fra casi d'uso e requisiti funzionali. In generale ciascun requisito funzionale dovrebbe rispecchiarsi in almeno un caso d'uso, e nessun caso d'uso dovrebbe implicare requisiti funzionali non presenti nel documento dei requisiti o in contraddizione con essi.
| Controllo di autorità | LCCN (EN) sh98004228 · GND (DE) 1299587100 · J9U (EN, HE) 987007532654505171 |
|---|
