Sto lavorando al modello di caso d'uso di un'applicazione di web design come Dreamwaver, non riesco a capire a quale livello dovrei scrivere il modello del caso d'uso.
ex: quando l'utente inserisce un testo dovrei fornire un caso d'uso di:
o è sufficiente fornire un caso d'uso chiamato "modifica proprietà del testo"?
Molti documenti su UML e su come scrivere casi d'uso, si concentra solo sulla parte come . Ecco un documento che sembra essere il migliore per rispondere alla tua domanda. Leggi questo: Scrittura di casi d'uso efficaci . (Scrivimi se vuoi una copia) Lo stesso autore ha il libro che è una forma estesa. Consulta qui prenota .
In sostanza, mentre i libri vengono pubblicati, devi prima definire l'ambito del sistema generale a diversi livelli. Ad esempio, inizia con un'organizzazione X che serve la sua organizzazione cliente. Il caso d'uso è definito di l'organizzazione su quella scala. Più in basso, ora le singole funzioni vengono eseguite in (uno o più prodotti), diciamo che un'applicazione client (utilizzata dall'applicazione client e dagli amministratori) parlerà con il server e così via.
Il livello dei dettagli aumenta man mano che si scende, ma l'ambito diventa stretto. Comprendi che lo scopo non è quello di ripetere le cose ma di organizzare le cose sotto forma di diversi livelli gerarchici.
In questo modo, continui a perfezionare l'ambito e vai più in profondità. Quindi quando ti fermi? Probabilmente la risposta semplice è: quando è banale non scrivere la domanda. In sostanza, (come per il libro) si scrivono casi d'uso di ciascuna entità separatamente. - L'organizzazione, i vari sistemi (o prodotti) consumati, A un certo punto, scrivere casi d'uso di un'intera applicazione dell'interfaccia utente potrebbe essere sufficiente; Ma se avete una componente importante che sembra di gran lunga più importante del caso d'uso a quel livello è più importante; a quel livello probabilmente dovrai scrivere il caso d'uso a livello di moduli / input a quel livello.
Modifica
Ora venendo alla tua domanda - come ho detto, dipende dalla portata. Dall'interfaccia utente (anche quando si trattano elaboratori di testi o editor di testo avanzato all'interno di un sistema molto più grande), ci si aspetta che l'interfaccia utente restituisca molti messaggi al core (ogni comando di formattazione come un semplice messaggio). Tuttavia, dal punto di vista dell'attuale oggetto del modello che implementa questo - ogni comando è un oggetto unico. Quindi, per l'oggetto back-end, ogni comando è una funzionalità unica e quindi sono casi d'uso diversi e unici.
Se va bene per il tuo cliente fornire un caso d'uso chiamato "modifica proprietà del testo" ed elencare in esso tutte le proprietà del testo che dovrebbero essere modificabili, allora dovrebbe andar bene.
La domanda suscita alla fine la domanda su quale sia il livello appropriato di granularità. Ma tutto dipende dal livello in cui vuoi che i tuoi casi d'uso siano (come sviluppatore o designer) o quale livello di controllo ha o vuole il tuo cliente. È un atto di equilibrio e ci sono alcune cose da considerare tra casi d'uso del corso e del corso:
Ho trovato che il meglio è un mix bilanciato tra di loro, e inoltre consente al cliente di specificare (o specificarlo per loro) le funzionalità che desidera e di creare casi d'uso da parte loro. Per i casi d'uso va bene che il cliente non debba preoccuparsi dei dettagli più fini di come funziona il software. L'unica cosa che interessa è se la funzione funziona o meno.
Ora la stima del tempo è importante, sia per te che per il tuo cliente / cliente / project manager, e se il caso d'uso è troppo grande per te da stimare il tempo allora hai un'opzione come sviluppatore da scomporre per te puoi pianificare, creare un progetto top-down ed essere in grado di stimarlo meglio. Pensaci; è più facile stimare diverse variazioni di 1 ora rispetto a un grande cambiamento di 8 ore.
È meglio definire il caso d'uso a livello di obiettivo dell'utente (cosa che l'utente otterrebbe dopo aver fatto il caso d'uso), poiché i casi d'uso sono intesi per catturare i requisiti funzionali e le fasi dettagliate possono essere elaborate in descrizioni caso d'uso o caso d'uso realizzazioni. Per il tuo caso, "modifica le proprietà del testo" sarebbero sufficienti e diversi scenari di utilizzo possono essere descritti come diverse istanze e percorsi di casi d'uso.
Leggi altre domande sui tag requirements use-case