Se ho un caso con 2 sottocasi dovrei usare 1 o 2 casi d'uso?

Ricorda, il punto di scrivere un caso d'uso è comunicare.

Se scrivi un documento che dice: usa il caso - l'attore cucina il cibo. Non è molto interessante Se questo caso d'uso fa parte di un elenco dei numerosi doveri di uno chef: gestire i dipendenti, ordinare cibo, prepararsi per l'ispezione sanitaria, allora è un po 'più interessante.

Se la pizza da cucina e gli astucci per la pasta sono identici al livello del tuo lavoro, lasciando il caso d'uso semplicemente come cibo da cucina va bene.

Se, tuttavia, hai bisogno di casi d'uso con più dettagli, questo mostra l'attrezzatura richiesta come forni e pentole, quindi "cucinare cibo" è troppo astratto.

Se ciò di cui hai bisogno non è ovvio per te, probabilmente stai solo facendo questo caso di uso sulla fede che c'è un motivo per farlo. Non lavorare sulla fede. Domanda esattamente a cosa serve questo finché non comprendi perché lo stai facendo. Allora saprai cosa devi comunicare.

Abbiamo tutti gli elementi?

Prendendo la definizione di Ivar Jacobson, l'originale inventore della modellazione del caso d'uso (pagina 4 del suo e-book gratuito) :

A use case is all the ways of using a system to achieve a particular goal for a particular user.

Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.

Per il momento, hai identificato l'attore principale (il capo) e alcuni potenziali casi d'uso, ma non ci hai detto nulla sull'avvio più importante della nostra analisi: qual è il sistema preso in considerazione?

Quale livello di dettaglio stai cercando?

Cockburn ha elaborato casi d'uso (nel suo libro "Scrivere casi d'uso efficaci"):

We have seen that both the goals and the interactions in a scenario can be unfolded into finer and finer-grained goals and interactions.

Ha identificato che esistono diversi livello di obiettivi (e quindi, diversi livelli di utilizzo):

• obiettivi di alto livello (li chiama cloud e kitten): questi casi d'uso forniscono una panoramica di altissimo livello degli obiettivi del sistema (ad esempio gestiscono un ristorante, suddivisi per gestire la stanza e gestiscono la cucina) e ampie categorie di attori ( es. personale, clienti, fornitori)
• obiettivi dell'utente (li chiama vedere il livello): questo è in genere il "livello di cibo del cuoco"
• obiettivi delle sottofunzioni (egli chiama l'indaco, dato che ora sei sotto il livello di visibilità): questa è un'ulteriore scomposizione degli obiettivi dell'utente.

Qual è lo scopo del tuo caso d'uso?

La prossima domanda è a cosa serve il tuo caso:

• vuoi sapere quale caso d'uso inserire nel diagramma UML?
• o vuoi descrivi i casi d'uso più in dettaglio, per poter scrivere le specifiche.

Non sapendo di quale sistema stiamo parlando, quale sia il tuo scopo e il livello di dettaglio di cui hai bisogno, è difficile valutare oggettivamente quale sarebbe l'alternativa migliore per te.

Inoltre, Jacobson e altri raccomandano di cercare il caso d'uso considerando il valore. Naturalmente, non è il valore di interesse per noi, ma è il valore del caso d'uso per l'utente.

Discussione / opinione informale

Spontaneamente, se guardassi a livello di utente, vedrei "cucinare cibo" come candidato principale per il caso d'uso. Venendo da uno sfondo ERP, vedrei Pasta e Pizza solo come entità / dati, così come le ricette per renderli (se non hai familiarità con le industrie di cottura o di processo, l'equivalente di produzione per una ricetta sarebbe una BOM + un percorso)

Se ci fosse un requisito per descrivere la differenza di processo tra "cook Pizza" e "cook Pasta", li presenterei come una sub variante in un caso d'uso simile a Cockburn (scenario). Ma nulla ti impedisce di mostrare tutti e tre i rapporti di generalizzazione.

JAAAY, scommetto che ritieni di non poter decidere tra due opzioni, entrambe sembrano avere pro e contro. È vero, è un falso dilemma. Tutti i casi d'uso sono perfettamente validi poiché sono su diversi livelli.

Write all 3 use cases, no need to choose.

C'è una ragione specifica per cui non consiglio di omettere nessuno di "CookFood" e "CookPasta". Dal momento che hai effettivamente avuto un tale pensiero significa che da qualche parte nella tua mente capisci già che c'è qualcosa di importante e distintivo in ognuno di essi. Potrebbe essere (indovinare qui) perché il caso d'uso di 'CookFood' è cruciale per il business team e 'CookPasta' è qualcosa di cui non vogliono nemmeno sentir parlare. Ma il team di sviluppo è desideroso di ricevere "CookPasta" pur avendo ancora "CookFood" per il quadro generale.

Dai un'occhiata a un esempio qui sotto. Ho saltato la maggior parte delle cose per illustrare l'idea, scrivere casi d'uso in uno stile che meglio si adatta alla tua situazione, compresi i loro livelli.

Scenario 1 (livello di riepilogo): Capo fa il suo lavoro
Chief esegue uno dei seguenti passaggi in ordine arbitrario un numero qualsiasi di volte:

1. Il capo gestisce i cuochi.
2. Menu degli aggiornamenti principali.
3. Cook prepara un pasto .

Scenario 2 (livello obiettivo dell'utente): Cook prepara un pasto

1. Cook prende un pasto dalla coda della cucina.
2. Ingredienti per le ricette di cucina.
3. Cook esegue una delle seguenti azioni in base al tipo di pasto scelto:
   1. Cook prepara la pasta .
   2. Cook prepara la pizza.
   3. Il tirocinante prepara un brindisi.
4. Cook consegna il pasto ai servi in coda.

Scenario 3 (livello di sottofunzione): Cook prepara pasta

1. Cuocere la pasta bollita.
2. Cook prepara un condimento.
3. Cook li mescola.
4. Cook riscalda la pasta nel microonde per un minuto.