Requisiti non funzionali come User Stories
Nel Product Backlog vengono raccolti i requisiti di un prodotto. Se si vogliono formulare dal punto di vista dell'utente, si utilizza spesso il formato della User Story. In modo chiaro e specifico vengono qui registrati i requisiti funzionali per il prodotto. Ma che dire dei requisiti non funzionali? Anche questi dovrebbero essere inclusi in un Product Backlog. Qui scoprirai perché i requisiti non funzionali sono importanti e come possono essere integrati al meglio nel Product Backlog, ad esempio attraverso il template delle User Stories.
Le differenze tra requisiti funzionali e non funzionali
Nel product management si distingue da tempo tra requisiti funzionali e non funzionali. Anche nella gestione agile dei requisiti, i due concetti vengono differenziati. Qui presentiamo brevemente le differenze.
Requisiti funzionali
Questi requisiti descrivono funzioni e specifiche concrete del prodotto. Come User Story, i requisiti importanti per l'utente vengono elencati nel modo più preciso e completo possibile. Si tratta di requisiti specifici del prodotto che generalmente non possono essere trasferiti a qualsiasi altro prodotto. Questi sono esempi tipici di requisiti funzionali:
Come utente di un programma di elaborazione testi, voglio poter inserire una tabella.
Il programma deve essere in grado di calcolare il contenuto calorico del menù sulla base di una formula.
Requisiti non funzionali
I requisiti non funzionali sono meno specifici. Descrivono ad esempio una qualità, una condizione o una proprietà del prodotto. Questi requisiti non sono necessariamente specifici del prodotto. Possono essere validi in generale per più prodotti o addirittura per l'intero design o l'architettura di un software:
Interfaccia user-friendly
Tempi di risposta rapidi
A causa del loro carattere poco specifico, c'è il pericolo che questi requisiti vengano trascurati nella creazione del Product Backlog. Tuttavia, dovrebbero esservi inclusi, poiché sono di grande interesse per l'utente. Se qualità, affidabilità o velocità non sono allineate alle esigenze dei clienti, il prodotto con alta probabilità non verrà utilizzato, perché la sola funzionalità non basta a soddisfare gli utenti. Per questo motivo si pone la questione di come i requisiti non funzionali possano essere integrati nello sviluppo del prodotto. Formularli come User Story è utile per dare priorità a questo tipo di requisiti.
Come descrivere i requisiti non funzionali in Scrum come User Stories
- I requisiti non funzionali dovrebbero essere descritti in modo misurabile
- Guardare i requisiti non funzionali dalla prospettiva del cliente
- Il requisito non funzionale è forse meglio collocato nella "Definition of Done"?
I requisiti non funzionali dovrebbero essere descritti in modo misurabile
L'affermazione che la tua pagina debba avere tempi di risposta il più rapidi possibile è troppo vaga per il team di sviluppo. Qui non vengono descritti requisiti misurabili. "Veloce" in questo caso è un'affermazione imprecisa che praticamente ogni sviluppatore definirebbe in modo diverso.
Per il team è utile in questo esempio ricevere indicazioni precise. Queste possono essere elaborate insieme. Un mezzo può essere una restrizione posta sul requisito. In questo modo le proprietà diventano più tangibili e possono essere implementate senza problemi. Qui il requisito potrebbe ad esempio essere:
La pagina dovrebbe caricarsi in meno di x secondi.
Il consumo calorico deve essere visualizzato entro 8 secondi dal clic.
Guardare i requisiti non funzionali dalla prospettiva del cliente
Nella creazione delle User Stories, i partecipanti dovrebbero mettersi nella prospettiva del cliente. Per la creazione della User Story può essere utile immaginare concretamente il prodotto con l'aiuto di un formato:
"Come <utente> voglio <obiettivo>, affinché <motivo>"
Questo semplice formato può aiutare te e il tuo team a chiedere il motivo del requisito. Perché può essere importante per un utente che il consumo calorico del menù venga visualizzato in meno di 8 secondi? Perché l'utente ha così rapidamente un valore di confronto con cui può preparare il menù nella propria pianificazione temporale. Tuttavia, dovresti mettere in discussione il risultato e considerare la formula solo come "strumento di pensiero". Se la risposta al "Perché?" risulta troppo complicata o confusa, allora dovresti cercare il dialogo diretto con il cliente o l'utente. Chiedi alle persone perché questa proprietà è importante per loro personalmente. A volte si scopre che un requisito non funzionale non è affatto così poco specifico, ma semplicemente formulato in modo impreciso.
Il requisito non funzionale è forse meglio collocato nella "Definition of Done"?
Si tratta di aspetti trasversali come ad esempio i tempi di risposta di un programma? Allora può avere senso includerli nella "Definition of Done". Insieme al tuo team e eventualmente agli stakeholder potete valutare se un tempo di risposta rapido non debba essere fondamentalmente un criterio per l'intero sistema.
L'integrazione di un requisito non funzionale nella Definition of Done ha come conseguenza che ogni item deve soddisfarlo. Questo è vantaggioso quando si tratta, ad esempio, di un design e della sua conformità con la Corporate Identity o simili.
Trasformare i requisiti non funzionali in requisiti funzionali
I requisiti non funzionali possono essere formulati come requisiti funzionali sotto forma di User Story. E dovrebbero esserlo, affinché non vengano trascurati o ignorati. È importante che siano formulati in modo misurabile e in qualche modo delimitati. Se non riesci a definire tu stesso una delimitazione, la formula presentata sopra ti aiuterà. Chiede il "Perché?" e può quindi essere un supporto al pensiero. Altrimenti ti aiuta il dialogo diretto con il tuo team, gli utenti o gli stakeholder.
Prime informazioni sul tema Scrum e User Stories le trovi sul nostro sito web. Vuoi acquisire conoscenze approfondite su Scrum? Allora iscriviti a una formazione Scrum e impara le basi del lavoro agile!
