Come documentare i requisiti non funzionali nelle User Story?

I requisiti non funzionali si presentano in molte forme, ma hanno una cosa in comune: non descrivono il comportamento funzionale del sistema, ma piuttosto vincolano le scelte progettuali che puoi fare.

I requisiti non funzionali non sono adatti per essere espressi come storie degli utenti perché le storie degli utenti funzionano meglio quando possono essere implementate una volta in un breve lasso di tempo (rispetto alla lunghezza dell'intero progetto) e quindi considerate Done. Dopo aver completato una storia, non è necessario rivedere regolarmente la storia. Per i requisiti non funzionali, ciò non funziona, poiché l'adesione ad essi deve essere mantenuta per l'intero progetto. Non puoi dire che considererai la compatibilità del browser solo una volta durante il progetto e ignorerai il resto del tempo.

Per i requisiti non funzionali che riguardano quasi tutte le storie utente (funzionali), il posto migliore per documentarle è come parte della Definizione di Fatto.
Per i requisiti non funzionali che influiscono su un sottogruppo relativamente piccolo della funzionalità, è possibile renderli parte dei criteri di accettazione delle storie utente pertinenti. Se questo sottoinsieme è ancora piuttosto grande per i tuoi gusti (o potrebbe crescere in futuro e hai paura di perdere alcuni requisiti non funzionali su una storia futura), puoi inserire i requisiti non funzionali in un documento di alcuni ordina e fai riferimento a ciò dai criteri di accettazione delle storie pertinenti.

Per quanto riguarda il formato dei requisiti stessi e un possibile documento per inserirli, usa quello che funziona meglio per te e il tuo team.

"Requisiti non funzionali" è un po 'vago e aperto all'interpretazione. Andando sul tuo esempio specifico, direi che quei requisiti dovrebbero essere usati come criteri di accettazione per altre storie.

Se sei preoccupato di ripetere la stessa storia di requisiti non funzionali dopo una trama dopo l'altra, un'altra soluzione sarebbe quella di raggruppare tutti questi requisiti in un documento (ad esempio: "standard applicativi") e "aderire all'applicazione" standard "parte della tua definizione di fatto.

Puoi incorporarli nel tuo DOD "Definizione di fatto".

Le non funzionali sono tuttavia problematiche in Agile, se cambiano non hai modo di rintracciare quali storie sono state fatte contro quali criteri.

Quindi proverei a elencarli come test per ogni storia. Anche se significava molto copia e incolla.

Nel suo libro "Scrum essenziale" , Kenneth S. Rubin dice (vedi pagina 93):

I frequently write nonfunctional requirements as user stories […], but I feel no obligation to do so, especially if it seems awkward or more convenient to write them in a different format [i.e. not following the "As a user …" pattern].

Detto questo, puoi semplicemente creare una User story in JIRA per documentare un requisito non funzionale.

Tuttavia, Kenneth consiglia anche - come già sottolineato da Ewan e Bart van Ingen Schenau - "[...] le squadre cercano di includere il maggior numero possibile di requisiti non funzionali nelle loro definizioni di fatto". Ciò è dovuto al fatto che i requisiti non funzionali spesso influenzano molte altre storie di utenti (funzionali) e se non vengono affrontate, la storia non viene eseguita. Pertanto, la definizione di fatto abbastanza spesso è il posto migliore.