Ho pubblicato un nuovo video di introduzione ai Casi d’Uso (Use Cases):
Il video è un estratto dal corso in auto-istruzione: https://corsi.analisi-disegno.com/corsi/casi-duso/
Ho pubblicato un nuovo video di introduzione ai Casi d’Uso (Use Cases):
Il video è un estratto dal corso in auto-istruzione: https://corsi.analisi-disegno.com/corsi/casi-duso/
A porsi le domande necessarie per capire le esigenze e individuare possibili soluzioni.
Lo scenario base di un caso d’uso (descrizione funzionale) può avere numerose varianti. Alcune tra queste sono semplici, altre complesse, e possono a loro volta dare origine ad ulteriori varianti.
Come gestire le varianti di varianti? Me lo ha chiesto una studentessa di informatica, proponendo un esempio interessante, che riporto qui. Nel seguito la mia risposta, con uso degli scenari alternativi.
Buongiorno Dott. Comai,
mi chiamo xxx, studentessa di informatica.
In questi giorni sto tentando di documentare alcuni semplici casi d’uso, utilizzando il suo template:
(http://adcorsi.com/analisidisegnowp/wpcontent/uploads/2013/08/templatecasiuso.odt)
Nel descrivere i casi d’uso mi è sorto, però, un dubbio:
E’ possibile che una variante dello scenario base abbia a sua volta varianti? C’è qualche regola che lo vieta?
Ad esempio, per il caso d’uso PrelievoSoldi (molto semplice) ho il seguente scenario base:
- Il cliente inserisce la tessera e inserisce il pin
- Il sistema valida il pin
- Il cliente indica l’importo da prelevare
- Il sistema autorizza il prelievo e restituisce la tessera
- Il cliente ritira la tessera, il denaro e la ricevuta.
Vorrei descrivere la situazione particolare in cui il sistema non riconosce il pin (passo 2). In tal caso l’utente può effettuare altri due tentativi, se sbaglia anche l’ultimo tentativo il sistema restituisce la tessera ed il caso d’uso termina con errore.
Non so se la descrizione dell’anomalia sia meglio esprimerla in una sola variante oppure descrivere ogni tentativo come variante di variante. Di seguito le riporto le mie due soluzioni:
Soluzione con unica variante dello scenario base:
2a.Se il sistema non riconosce il cliente, il cliente deve reinserire il proprio pin. Se il sistema riconosce il pin, il cliente torna al passo 3 dello scenario base. Altrimenti, lo reinserisce ancora e se il sistema non lo riconosce nuovamente restituisce la tessera al cliente.
Soluzione con variante per ogni tentativo:
Variante 1:
2a. Il pin non è valido
1. Il cliente inserisce di nuovo il proprio pin.
2. Il sistema valida il pin, si ritorna al passo 3 dello scenario
base
Variante 2: variante della variante 1
2a.2a. Il pin non è valido
1. Il cliente inserisce di nuovo il proprio pin
2. Il sistema valida il pin, e ritorna al passo 3 dello scenario
base
Variante 3: variante della variante 2
2a.2a.2a. Il pin non è valido
1. Il sistema restituisce la tessera e termina il caso d’uso con errore.
2. Il cliente ritira la tessera
Spero possa aiutarmi
Grazie
La soluzione è l’uso degli scenari alternativi, cioè di descrizioni di scenario ulteriori rispetto allo scenario base, anche se ad esso riconducibili. In pratica:
Prendere la variante che può avere varianti, e “promuoverla” a scenario alternativo.
Proseguendo nell’opera di adeguamento della tecnica dei casi d’uso (Use-cases 2.0) Jacobson propone la definizione di casi d’uso infrastrutturali, per integrare gli aspetti non funzionali – essenziali per la gestione di ogni sistema, ma “interni” – che non trovavano posto nelle versioni iniziali della sua teoria.
Dall’articolo Use-Case 2.0, apparso su Communications of the ACM, maggio 2016:
Handling all types of requirements
Although they are one of the most popular techniques for describing systems’ functionality, use cases are also used to explore non-functional characteristics. The simplest way of doing this is to capture them as part of the use cases themselves—for example, relating performance requirements to the time taken between specific steps of a use case or listing the expected service levels for a use case as part of the use case itself.
Some non-functional characteristics are subtler than this and apply to many, if not all, of the use cases. This is particularly true when building layered architectures, including infrastructure components such as security, transaction management, messaging services, and data management. The requirements in these areas can still be expressed as use cases—separate use cases focused on the technical usage of the system. These additional use cases are called infrastructure use cases, as the requirements they contain will drive the creation of the infrastructure on which the application will run.
Ivar Jacobson ha pubblicato Use-Case 2.0 White Paper, in cui propone una serie di modifiche alla teoria e alla pratica dei casi d’uso.
Lo scopo è di rendere i casi d’uso più compatibili con lo sviluppo agile, in particolare con Scrum, e con le tecniche lean tipo Kanban.
Tra le proposte, centrale il concetto di “Use Case Slice”, cioè l’idea di poter affettare un caso d’uso per poterne gestire meglio la pianificazione, lo sviluppo e il test.
La mia guida alla scrittura dei casi d’uso è sempre molto usata, così come la relativa template.
Periodicamente ricevo delle richieste di chiarimento su aspetti particolari, e la più recente contiene una serie di domande interessanti, che meritano risposte pubbliche.
Webinar sui casi d’uso tenuto da Karl Wiegers, esperto in gestione requisiti. Sintetico, ma con alcune osservazioni utili, ad esempio sulle relazioni tra requisiti funzionali, casi d’uso e test.