Requisiti -> Casi D’uso

In questo post (rispolverato dalla precedente versione del mio sito) farò un escursus su come arrivare al requisito
software dall’esigenza del cliente.

Qualche definizione di requisito :
1 – Condizione o capacità che occorre all’utente per risolvere un problema o raggiungere un obiettivo.
2 – Un requisito è una condizione o capacità documentata.

Sono raggruppati in 6 caratteristiche e 21 sottocaratteristiche (di seguito le 6 caratteristiche) :

Funzionalità :
Disponibilità : Capacità del sistema di fornire continuità di servizio.
Usabilità : Facilità di utilizzo da parte dell’utente.
Efficienza : Capacità di fornire prestazioni adeguate. Per adeguate intendo dire quello che l’utente si aspetta o ci chiede.
Manutenibilità : Facilità di manutenzione correttiva ed evolutiva.
Portabilità : trasportabilità da un ambiente ad un altro.

Per arrivare ai casi d’uso le fasi sono :

FASE 1.
In questa fase particolare risalto ha il colloquio con il committente, serve a ridurre la distanza tra la percezione delle cose e cosa si desidera realmente.
Si attua creando il documento di vision i cui contenuti sono :
– Identificazione del vero problema.
– Identificazione degli stakeholder.
– Identificare vincoli e confini del problema.
– Identificare i bisogni/caratteristiche degli stakeholder.
Avremo alla fini di questa fase un elenco di bisogni del cliente da soddisfare :
– BISOGNO 1
– BISOGNO 2
– BISOGNO 3

FASE 2
In questa fase si esplicitano meglio i bisogni del cliente in features. Quindi avremo un elenco di features :
– FEATURES 1
– FEATURES 2
– FEATURES 3
– FEATURES 4
– FEATURES 5

Un bisogno deve essere associato ad almeno una features. Alla fine si tracciano i bisogni e le features tramite una matrice di tracciabilità :

In questa fase sono utili i casi d’uso. Nell’elencare e descriverli si parte, ovviamente, dai requisiti del cliente (bisogni) quindi si ottengono dei casi d’uso (di alto livello). Il risultato di questa fase è la specifica dei requisiti utente.
Per non rimanere nella teoria un esempio calzante è quello delle regole del calcio :

BISOGNI del cliente :
B001 : La partita deve durare un tempo definito.
B002 : Il numero di giocatori deve essere definito.
B003 : Bisogna stabilire quanti arbitri ci saranno.

FEATURES :
F001 : La partita deve durare 90 minuti.
F002 : La partita è divisa in 2 tempi da 45 minuti.
F003 : Ogni squadra dispone di 10 giocatori più il portiere.
F004 : Il numero di arbitri è 1 arbitro più 2 guardalinee e il quarto uomo.

Quindi la matrice di tracciabilità :

FASE 3
E’ la fase dei requisiti SW. In questa fase di affinano le features (che abbiamo sotto forma di casi d’uso) dettagliando meglio i casi d’uso considerando tutti gli scenari del caso d’uso e non solo quello di successo (MSS, main success scenario) come magari è stato fatto nel passo 2; inoltre è di fondamentale importanza il coinvolgimento continuo di un esperto del dominio nonché degli stakeholders. Il risultato di questa fase è la specifica dei requisiti software che possiamo avere nella forma di :
– Documento di specifica dei requisiti.
– Use Case ; o diagramma dei casi d’uso.
– Forma mista SRS + Use case (1 + 2)
Anche in questa fase dovremmo tracciare i requisiti software con le features.
N.B.: Use case e diagramma dei casi d’uso non sono la stessa cosa. Un caso d’uso non implica necessariamente
rappresentarlo con un diagramma.
La figura seguente riassume quanto finora detto.

Riferimenti :

Riferimenti :

This site uses Akismet to reduce spam. Learn how your comment data is processed.