I criteri di accettazione della user story agile sono gli stessi dei requisiti funzionali tradizionali?

Non penso che esista una mappatura 1-1 tra requisiti funzionali e user story o criteri di accettazione.

Per prima cosa, il tuo esempio di requisito funzionale non è un buon requisito . Non è atomico: scriverei i tuoi requisiti funzionali come requisiti multipli:

• The system shall require an email address to create an account.
• The system shall require a password to create an account.

Vorrei quindi aggiungere ulteriori requisiti per affrontare l'univocità degli indirizzi e-mail, qualsiasi tipo di richiesta di password e forse anche la convalida degli indirizzi e-mail. Alla fine, avrei circa 5 o 6 affermazioni "obbligatorie" tradizionali relative agli utenti che creano un account.

Come puoi vedere, non c'è nulla in questi requisiti sull'archiviazione delle preferenze, che è un aspetto chiave della tua user story. Osservando i criteri di accettazione, hai decisioni di design codificate che non fanno parte della storia dell'utente. C'è una disconnessione lì.

In un progetto agile che utilizza storie utente, creerei un'epopea per account e profili utente. Una storia sotto questo account creerebbe un account: "Come acquirente, voglio creare un account con un indirizzo email." Potresti avere altre storie sull'accesso con Google o Facebook (o qualche altro SSO) che fanno parte di questa epopea. Verranno creati i criteri di accettazione per definire i casi: che cosa dovrebbe accadere quando lo stesso indirizzo di posta elettronica viene utilizzato due volte? Cosa dovrebbe accadere se un utente immette l'indirizzo email sbagliato? Cosa succede se qualcosa che non è un indirizzo email valido non viene inserito?

Raccomanderei di non provare a mappare i concetti dai metodi di gestione dei progetti tradizionali a metodi agili. Tendi a fare lo stesso tipo di cose, ma non c'è una mappatura 1: 1 pulita tra le cose.

I requisiti funzionali richiedono che le persone siano in grado di pensare in modo astratto al problema. Le specifiche scritte in questo modo tendono ad essere molto dense e hanno molte implicazioni. Spesso le persone che li scrivono si confondono tra i requisiti e l'implementazione.

Le storie degli utenti non richiedono tanta astrazione. Inoltre costringono la persona a scriverle per riflettere su come viene utilizzato il software e meno sul modo in cui viene implementato.