• 1. Elicitazione (Scoperta): Scoprire e raccogliere i requisiti parlando con gli stakeholder. La sfida principale è che gli esperti di dominio fanno fatica ad articolare conoscenze per loro "ovvie".
• 2. Specifica: Trasformare le idee in documenti. A causa dell'ambiguità del linguaggio naturale, si usano specifiche strutturate (es. tabelle condizionali) o si fa riferimento a Standard industriali (es. IEEE 830, template VOLERE).
• 3. Convalida (Validation): Assicurarsi che i requisiti siano coerenti, realistici e verificabili prima di scrivere codice. Si usano revisioni, prototipazione e Generazione di test-case.
• 4. Gestione (Management): Tracciare e valutare i costi e gli impatti dei cambiamenti ai requisiti.

Non si ascoltano solo gli utenti finali. Uno Stakeholder è chiunque abbia un interesse legittimo nel sistema.

• Visibili: Chi usa il sistema quotidianamente (es. in un sistema medico: pazienti, medici, infermieri).
• Strutturali: Chi è coinvolto indirettamente ma detta le regole (es. IT staff per le compatibilità, manager dell'etica medica, responsabili normativi/legali).

• Requisiti Funzionali: Descrivono i servizi offerti dal sistema, le reazioni agli input e cosa il sistema non deve fare.
• Requisiti Non Funzionali: Vincoli sul sistema globale. Si classificano in:
  • Prodotto: Velocità, Usabilità (FURPS+).
  • Organizzativi: Policy aziendali (es. usare Git, Docker).
  • Esterni: Rispetto delle leggi (es. GDPR, privacy medica HStan-03), Interoperabilità.

• Given (Dato): Definisce le precondizioni o lo stato iniziale del sistema prima dell'azione dell'utente.
  Es: "Dato che l'utente ha degli articoli nel carrello..."
• When (Quando): Descrive l'azione principale che l'utente compie o l'evento che si verifica.
  Es: "Quando l'utente clicca sul pulsante 'Procedi al pagamento'..."
• Then (Allora): Descrive il risultato atteso o le postcondizioni verificabili.
  Es: "Allora viene mostrata la pagina di checkout sicura."
• And / But (E / Ma): Permettono di concatenare più clausole per mantenere la leggibilità.

Superare i criteri di accettazione Gherkin non è sufficiente per dichiarare una User Story finita. Deve anche rispettare la Definition of Done del team di sviluppo.

• In ambienti maturi e critici si applica una Stringent DoD, che obbliga il codice a rispettare vincoli ingegneristici ferrei, come: Code Coverage dei test unitari superiore all'85%, Zero errori nei controlli degli standard di codifica (Linting), nessuna introduzione di Debito Tecnico non giustificato e superamento di test di penetrazione automatici.

• Attori: Entità esterne (persone, timer, o altri sistemi IT) che interagiscono col sistema.
• Trigger: L'evento scatenante che avvia l'interazione.
• Pre-condizioni: Lo stato certificato in cui deve trovarsi il sistema prima che il caso possa iniziare.
• Normal Flow (Flusso Base / Happy Path): La sequenza ottimale di interazioni in cui tutto procede senza intoppi e l'obiettivo viene raggiunto.
• Flussi Alternativi ed Eccezioni: Percorsi varianti e gestione degli errori (es. "Cosa succede se la carta di credito viene rifiutata?").
• Post-condizioni: Garanzie sullo stato del database e del sistema alla conclusione del caso.

• Simulatore di Stakeholder: I modelli LLM possono assumere il ruolo ("persona") di specifici utenti finali per evidenziare bisogni o edge cases che gli umani non avevano considerato.
• Analisi Semantica: I TuringBots analizzano decine di requisiti testuali per individuare "Bad smells" (come la Trappola dell'Or), ambiguità o conflitti di logica.
• Generazione Automatica Gherkin: A partire dalla trascrizione di un meeting, l'AI è in grado di estrarre autonomamente le User Stories e abbozzarne i Criteri di Accettazione in sintassi Given-When-Then pronta per l'automazione dei test.