Livello di dettaglio dettagliato Documentazione del caso [chiuso]

Question

Sto facendo uno sforzo per disciplinare i miei progetti e creare un documento Vision / Scope all'inizio. Inclusi in questo sono gli schemi dei casi d'uso. Il solo fatto di elencare i casi d'uso mi ha davvero aiutato a vedere pienamente tutti i requisiti richiesti dal cliente e ha aperto la finestra di dialogo.

Mi chiedo quanto sia dettagliato il caso d'uso. Se sto creando un'applicazione Web e l'utente accederà per visualizzare un rapporto, elencherò tutte le colonne sul rapporto nella descrizione del caso d'uso?

In caso contrario, quando dovrei documentare quei dettagli?

Answer 1

il vantaggio dei diagrammi dei casi d'uso è che sono semplici e gli utenti finali possono leggerli e capirli

le colonne per andare su un report fanno parte di una progettazione o di una specifica dei requisiti (dettagli di una funzione, in termini agili) e non appartengono a un diagramma del caso d'uso

tutto ciò che ingombra il diagramma dei casi d'uso appartiene altrove

dove? non importa, purché sia ??un luogo coerente e tu sappia dove trovarlo ;-)

per ricordare alle persone che aspetto ha un diagramma dei casi d'uso - e perché non c'è spazio per dettagli spuri -
_{(fonte: agilemodeling.com )}

Answer 2

Un caso d'uso, dove lavoro, è una descrizione dell'applicazione dal punto di vista dell'utente. A quel livello, è molto dettagliato. Quindi, nel tuo esempio di report, il caso d'uso descriverà il layout del report, quali dati vengono visualizzati, in quale ordine e così via. Ciò che il caso d'uso non ti dice è come vengono acquisiti i dati o da dove provengono.

Un altro modo di vederlo è pensare di passare il caso d'uso a un tester. Possono testare qualsiasi cosa nel documento (test della scatola nera) e registrarlo come difetto. Pertanto, se si suppone che determinati dati vengano visualizzati in determinate condizioni, tale caso deve essere specificato nel caso d'uso in modo che possa essere testato.

Altri documenti che potresti voler creare per completare l'immagine sono quelli che chiamiamo SAD (Software Architecture Document) e NFR (Non-Functional Requirements). Il DAU descriverà dal punto di vista della progettazione software come programmare la soluzione, quali tecnologie verranno utilizzate e quali algoritmi sono richiesti. L'NFR includerà cose come il ripristino da un'interruzione del software o dell'hardware, i tempi di risposta e così via.

Answer 3

Se sai quali colonne devono essere incluse, quindi sì, inseriscile nel documento. Se devi pensarci un po 'prima, allora fallo e documentalo. Salverà il programmatore che dovrà pensarci o chiederlo in seguito, il che rende l'intero processo più efficiente.

Tuttavia, se davvero non sai quali colonne dovrebbero essere ancora incluse, perché non sai abbastanza su come verrà riprodotto l'intero sistema una volta avviato lo sviluppo, allora non ti preoccupare e dì semplicemente " Colonne specifiche TBD. "

Non puoi conoscere tutto in anticipo, ma sicuramente documentare ciò che sai.

Answer 4

La descrizione del caso d'uso deve essere compresa tra:

• Dettagli bassi: in modo che l'utente lo capisce e pensa: " Come è facile farlo "
• Dettagli elevati: nessuna possibilità aperta (descrizione dettagliata di cosa accade dopo ogni passaggio)

Answer 5

Costruire diagrammi di casi d'uso con notazioni UML ci aiuta a capire & amp; specificare rapidamente i requisiti, in genere è possibile disegnare diagrammi di casi davanti al team di ingegneri del software per comprendere rapidamente la situazione.

In realtà, un caso d'uso dovrebbe essere in formato scritto. Ha tre formati.

1. Breve
2. Casual
3. Completamente vestito

Nel caso di un rapporto, Formato del rapporto e amp; le specifiche devono essere allegate al documento SRS, in modo che i test possano essere eseguiti di conseguenza.

Per dettagli ... Vedi " Applicazione di UML e Pattern: un'introduzione all'analisi e alla progettazione orientate agli oggetti e allo sviluppo iterativo di Craig Larman "