Per fare ciò bisogna: ignorare l'interfaccia utente, concentrarsi sullo scopo dell'attore
I casi d'uso devono essere scritti in modo conciso e allo stesso tempo in modo completo (con chiara indicazione di soggetto e verbo e di eventuali frasi subordinate).
Questo tipo di casi d'uso sono i più comuni e consigliati. Non descrivono il funzionamento interno del sistema, i suoi componenti o aspetti relativi al suo progetto. Piuttosto il sistema è descritto come dotato di responsabilità e collaborano con altri elementi dotati di responsabilità.
Questo richiede di scrivere i requisiti in modo da concentrarsi sugli utenti di un sistema e quindi sugli attori che si interfacciano con il sistema e ponendo l'accento anche sulla comprensione di ciò che l'attore considera un risultato di valore.
Procedura base per trovarli è:
In generale, va definito un caso d'uso per ciascun obiettivo utente. É opportuno assegnare al caso d'uso un nome simile all'obiettivo dell'utente. Se l'obiettivo è elaborare una vendita, il caso d'uso si chiamerà Elabora vendita. Il nome dei casi d'uso deve iniziare con un verbo.
Quale dei seguenti casi d'uso è valido?
Si potrebbe ribattere che tutti questi sono casi d'uso a livelli diversi, a seconda dei confini del sistema, degli attori e degli obiettivi.
Ma invece di chiedere in generale "Qual è un caso d'uso valido?", una domanda più pratica è "Qual è un livello utile per esprimere i casi d'uso nell'analisi dei requisiti di una applicazione software?".
I casi d'uso possono avere diversi livelli, con riferimento all'obiettivo che rappresentano.
UML fornisce una notazione dei diagrammi dei casi d'uso che consente di illustrare i nomi e gli attori dei casi d'uso nonché le relazioni tra gli stessi.
UML comprende un tipo di diagrammi utili per visualizzare i flussi di lavoro e i processi di business che descrivono flussi di lavoro complessi, che comprendono molti partecipanti e azioni concorrenti. I diagrammi di attività vengono presentati più avanti.
| Disciplina | Elaborato | Ideaz.: 1 settimana | Elab. 1: 4 settimane | Elab. 2: 4 settimane | Elab. 3: 4 settimane | Elab. 4: 4 settimane |
|---|---|---|---|---|---|---|
| Requisiti | Modello dei casi d'uso | Workshop dei requisiti di 2 giorni. La maggior parte dei casi d'uso vengono identificati, gli viene dato un nome e sono riassunti in un breve paragrafo. Il 10% dei casi d'uso più importanti viene analizzati e scritto in dettaglio. Questo 10% dovrà avere maggior importanza dal punto di vista dell'architettura e del rischio, ed elevato valore di business. | Quasi alla fine di questa iterazione si tiene un altro workshop sui requisiti di 2 giorni. Si ottengono un approfondimento e un feedback dal lavoro di implementazione, quindi si completa il 30% dei casi d'uso nel dettaglio | Quasi alla fine di questa iterazione si tiene un altro workshop sui requisiti di 2 giorni. Si ottiene un approfondimento e feedback dal lavoro di implementazione, quindi si completa il 50% dei casi d'uso nel dettaglio. | Si ripete, si completa il 70% di tutti i casi nel dettaglio | Si ripete con l'obiettivo di chiarire e scrivere nel dettaglio l'80-90% dei casi d'uso. Solo una piccola parte di questi è stata implementata durante l'elaborazione, mentre il resto verrà fatto durante la costruzione. |
| Progettazione | Modello di progetto | Nessuno | Progettazione relativa a un piccolo insieme di requisiti significativi dal punto di vista dell'architettura e del rischio | Ripetere | Ripetere | Ripetere. I rischi maggiori e gli aspetti più significativi dell'architettura dovrebbero ora essere stati stabilizzati. |
| Implementazione | Modello di implementazione (codice e così via) | Nessuno | Implementare questi | Ripetere. Viene costruito il 5% del sistema finale | Ripetere. Viene costruito il 10% del sistema finale. | Ripetere. Viene costruito il 15% del sistema finale. |
| Gestione del progetto | Piano di sviluppo software | Stime molto vaghe dell'impegno complessivo | Le stime iniziano a prendere forma | Un po' meglio.. | Un po' meglio.. | Ora è possibile affidarsi in modo razionale a stime sulla durata complessiva del progetto, le milestone principali, l'impegno e i costi. |
| Disciplina | Elaborato | Ideaz. | Elab. | Costr. | Trans. |
|---|---|---|---|---|---|
| Iterazione | I1 | E1..En | C1..Cn | T1..T2 | |
| Modellazione del business | Modello di dominio | i | |||
| Requisiti | Modello dei casi d'uso | i | r | ||
| Visione | i | r | |||
| Specifiche supplementari | i | r | |||
| Glossario | i | r | |||
| Progettazione | Modello di progetto | i | r | ||
| Documento dell'Architettura Software | i |
Legenda: i sta per inizio, r sta per raffinamento