Possiamo procedere alla validazione dei requisiti e per farlo utilizzeremo le carte scenario come supporto di partenza mi sposto sulla fim dove ho già posizionato qualche materiale utile ovviamente sul lavoro che abbiamo già fatto insieme e che continueremo ad utilizzare e ad approfondire.

Anche grazie a queste carte lo scenario di partenza è appunto eh, dove abbiamo il contesto e tutta la la parte dei dettagli e i requisiti, quindi che abbiamo mappato tramite uno user story mapping e grazie anche all'aiuto delle carte requisito e adesso è il momento di valida e accendo appunto questo blocco dove ci sono dentro le carte scenario e come ti dicevo le carte scenario sono simili a quelle requisito e chiaramente sono solo un supporto per permettere il dialogo e quindi anche quel dialogo dove eh si usa la tecnica, ad esempio dei sei cappelli per cercare di approfondire con dei punti di vista differenti temi del progetto che magari sono stati già trattati e per andarli a in qualche modo a stressare, ad approfondire, a spulciare per tirare fuori magari qualche altro elemento importante.

E chiaramente gli scenari sono anche un po' divertenti se vogliamo e e servono appunto a a cercare di attivare questo dialogo extra rispetto al progetto.

Facciamo un esempio ne prendo due o tre veramente in modo randomico e me li copio, diciamo in questa parte in cui li leggeremo e cercheremo di capire, in effetti che cosa possono avere come impatto all'interno del nostro, della nostra mappatura dei requisiti che abbiamo fatto in precedenza e ad esempio, pagamenti non pervenuti.

Um l'ordinario è questo la cortese mail è per ricordare di pagare le ultime quarantadue fatture.

In alternativa ci vediamo costretti a staccare il servizio, ovvero ci sono delle procedure per gestire casi di mancato pagamento.

Cosa succede se i pagamenti sono mancanti per un periodo prolungato? Ecco già qui c'è un punto noi abbiamo appunto un sistema di pagamento e perché permette di pagare l'ordine.

Una cosa che potremmo pensare è che qualora il dato che la persona sta ordinando all'interno del del punto vendita di ti ammonta dis e potremo pensare che può pagare in una versione ovviamente principale di default tramite un pagamento digitale, ma potremmo pensare di trovare una soluzione per poter pagare anche in cassa e quindi permettere di ordinare il prodotto tramite l'app e poi pagare in cassa quando ha terminato e questa è una cosa ad esempio a cui non avevo pensato e che in questo momento mi è venuta in mente e quindi potremmo pensare di eccolo qui, inserire un metodo di pagamento.

Aggiungo una storia come utente vor voglio poter pagare anche in contanti o con la carta presso la cassa del punto vendita per non usare una versione digitale di pagamento.

Okay? E già questa, diciamo, è un'informazione in più che è venuta fuori da uno scenario um queste sotto le saltiamo e sono un utente davvero pro hai presente quell'amico smanettone che quando esci la sera prenota con lo smartphone, paga con l'orologio e parla con un robot? Ecco, e in realtà qua il concetto è legato a quelle che sono quelle funzionalità e anche un po' nascoste molte volte, che però sono apprezzatissime da utenti un po' più digitali, un po' più appunto pro e e quindi hai previsto delle ad esempio.

Quindi una cosa che potremmo pensare è che, um l'app potrebbe avere delle gesture, un po' come queste app un po' più moderne, ad esempio Tinder o Snapchat, che permettono di um al in alternativa a un tasto classico, di andare a mettere ad esempio nel carrello una o più prodotti tra l'altro, anche semplificando quella che è l'esperienza e quindi magari anche incentivando per chi ne fa uso, anche un un acquisto, anche un po' più di impulso.

Quindi quello che potremmo pensare, ad esempio nel dettaglio di un prodotto è come utente.

Come utente voglio poter aggiungere al carrello i prodotti in modo più veloce grazie a delle okay bene.

