Come dovrei tradurre un documento dei requisiti in user story?

Non esiste una scorciatoia. Quello che hai è bello se la verifica formale dei requisiti di sistema è un requisito del progetto. Se la verifica formale dei requisiti di sistema non è un requisito, di solito è possibile saltare i requisiti formali. In ogni caso, creare casi d'uso / storie degli utenti è sempre utile, quindi dovresti crearli, anche se sono solo una versione ridotta di ciò che faresti normalmente.

Oltre a ciò, sta semplicemente elaborando ciascun requisito in un ciclo. Leggi ogni requisito identifica una storia utente che copra il requisito e mappa il requisito per la trama dell'utente. Se la User story non esiste già, crea una User story per il requisito.

All'inizio può sembrare molto, ma in realtà non dovrebbe richiedere molto tempo per avere un primo taglio. La maggior parte delle volte, i requisiti formali finiscono per essere raggruppati in storie correlate, quindi non sarà sorprendente mettere in discussione oltre 10 requisiti in un momento in cui viene creata una storia utente. Ciò che richiederà più tempo è ottenere risposta alle tue domande sui requisiti che non capisci. Avresti dovuto ottenere queste risposte alla fine, è solo che li hai identificati ora invece che dopo.

È probabile che soddisfi alcuni requisiti che non si integrano perfettamente in una sola user story. In questi casi dovresti ottenere requisiti più specifici che si adattino in modo più pulito alle singole storie. Mappare i requisiti derivati alle storie degli utenti e mantenere la capacità di tracciabilità dei requisiti originali. Ecco perché ci sono requisiti di livello di sistema e requisiti software. (A seconda del progetto potrebbe esserci anche un livello intermedio di requisiti).

Ora che hai "requisiti formali" e storie di utenti con quei requisiti associati a loro, allora diventa un gioco da ragazzi scrivere procedure di test per verificare formalmente i tuoi requisiti sulla base delle storie degli utenti.

Per riassumere, mi dispiace non ci sono scorciatoie. Se il tuo programma deve verificare formalmente i requisiti, avere i requisiti formali già scritti ti semplifica la vita. È molto, molto, molto più difficile e più dispendioso in termini di tempo scrivere un documento formale dei requisiti piuttosto che un mucchio di storie di utenti, anche con la mappatura dei requisiti formali per le storie degli utenti.

But my team is working using agile methods (a combination of scrum and kanban), so what we need is user stories.

Questo è un equivoco. Né Scrum né Kanban richiedono che i requisiti siano specificati nelle storie degli utenti. Entrambi sono silenziosi sul problema.

La Guida Scrum fa riferimento a "Prodotto Backlog Item". Questi articoli hanno solo pochi attributi: descrizione, ordine, stima, valore. Non c'è nulla sul formato o lo stile richiesto da Scrum, anche se spesso si trova il formato User Story utilizzato. Kanban ha ancora meno requisiti sugli articoli di questo.

Invece di provare a convertire le specifiche dei requisiti in User Story, assicurati che i tuoi requisiti soddisfino le caratteristiche di un buon requisito - coesi, completi, coerenti, atomici, tracciabili, attuali, non ambigui, hanno un'importanza specificata e sono verificabili. Quindi, identifica eventuali dipendenze tecniche tra i requisiti e assicurati che abbiano la priorità in modo appropriato.

Se stai abbracciando Agile, riconoscerai che le specifiche dei tuoi requisiti non sono "finite" - questi requisiti potrebbero cambiare. Invece, si concentra sui principi dello sviluppo agile del software. Iterate rapidamente - implementa sezioni della funzionalità specificata nella specifica dei requisiti e mettila di fronte a persone in grado di valutare il software e fornire feedback da incorporare in futuro iterazioni. Fate in modo che il vostro team di sviluppo lavori a stretto contatto con esperti in materia, responsabili di prodotto e rappresentanti degli stakeholder per comprendere gli utenti e le loro esigenze. Concentrati innanzitutto sui requisiti di priorità più elevata: potresti non aver effettivamente bisogno di implementare tutto per essere accettabile dagli utenti e puoi massimizzare il lavoro che non viene svolto. Rifletti e migliora il funzionamento della squadra.

Mi scuso per essere un po '"scrum pedantic" ma sono l'unico sorpreso dal fatto che nessun Product Owner sia menzionato?

È il significato della risposta di @ Thomas_Owens: puoi trasformare la documentazione dei requisiti in ciò che si adatta al processo del tuo team ma se nessun PO è qui per aiutarti (leggi: informarti), ha poco valore se non puoi dare la priorità e perfezionare gli articoli :).

Immagino che tu abbia solo poca scelta su questa situazione ma, personalmente, quello che farei prima con questo documento è trovare la persona che può spiegarmi ogni cosa e nominarla come PO. Forse colui che l'ha scritto?