Sono confuso riguardo ai livelli dei casi d'uso. Tutto quello che ho potuto capire è che i casi d'uso contenuti in un altro caso d'uso ricadono sotto il livello che si trova al di sotto del livello del caso d'uso del contenitore.
Ho identificato i seguenti casi d'uso per un negozio di e-commerce e vorrei sapere se i loro livelli sono determinati correttamente o meno. Si prega di fornire una descrizione delle differenze tra i livelli se ho fatto qualcosa di sbagliato qui.
Non esiste un unico modo "corretto" di scrivere e strutturare i casi d'uso. Innanzitutto, il tuo approccio deve funzionare per te e per le persone con cui lavori.
Vorrei suggerire che "login" spesso non è un "vero" obiettivo dell'utente, quindi vedrei questo come sotto il livello di obiettivo dell'utente. Dal mio punto di vista, "acquistare prodotti" sembra essere un ragionevole obiettivo dell'utente per un cliente nel tuo esempio. "Sfoglia prodotti" potrebbe non essere sempre un obiettivo dell'utente principale, ad es. quando stai sfogliando un catalogo per comprare qualcosa. D'altra parte, il Cliente potrebbe semplicemente voler ottenere informazioni senza l'intenzione di acquistare immediatamente.
La "scrittura di casi d'uso efficaci" di Alistair Cockburn è sicuramente una grande fonte di scrittura di casi d'uso. Suggerisco anche di guardare "Lean Architecture for Agile Software Development" di James Coplien e Getrud Bjornvig: questo libro discute l'idea di una "abitudine", cioè una sequenza di compiti che viene fuori nel contesto di diversi casi d'uso ma che è in stesso non è un caso d'uso completo. (Cerca "abitudini d'uso" e troverai una sezione pertinente del libro, quindi vai a comprare e leggi il libro: è fantastico!)
La scomposizione dei casi d'uso in casi d'uso sempre più piccoli è un argomento molto dibattuto e molte persone sono piuttosto riluttanti a farlo. Tra le altre questioni, il sovraccarico amministrativo di tenere traccia delle dipendenze dei casi d'uso e di tenere in relazione i casi d'uso correlati può essere molto elevato. Inoltre, i casi d'uso a grana fine e altamente decomposti sono spesso difficili da lavorare con persone non IT (e, a dire il vero, anche per gli esperti IT).
Cordiali saluti, Oliver
Vorrei solo secondare la risposta di Oliver. Di solito, per accedere non si definisce un obiettivo aziendale: è uno scenario di implementazione sottomesso a un obiettivo aziendale. Alla fine della giornata le persone non tornano a casa e dicono: "Tesoro, ho passato una splendida giornata di lavoro - ho effettuato l'accesso 36 volte!"
Alistair Cockburn incornicia i suoi casi d'uso in un obiettivo (quindi, "casi d'uso guidati dall'obiettivo") e la pratica del caso d'uso più buona segue la sua visione.
Le abitudini sono uno strumento di sviluppo utilizzato per ricordare sequenze ricorrenti di implementazione (solitamente codice) e per ricordare come si inseriscono nel flusso generale durante l'analisi. Sono usciti dal mio lavoro insieme a Gertrud Bjørnvig e Trygve Reenskaug sul paradigma DCI, che è un modo per collegare nel codice i modelli mentali di utenti e sviluppatori.
La nostra posizione (di Gertrud e mia) - basata su un bel po 'di esperienza - è che i casi d'uso in decomposizione confondono solo coloro che hanno più bisogno di acquistare ciò che dicono: l'utente finale. Mentre la visione originale di Jacobsson delle relazioni di casi d'uso formale come "raffina" ed "estendere" hanno una bella semantica formale, l'acquisizione dei requisiti alla fine è un'attività necessariamente informale ricca di incoerenze, allusioni e contesto. Pertanto, si consiglia di utilizzare i casi di utilizzo non per comunicare i mandati di requisiti da alcuni oracle di mercato al team, ma solo a structure e documentare le conversazioni e le decisioni che si verificano tra la gestione del prodotto e sviluppo in una finestra aperta con feedback a cortocircuito molto breve.
Leggi altre domande sui tag design architecture use-case requirements-management