Ad esempio ci sono degli eg presenti da qualche parte.

Questa è una cosa carina che di norma si fa all'interno di un'app, ovvero di aggiungere dei piccoli g, ad esempio premendo più volte un tasto oppure qualcosa che succede scrollando fino alla fine.

Insomma, e queste sono delle cose di delle piacevolezze che si possono aggiungere e chiaramente non aiutano il business, ma possono essere un elemento, ad esempio di branding.

Um un'altra cosa che potremmo pensare è di utilizzare questo scenario, ovvero il device inaspettato.

E quindi tu hai costruito tutto perché funzioni su desktop mobile.

In questo caso di un'app però aprono il tuo prodotto digitale da un televisore, un tablet del duemilauno e lo schermo del frigo smart e quindi il sistema che stai progettando sa è o sarà davvero responsabile.

Ecco, una cosa che succede molto spesso è che alcune persone utilizzano un'app mobile da quella sorta di diciamo di device che è una metà tra un un telefono, un tablet e che in qualche modo straccia in modo veramente eccessivo.

L'interfaccia.

Quindi una cosa, per esempio, che si potrebbe inserire tra i requisiti e potremmo aggiungerlo anche in fondo, come i requisiti non funzionali.

Lo posso prendere qui adesso lo poggio e in qualche modo poi lo metterò in ordine più avanti.

È, ad esempio, che un requisito non funzionale, non funzionale, ovvero che non si tratta di un requisito legato a un utente specifico, ma è un qualcosa comunque da tenere in considerazione, è quello di verificare che L'app possa funzionare anche su device più grandi, come un tablet o un uno smartphone con uno schermo particolarmente grande.

Quindi è veramente okay, Okay.

Quindi questo potrebbe essere un requisito non funzionale che io metto qua per una questione di ordine.

Ci metto un titolo, potremmo scrivere requisiti non funzionali.

Questa è una cosa che si fa molto spesso.

All'interno di una mappatura dei requisiti un'altra.

Cosa potrebbe essere? Quale sistema operativo è stato previsto come minimo supportato.

Questa è una cosa molto importante che spesso ci si dimentica.

Anche questo è un requisito non funzionale e potremmo dire che, um l'app deve essere deve essere scaricabile.

Okay, e per chi ha Google come versione X e Apple iOS e iOS versione Y.

Questo ovviamente, per fare un esempio.

E ultima cosa, um nel caso, ovviamente se ci sono condizioni particolari in cui in effetti um diciamo quest'app non pos- possa non funzionare.

Quindi che cosa abbiamo fatto per prevedere di evitare che le persone possano utilizzare l'app in modo particolare? Ad esempio una cosa che per esperienza mi è capitata è che si fa un'app, ad esempio per il tablet, ma le persone poi um e quindi l'app è stata immaginata, studiata, anche progettata per il tocco, quindi per il tap.

Però poi viene un qualcuno che aggancia una tastiera e un mouse e quindi ci sono alcune dinamiche che vengono meno.

Pertanto ci sono delle situazioni che devono essere in qualche modo approfondite per andare ad evitare che si possa fare un uso improprio, ad esempio con un device troppo particolare o, ad esempio delle periferie che non sono supportate e quindi Grazie anche a questo scenario è possibile fare questa mappatura dei requisiti approfondita, andare a condire e quindi a migliorare quella che è la nostra user story mapping, per poi arrivare a un punto in cui siamo tutti contenti e un po' più diciamo sereni che in effetti abbiamo un dito e chiaramente non al cento per cento, perché questa cosa è molto difficile da raggiungere.

Però sicuramente ci siamo avvicinati a a questa soglia e ed è qui che in qualche modo il dialogo poi può continuare utilizzando le altre carte scenario e quindi in generale poi andando a mappare quelli che sono i casi d'uso e che sicuramente saranno specifici per il tuo progetto.