Che cosa può essere utilizzato al posto dei casi d'uso per raccogliere i requisiti?

A seconda della / la loro definizione di "caso d'uso" si potrebbe invece guardare alle "storie degli utenti". Dico questo se definisci un caso d'uso simile alla definizione di Usability.gov

A use case is a description of how users will perform tasks on your Web site. A use case includes two main parts: the steps a user will take to accomplish a particular task on your site the way the Web site should respond to a user's actions. A use case begins with a user's goal and ends when that goal is fulfilled.

Puoi invece usare le storie degli utenti, che provengono dalle metodologie di sviluppo agili. Sono più su che cosa vuoi fare, poi come per farlo. Ci sono molti articoli e definizioni diversi sulle storie degli utenti là fuori. Questo vecchio articolo presenta in realtà ciò che considerano la differenza tra casi d'uso e storie degli utenti ( New to User Stories ? ) E alla fine, fanno davvero la stessa cosa. Li incorniciano in modo diverso. Hai ancora bisogno delle stesse informazioni, chi, cosa e perché (obiettivo). Dovevano essere più narrativi, con persone legate a tipi di utenti reali del tuo sistema. Sono più descrittivi, ma contengono ancora tutte le informazioni necessarie.

Sembra che nel tuo caso, rappresentare le stesse informazioni che hai bisogno in modo diverso potrebbe essere esattamente ciò di cui hai bisogno.

È piuttosto strano che la BA rifiuti un modello di requisiti senza proporre un altro. Generalmente il BA dovrebbe dare suggerimenti sulla documentazione (se non ci sono standard già accettati in azienda), o almeno informare in quale formato lui / lei preparerà i requisiti.

In genere i documenti sui requisiti aziendali (o BRD ) non hanno un formato rigoroso, ma ci sono alcuni argomenti che dovrebbero copertura:

• informazioni generali (scopo, riferimenti, ipotesi, ecc.)
• processi aziendali
• ambito di applicazione
• requisiti funzionali (possono includere anche casi d'uso)
• requisiti dei dati (volume dei dati, conversione dei dati, ecc.)
• requisiti non funzionali (sicurezza, prestazioni, scalabilità, ecc.)
• Requisiti dell'interfaccia utente
• ecc.

Coprire tutti gli argomenti di cui sopra sarà probabilmente sufficiente per documentare tutte le decisioni prese durante gli incontri. Suggerisco anche che oltre a descrivere le decisioni finali, si cita anche il motivo per cui questa o quella decisione è stata / non è stata presa e perché una determinata soluzione funziona / non funziona. Questo ti aiuterà a evitare di ripetere le stesse discussioni.

Dalla mia esperienza, il BA con cui ho collaborato ci ha fornito i requisiti sotto forma di diagrammi dell'interfaccia utente. Dato che abbiamo sempre lavorato allo stesso progetto, c'erano alcune convenzioni che tutti conoscevamo e non c'era bisogno di includere quelle richieste ogni volta. Insieme con i diagrammi è stata descritta la funzionalità. Questi documenti sono stati utilizzati sia dagli sviluppatori che dal progettista dell'interfaccia utente e ogni volta che avevamo domande, eravamo invitati a chiedere. Dopo che i requisiti erano pronti e gli sviluppatori li hanno studiati, abbiamo organizzato una riunione di pianificazione durante la quale il PM ha preparato storie e attività degli utenti.

Un'altra opzione potrebbe essere Personas e Storie. Le persone vanno oltre gli attori di Use Case perché rappresentano una persona reale che usa il sistema e come potrebbero interagire con esso. Ad esempio per un sistema di gestione stipendi, avresti personaggi come:

• Bob dalla contabilità
• Alice di hr
• Tom the manager
• Bill il dipendente
• John the CEO

Questo ti consente di creare storie su come questi utenti utilizzano il sistema. Per iniziare con i concetti, controlla il libro di Mike Cohn User Stories Applicate