<Nome del progetto>
Specifica caso d'uso: <Nome del caso d'uso>
Versione <1.0>
[Nota: Il seguente modello è fornito per l'utilizzo con RUP (Rational Unified Process). Il testo racchiuso in parentesi quadre e visualizzato in blue italics (stile=InfoBlue) è inserito per fornire una guida all'autore e dovrebbe essere cancellato prima di pubblicare il documento. Un paragrafo digitato seguendo questo stile sarà automaticamente riportato all'impostazione normale (stile=Body Text).]
Cronologia revisione
Data |
Versione |
Descrizione |
Autore |
<gg/mmm/aa> |
<x.x> |
<dettagli> |
<nome> |
|
|
|
|
|
|
|
|
|
|
|
|
Indice
2.2.1 < Primo flusso alternativo>
2.2.2 < Secondo flusso alternativo>
3.1 < Primo requisito speciale>
6.1 <Nome del punto d'estensione>
Specifica caso d'uso:
<Nome del caso d'uso>
[Il seguente modello viene fornito per una Specifica del caso d'uso, che contiene le proprietà testuali del caso d'uso. Questo documento viene utilizzato con uno strumento di gestione dei requisiti, come Rational RequisitePro, per specificare e indicare i requisiti nelle proprietà del caso d'uso.
I diagrammi del caso d'uso possono essere sviluppati in uno strumento di modellazione visivo, come Rational Rose. Un report di caso d'uso (con tutte le proprietà) può essere creato con Rational SoDA. Per ulteriori informazioni, vedere le guide al tool in RUP.]
[La descrizione illustra brevemente lo scopo del caso d'uso. Per questa descrizione sarà sufficiente un solo paragrafo.]
[Questo caso d'uso inizia quando l'attore fa qualcosa. Un attore avvia sempre i casi d'uso. Il caso d'uso descrive ciò che fa l'attore e come risponde il sistema. Ciò deve essere formulato sotto forma di dialogo tra l'attore e il sistema.
Il caso d'uso descrive ciò che succede dentro il sistema, ma non dice come o perché. In caso di scambio di informazioni, essere precisi su cosa viene ricevuto e inoltrato. Ad esempio, non è molto illuminante dire che l'attore inserisce informazioni sul cliente. È preferibile dire che l'attore inserisce il nome e l'indirizzo del cliente. Spesso è utile un Glossario dei termini per rendere gestibile la complessità del caso d'uso. Si potrebbe voler definire cose come informazioni sul cliente per evitare che il caso d'uso si perda in dettagli.
All'interno del testo del caso d'uso potrebbero essere inserite delle alternative semplici. Se bastano solo poche frasi per descrivere ciò che succede quando c'è un'alternativa, farlo direttamente all'interno della sezione Flusso di eventi. Se il flusso alternativo è più complesso, utilizzare una sezione separata per descriverla. Ad esempio, una sottosezione Flusso alternativo spiega come descrivere alternative più complesse.
Spesso una fotografia vale più di mille parole, anche se niente può sostituire una prosa chiara e pulita. Se ciò migliora la chiarezza, sentirsi liberi di incollare nel caso d'uso rappresentazioni grafiche delle interfacce utente, flussi di processo o altre figure. Se un grafico di flusso può essere utile per rappresentare un processo di decisioni complesso, utilizzarlo senza dubbio. Similmente al comportamento dipendente dallo stato, un diagramma di transizione di stato spesso chiarifica il comportamento di un sistema meglio di pagine e pagine di testo. Utilizzare il mezzo di informazione adeguato al problema, ma attenti ad utilizzare terminologia, notazioni o figure che il pubblico potrebbe avere difficoltà a capire. Ricordarsi che lo scopo è di chiarire, non di rendere complicato.]
[Alternative più complesse sono descritte in una sezione separata, a cui si fa riferimento nella sottosezione Flusso di base della sezione Flusso di eventi. Pensare alle sottosezioni Flusso alternativo come comportamento alternativo - ogni flusso alternativo rappresenta un comportamento alternativo in genere a causa delle eccezioni che avvengono nel flusso principale. Possono essere utili alla descrizione di eventi associati con il comportamento alternativo. Quando un flusso alternativo termina, gli eventi del flusso principale vengono recuperati.]
[I flussi alternativi possono essere divisi, a turno, in sottosezioni per migliorare la chiarezza.]
[Potrebbero esserci, e probabilmente ci saranno, vari flussi alternativi in un caso d'uso. Mantenere separati i flussi alternativi per migliorare la chiarezza. L'utilizzo di flussi alternativi migliora la leggibilità di un caso d'uso. I flussi alternativi impediscono che i casi d'uso vengano scomposti in gerarchie di casi d'uso. Si ricordi che i casi d'uso sono solo descrizioni testuali il cui scopo principale è documentare il comportamento di un sistema in modo chiaro, conciso e comprensibile.]
[Un requisito speciale è tipicamente un requisito non-funzionale specifico per un caso d'uso, ma non è specificato chiaramente o naturalmente nel testo del flusso di eventi del caso d'uso. Esempi di requisiti speciali includono requisiti legali e contrattuali, standard di applicazioni e attributi di qualità del sistema da costruire comprendendo requisiti di utilizzabilità, affidabilità prestazione o supportabilità. In aggiunta, in questa sezione potrebbero essere catturati altri requisiti - come ambienti e sistemi operativi, requisiti di compatibilità e vincoli progettuali.]
[Una precondizione di un caso d'uso è lo stato del sistema che deve essere presente prima che un caso d'uso venga attuato.]
[Una postcondizione di un caso d'uso è un elenco di possibili stati in cui può trovarsi il sistema immediatamente dopo la fine di un caso d'uso.]
[Punti di estensione del caso d'uso.]
[Definizione della locazione del punto di estensione nel flusso di eventi.]