Concentrati su cosa c'è e perché ed evita come quando scrivi le storie degli utenti.
Quello che stai affrontando è in realtà un ottimo esercizio per tutti gli sviluppatori. Essere in grado di esprimere il requisito in termini di business semplici è una competenza importante.
Dovresti concentrarti sui requisiti generali come "devi essere in grado di fare una singola selezione da un elenco a discesa di oggetti in modo che l'utente possa abilitare l'azione Foo" invece di specificare usando una casella combinata o una casella di riepilogo o qualsiasi altra cosa che innesca una routine specifica.
Un altro modo di avvicinarsi a questo è fingere che il codice base / framework sottostante sia quasi una scatola nera completa. Ogni volta che ti ritrovi a dire "usa l'oggetto XYZ", puoi controllare da solo chiedendoti se lo sapresti in un sistema di scatole nere.
Aggiornamento:
IMO, va bene inserire i dettagli in un caso d'uso che indichi il livello di dettaglio richiesto per le informazioni. Ad esempio, con un sistema di iscrizione è equo il gioco per specificare
- cognome; campo obbligatorio
- nome di battesimo; campo obbligatorio
- Account ID; sistema generato nessun input necessario
- segno zodiacale; campo facoltativo - (suggerimento) fornire la ricerca dall'inserimento della data di nascita?
- ecc ....
La chiave è che non stai specificando il come tecnico per quella informazione. Se ti ritrovi a dire "usa una stringa di classe / carattere array / o campo varchar" per cognome, allora sai che stai esagerando.
Se sei multilingue, usa due lingue diverse come cartina del tornasole. Ad esempio, le stringhe in C sono generalmente matrici di char (acter) mentre C ++, Java e C # (ok, e quasi tutti gli altri ...) hanno un oggetto simile a String reale. Se trovi che la tua specifica è invalidata utilizzando una di queste lingue, saprai che hai specificato troppo.
Vale la pena notare che sto specificatamente utilizzando il termine Use Case anziché Strumento utente , sebbene la variante che utilizzo sia un ibrido di entrambi. Il mio obiettivo di un caso d'uso è quello di dare una panoramica di ciò che sta accadendo (una User Story nel senso più stretto), ma poi lavorare attraverso gli attori, i sistemi e le funzionalità generali che è necessario. Il mio approccio è più vicino a quello che Fowler sta suggerendo in quell'articolo di wikipedia in contrasto con l'approccio di Cockburn.
Quindi avrò un caso singolo (o così) per lo scenario di registrazione o l'elemento di lavoro. Se è davvero complesso, lo spezzerei in multipli, ma non è un grosso problema. Il caso d'uso può quindi essere suddiviso in singoli compiti, se necessario. Ciò che viene gettato in una mischia particolare dipende da molte variabili, ma non c'è nulla in questo approccio che ti impedisca di avere un componente dimostrabile alla fine della mischia.