Scomposizione del caso d'uso per il sistema di registrazione delle classi

2

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:

  1. Un grande "Register Student (s) For Classes" use case
  2. Dividilo in casi d'uso separati: "Inserisci le informazioni dello studente", "Seleziona le classi", "Paga per le registrazioni"
  3. 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.

    
posta Matt Browne 07.06.2013 - 02:49
fonte

1 risposta

2

In breve, non c'è una vera risposta giusta o sbagliata qui: è una di quelle cose in cui si adatta al tuo stile di lavoro e al tuo flusso di lavoro. Personalmente, mi piace prendere tutti gli utenti che potrebbero mai usare il mio sistema e quindi elencarli.

  • principale
  • Student
  • Maestro
  • Amministratore

Quindi scrivo TUTTE le cose diverse che quegli utenti vorrebbero realizzare per il mio sistema

  • Parent
    • Registra bambino / figli (potrebbe essere più di un bambino)
  • Student
    • registrarsi
  • Teacher
    • Visualizza gli studenti che si sono registrati per la loro classe
  • Amministratore
    • Registrati studenti
    • Sposta gli studenti in diverse sezioni

Infine, ognuno di questi comportamenti diventa un caso d'uso, con flussi principali e flussi alternativi, come un genitore che inserisce una classe non valida o un amministratore che tenta di spostare uno studente in una sezione completa. Potresti scoprire che alcuni di questi casi d'uso sono molto similari e va bene, sentiti libero di combinarli. Almeno in questo modo sai che non ne manchi nessuno!

    
risposta data 07.06.2013 - 04:44
fonte

Leggi altre domande sui tag