Linea guida: Workshop sui casi d'uso
Questa linea guida descrive come preparare e tenere un workshop sui casi d'uso.
Relazioni
Descrizione principale

Organizzazione del workshop

Il workshop sui casi d'uso è una riunione organizzata di brainstorming. E' necessario rappresentare una vasta gamma di conoscenze:

  • Requisiti del cliente
  • Progettazione di sistema
  • Progettazione di unità
  • Rational Unified Process
  • Verifica

Questo significa che il gruppo conterrà persone con background, conoscenze ed esperienze differenti. Cercare di formare un gruppo piccolo (meno di dieci partecipanti). Una configurazione normale è di prendere metà del gruppo dal team di sviluppo e l'altra metà dai rappresentanti degli utenti. Al centro c'è il moderatore. Il moderatore deve fungere da mediatore (un catalizzatore di tutte le idee e desideri).

Tool

I tool necessari sono:

  • Due grandi lavagne bianche (una è sufficiente ma due sono meglio)
  • Fogli da lavagna a cavalletto
  • Nastro adesivo
  • Foglietti autoadesivi in due colori
  • Penne per lavagne bianche (in diversi colori)
  • Matite
  • Pareti su cui attaccare i fogli, preferibilmente in una stanza "laboratorio" da poter utilizzare indisturbati per due o tre settimane.

Definizione degli attori

Tentare di identificare chi o cosa utilizzerà il sistema. Iniziare considerando che delle vere persone utilizzeranno il sistema; la maggior parte delle persone riesce a focalizzare meglio su cose concrete piuttosto che astratte. Una volta identificati gli utenti, tentare di individuare il ruolo che l'utente deve svolgere quando interagisce con il sistema - in genere si tratta di un buon nome per un attore.

Quando si identificano gli attori, scrivere una breve descrizione di ognuno; di solito, pochi punti che riassumono il ruolo svolto dall'attore nei confronti del sistema e le relative responsabilità sono utili successivamente quando verrà il momento di stabilire di cosa ha bisogno l'attore dal sistema.

Quando si definiscono gli attori, non dimenticare gli altri sistemi con i quali interagisce il sistema in fase di progettazione. L'icona relativa all'attore qui è fuorviante, sembra implicare una 'persona' ma il concetto di attore comprende anche i sistemi. Tuttavia, inizialmente individuare degli attori 'umani'; la maggior parte dei gruppi rende meglio se in principio ci si concentra su cose note e, in seguito, si prendono in considerazione quelle più insolite.

Non preoccuparsi della struttura del modello di casi d'uso o delle relazioni fra gli attori; individuare semplicemente le persone o le cose che utilizzeranno il sistema. Focalizzare sull'identificazione e prepararsi ad individuare molti attori. Non occuparsi ora di filtrare l'elenco; verrà fatto durante l'identificazione dei casi d'uso (vedere di seguito).

Un sistema gestionale

Porre questa domanda: quali sono i ruoli nell'organizzazione che utilizzerà il sistema? Disegnare un omino per ciascun ruolo suggerito e scriverci sotto un nome. Quindi elencare due colonne di attori sulla lavagna - una su ogni lato della nuvola o icona appena disegnata. A volte può essere utile utilizzare la parola ruolo o utente al posto di attore.

Domande da porre:

  • Chi utilizzerà il sistema?
  • A quali altri sistemi il sistema invierà informazioni?
  • Da quali altri sistemi riceverà informazioni?
  • Chi avvia il sistema?
  • Chi gestirà le informazioni degli utenti?

Diagramma descritto nel testo di accompagnamento.

Istanza o classe?

Potrebbero essere poste domande quali "Perché non è Tom l'attore? E' sempre Tom che se ne occupa". Sarà quindi necessario porre altre domande per ottenere una comprensione di quale sia il ruolo di Tom. Il nome dell'attore deve rifletterne il ruolo.

  • Qual è il ruolo di Tom?
  • Chi altro è in grado di eseguire quel ruolo?
  • Perché Tom ha quel ruolo?

