Attualmente sto lavorando al refactoring di un sistema di registrazione del campo estivo per includere alcune nuove funzionalità e lo utilizzerò anche come base per un nuovo sistema di registrazione delle classi dopo la scuola.
Per questa nuova versione del sistema, voglio iniziare scrivendo le descrizioni dei casi d'uso per il processo di registrazione (e in definitiva ho intenzione di documentare tutti i casi d'uso).
Capisco che lo scopo di un caso d'uso è raggiungere l'obiettivo di un utente, ma non sono ancora sicuro di come il processo di registrazione debba essere diviso in casi d'uso.
Ecco le opzioni a cui stavo pensando:
- Un grande "Register Student (s) For Classes" use case
- Dividilo in casi d'uso separati: "Inserisci le informazioni dello studente", "Seleziona le classi", "Paga per le registrazioni"
- hanno casi d'uso separati ma hanno anche un caso d'uso "Register Student (s) For Classes" che include "i casi d'uso più granulari
Un altro fattore da considerare è la tempistica: i genitori possono voler inserire le informazioni di base dei loro studenti (nome, età, ecc.) prima dell'inizio della registrazione, ma naturalmente alcuni genitori completeranno l'intera procedura di registrazione in una sola seduta . Inoltre, il pagamento non seguirà sempre immediatamente la selezione della classe; in alcuni casi i genitori potranno completare il pagamento in un secondo momento (entro una finestra di 48 ore).
Ho letto alcuni articoli su casi d'uso sul sito web di Alistair Cockburn, ma sono ancora confuso su quali siano le linee guida per dividere i casi d'uso in un caso come questo.
La mia inclinazione è di andare con l'opzione 3 poiché il sistema avrà un'interfaccia della procedura guidata che potrebbe guidare l'utente attraverso la registrazione dall'inizio alla fine, realizzando l'obiettivo dell'utente di registrare il / i suo / i studente / i per le classi , ma i casi d'uso "inclusi" potrebbero anche essere avviati da soli. Mi chiedevo anche se dovessi avere un "caso di selezione delle classi di modifica" distinto per il caso in cui il genitore ritorna nel sistema successivamente e cambia le selezioni di classe per conto dello studente, o se questo dovrebbe essere solo uno scenario alternativo del Caso di utilizzo "Seleziona classi".
Che cosa consiglieresti e perché? Quali linee guida dovrebbero essere usate in generale quando si analizzano i limiti del caso d'uso, oltre l'idea di un "obiettivo utente"?
Aggiornamento:
Ho trovato utile questa citazione del primo capitolo del libro di Alistair Cockburn:
Depending on the level of view needed at the time, the writer will choose to describe a multi-sitting or summary goal, a single-sitting or user goal, or a part of a user goal, or subfunction. Communicating which of these is being described is so important that my students have come up with two different gradients to describe them: by height relative to sea level (above sea level, at sea level, underwater), and by color (white, blue, indigo).
Mi sembra che "Register Student (s)" sia un obiettivo di livello riassuntivo, poiché potrebbe potenzialmente richiedere più sedute per completare. In questo caso, la linea è sfocata, ma penso che l'idea di un caso d'uso riassuntivo suggerisca che il mio approccio n. 3 sopra è ragionevole.