### Autori - Fabio Marchesi, matricola: 844941. - Simone Mallei, matricola: 844659. Questa documentazione si riferisce al seguente [repository](https://gitlab.com/simonemallei/2021_assignment2_trenord_app_update). # Trenord App Update Dato che si vuole aggiornare l'applicazione di Trenord, prima della strategia di elicitazione viene mostrata un'introduzione alle aziende che hanno contribuito alla creazione della prima versione di questa piattaforma, per poter comprendere le funzionalità offerte inizialmente dall'applicazione che si ha intenzione di aggiornare. ## Introduzione >Fondata il 3 maggio 2011 dai due attuali azionisti, FNM e Trenitalia, Trenord figura tra le più importanti realtà del trasporto pubblico locale ferroviario a livello europeo, sia per dimensioni sia per capillarità del servizio. 214 milioni sono i passeggeri che nel 2019 hanno viaggiato con Trenord utilizzando le 2.300 corse quotidiane che servono capillarmente tutta la Lombardia, 7 province di regioni confinanti, il Canton Ticino e l’Aeroporto Internazionale di Malpensa. I nostri treni raggiungono 460 stazioni dislocate su una rete ferroviaria di circa 2.000 chilometri. La capillarità del servizio Trenord interessa il 77% dei comuni lombardi (dove vive il 92% dei cittadini) che dispongono di una stazione ferroviaria entro un raggio di 5 km. (Fonte: [Trenord](https://www.trenord.it/chi-siamo/)) Trenord è quindi l'azienda che si occupa del trasporto locale in tutta la Lombardia ed in zone limitrofe. Per permettere una digitalizzazione del servizio e un aiuto ai loro clienti, nel 2015 è stata sviluppata un'applicazione che ha intravisto 3 aziende esterne come protagoniste: - [Mia-Platform](https://mia-platform.eu/case-history/trenord-the-digital-platform-for-mobility-in-lombardia/): si è occupata della gestione dei dati in tempo reale degli utenti e dei treni, creando un'unica piattaforma che permettesse di offrire vantaggi ai viaggiatori che usufruiscono del servizio di Trenord trovando tutto quello che necessitano sui ritardi dei mezzi ed altre informazioni utili al servizio. - [Nord-Com](https://www.nord-com.it/progetti/e-store-per-trenord/): ha implementato il sistema di E-Store dell'applicazione, rendendo disponibile la possibilità di acquistare online biglietti del treno in base alla tratta selezionata, abbonamenti per clienti abituali e anche titoli di viaggio relativi a tratte interne alla città di Milano per semplificare i viaggiatori più occasionali nella gestione dei propri biglietti facenti riferimento ad altri mezzi pubblici. - [Intrè](https://www.intre.it/case-study/app-ufficiale-trenord/): quest'ultima si è occupata dell'implementazione dell'applicazione dal punto di vista dell'interfaccia utente sotto tutti i punti di vista, unendo il lavoro svolto dalle due aziende soprastanti e sviluppando infine il frontend, cercando di mantenere fluidità per tutti i dispositivi e dando un'esperienza di utilizzo piacevole agli utenti. Uno dei motivi che ha portato alla nostra attenzione l'applicazione e lo sviluppo di un aggiornamento è la possibilità di dare più attenzione ai viaggiatori pendolari, che coincidono con i clienti più abituali e fidati che usufruiscono dei treni: è infatti fondamentale cercare di dare un'esperienza sempre più completa e "smart" a questa parte della clientela che costituisce il cuore del servizio concesso da Trenord. Infatti le funzionalità principali presenti all'interno dell'app sono le seguenti: - Richiedere le tratte possibili data una stazione di partenza, una di arrivo ed un orario di partenza di riferimento (con posizione del treno aggiornata in tempo reale): questa possibilità è fondamentale per il viaggiatore (sia abituale, sia occasionale), che può in questo modo osservare in tempo reale come raggiungere una certa stazione e sapere il tempo di arrivo stimato. - Osservare partenze ed arrivi su una singola stazione di riferimento: funzione che si rivela utile nel momento in cui si vuole prendere il primo treno che passa per una certa stazione e si è a conoscenza di quali mezzi portano alla fermata in cui si vuole scendere, in modo tale da intraprendere una decisione su quale treno salire in base a relativi tempi di arrivo e ritardi che hanno collezionato - Acquistare biglietti o abbonamenti di Trenord e/o ATM: questa caratteristica rende l'applicazione più evoluta dal punto di vista digitale, implementando un vero e proprio e-store che rende intuitivo e comodo l'acquisto di singoli biglietti ATM e per treni di Trenord (utile per viaggiatori occasionali) e addirittura abbonamenti (quindi per viaggiatori abituali) con scelta della stazione di attivazione di quest'ultimi. Mentre quelle che abbiamo intenzione di aggiungere per rendere più ricca l'esperienza sono: - Impostazione del proprio itinerario settimanale e/o giornaliero: è l'aggiunta principale dell'aggiornamento di quest'app. Pensata principalmente per i viaggiatori abituali che usufruiscono del servizio di Trenord più volte settimanalmente (se non addirittura giornalmente), la possibilità di scegliere un itinerario darà dei benefici sia al viaggiatore per poter avere notifiche relative a ritardi e/o cancellazioni dei treni presi ad un certo orario, sia a Trenord, di poter fare stime maggiori sull'utilizzo specifico di alcune tratte da chi possiede abbonamenti (per poter anche potenziare il servizio sulle tratte più affollate). - Consultare, come per le stazioni dei treni, le fermate della metro e orari con percorso attuale di ogni corsa: insieme all'itinerario, questa funzionalità permetterebbe un uso più completo dell'applicazione in modo tale da poter usufruire non solo dei treni, ma anche di mezzi che possono tornare utili in città come le metro (soprattutto se si è in possesso di abbonamenti che comprendono già entrambe le tipologie di trasporto). - Alternative per effettuare la stessa tratta del proprio itinerario a seguito di un ritardo o di una cancellazione: una sottofunzionalità relativa a quella degli itinerari. Aggiungere questa possibilità, con una certa soglia di ritardo accettabile in base all'utente che richiede la possibilità di ricevere eventuali alternative, dona all'utente una risposta istantanea al problema di un ritardo o di una cancellazione di una tratta, che permette al cliente di non dover cercare di fretta il primo treno che va verso una stazione (potenzialmente una coincidenza) dall'app o nel tabellone una volta arrivati in stazione. - Acquistare biglietti o abbonamenti relativi agli altri capoluoghi di provincia della regione: caratteristica che potrebbe arricchire l'e-store presente nell'app, anche se sarà necessario consultare diversi stakeholder per considerare la fattibilità di una collaborazione simile a quella ottenuta con ATM per ogni città di riferimento. ## Strategia di elicitazione ### Elenco Stakeholder Gli stakeholder (dall'inglese, "portatori di interesse"), sono le figure che hanno interesse al progetto al quale si fa riferimento. Possono rappresentare una categoria di persone, oppure un'azienda stessa. Bisogna distringuere questi individui sia dal punto di vista del potere (decisionale, che può essere rappresentato anche da quello economico/finanziario), sia dal punto di vista dell'interesse in base all'utilizzo dell'applicazione (nel caso dei viaggiatori abituali) o in base ai guadagni che si otterrebbero (ad esempio nel caso di Trenord). Quindi per poter selezionare attentamente le figure che possono avere degli interessi nel progetto, è necessario considerare diversi aspetti che possono venir fuori durante l'elicitazione dei requisiti e comprendere quali categorie è necessario interrogare o mantenere soddisfatti in base alla loro importanza. L'elenco degli stakeholder ottenuto è il seguente: - [Trenord](https://www.trenord.it/) - Stakeholder chiave (alto interesse/alto potere): è la figura che ha maggior potere e tra quelle con più interesse nel progetto. Infatti è Trenord a finanziare l'aggiornamento dell'applicazione e l'app stessa è progettata per essere un aiuto nell'utilizzo dei servizi di Trenord, quindi l'azienda è interessata sia ad un buon investimento dal punto di vista finanziario, sia ad un eventuale miglioramento dell'immagine della compagnia attraverso la propria applicazione. - Pendolari / Viaggiatori abituali - Stakeholder operativo (alto interesse/basso potere): costituito dagli utenti principali che utilizzano più spesso l'applicazione con una frequenza settimanale (se non addirittura giornaliera), è fondamentale riuscire ad aggiungere delle funzionalità che possano rendere più comodo l'utilizzo dell'app per questa categoria di persone e che vengano forniti servizi aggiuntivi che facilitino la scelta dei mezzi in situazioni particolari (come ritardo o cancellazione di un treno). - Manutenzione Servizio dell'App - Stakeholder operativo (alto interesse/basso potere): sono coloro che si occupano attualmente della manutenzione dei servizi dell'app. Hanno un alto interesse in quanto conoscono bene l'applicazione nel complesso ed è importante mantenerli informati su tutte le scelte intraprese in quanto si occuperanno della manutenzione anche a seguito dell'aggiornamento. Vengono ritenuti fondamentali per il progetto in quanto conoscono bene il dominio dal punto di vista operativo e hanno mantenuto per diverso tempo una conoscenza approfondita di come funziona la piattaforma nel complesso. - [ATM](https://www.atm.it/) - Stakeholder istituzionale (basso interesse/alto potere): per l'aggiornamento che si vuole effettuare il ruolo di ATM viene considerato importante, infatti è necessario il supporto dell'azienda per poter includere le tratte della metropolitana all'interno dell'applicazione ed è quindi rilevante mantenerli soddisfatti nelle attività che prevedono la loro presenza, in modo tale da riuscire ad ottenere il meglio attraverso questa collaborazione. - Servizi di autotrasporti provinciali lombardi - Stakeholder istituzionale (basso interesse/alto potere): le compagnie di riferimento sono ritenute importanti in quanto, senza il loro appoggio, non sarà possibile effettuare l'ampliamento dell'e-store dell'applicazione. Si ritiene necessario quindi dare loro importanza soprattutto nelle attività che riguardano il negozio elettronico dell'app di Trenord, consultando le loro opinioni riguardanti biglietti ed abbonamenti locali da integrare nello store. - Sviluppatori dell'aggiornamento - Stakeholder chiave (alto interesse/alto potere): sono coloro che si occupano dello sviluppo dell'aggiornamento e hanno un ruolo fondamentale nella raccolta dei requisiti per poter trovare un compromesso fra le necessità di ogni stakeholder preso in considerazione. - Sviluppatori della prima applicazione: - [Intrè](https://www.intre.it/case-study/app-ufficiale-trenord/) - Stakeholder marginale (basso interesse/basso potere): è la compagnia che si è occupata dell'interfaccia utente dell'applicazione, può tornare utile mantenere un contatto nel caso in cui si possano avere dubbi su alcune scelte relative all'esperienza utente nell'utilizzo dell'app. - [Nord-Com](https://www.nord-com.it/progetti/e-store-per-trenord/) - Stakeholder marginale (basso interesse/basso potere): essendo l'azienda che si è occupata dello sviluppo dell'e-store dell'applicazione, si ritiene importante consultarla per l'ampliamento del negozio elettronico in riferimento agli altri capoluoghi di provincia che si trovano in Lombardia. Infatti durante il primo sviluppo, avranno considerato diverse possibilità che, per un motivo o per un altro, potrebbero risultare più critiche rispetto a quella scelta. - [Mia-Platform](https://mia-platform.eu/case-history/trenord-the-digital-platform-for-mobility-in-lombardia/) - Stakeholder marginale (basso interesse/basso potere): è la compagnia che si è occupata della gestione dei dati degli utenti e dei treni. Viene contattata per poter trattare le corse della metropolitana allo stesso modo di quelle ferroviarie e unire questi dati in un'unica piattaforma condivisa, in modo tale da considerare entrambe le tipologie di trasporto (treni e metro) contemporaneamente data una posizione di partenza ed una di arrivo. - Turista / Viaggiatore occasionale - Stakeholder marginale (basso interesse/basso potere): costituito da utenti che utilizzano l'applicazione per un periodo limitato e in circostanze ben definite, si ritiene necessario comunque permettere anche a questa categoria di persone un'esperienza che sia intuitiva e che aiuti soprattutto nella scelta dei mezzi da prendere per raggiungere una certa destinazione interna alla città di Milano. ### Piano delle Attività Per effettuare l'elicitazione dei requisiti funzionali e non funzionali relatiivi al progetto proposto è stata stilata una lista di attività. Tali attività coinvolgono i principali stakeholders in modo di ottenere una lista completa di requisiti con un numero di conflitti molto limitato. Le attività verranno eseguite nel seguente ordine cronologico: - Group Session di presentazione. - Questionario "Itinerari e Notifiche". - Scenario a seguito di un ritardo/cancellazione di un treno. - Background Study e Data Collection applicato agli itinerari. - Intervista su ampliamento biglietti del Trenord E-store. - Scenario di un turista nella città di Milano. - Group Session finale. ### Group Session di presentazione La prima attività consiste una riunione di gruppo nella quale sono presenti rappresentanti della maggior parte delle figure interessate in modo di discutere la proposta di aggiornamento dell'app di trenord. Tale riunione è il primo passaggio per capire la fattibilità delle modifiche proposte e per il raccoglimento dei requisiti necessari: la presenza di più stakeholders permette di individuare i requisiti dei vari aspetti evidenziando anche possibili fonti di conflitto tra essi. La sessione di gruppo sarà strutturata, ossia un partecipante avrà un ruolo specifico (portavoce della parte rappresentata) e contribuirà alla fase di analisi dei requisiti in base al proprio ruolo. La scelta è ricaduta sullo svolgimento strutturato in quanto sono già chiari i concetti fondamentali che si vogliono intruddure e non è quindi necessaria una fase di brainstorming iniziale. Essendo questa attività quella premiliminare verranno discussi principalmente requisiti funzionali. Alla riunione saranno presenti: - Sviluppatori dell'aggiornamento: in qualità di coordinatori della riunione, sono essi a conoscere quali sono gli obiettivi principali di tale aggiornamento e potranno utilizzare tale riunione per esplicare alle parti interessate le ragioni di tale aggiornamento. - Rappresentate Trenord: rappresentano lo stakeholder con un maggiore livello di potere e dal quale dipende l'esecuzione del progetto. Essendo la figura principale sarà fondamentale per discutere la maggior parte dei requisiti funzionali (per esempio l'utilità dei servizi proposti), ma anche per discutere i requisiti non funzionali relativi ai costi ed ai tempi d'esecuzione del progetto. - Rappresentante del servizio di manutenzione dell'app: rappresenta lo stakeholder che attualmente è maggiormente coinvolto per quanto riguarda l'applicazione ed è in grado di stabilire con maggior precisione sia i requisiti funzionali ma soprattutto quelli non funzionali basandosi principalmente sul system-as-is. Ha infatti informazioni precise sugli standard relativi alle performance ed alla sicurezza nel sistema attuale. - Rappresentante ATM: volendo integrare una parte di funzionalità che richiedono l'utilizzo dei servizi ATM per l'ampliamento delle informazioni e dei servizi offerti dall'applicazione è necessario un confronto per discutere la fattibilità ed anche eventuali conflitti di genere economico o burocratico. - Rappresentanti servizi trasporto pubblico provinciale: stakeholder di alto potere, soprattutto per quanto riguarda la proposta di ampliamento dello store. Il loro giudizio sarà fondamentale per individuare conflitti sotto questo aspetto. In questa prima group session non saranno invece presenti rappresentati per le seguenti parti: - Viaggiatore / Pendolare: è lo stakeholder di maggior interesse ma anche quello con meno potere decisionale, per questo motivo non ha voce in capitolo per quanto riguarda le principali decisioni progettuali. Inoltre l'opinione del viaggiatore sarà fortemente consultata tramite un questionario durante lo step successivo del workflow. - Sviluppatori dell'app attuale: il loro lavoro è stato esaustivamente analizzato durante la fase di background study e non hanno una forte rilevanza per quanto riguarda le decisioni attuali, per le questioni di tipo tecnico (requisiti non funzionali) come performance e sicurezza ci si può sicuramente consultare con i responsabili per la manutenzione presenti alla riunione. ### Questionario "Itinerari e Notifiche" Il questionario ha come obiettivo principale quello di raccogliere un ampio insieme di informazioni ottenute direttamente da un sottoinsieme degli stakeholders. Tramite questionari è possibile ottenere indicazioni in modo molto economico e rapido. In questo caso il target del questionario sono i viaggiatori che essendo coloro che gioverebbero maggiormente dalle modifiche proposte possono indirizzare gli sviluppi software nella direzione più efficace possibile. La diffusione del questionario è molto semplice e economica, infatti sarà possibile sfruttare la posizione nevralgica delle stazioni ferroviarie, soprattutto quelle situate in città di dimensioni medio alte per poter raggiungere un elevato numero di persone velocemente. Il questionario sarà diffuso in forma digitale tramite un codice QR condivisibile tramite locandine disposte negli appositi spazi delle stazioni ferroviarie. Il questionario raccoglie inizialmente informazioni sull'utilizzo effettivo da parte del partecipante del servizio ferroviario per poi, tramite domande a risposta multipla che utilizzano la [Likert scale](https://en.wikipedia.org/wiki/Likert_scale), capire quanto le proposte di modifica dell'app gioverebbero la sua esperienza ferroviaria. La scala di Likert risulta essere particolarmente efficiente per questionari di questo genere in quanto, pur mantenendo un elevato grado di espressività, permette il completamento del questionario in modo semplice. Inoltre la possibilità di esprimere un punto di vista neutrale rispetto alle domande poste garantisce che i risultati non siano fortemente influenzati da opinioni incerte. Il questionario ha una lunghezza limitata in quanto bastano effettivamente pochi quesiti per essere in grado di capire se i viaggiatori, che sono gli stakeholders di maggior interesse rispetto all'aggiornamento proposto, siano effettivamente interessati o meno. Inoltre un questionario poco impegnativo risulta essere più veritiero rispetto ad uno più contorto che potrebbe esaurire la pazienza di colui che lo completa. I risultati di tale questionario saranno poi facilmente interpretabili, innanzitutto, tramite le prime 2 domande, si può identificare la parte di popolazione che potrebbe usufruire effettivamente del servizio proposto. Successivamente, valutando il grado accordo medio sulle ultime domande si può capire quale è la percentuale di utenti che utilizzerebbero i servizi proposti per ottenere un'esperienza di viaggio più agevolata. Tale questionario rappresenta una delle fasi iniziali del processo di elicitazione, in quanto svolge uno studio di fattibilità del progetto proposto. In caso i risultati ottenuti siano particolarmente negativi non sarà necessario procedere con il resto delle attività di elicitazione in quanto non è stato ottenuto il consenso da parte dello stakeholder di maggior interesse. Gli stakeholders che si vogliono confrontare tramite tale attività sono: - I viaggiatori: rappresentano lo stakeholder di maggior interesse ma non hanno un alto potere decisionale, il questionario è il modo tramite il quale possono esprimere il loro interesse verso il progetto proposto. Non vengono confrontati invece i seguenti stakeholders: - Tutti gli altri stakeholders, infatti tale attività ha l'obiettivo unico di raccogliere le opinioni dei viaggiatori e ricavarne i relativi requisiti funzionali (quali aggiunte fare al system-as-is), gli altri stakeholders verranno invece confrontati nelle fasi successive. --- #### Questionario: - Quanto frequentemente utilizzi i servizi ferroviari: - [ ] Solo in occasioni straordinarie. - [ ] Al più due treni a settimana. - [ ] Tutti i giorni, un treno al giorno. - [ ] Tutti i giorni, più treni al giorno. *Solo nel caso in cui venga selezionata la terza o la quarta opzione si procede con il questionario.* - L'itinerario dei treni utilizzati si ripete settimanalmente: - [ ] No. - [ ] Sì, per la maggior parte delle settimane. - [ ] Sì, tutte le settimane. *Solo nel caso in cui venga selezionata la seconda o la terza opzione si procede con il questionario.* **Esprimi il tuo grado di condivisione con le seguenti affermazioni** - Ritengo utile la possibilità di inserire il proprio itinerario settimanale per ricevere notifiche riguardo ritardi o cancellazioni relative ai treni compresi nel proprio itinerario settimanale: - [ ] Completamente d'accordo. - [ ] Parzialmente d'accordo. - [ ] Imparziale. - [ ] Parzialmente in disaccordo. - [ ] Completamente in disaccordo. - Ritengo utile la possibilità di inserire il proprio itinerario settimanale per ricevere alternative in caso di ritardi o cancellazioni relative ai treni compresi nel proprio itinerario settimanale: - [ ] Completamente d'accordo. - [ ] Parzialmente d'accordo. - [ ] Imparziale. - [ ] Parzialmente in disaccordo. - [ ] Completamente in disaccordo. - Ritengo utile la possibilità di inserire il proprio itinerario settimanale per ricevere proposte relative agli abbonamenti più convenienti: - [ ] Completamente d'accordo. - [ ] Parzialmente d'accordo. - [ ] Imparziale. - [ ] Parzialmente in disaccordo. - [ ] Completamente in disaccordo. - Ritengo corretto l'utilizzo delle informazioni relative al mio itinerario settimanale per un miglioramento del servizio ferroviario di Trenord: - [ ] Completamente d'accordo. - [ ] Parzialmente d'accordo. - [ ] Imparziale. - [ ] Parzialmente in disaccordo. - [ ] Completamente in disaccordo. - Ritengo utile l'ampliamento dell'e-store dell'applicazione in modo che sia possibile effettuare l'acquisto di biglietti relativi ad altri mezzi di trasporto anche per gli altri capoluoghi di provincia: - [ ] Completamente d'accordo. - [ ] Parzialmente d'accordo. - [ ] Imparziale. - [ ] Parzialmente in disaccordo. - [ ] Completamente in disaccordo. --- ### Scenario a seguito di un ritardo/cancellazione di un treno Lo scenario risulta molto efficace per mostrare praticamente come il system-to-be reagisca, anche analizzando le interazioni con l'ambiente, in modo differente al system-as-is nel caso in cui un evento che potrebbe accadere si manifesta. Essendo molto pragmatico risulta essere facilmente comprensibile agli stakeholders con nozioni e conoscenze tecniche ridotte (una motivazione più esaustiva dell'utilizzo degli scenari è contenuta all'interno dello scenario riguardante un turista che visita Milano, viene dunque omessa qui per non essere ripetitivi in compenso viene mostrato effettivamente lo scenario). Questo scenario viene utilizzato per mostrare in maniera pratica la serie di eventi causati da una cancellazione di un treno inserito all'interno dell'itinerario giornaliero/settimanale di un cliente che utilizza l'app Trenord dopo l'aggiornamento proposto. Tale scenario è classificato come **positive**, in quanto indica un aspetto che il system-to-be deve coprire e **abnormal** in quanto la cancellazione del treno è un evento eccezionale. Supponiamo che l'itinerario giornaliero del viaggiatore in questione comprenda i seguenti viaggi: | Stazione | Treno | Partenza | Arrivo | Coincidenza per il Treno Successivo | |------------------|----------------------|----------|--------|-------------------------------------| | Montello Gorlago | Bergamo | 07:39 | 7:54 | 8 minuti | | Bergamo | Milano Lambrate | 08:02 | 08:39 | 17 Minuti | | Milano Lambrate | Milano Greco Pirelli | 08:56 | 09:02 | | Supponiamo ora che il treno con tratta Bergamo - Milano Lambrate delle ore 08:02 venga cancellato alle ore 07:48 a causa di un malfunzionamento tecnico del treno in questione. Per come funziona il system-as-is il viaggiatore si accorgerebbe della cancellazione del treno una volta raggiunta la stazione di Bergamo (a meno che si tenga costantemente aggiornato riguardo la situazione dei treni che ha intenzione di prendere manualmente tramite l'app, situazione molto rara, soprattutto per i viaggiatori abituali), dovendo poi cercare manualmente un'alternativa, rischiando di perdere la coincidenza. Nel system-to-be proposto il viaggiatore, che avrà precedentemente inserito il proprio itinerario, verrebbe tempestivamente avvisato (07:48) utilizzando una notifica tramite l'applicazione di Trenord e verrebbe inoltre proposta la seguente alternativa (ai fini dello scenario è mostrata solo l'alternativa principale): | Stazione | Treno | Partenza | Arrivo | Coincidenza per il Treno Successivo | |----------|----------------------|----------|--------|-------------------------------------| | Bergamo | Milano Greco Pirelli | 08:20 | 09:20 | | In questo modo il viaggiatore è informato preventivamente ed ha a disposizione un lasso di tempo maggiore per decidere come rimediare all'imprevisto, per esempio effettuando l'acquisto di un nuovo biglietto. Una dinamica simile sarebbe accaduta anche nel caso in cui il treno con tratta Bergamo - Lambrate non fosse stato cancellato ma il treno con tratta Montello - Bergamo avesse accumulato un ritardo sufficiente a far perdere la coincidenza per il treno successivo. Importante sottolineare che le informazioni relative ai ritardi / cancellazioni / tratte alternative sono già in possesso del system-as-is che però non le sfrutta a pieno, per questo motivo l'aggiornamento proposto, nonostante aggiunga funzionalità interessanti non comporterebbe un cambiamento drastico del funzionamento del system-as-is, avendo dunque costi limitati. Tramite questa attività di elicitazione ci si aspetta di trovare nuovi requisiti funzionali rispetto a questa eventualità specifica, per esempio discutendo se il metodo di notifiche e suggerimento di soluzioni alternative proposto sia valido. Tale attività è stata collocata relativamente presto in quanto all'interno di essa vengono discussi aspetti fondamentali del system-to-be e che devono dunque essere chiariti perfettamente. Gli stakeholders coinvolti nella discussione dello scenario proposto sarebbero: - Gli sviluppatori del progetto: si occupano di mostrare lo scenario spiegando le varie dinamiche che potrebbero accadare. Utilizzano tale attività per mostrare in maniera pratica un sottoinsieme delle funzionalità proposte. - Rappresentante Trenord: valuta e indirizza cambiamenti rispetto allo scenario proposto. Essendo lo scenario molto semplice da comprendere non è necessario che tale rappresentante abbia conoscenza tecniche relative al system-as-is. Essendo lo stakeholder di maggior portere può suggerire modifiche e nuovi requisiti, specificando quali aspetti dello scenario proposto non lo convincono oppure quali aggiungerebbe (requisiti funzionali). - Rappresentante servizio manutenzione dell’app: essendo l'ente più aggiornato sul funzionamento attuale dell'app risulta particolarmente utile per valutare se i servizi proposti possano generare conflitti. Potrebbe essere fonte di altri requisiti non funzionali relativi all’effettiva implementazione dell’applicativo (sicurezza / performance). Non vengono inclusi invece: - I viaggiatori: il loro consenso (o dissenso) riguardo alle funzionalità proposte è già stato raccolto tramite il questionario. - Gli altri stakeholders in quanto non sono ritenuti necessari durante la discussione dello scenario proposto. ### Background Study e Data Collection applicato agli itinerari A seguito delle prime attività che hanno lo scopo principale di scoprire requisiti funzionali fondamentali per ciò che rappresenta il nucleo dell'aggiornamento dell'applicazione, si ritiene necessario effettuare anche uno studio più approfondito sull'implementazione del system-as-is ed una prima decisione sulla collezione dei dati che verranno utilizzati per ottenere il massimo dalla nuova funzionalità degli itinerari. Il Background Study è un'attività che ci permette non solo di comprendere il dominio esterno all'applicazione (che abbiamo già considerato superficialmente nell'introduzione), ma anche tutto ciò che riguarda il system-as-is dal punto di vista dell'implementazione e di tutta la documentazione che è stata prodotta durante lo sviluppo della prima applicazione. La fase di Data Collection, invece, ci permetterà di considerare dati che esistono già, ma che devono essere richiesti per poterli osservare (quindi relativi all'utilizzo dell'applicazione), e di considerare dati che sono stati prodotti in parte durante una delle precedenti fasi di elicitazione (relativi al questionario sugli itinerari). La fase di Background Study avrà lo scopo principale di scoprire requisiti principalmente non funzionali relativi alle prestazioni dell'applicazione e funzionali per indicare quali dati dovranno essere rappresentati. Le documentazioni e i dati richiesti per la fase di Background Study saranno: - Documentazione della piattaforma unica di Mia-Platform: ci tornerà utile, insieme ai dati relativi alle corse dei treni, per poter scoprire i requisiti corrispondenti alla piattaforma unica che verrà usata dall'applicazione aggiornata. - Dati relativi alle corse dei treni: raccolti da Mia-Platform, questi dati ci daranno una prima idea su cosa includere nella piattaforma per poter aggiungere le fermate relative alla rete metropolitana di Milano. - Documentazione dell'E-store sviluppato da Nord-Com: sarà ciò che ci permetterà di studiare il dominio del negozio elettronico sviluppato da Nord-Com e che ci darà le conoscenze necessarie per poter intervistare in modo efficiente il project manager di Nord-com sull'ampliamento dello store senza dover chiedere caratteristiche che possono risultare banali. - Documentazione sull'esperienza utente prodotta da Intrè: questa parte di documentazione considera ciò che è stato prodotto dall'azienda di Intrè sull'interfaccia e su quali fondamenti è stata sviluppata l'esperienza utente. Ci tornerà utile per i requisiti che verranno scoperti con lo scenario relativo all'utilizzo dell'applicazione da parte di un turista. La fase di Data Collection andrà a considerare diversi tipi di dati e ci permetterà di scoprire requisti di natura diversa: alcuni riguarderanno la raccolta dei dati relativi alle performance dell'applicazione e dell'utilizzo di essa, mentre altri riguarderanno maggiormente i dati utente e gli itinerari. Infatti la prima collezione conterrà i dati di monitoring relativi all'utilizzo dell'applicazione prodotti dai manutentori del servizio, che ci serviranno per poter avere un'idea delle performance reali che possiede la piattaforma e ci darà un'idea sul numero di richieste inviate dagli utenti durante la giornata. La seconda collezione, considerando i dati delle risposte ottenute dal questionario relativo agli itinerari, ci permetterà di scoprire requisiti non funzionali che andranno a considerare la raccolta dei dati sugli itinerari per garantire la privatezza dei dati previsti e la sicurezza in generale, per poterli utilizzare in modo tale da dare un servizio migliore all'utente stesso (quindi ad esempio attraverso le proposte di abbonamenti più convenienti). Inoltre questo tipo di raccolta dei dati potrebbe tornare utile anche per ulteriori aggiornamenti futuri dell'applicazione. Gli stakeholder inclusi per quest'attività sono i seguenti: - Sviluppatori dell'aggiornamento: il loro scopo è quello di richiedere la documentazione necessaria e i dati che ritengono utili per lo studio del dominio di riferimento per la nuova versione dell'applicazione. - Manutentore dell'app: la loro utilità è quella di fornire agli sviluppatori dell'aggiornamento i dati relativi al monitoring dell'utilizzo dell'app e delle richieste inviate giornalmente dagli utenti. Se hanno il permesso, forniranno anche la documentazione relativa al progetto già sviluppata. - Sviluppatori dell'applicazione originale: nel caso in cui i manutentori dell'applicazione non hanno il permesso di condividere la documentazione relativa alla prima versione dell'applicazione, verranno contattate le aziende che hanno contribuito al progetto originale per poter ottenere tutto ciò che è necessario per comprendere al meglio il dominio sotto ogni aspetto. Quest'attività è stata posta in una posizione iniziale, ma non tra le primissime attività in quanto abbiamo preferito, prima di effettuare uno studio specifico sullo sviluppo precedente, studiare l'effettiva fattibilità dell'aggiornamento e su quali caratteristiche gli utenti finali hanno dato un riscontro di maggior interesse, in modo tale da adattarci sulla scelta dei dati da considerare maggiormente o meno. La posizione centrale risulta comunque fondamentale in quanto la fase di background study ci permette di conoscere maggiormente nel dettaglio il dominio dello sviluppo della prima applicazione, in modo tale da garantire l'efficienza nelle attività successive e non una ricerca su alcune caratteristiche del progetto a seguito di attività come l'intervista indicata nel piano. ### Intervista su ampliamento biglietti del Trenord E-store L'attività sull'ampliamento dell'E-store in questo caso prevede di intervistare le figure che si ritengono necessarie per poter sviluppare quest'aggiornamento in modo tale che l'ottimizzazione sia mantenuta ad un livello simile di quella attuale. L'intervista è un'attività che ci permette di confrontarci direttamente con alcuni degli stakeholder. A differenza delle sessioni di gruppo, le interviste prevedono poche figure differenti all'interno dell'attività, questo perché permette un dialogo più profondo su questioni che possono riguardare requisiti che vanno a considerare criticità di un sistema e quindi si ritiene necessario includere solo le categorie che sono in grado di dare un contributo a questo tipo di problemi. Inoltre, svolgendosi con pochi individui, i conflitti d'interesse interni sono minimizzati e la comunicazione tende ad essere più diretta fra le parti, con l'intento di riuscire a trovare un compromesso che riesca ad accontentare tutti i presenti. A seguito della fase di Background Study e di Data Collection, che ci hanno permesso di comprendere al meglio il dominio al quale facciamo riferimento e ad avere dei primi dati riguardanti diverse caratteristiche dell'applicazione (come ad esempio l'utilizzo effettivo dei servizi di e-store), potremo infatti chiedere domande più specifiche con lo scopo di scoprire requisiti non funzionali relativi a scalabilità, manutenibilità e sicurezza per il sistema che rappresenta l'intero negozio (ad esempio, dalla scalabilità nel numero di richieste contemporanee per l'acquisto di un biglietto, alla sicurezza da garantire nella fase di pagamento). Vengono intervistati: - Project Leader di Nord-Com per l'applicazione originale: è una figura importante in quest'attività in quanto in base alle sue risposte potremo comprendere per quale motivo sono state effettuate alcune scelte nell'implementazione dello store attuale. Potremo anche riuscire a ottenere indirettamente dei consigli su alcune caratteristiche dello store in base a quello che è stato lo sviluppo della prima versione dell'applicazione. - Rappresentante del servizio di manutenzione dell'app: è fondamentale intervistare anche un rappresentante del servizio di manutenzione (nel dettaglio, uno che si occupa proprio dell'e-store), in modo tale da individuare criticità già presenti ed eventuali vulnerabilità da risolvere o perlomeno da non peggiorare nel funzionamento dell'applicazione. Altri stakeholder interessati a quest'attività che non vengono intervistati sono i seguenti: - Rappresentante servizi di autotrasporti provinciali lombardi: per quest'attività non è stato interpellato alcun rappresentante di questa categoria in quanto non si ritiene necessaria la loro presenza, infatti l'intervista verterà più nell'aspetto tecnico dell'implementazione dell'aggiornamento dello store. Per questa caratteristica dell'aggiornamento, i rappresentanti verranno informati a seguito dell'intervista su com'è andata l'attività e verranno tratte le conclusioni relative all'ampliamento durante la Group Session finale. - Rappresentante dei viaggiatori (abituali o occasionali): nonostante siano effettivamente i viaggiatori ad utilizzare il servizio, non si ritiene importante includerli in questa attività perché, come per il rappresentante di servizi di trasporto provinciali, verranno discussi aspetti principalmente specifici nell'ambito di requisiti non funzionali che in realtà risultano "invisibili" all'utente durante l'utilizzo della piattaforma. La posizione dell'attività rispetto al workflow di elicitazione è determinata dal fatto che l'ampliamento dell'e-store non rappresenta uno dei fondamenti dell'aggiornamento, quindi non si ritiene necessario eseguirla tra le prime attività. Inoltre, bisogna considerare che per poter effettuare un'intervista efficace nella comunicazione ed efficiente nel tempo impiegato, è stata svolta una fase di Background Study e di Data Collection proprio per riuscire ad ottenere il meglio da questa attività, concludendo la comprensione totale del system-as-is sotto l'aspetto considerato nell'intervista e scoprendo i requisiti che riguardano il funzionamento tecnico del negozio elettronico. ### Scenario di un turista nella città di Milano Per poter scoprire requisiti funzionali a seguito dell'aggiunta delle fermate della metro e degli orari delle corse relative, è stato deciso di eseguire questo tipo di attività. Infatti, lo scenario permette di creare degli esempi concreti (considerando anche tratte che prevedano l'utilizzo di mezzi precisi), risultando stimolante nella stesura dei requisiti, cercando di costruirli a partire dalle singole istanze fino a fare in modo che risultino generali rispetto alle situazioni prese in esame in precedenza. Inoltre si potrà considerare come strutturare la ricerca di una tratta nel caso in cui si preveda l'utilizzo di più mezzi di diversa natura: quindi decidendo se mantenere la struttura già presente oppure se alterarla in base ad altre preferenze che potrebbe avere un turista. I requisiti che ci aspettiamo di scoprire con quest'attività sono principalmente di tipo funzionale e fanno riferimento alla ricerca della tratta per raggiungere una certa destinazione a partire da una posizione di partenza di un potenziale viaggiatore, considerando sia la rete ferroviaria, sia quella metropolitana. In questo caso non si considera l'aspetto tecnico sulla gestione dei dati relativi alle corse della metro in quanto sono già stati considerati durante l'attività di background study, che ci ha permesso di avere la descrizione dei requisiti di una piattaforma che unisce tutte le informazioni già presenti con quelle da considerare in più per l'aggiornamento. Gli stakeholder che partecipano a quest'attività sono i seguenti: - Sviluppatore dell'aggiornamento: il suo scopo principale è quello di presentare gli scenari alle altre categorie presenti, ascoltare e capire le osservazioni poste dagli altri stakeholder, in modo tale da individuare possibili criticità dello scenario e riuscire a risolvere eventuali problemi legati ad esso, cosicché l'utente reale non si trovi in difficoltà durante l'utilizzo dell'applicazione. - Rappresentante ATM: si ritiene utile includere una persona che possa rappresentare questo stakeholder perché la sua presenza permette di ottenere informazioni su ciò che ATM si aspetta dal punto di vista dell'esperienza che un suo cliente meno abituale dovrebbe ricevere in modo tale che quindi l'utilizzo risulti intuitivo ed il più immediato possibile. - Rappresentante Trenord: è importante avere un rappresentate dell'azienda ferroviaria di riferimento in quanto è necessario fare in modo che si raccolgano le opinioni di questa categoria di stakeholder e mediare preventivamente eventuali conflitti che si possono creare con altre parti di riferimento. - Turista: essendo una categoria di persone che può essere rappresentata da qualsiasi individuo, si decide di rappresentare questa categoria di persone attraverso conoscenti diretti degli sviluppatori dell'aggiornamento che non hanno mai utilizzato l'app di Trenord per comprendere se lo scenario da un punto di vista esterno risulta comprensibile. Sarebbe preferibile includere anche individui non conosciuti dagli sviluppatori in quanto potrebbero esserci dei bias definiti dal rapporto tra le persone considerate (i rappresentati dei turisti potrebbero risultare meno critici nei confronti degli sviluppatori). Questo scenario è stato posizionato come ultima attività precedente alla group session finale in quanto questa fase permette una raccolta di requisiti che vanno a considerare principalmente i viaggiatori occasionali: infatti hanno un'importanza minore dal punto di vista della soddisfacibilità rispetto ad altri tipi di viaggiatori. Quindi i requisiti raccolti andranno a considerare più l'esperienza utente di un viaggiatore che non conosce bene la piattaforma rispetto a quella di un individuo che conosce bene l'applicazione, essendo un viaggiatore più abituale. Si può dedurre che non considerando requisiti che risultano vitali per l'aggiornamento che si vuole implementare, ha senso posizionare quest'attività verso la fine del workflow della strategia. ### Group session finale Una volta completate le attività di elicitazione precedenti avremo a disposizione un'ampia e completa visione di tutto quello che riguarda i requisiti del nostro progetto. Infatti avendo compiuto uno studio del dominio intensivo, avendo confrontato i vari stakeholders sugli aspetti che li riguardano principalmente ed essendoci accertati che non ci siano conflitti tra essi possiamo dunque stabilire la fattibilità del progetto proposto, ed in caso il riscontro fosse stato positivo avremo a disposizione un'esaustiva lista di requisiti che coprono i vari aspetti del progetto. Viene dunque organizzata una group session nella quale verrano presentati i risultati raccolti e le loro analisi in modo da poter combinare le informazioni raccolte in un'unica proposta di progetto contenente i relativi requisiti ottenuti. Tale riunione potrebbe anche essere fonte di nuovi requisiti dimenticati nelle attività precedenti. Alla group session saranno presenti: - Sviluppatori del progetto: incaricati della discussione dei risultati ottenuti proponendo una visione completa del progetto. A questo punto è già stata compilata una lista di requisiti che dovrebbe coprire la maggior parte delle questioni delicate del progetto proposto, ed è il momento dunque di trarre le conclusioni. Vengono dunque analizzati i risultati delle attività precedenti, in particolare i risultati ottenuti dal questionario: nel caso in cui sia stato rilevato un forte interesse da parte dei viaggiatori allora ci si può concentrare sugli aspetti non funzionali (come per esempio le questioni economiche relative allo sviluppo del progetto proposto), viceversa, ci si dovrebbe concentrare maggiormente sulle possibili modifiche (requisiti funzionali) da apportare al progetto in modo da renderlo più appetibile. - Rappresentante Trenord: innanzitutto ha la possibilità di vedere una proposta di progetto concreta, con le relative analisi, in questo modo gli sarà possibile valutare il progetto nella sua interezza ed eventualmente di specificare requisiti aggiuntivi. Supponendo infatti che ci siano stati riscontri positivi dalle attività precedenti il rappresentante di Trenord diventa fondamentale per la discussione e la specifica degli aspetti non funzionali del progetto, infatti essendo presente una proposta completa è possibile discutere su tempi e costi relativi al progetto. - Rappresentante servizio manutenzione dell’app: nel caso in cui i riscontri delle attività precedenti siano stati positivi per un eventuale implementazione sarà sicuramente comodo avere un confronto aggiuntivo con il servizio attuale di manutenzione, in modo di discutere eventualmente altri requisiti non funzionali relativi all'effettiva implementazione dell'applicativo (sicurezza / performance). - Rappresentante ATM: nel caso in cui i riscontri delle attività precedenti siano stati positivi allora, considerando che nel progetto proposto è presente un'aggiunta che utilizza i loro servizi, un confronto aggiuntivo potrebbe confermare la completezza dei requisiti stilati oppure portare all'aggiunta di nuovi requisiti. - Rappresentante dei servizi di autotrasporti provinciali lombardi: principalmente per confermare che le modifiche proposte per l'ampliamento dell'e-store siano corrette e che i relativi requisiti siano esaustivi. Infatti si vuol rendere possibile l'acquisto di biglietti per altri mezzi di trasporto anche per gli altri capoluoghi di provincia e non solo per Milano (come succede attualmente nel system-as-is) Alla group session non saranno presenti invece rappresentanti dei viaggiatori, innanzitutto perché sono stakeholders di basso potere ma soprattutto perché la loro opinione è stato raccolta in maniera esaustiva tramite il questionario.