Molti attori possono essere identificati direttamente dalla loro normale posizione nell'organizzazione. Una posizione nell'organizzazione potrebbe corrispondere a più di un ruolo per il sistema. Ad esempio, Tom potrebbe essere un magazziniere o la persona responsabile dell'organizzazione del magazzino per la creazione di spazio per i nuovi prodotti. Queste due responsabilità potrebbero rappresentare due attori diversi per il sistema.

Alcune persone vorranno generalizzare fino agli estremi. Potrebbero suggerire un utente come attore, ed affermare che si tratta dell'unico attore di cui si ha bisogno. Vero, ma noioso, e non aggiunge molto alla comprensione del sistema. Tentare di evitare di discutere su questo argomento, se viene fuori. Annotare sulla lavagna l'attore Utente e continuare con l'attore successivo.

Trucchi del mestiere

  • Chiedere a tutti se manca qualcosa.
  • Esternare dei suggerimenti non buoni. In questo modo il team può correggervi e spiegare gli esatti ruoli del sistema.
  • Accettare sempre tutti i suggerimenti (è sempre possibile rimuovere in un secondo momento i duplicati e i non attori. Effettuare delle critiche ai suggerimenti di qualcuno abbassa semplicemente lo spirito della riunione.

La definizione degli attori in genere richiede da 1 a 4 ore. La lavagna a questo punto dovrebbe elencare molti attori, ma accertarsi che vi sia ancora spazio per aggiungere i casi d'uso. Quando la serie di attori sembra essere completa, è ora di iniziare con i casi d'uso.

Diagramma descritto nel testo di accompagnamento.

Definizione dei casi d'uso

Cancellare dalla lavagna la nuvola o l'icona ed iniziare ad identificare i casi d'uso. Concentrare l'attenzione su casi d'uso concreti, evitare discussioni sulle relazioni di inclusione e di estensione. Tracciare un'ellisse e scrivere il nome di ogni suggerimento. Disegnare delle frecce che puntano agli attori.

Utilizzare come punto di forza il fatto di non sapere nulla sulla loro applicazione. I partecipanti al workshop devono spiegare cosa dovrebbe svolgere il sistema. Porre molte domande sul sistema. Quando i partecipanti forniscono le spiegazioni, verranno creati i casi d'uso.

Alcune persone sono in grado di capire immediatamente il concetto di caso d'uso, altre no. Per collocare il concetto in una prospettiva più semplice, far tracciare a qualcuno una vista del sistema. Una vista del sistema è un'astrazione del sistema. Ad esempio, può trattarsi di un server con un database ed un certo numero di client oppure di schede di circuiti con i relativi compiti speciali contrassegnati. Questa vista in genere è semplice da illustrare: uno dei partecipanti di solito prende la penna della lavagna bianca e mostra come funziona il sistema. La vista del sistema sarà utile per estendere i casi d'uso da un margine del sistema all'altro ed implicitamente indica un certo numero di stati diversi del sistema. Porre delle domande sugli stati e verranno creati altri casi d'uso. Verificare cosa accade quando si interrompono le differenti comunicazioni - ciò è utile per identificare dei flussi alternativi nei casi d'uso.

Se si sta lavorando con un sistema tecnico, la vista del sistema è spesso qualcosa di molto noto a tutti e potrebbe essere il metodo migliore per individuare gli attori. In questo caso si può lasciare ai partecipanti il compito di disegnare la vista del sistema prima di iniziare a richiedere gli attori.

Se si sta lavorando con un sistema gestionale, la vista del sistema potrebbe non essere così ovvia a tutti. In questo caso potrebbe essere più utile un grafico che descrive le routine manuali. Il grafico può descrivere come viene spostata un'entità di business da una persona all'altra e cosa deve essere svolto con quell'entità. Per visualizzare il processo di ordine e consegna, il grafico potrebbe mostrare una vista schematica dell'ufficio del cliente, il proprio ufficio, il magazzino ed il magazzino del cliente.

Accertarsi che sia il modello di casi d'uso che la vista di sistema/vista delle entità di business siano chiaramente visibili a tutti. Questo è uno dei casi in cui due lavagne potrebbero tornare utili.

Lasciare che i casi d'uso abbiano dei nomi lunghi. Un caso d'uso identificato di recente potrebbe avere un nome lungo come una frase (è un buon inizio per la breve descrizione del caso d'uso ed in seguito il nome può essere accorciato).

Sarà sempre presente un certo numero di casi d'uso che sembrano avere delle parti in comune. Verificare che tutti comprendano che per ora è accettabile. Non ha senso ancora procedere ora con la strutturazione, poiché non si conosce abbastanza il contenuto dei casi d'uso. E' necessario attendere che il flusso di eventi sia stato delineato, prima di iniziare a parlare delle relazioni dei casi d'uso.

Quando il gruppo concorda che i casi d'uso presenti sulla lavagna coprono la funzionalità dell'intero sistema, effettuare una pausa per il pranzo.

Una volta rientrati dalla pausa, rivedere i risultati della sessione mattutina:

  • Osservare ciascun attore: quali sono i suoi compiti in questo sistema? 'Compito' può risultare una parola più adatta di 'caso d'uso' per le persone non esperte di tecniche di modellazione di casi d'uso.
  • Osservare ogni caso d'uso suggerito: è comprensibile il valore che ne otterrà l'utente con questo caso d'uso? Se il risultato è positivo, l'utente sarà più predisposto a voler creare il caso d'uso.
  • Osservare ciascun caso d'uso suggerito: è completo? Oppure è semplicemente una piccola parte di qualcosa di più grande?

Domande da porre:

  • Ogni attore deve avere almeno un caso d'uso. In caso contrario, potrebbe trattarsi di un attore duplicato (un altro attore esegue lo stesso ruolo) o l'attore non è realmente un diretto utente del sistema. In questi casi, se una discussione in merito alla conservazione dell'attore non porta a forti motivazioni per mantenere l'attore, questi può essere rimosso.

Scrivere una breve descrizione per ogni caso d'uso

Esaminare i casi d'uso uno alla volta e creare un foglio per ogni caso d'uso. Disegnare un'ellisse e scrivere il nome del caso d'uso in cima al foglio. Prendere una matita e chiedere al gruppo di aiutarvi a scrivere una breve descrizione del caso d'uso. Una breve descrizione deve essere composta da circa un massimo di 3 frasi. A volte è utile disegnare gli attori collegati al caso d'uso. Cercare di lasciare circa metà foglio vuoto per la fase successiva.

Diagramma descritto nel testo di accompagnamento.

Durante questa attività ci si renderà conto che determinate cose che sembravano chiare a tutti in realtà non lo sono affatto. Fare riferimento ai requisiti identificati come a funzioni ed esigenze chiave dell'utente nella Visione e tentare di individuare i requisiti su questo caso d'uso.

Verranno creati dei nuovi casi d'uso. Altri scompariranno. Collocare i fogli dei casi d'uso sulle pareti. Organizzarli in modo tale da avere una colonna per area funzionale. (Non utilizzare la lavagna per questa attività: è necessaria per la vista del sistema, gli attori e i casi d'uso). Se non è possibile risolvere dei quesiti immediatamente, segnarli su un foglietto adesivo e collocarli sul caso d'uso appropriato. Utilizzare un colore per i quesiti.

Quando tutti i casi d'uso hanno il proprio foglio e la propria descrizione, si passa alla successiva modalità. Spesso è consigliabile ritagliare un po' di tempo per definire se davvero sono stati individuati tutti i casi d'uso necessari.

Il modello creato fino a questo momento può essere documentato in Rational Rose o Rational RequisitePro e prodotto sotto forma di un report di valutazione del modello di casi d'uso.

Descrizione strutturata per fasi del flusso di eventi di ciascun caso d'uso

Il metodo per iniziare la scrittura di un caso d'uso è di strutturarne prima il testo. Non ha senso cercare di strutturare da soli il testo senza prima aver ottenuto l'input dagli stakeholder.

Esaminare i casi d'uso uno alla volta. Annotare le differenti azioni in ordine. Non cercare di immaginare quale aspetto avranno le strutture del codice, i loop, le istruzioni for-while, ecc., occuparsi semplicemente del flusso base di eventi senza prendere ancora in considerazione le alternative. Denominare i passi 1, 2, 3, 4... Per facilitare al gruppo la comprensione del livello di dettaglio richiesto, si può affermare di volere da 5 a 10 passi nel flusso di base.

Una volta concordati i passi del flusso base di eventi, ripercorrerlo ed identificare dei passi alternativi. Denominare i flussi alternativi A1, A2, A3, A4...

Diagramma descritto nel testo di accompagnamento.

Durante la discussione verranno sollevate diverse questioni, molte delle quali non verranno risolte fino a che non si arriva all'Analisi e progettazione. Ricordarsi di annotare tutte le problematiche, oltre alle supposizioni necessarie lungo il percorso. Alcune delle problematiche devono essere risolte presto in modo che lo specificatore di requisiti possa correttamente illustrare nei dettagli il flusso di eventi ed alcune delle questioni che devono essere risolte prima di iniziare l'analisi e la progettazione.

Ciò che è presente su ogni foglio ora deve essere sufficiente per lo specificatore di requisiti, perché possa descrivere in dettaglio il flusso di eventi del caso d'uso.

Acquisizione delle specifiche supplementari

Durante questa sessione vi saranno dei requisiti sul sistema che non si sarà in grado di cogliere prontamente in un caso d'uso. In genere questo tipo di istruzioni ha a che fare con la funzionalità, l'utilizzabilità, l'affidabilità, le prestazioni e la supportabilità del sistema. Tenere un foglio separato in cui annotare queste istruzioni. Formeranno una base per le specifiche supplementari.

Ricondurre i requisiti ai casi d'uso

Ripercorrere le richieste chiave degli stakeholder ed ogni funzione contenute nel documento Visione e verificare che il modello di casi d'uso le affronti nel modo appropriato. Discutere quali esigenze dell'utente o requisiti debbano essere ricondotti a quali casi d'uso.

Diagramma descritto nel testo di accompagnamento.

Prendere il documento Visione e leggere la prima funzione. Annotarne l'identità su uno (o più, se necessario) foglietti autoadesivi (utilizzare un secondo colore per facilitare la distinzione fra i requisiti e le problematiche). Posizionare il foglietto sui casi d'uso che soddisfano quel requisito. In seguito sarà possibile inserire queste tracciabilità nel repository di RequisitePro.

Esiste sempre un certo numero di requisiti che non possono essere collegati ad alcun caso d'uso:

  • Può trattarsi di requisiti specifici che devono essere rinviati alla progettazione; annotarli su un foglio (requisiti di progettazione).
  • Può trattarsi di requisiti generali che non possono essere collegati ad alcun caso d'uso: collocarli nell'elenco per le specifiche supplementari.
  • Può trattarsi di requisiti dimenticati e richiedono dei nuovi casi d'uso o delle modifiche a quelli esistenti.

Rivedere la struttura: esistono dei casi d'uso senza requisiti? Perché? Il caso d'uso non è necessario? O la persona che ha scritto la specifica del requisito ne ha dimenticato la funzionalità? (In genere si tratta di questo). La situazione deve essere risolta. Il cliente è al corrente che ha bisogno di questa funzionalità? Ha intenzione di pagarla?