Risposta

Il business analyst deve formalizzare i criteri di accettazione (acceptance criteria) per ogni requisito in modo che siano chiari e univoci per tutti i partecipanti al progetto: cliente, sviluppatori e tester. A tal fine, vengono utilizzate tecniche di specifica, come la formulazione dei criteri in notazioni Gherkin (Given-When-Then), checklist e casi d'uso (use cases). L'analista documenta i criteri negli artefatti dei requisiti e si assicura che per ogni requisito ci sia un insieme di condizioni oggettive tramite cui poter confermare inequivocabilmente il completamento del compito.

Caratteristiche chiave:

• Formulazione chiara e misurabile dei criteri usando termini commerciali e tecnici.
• Coinvolgimento del cliente nella convalida dei criteri prima dell'inizio dello sviluppo.
• Inclusione dei criteri nelle user stories, specifiche e test case.

Domande trabocchetto.

È possibile utilizzare solo le user stories per descrivere i requisiti, senza criteri di accettazione aggiuntivi?

No, le user stories senza chiari criteri di accettazione sono troppo astratte e possono essere interpretate in modi diversi. I criteri sono necessari per capire se il requisito è stato implementato correttamente.

È necessario includere requisiti non funzionali (ad esempio, prestazioni) nei criteri di accettazione?

Sì, anche i requisiti non funzionali dovrebbero essere formalizzati nei criteri, altrimenti c'è il rischio che vengano dimenticati o implementati solo parzialmente.

Chi dovrebbe approvare i criteri di accettazione: solo il business analyst?

No, è sempre necessario il consenso sui criteri con il cliente e, se possibile, con il team di sviluppo, per minimizzare i malintesi.

Errori comuni e anti-pattern

• Ignorare la convalida dei criteri con il cliente.
• Lasciare i criteri a discrezione del team di sviluppo.
• Aggiungere criteri con ritardo dopo l'inizio dei lavori.

Esempio reale

Casi negativi: Il business analyst non ha concordato i criteri di accettazione con il cliente, e gli sviluppatori hanno interpretato i requisiti a modo loro. Vantaggi: Sviluppo rapido, nessuna riunione ha ritardato il processo. Svantaggi: Dopo il rilascio, il 70% della funzionalità non corrispondeva alle reali aspettative, è sorto un conflitto.

Casi positivi: L'analista ha redatto criteri di accettazione formali, li ha concordati con entrambe le parti e li ha allegati alle user stories. Vantaggi: Comprensione tra il cliente e il team, minimo di bug dopo il rilascio. Svantaggi: All'inizio ci è voluto un po' più di tempo per i rinforzi.