Trovo utile in queste situazioni fare un passo indietro dai "requisiti funzionali" per un secondo e provare a vederlo come il processo aziendale di livello superiore che si sta verificando. Per me, mi sembra che tu abbia solo 3 storie:

Storie primarie

1. Come iniziatore di processo, devo essere in grado di inviare una richiesta interna al Super User per l'approvazione.
2. In qualità di Super User, devo essere in grado di approvare le richieste al fine di garantire che solo le richieste qualificate vengano inviate al sistema esterno.
3. In qualità di Super User, devo essere in grado di accettare o rifiutare i risultati dell'elaborazione del sistema esterno.

Il fatto che i dati vengano trasferiti in qualche modo tra i sistemi è un problema di implementazione e, a mio avviso, non dovrebbe far parte dei criteri di accettazione. Se il Super User può approvare la richiesta e un piccione vola su alcune persone in Elbonia per un'ulteriore elaborazione, questo è altrettanto valido finché i dati arrivano al sistema esterno e un risultato ritorna in qualche modo per accettare / rifiutare .

Tuttavia, la mia analogia con il piccione potrebbe aver innescato un "ma ciò richiederebbe troppo tempo", il che indica che probabilmente hai un criterio di accettazione sulla storia riguardante i tempi di transazione accettabili per inviare e ricevere richieste.

Da una prospettiva di implementazione, questo ti consente di pubblicare storie contro un'API stoppata e completare storie, mantenendole indipendenti l'una dall'altra.

Storie di sistema esterne

Se stavi sviluppando anche il sistema esterno, ti suggerirei una storia aggiuntiva per il team di sviluppo esterno:

1. In qualità di Super User, ho bisogno che le richieste approvate siano elaborate e che un valore sia restituito per accettazione.

Avrai quindi i criteri di accettazione su come elaborare e restituire valori in quella storia per il team che sviluppa il sistema esterno.

Altri criteri di accettazione nascosti

Le storie sopra sembrano avere un'immagine incompleta. Se i dati non vengono mai elaborati e archiviati, non sarà possibile tornare indietro e visualizzarli in un secondo momento. È importante? Se hai creato uno stub API e non hai eseguito il sistema esterno, perché sarebbe male?

(Sarebbe male, ma la domanda dovrebbe far scattare un pensiero su altre storie di cui probabilmente hai bisogno)

Si potrebbe anche sostenere che il caso sopra descritto è una storia per singolo utente se il valore aziendale per il superutente non viene derivato fino al completamento del passaggio 4 nel processo.

Considera una storia utente di livello superiore come:

COME SUPER user VOGLIO eseguire il processo aziendale XYZ COSÌ CHE POSSO accettare / rifiutare i risultati.

1,2,4 diventano criteri di accettazione per convalidare che l'utente super può eseguire questi passaggi nel sistema ... convalidare i super utenti riceve la richiesta, convalidare super utente può approvare / negare la richiesta, convalidare il super utente può , rifiuta / approva il risultato.

3 potrebbe anche essere considerato un criterio di accettazione ... qualcosa del tipo: "Convalida il sistema interno consuma l'output dal sistema esterno"

Se la storia utente di alto livello non è sufficientemente dettagliata per rientrare in un'iterazione, la risposta di Jay S fornisce una grande scomposizione.

Poiché il processo di terze parti non fa parte del sistema che stai sviluppando, ma il tuo sistema deve interagire con esso, il processo di terze parti è un attore per il tuo sistema.
In generale, un attore può essere considerato come una generalizzazione di un utente. Gli attori possono essere utenti umani, ma anche sistemi informatici esterni con cui il sistema comunica.

Potresti scrivere la user story per il passaggio 3 con il sistema esterno come utente:

3. Come < sistema esterno & gt ;, voglio ricevere una notifica in < in questo modo > quando una richiesta viene approvata, così posso eseguire < processo esterno & gt ;. Indicherò il completamento del < processo esterno > in < in questo modo >.