È un buon uso?

Naviga le tue risposte
2

Ho studiato l'analisi orientata agli oggetti e, per iniziare con questo, in pratica ho deciso di costruire innanzitutto il mio sistema di gestione per avere i dati dei miei clienti e così via. Cercare di raccogliere i requisiti per la prima volta e scrivere casi d'uso per la prima volta mi ha portato ad alcuni dubbi. Voglio chiedere qui alcuni dubbi riguardo ai casi d'uso.

Uno dei requisiti che ho pensato era "gestire i clienti". Da questo requisito ho ottenuto alcuni casi d'uso:

  1. Registra una nuova persona giuridica come cliente;
  2. Registra una nuova persona fisica come cliente;
  3. Aggiorna e correggi i dati del cliente;
  4. Rimuovi un cliente dal sistema;
  5. Leggi il riepilogo del cliente;

Ora, sono molto in dubbio su tutto questo. Primo, è giusto: prendere un singolo requisito e da esso derivare molti casi d'uso diversi? O dovrebbe essere solo one use case "Gestisci Clienti" contenente tutto?

In secondo luogo, darò un esempio di ciò che ho fatto. Ho scelto di iniziare dal primo. Così ho scritto il seguente caso d'uso:

Titolo: registra una nuova persona giuridica come cliente;

Attore: Utente;

Scenario: l'utente sceglie di registrare una nuova società come cliente. L'utente informa i dati dell'azienda e il sistema convalida i dati informati. L'utente viene quindi invitato a informare i dati del responsabile della società e il sistema convalida i dati informati. L'utente viene quindi portato all'elenco di tutti i clienti di persone giuridiche.

Ora, sono abbastanza sicuro di non farlo nel modo giusto. Primo, sembra semplice, è come se dicessimo "bene, l'utente va e registra i dati". Secondo, tutti gli altri casi di utilizzo sarebbero esattamente così, quindi non vedo come questo mi possa aiutare. In terzo luogo, da questo caso d'uso ho potuto ottenere solo tre possibili oggetti "cliente persona giuridica" e "responsabile dell'azienda", quindi penso davvero che questo non sia sufficiente.

Inoltre, di solito ci sono molti requisiti come "gestire i clienti", "gestire i dipendenti" o "gestire i fornitori" e sembra che all'inizio saranno sempre così. È corretto? Questi tipi di requisiti finiscono sempre con questo tipo di casi d'uso semplici come questo?

Sto facendo questo giusto? C'è qualcosa di sbagliato nei casi di utilizzo che ho scoperto e nel modo in cui ho scritto quel particolare caso d'uso? Come lavoriamo con questo tipo di casi d'uso così semplici che lo scenario è quasi come se si affermasse di nuovo l'obiettivo del caso d'uso?

So che ci sono molte domande lì, ma ogni tipo di aiuto è apprezzato. Sto iniziando ora a lavorare con questo genere di cose e non sono sicuro se sto facendo le cose per bene. Grazie mille in anticipo!

    
posta user1620696 15.08.2013 - 22:22
fonte

2 risposte

3

Questi casi d'uso mi stanno bene.

Ciò che potresti non rendertene conto è che i casi d'uso possono differire in base ai "ruoli ...", ovvero, alcune persone possono avere l'autorità per esaminare gli account dei clienti, ma altri no. I ruoli e le responsabilità di un product manager saranno radicalmente diversi da quelli di un impiegato.

Di conseguenza, scrivere in questo modo i casi d'uso soddisferà requisiti basati non solo sul tipo di informazioni a cui alcuni utenti hanno accesso, ma anche sui servizi richiesti e attesi dal sistema da ciascun utente.

I tuoi casi d'uso ti aiuteranno anche a definire i ruoli ... Se trovi che molti casi d'uso sono simili, puoi combinare i loro elementi comuni in un ruolo. Come molte altre attività di sviluppo del software, questo processo è iterativo: affinerai i tuoi casi d'uso quando tu e i tuoi clienti inizierete a capirli meglio.

    
risposta data 15.08.2013 - 22:32
fonte
3

Gran parte del beneficio dei casi d'uso deriva dalla risposta a "Che cosa succede se?" Ad esempio, tu dici che il sistema convalida le informazioni. Quali saranno le tue convalide? Alcuni campi sono obbligatori o si tratta solo del numero di telefono o dell'indirizzo di posta elettronica che soddisfa un determinato formato? Diciamo che alcuni campi sono obbligatori,

What happens when the data doesn't meet the rules?

Puoi salvare un cliente riempito solo parzialmente? Dovrai solo premere Annulla e perdere tutti gli altri campi che hai inserito? Se è possibile salvarne uno parziale, avrà un aspetto diverso nell'elenco di tutti i clienti? Ci saranno alcune cose che non puoi fare perché non è ancora valido?

Mentre passi attraverso questi casi d'uso, penserai anche agli altri. Ad esempio, cosa significa rimuovere un cliente? Butti via tutti i dati o tienili in una sorta di cronologia o sezione archivio? Se lo tieni, come fa un utente a guardarlo? Lo includeresti comunque in alcuni riepiloghi o elenchi o rapporti? Qual è il punto di tenerlo o di cancellarlo?

E questo potrebbe farti pensare hey, dovrei essere in grado di supportare questi dati in qualche modo. O esportalo in Excel. Oppure fai una lista che posso incollare in qualche altra applicazione. E altri casi di utilizzo ti sembrano.

La cosa più importante su di loro è il processo di pensiero che ti guidano attraverso. Questo è più importante quando intervisti qualcuno per far fronte alle esigenze del tuo business, e meno quando sei tu stesso, ma non è ancora pari a zero. Possono anche essere un utile riferimento per te più tardi.

    
risposta data 16.08.2013 - 02:37
fonte

Leggi altre domande sui tag

Come funzionano veramente i join MySQL? User story e servizio Web