Università Ca Foscari di Venezia Facoltà di Scienze Matematiche, Fisiche e Naturali Ingegneria del software a.a. 2010/2011 PDMA Personal Digital Museum Assistant : Documento di analisi e specifica dei requisiti Componenti del gruppo: Cusinato Daniele email: dcusinat@dsi.unive.it De Marchi Davide email: ddemarch@dsi.unive.it Simioli Massimo email: msimioli@dsi.unive.it Tognacci Dario email: dtognacc@dsi.unive.it data rilascio: 25 novembre 2010 data ultima revisione: 25 novembre 2010 versione:1
Registro delle revisioni del documento Versione 1 descrizione Stesura bozza Documento dei requisiti del progetto PDMA Data rilascio 25/11/10 Pagina 2 di 69
Indice generale 1 Il documento...5 1.1 Scopo del documento... 5 1.2 del documento... 5 1.3 delle funzionalità generali del prodotto... 5 2 Modellazione del sistema...7 2.1 Modello architetturale... 7 2.2 Modello dataflow...8 2.3 Modello relazionale...10 2.4 Modello a stati...12 3 Analisi dei viewpoint... 14 3.1 Individuazione dei viewpoint... 14 3.1.1 Viewpoint interattivi...14 3.1.2 Viewpoint di dominio...15 3.2 Gerarchia dei viewpoint... 15 3.3 dei protagonisti...17 4 dei requisiti funzionali...20 4.1 Requisiti esterni... 20 4.2 Requisiti interni... 20 5 dei requisiti non funzionali...32 5.1 Requisiti di prodotto... 33 5.2 Requisiti di processo...37 5.3 Requisiti esterni... 39 6 Evoluzione del sistema... 40 6.1 Assunzioni principali... 40 6.2 Sviluppi futuri... 40 6.2.1 Aumento accessibilità... 40 6.2.2 Evoluzione del sistema di sovrapposizione layer...40 7 dei requisiti... 41 7.1... 41 7.2 Matrice dei riferimenti... 63 8 Appendice... 64 8.1 Normative menzionate...64 8.1.1 Normative famiglia ISO 9000 Quality management system...64 8.1.2 ISO/IEC 9126 Software engineering Product quality...64 8.1.3 ISO/IEC 12207 Software Life Cycle Processes...65 8.1.4 ISO/IEC 19501 Unified Modeling Language...65 8.2 Glossario...66 8.3 Allegati... 68 9 Riferimenti... 69 Pagina 3 di 69
Indice delle illustrazioni Illustrazione 1: Data flow generale del sistema... 9 Illustrazione 2: Modello relazione del sistema... 11 Illustrazione 3: Modello a stati schermata Impostazioni... 12 Illustrazione 4: Modello a stati Utente... 12 Illustrazione 5: Modello a stati schermata Mappa...12 Illustrazione 6: Modello a stati schermata Informazioni...13 Illustrazione 7: Modello a stati Receptionist...13 Illustrazione 8: Gerarchia viewpoint... 16 Pagina 4 di 69
1 Il documento 1.1 Scopo del documento Scopo del documento è offrire una dettagliata descrizione del prodotto oggetto del documento Business Plan PDMA Personal Digital Museum Assistant. Tale analisi è funzionale a stabilire che cosa il sistema in questione deve fare e quali servizi deve fornire. Le decisioni sul come deve realizzare tutto ciò sono rimandate ad un successivo documento di progettazione del sistema. 1.2 del documento Questo documento, indicato nel seguito nelle sue forme abbreviate come il Documento, Documento dei requisiti, dei requisiti o, nella sua forma estesa, Documento di analisi e specifica dei requisiti, presenta una precisa analisi del sistema PDMA; partendo da una generica descrizione delle sue componenti e del contesto applicativo in cui questo prodotto si troverà ad operare, scendendo poi in dettaglio nell analisi dei requisiti che il sistema deve soddisfare, parlando infine dei possibili sviluppi grazie ai quali aumentare il suo ciclo di vita. Presentiamo di seguito una breve panoramica sui capitoli di questo documento: Capitolo 2 Modellazione del sistema: viene discussa la struttura del sistema mediante l uso di modelli descrittivi e predittivi che rappresentano una versione semplificata del sistema stesso. Vengono descritti, oltre a tali modelli, anche i componenti principali che vanno a comporre il sistema ed i loro collegamenti; Capitolo 3 Analisi dei viewpoint: analizzare il sistema dalle prospettive di tutti i possibili suoi utilizzatori e/o componenti che possono interagire con esso consente di individuarne i requisiti e comprendere come questi possono essere realizzati. Questo è lo scopo dell analisi trattata nel capitolo ed è una fase cruciale per la corretta individuazione dei requisiti e delle specifiche del sistema; Capitolo 4 dei requisiti funzionali : descrive i servizi che il sistema deve fornire, il suo comportamento in base a particolari sequenze di input o situazioni; Capitolo 5 dei requisiti non funzionali: discute dei servizi offerti dal sistema, definendo proprietà e vincoli come affidabilità, robustezza, usabilità, vincoli temporali e di memoria; Capitolo 6 Evoluzione del sistema: descrive le assunzioni principali su cui si basa il sistema e le eventuali evoluzioni future, possibili risposte ai cambiamenti hardware e software che possono presentarsi durante il ciclo di vita del sistema ed interfacciamento con nuove tecnologie che, sfruttando le sinergie tra i diversi componenti, siano in grado di offrire nuovi servizi. Tutto questo con lo scopo di aumentare la sua longevità e quindi la possibilità offerta di ricavare guadagni. Capitolo 7 dei requisiti : si descrivono con dovizia di particolari i requisiti funzionali descritti precedentemente nel capitolo 4, fornendo per ognuno di essi precisi dettagli e la loro stretta correlazione. 1.3 delle funzionalità generali del prodotto Il prodotto PDMA, indicato nel seguito con il Prodotto o PDMA, prevede mediante il suo uso, la fruizione di contenuti informativi multimediali per un museo aziendale. Il sistema in sè è composto da un dispositivo palmare portatile, da un dispositivo di ascolto (auricolari) e da un dispositivo HMD (occhiali con display LCD). Tramite la combinazione di questi elementi il visitatore può ricevere e Pagina 5 di 69
prendere visione, sia in forma scritta che mediante rappresentazioni video od audio, delle informazioni riguardanti gli oggetti presenti nelle sale espositive. Il visitatore disporrà delle informazioni nella sua lingua nativa, o comunque nella lingua prescelta inizialmente, e potrà selezionare semplicemente le informazioni a cui è interessato mediante lo schermo touchscreen di cui è dotato il palmare. Il visitatore è messo nelle condizioni di muoversi liberamente attraverso le sale del museo, grazie anche alla completa assenza di connessioni via cavo dei dispositivi, oppure può decidere di seguire percorsi indicati dal dispositivo portatile, in base alle scelte ed interessi indicati dal visitatore stesso. Pagina 6 di 69
2 Modellazione del sistema Durante la modellazione del sistema si è reso necessario dividere questa onerosa fase progettuale in due distinte sezioni, riguardanti a loro volta aree del progetto diverse, e che richiedono quindi specifiche analisi dedicate, supportate da validi modelli schematici. A seguire, una panoramica sui modelli descritti dettagliatamente nei paragrafi successivi: 1. Modello architetturale: viene presentata l architettura dell intero sistema distinguendo fra le varie parti che lo compongono ed i collegamenti fra queste: prodotto offerto al visitatore, infrastruttura di comunicazione ed immagazzinamento dati a supporto dei dispositivi portatili; 2. Modello dataflow: modello espositivo di tutti i processi di comunicazione, scambio dati ed interfacciamento tra i blocchi costituenti il modello architetturale; all interno vengono inoltre presentati i modelli di comunicazione adottati tra i diversi blocchi; 3. Modello relazionale: permette di prendere coscienza, tramite una visualizzazione grafica, dei legami e delle connessioni tra i componenti architetturali del sistema e i viewpoint individuati e analizzati nel dettaglio nel successivo capitolo 3. 4. Modello a stati: permette di prototipizzare il sistema, visualizzando l'interazione tra le varie parti che lo costituiscono e l'utente del dispositivo. Contribuisce a rendere più chiara la struttura del sistema. 2.1 Modello architetturale Il modello architetturale ha lo scopo di presentare e visualizzare i principali blocchi costituenti il sistema in esame. Il nostro progetto prevede due sottosistemi distinti, con compiti differenti, ma comunicanti tra loro al fine di fornire il servizio richiesto al visitatore. Precisamente, essi sono: 1. Sottosistema dispositivo: (indicato come SSD) costituito dal dispositivo portatile PDMA, dalla coppia di auricolari e dal paio di occhialini. Esso costituisce l interfaccia visiva e uditiva verso l utilizzatore; 2. Sottosistema infrastrutturale: (indicato come SSI) costituito dal server, dalla base di dati e da tutti i collegamenti fisici e aerei (rete di comunicazione) necessari a fornire informazioni e comunicare con i sottosistemi dispositivo. Deve essere ben progettato per soddisfare criteri specifici quali affidabilità, indice di throughput e robustezza. Analizziamo ora in dettaglio i singoli componenti che vanno a costituire i sottosistemi appena descritti. PDMA: è il fulcro del sistema, mettendo in comunicazioni tra loro tutti componenti. E un dispositivo palmare, personale per ogni visitatore, che selezionare le informazioni di proprio interesse, fornendo una strutturata interfaccia utente e occupandosi personalmente del recupero delle selezionate; i successivi permette di ma intuitiva informazioni Occhialini: è il componente che ci permette di parlare effettivamente di realtà aumentata, e che da particolare innovazione al nostro progetto. Fornisce graficamente le informazioni richieste dal visitatore sotto forma di tracce visive, siano esse immagini, video o semplice testo. Auricolari: fornisce al visitatore l interfaccia uditiva verso l utilizzatore, fornendo audioguide, informazioni sugli oggetti esposti e tutte quelle informazioni che, selezionate mediante il PDMA, sono costituite da tracce audio; Pagina 7 di 69
Oggetto esposto: blocco architetturale che, anche se non direttamente connesso al sistema, viene fornito di tecnologia tale da permettere al PDMA di ricavare precisamente la sua posizione fisica all interno della sala espositiva; Server: elaboratore dedicato a ricevere richieste da parte dei PDMA, elaborare tali richieste e predisporre le informazioni recuperate dalla base di dati in appositi pacchetti da inoltrare verso i PDMA richiedenti; Base di dati: raccolta di informazioni testuali, audio e video riguardanti gli oggetti esposti all interno del museo. Deve fornire un accesso rapido alle informazioni contenute al suo interno, in maniera tale da poter gestire richieste multiple da parte del server; Rete di comunicazione: l insieme di tutti i collegamenti realizzati mediante cavi elettrici od onde radio che vanno a permettere la comunicazione tra i componenti sopra descritti. Realizzata mediante standard di comunicazione ampiamente diffusi, deve garantire il servizio in ogni genere di situazione di traffico rete. 2.2 Modello dataflow Il modello dataflow, partendo da quello architetturale, va ad evidenziare le connessioni tra i diversi componenti del sistema, con i loro scambi di dati. All interno del nostro sistema abbiamo individuato 4 differenti sottosistemi comunicativi, e cioè: 1. Sottosistema Server Base di dati: (indicato come SSSBD): realizzato internamente al server od esternamente mediante cablaggio, sottosistema fullduplex, gestisce il trasferimento delle richieste di informazioni, il loro trasferimento verso il server, il quale provvederà ad elaborarle e restituirle al PDMA richiedente attraverso SSSP; 2. Sottosistema Server PDMA: (indicato come SSSP) realizzato mediante onde radio, questo sottosistema fullduplex permette l invio di richieste verso il server e la ricezione da quest ultimo delle informazioni richieste; 3. Sottosistema PDMA Occhialini Auricolari : (indicato come SSPOA) sottosistema radio simplex monodirezionale dal PDMA verso gli occhialini e gli auricolari, permette alle informazioni visive o testuali di giungere agli occhialini e venire visualizzate e, alle informazioni audio, di essere ricevute dagli auricolari che provvederanno a riprodurle; 4. Sottosistema PDMA Oggetto esposto: (indicato come SSPO) realizzato con tecnologie radio, è un sottosistema halfduplex, in cui prima viene trasmessa la richiesta di informazioni riguardanti l attuale vicinanza agli oggetti esposti, quindi utilizzata per la trasmissione delle informazioni dagli oggetti vicini verso il PDMA. Pagina 8 di 69
Illustrazione 1: Data flow generale del sistema. Pagina 9 di 69
2.3 Modello relazionale Nello schema relazionale introdotto di seguito, è stata usata una codifica rappresentativa tale da permettere la rapida comprensione degli attori in gioco nel progetto PDMA. Esponiamo brevemente i blocchi che vanno a costituire tale diagramma e le loro corrispondenti convenzioni grafiche: Viewpoint: rappresentati da rettangoli rosa, i viewpoint individuati sono gli attori principali del progetto imprenditoriale. Sono marcati con il nome del viewpoint; Componenti chiave: visualizzati con rettangoli blu, sono componenti che rivestono un ruolo fondamentale nel nostro progetto imprenditorale e che si designano superpartes rispetto al sistema; Componenti del sistema: individuati da rettangoli verdi, sono componenti dei sottosistemi dispositivo SSD e dei sottosistemi infrastrutturali SSI. Sono evidenziati con il nome del componente; Legami relazionali: rappresentati da rombi gialli, sono il cuore di questo modello e visualizzano i legami tra gli altri blocchi sopra elencati. Sono identificati da forme verbali. Pagina 10 di 69
Illustrazione 2: Modello relazione del sistema Pagina 11 di 69
2.4 Modello a stati Il modello a stati esposto nel seguito esprime una prototipizzazione del sistema, al fine di rendere chiaro l interaction design tra visitatore e dispositivo, receptionist e dispositivo. La prototipizzazione è una tecnica d indagine dell usabilità del sistema per rendere più chiari aspetti che prima non lo erano e che, al contempo, permette di risparmiare tempo e fatica cercando di migliorare la qualità finale del prodotto. Illustrazione 4: Modello a stati Utente Illustrazione 3: Modello a stati schermata Impostazioni Illustrazione 5: Modello a stati schermata Mappa Pagina 12 di 69
Illustrazione 6: Modello a stati schermata Informazioni Illustrazione 7: Modello a stati Receptionist Pagina 13 di 69
3 Analisi dei viewpoint Come detto in precedenza, i viewpoint esprimono il sistema considerato dal punto di vista di uno stakeholder. Rappresentano, quindi, dei punti cruciali per una dettagliata e corretta analisi del sistema. A seguire presentiamo i viewpoint individuati per il nostro progetto e la loro gerarchia. 3.1 Individuazione dei viewpoint Abbiamo individuato le seguenti due principali classi di viewpoint: Viewpoint interattivi: sono tutti gli attori che interagiscono attivamente con il sistema in oggetto. In questa categoria ricadono il personale del museo che agiranno direttamente sul sistema una volta consegnato, i tecnici M3D che provederanno alla sua creazione, aggiornamente e mantenimente in esercizio e gli utenti che lo utilizzeranno; Viewpoint di dominio: rapprentano vincoli e caratteristiche del dominio che vanno ad influenzare in qualche modo i requisiti analizzati nei successi capitoli. Essi rappresentano standard o requisiti legislativi da rispettare. Nel seguito la trattazione dei singoli viewpoint appartenenti a queste due classi principali. 3.1.1 Viewpoint interattivi La nostra analisi ha portato all individuazione di 3 sottoclassi specifiche delle entità in gioco nel progetto, contenenti a loro volta specifici viewpoint rappresentanti l insieme di tutti gli stakeholder interessati dal sistema. Segue una panoramica di quest ultimi, supportata da una descrizione degli stessi. Classe Personale di museo Purchaser: è Il committente del progetto imprenditoriale, è suo compito definire i requisiti fondamentali e le personalizzazioni di cui necessita e fornire alla società M3D le informazioni e i contenuti multimediali da inserire all interno del sistema. Receptionist: è il personale del museo che ha compiti gestionali relativi al sistema PDMA, quali consegna dei dispositivi ai visitatori, il loro addestramento all uso del prodotto, il mantenerli carichi e operativi, fornire supporto e chiarimento agli utenti. Classe Tecnici M3D Content editor: è il curatore dei contenuti del sistema, siano essi audio, video o testo. E personale addetto all inserimento, aggiornamento, revisione e/o cancellazione dei contenuti multimediali presenti nella base di dati su cui si appoggia il server. Ogni informazione dovrà essere quindi associata ad uno specifico oggetto esposto. Hardware Software Administrator: è il personale addetto alla manutenzione del sistema hardware ed alla gestione corretta ed efficiente dei database in cui sono inseriti i contenuti multimediali. Questa figura professionale deve essere in possesso di solide capacità di configurazione e aggiornamento del sistema per rispondere a situazione improvvise. Author: è il personale delegato alla progettazione e realizzazione fisica del sistema, con ampie capacità di problem solving, devono essere in grado di personalizzare e installare il Pagina 14 di 69
prodotto e di risolvere eventuali bug progettuali. Classe Utenti Visitor: È il fruitore finale del sistema. L intero sistema deve progettato, disegnato e realizzato attorno a questa figura. Deve essere messo in condizione di usare con facilità ed intuitività tutte le funzionalità che offre il prodotto, navigando tra i contenuti offerti, ricercare e scegliere di quali fruire e ricevere assistenza se ne necessita. 3.1.2 Viewpoint di dominio Per la produzione di un sistema efficiente, scalabile, ben documentato, facilmente realizzabile e con un alta percentuale di successo del progetto industriale, l analisi del dominio ha portato all identificazione dei seguenti standard ISO da rispettare. Vediamo una breve panoramica delle ISO selezionate e una breve descrizione del loro contenuto. Normative famiglia ISO 9000 Quality management system : insieme di linee guida che definiscono i requisiti per l implementazione di un sistema di gestione di qualità, mediante miglioramento continuo di efficacia ed efficienza nella produzione del prodotto, con il fine di incrementare la soddisfazione del cliente. ISO/IEC 12207 Software Life Cycle Processes : normativa che propone uno standard nel processo di sviluppo e mantenimento del software, comprensivo di processi ed attività relative alle specifiche ed alla configurazione del sistema. ISO/IEC 19501 Unified Modeling Language : normativa che prevede di unificare le descrizioni di soluzioni analitiche e progettuali in modo sintetico e comprensibile. ISO/IEC 9126 Software engineering Product quality : normativa e linee guida per la descrizione di un modello di qualità del software, proponendo un approccio tale da migliorare l organizzazione ed i processi di sviluppo. 3.2 Gerarchia dei viewpoint Ricapitoliamo l insieme di tutti i viewpoint analizzati, evidenziando le gerarchie che si vengono a creare tra di loro, mediante l organigramma qui esposto. Pagina 15 di 69
Illustrazione 8: Gerarchia viewpoint Pagina 16 di 69
3.3 dei protagonisti Evidenziamo ora, in forma standardizzata, i viewpoint da noi definiti focalizzando precisamente i servizi che vanno ad erogare o che vanno ad utilizzare e gli eventi mediante i quali interagiscono. Utente Riferimento Interattivi Eventi Servizi Fruizione Informazioni Sub Viewpoints Visitors M3D Riferimento Interattivi Eventi Servizi Creazione Sistema e Mantenimento Sub Viewpoints Content Editor, HWSW Administrator, Author Personale Museo Riferimento Interattivi Eventi Servizi Consegna Sistema agli Utenti finali, Diramazione Specifiche Sub Viewpoints Receptionists, Purchaser Pagina 17 di 69
Visitor Riferimento Utente Eventi Configurazione PDMA (Post Addestramento) Navigare tra i contenuti Abilita e Disabilita il dispositivo Servizi Fruizione Informazioni Sub Viewpoints HWSW Administrator Riferimento M3D Eventi Configura il sistema Aggiorna il sistema Servizi Mantenimento del Sistema Sub Viewpoints Content Editor Riferimento M3D Eventi Modifica i dati del sistema Aggiunge nuovi record, associandoli ad un determinato Item Servizi Aggiornamento del Sistema Sub Viewpoints Pagina 18 di 69
Author Riferimento M3D Eventi Personalizzazione del prodotto Installazione del prodotto Servizi Creazione del Sistema Sub Viewpoints Receptionist Riferimento Personale Museo Eventi Consegna PDMA all'entrata Ritiro PDMA all'uscita Ricarica componenti PDMA Addestramento visitatore all'utilizzo del PDMA Servizi Consegna Dispositivi all utente finale Sub Viewpoints Purchaser Riferimento Personale Museo Eventi dei requisiti delle personalizzazioni Fornitura dei dati da inserire nei database Servizi Diramazione Specifiche Sub Viewpoints Pagina 19 di 69
4 dei requisiti funzionali I requisiti funzionali rappresentano le condizioni necessarie al funzionamento del sistema, le funzioni che esso deve fornire per soddisfare i bisogni degli stakeholder. La documentazione classica prevede la suddivisione dei requisiti funzionali in due gruppi nettamente distinti, cioè: Requisiti funzionali interni: rappresentano le funzionalità che il sistema deve internamente ottemperare affinchè sia realizzato il suo scopo; Requisiti funzionali esterni: sono i vincoli ambientali necessari al corretto funzionamento del sistema nella sua interezza. Sebbene questa usuale ripartizione, dopo una fase di elicitazione dei requisiti, i vincoli da noi specificati appartengono solamente a questa prima categoria. Per la trattazione specifica, si rimanda ai paragrafi successivi. 4.1 Requisiti esterni A causa dell ampio spettro applicativo che il prodotto da noi presentato può avere e la sua adattabilità a più realtà museali, non è possibile definire a priori i requisiti esterni funzionali. Ogni ambiente espositivo presenta differenti esigenze e peculiarità che necessitano di specifiche indagini per cogliere quello che esso effettivamente essi richiedeno. Questa analisi viene perciò demandata ad ogni singola commessa assegnataci, diventando perciò parte fondamentale di analisi della specifica realtà in cui si andrà ad operare. 4.2 Requisiti interni L analisi dei requisiti funzionali interni viene di seguito esposta mediante la seguente rappresentazione tabellare. Breve stringa che identifica il requisito del requisito Motivo della scelta del requisito dei requisiti correlati Stringa identificativa della specifica del requisito Pagina 20 di 69
RF4.2.1 Visualizzazione schermata principale all avvio All'avvio del dispositivo, esso deve visualizzare una schermata principale. SRF4.2.1 RF4.2.2 Struttura schermata La schermata di impostazione e la schermata principale sono composte da un menù SRF4.2.2 RF4.2.3 Struttura menù principale Il menu della schermata principale deve prevedere l'accesso alle schermate impostazioni, mappa interattiva, contenuti multimediali. RF4.2.4 SRF4.2.3 RF4.2.4 Menù schermata impostazioni Il menu della schermata impostazioni deve prevedere l'accesso alla schermata impostazione lingua, impostazione contrasto, impostazione font, impostazione luminosità, impostazione volume, ritornare al schermata principale RF4.2.5, RF4.2.9, RF4.2.13, RF4.2.17, RF4.2.21 SRF4.2.4 Pagina 21 di 69
RF4.2.5 Schermata lingue La schermata impostazione lingua deve visualizzare un insieme di lingue. RF4.2.6 SRF4.2.5 RF4.2.6 Scelta lingue Deve essere possibile selezionare una lingua tra quelle appartenenti all'insieme. RF4.2.7 SRF4.2.6 RF4.2.7 Impostazione lingue Deve essere possibile applicare la nuova impostazione della lingua. RF4.2.38 SRF4.2.7 RF4.2.8 Ritorno alla schermata impostazioni dal menù lingua Una volta applicata la nuova impostazione si deve ritornare alla schermata impostazioni dal menù lingua SRF4.2.8 Pagina 22 di 69
RF4.2.9 Schermata contrasto La schermata impostazione contrasto deve permettere la modifica del contrasto del display del dispositivo. RF4.2.10 SRF4.2.9 RF4.2.10 Selezione contrasto Deve essere possibile selezionare un nuovo contrasto. RF4.2.11 SRF4.2.10 RF4.2.11 Applicare nuovo contrasto Deve essere possibile applicare la nuova impostazione del contrasto. SRF4.2.11 RF4.2.12 Ritorno al menù principale dalla schermata regolazione contrasto Una volta applicata la nuova impostazione si deve ritornare alla schermata impostazioni. SRF4.2.12 Pagina 23 di 69
RF4.2.13 Schermata font La schermata impostazione font deve prevedere la modifica del font utilizzato e la sua dimensione. RF4.2.14 SRF4.2.13 RF4.2.14 Scelta font Deve essere possibile selezionare un font ed una grandezza tra quelle appartanenti all'insieme. RF4.2.15 SRF4.2.14 RF4.2.15 Impostazione font Deve essere possibile applicare la nuova impostazione del font e della sua grandezza. SRF4.2.15 RF4.2.16 Ritorno alla schermata principale dal menù scelta font Una volta applicata la nuova impostazione si deve ritornare alla schermata impostazioni. SRF4.2.16 Pagina 24 di 69
RF4.2.17 Schermata luminosità display La schermata impostazione luminosità deve permettere la modifica della luminosità del display del dispositivo. RF4.2.18 SRF4.2.17 RF4.2.18 Selezione nuova luminosità Deve essere possibile selezionare una nuova luminosità. RF4.2.19 SRF4.2.18 RF4.2.19 Applicazione nuova luminosità Deve essere possibile applicare la nuova impostazione della luminosità. SRF4.2.19 RF4.2.20 Ritorno al menù principale dalla schermata modifica luminosità Una volta applicata la nuova impostazione si deve ritornare alla schermata impostazioni. SRF4.2.20 Pagina 25 di 69
RF4.2.21 Schermata volume audio La schermata impostazione volume deve permettere la modifica del volume dell'audio riprodotto. RF4.2.22 SRF4.2.21 RF4.2.22 Scelta livello volume Deve essere possibile selezionare un nuovo volume. RF4.2.23 SRF4.2.22 RF4.2.23 Applicazione livello volume Deve essere possibile applicare la nuova impostazione del volume. SRF4.2.23 RF4.2.24 Ritorno al menù principale dalla schermata modifica volume Una volta applicata la nuova impostazione si deve ritornare alla schermata impostazioni. SRF4.2.24 Pagina 26 di 69
RF4.2.25 Schermata mappa interattiva La schermata mappa interattiva è composta da un menu. RF4.2.26 SRF4.2.25 RF4.2.26 Possibili scelte nel menù mappa interattiva Il menu della schermata mappa interattiva deve prevedere l'accesso alla schermata mappa, alla schermata scelta POI (punti di interesse), alla schermata principale. RF4.2.27 SRF4.2.26 RF4.2.27 Mappa La schermata mappa deve visualizzare la mappa degli ambienti del museo, la posizione corrente del visitatore e fornire la possibilità di tornare alla schermata mappa interattiva. SRF4.2.27 RF4.2.28 Aggiornamento posizione utente sulla mappa La posizione del visitatore deve essere aggiornata in base ai suoi spostamenti. RF4.2.29 SRF4.2.28 Pagina 27 di 69
RF4.2.29 Direzione mappa su display La mappa deve essere direzionata in base agli spostamenti del visitatore. SRF4.2.29 RF4.2.30 Lista POI La schermata POI deve visualizzare una lista dei punti di interesse in prossimità del visitatore. SRF4.2.30 RF4.2.31 Ritorno alla schermata mappa interattiva La schermata POI deve prevedere di tornare alla schermata mappa interattiva. SRF4.2.31 RF4.2.32 Selezione POI Deve essere possibile selezionare un punto di interesse. RF4.2.33 SRF4.2.32 Pagina 28 di 69
RF4.2.33 Calcolo percorso e visualizzazione Selezionato un punto di interesse viene calcolato il percorso per raggiungere la destinazione e visualizzato nel display SRF4.2.33 RF4.2.34 Ritorno al menù principale dalla schermata POI La schermata informazioni deve permettere di tornare alla schermata principale. SRF4.2.34 RF4.2.35 Lista di tutte le informazioni disponibili per l oggetto La schermata informazioni deve visualizzare le informazioni riguardanti l oggetto scelto. RF4.2.36 SRF4.2.35 RF4.2.36 Riproduzione contenuti multimediali La schermata informazioni deve prevedere la riproduzione di contenuti multimediali ove presenti. RF4.2.37 SRF4.2.36 Pagina 29 di 69
RF4.2.37 Modi di fruizione delle informazioni La riproduzione di contenuti multimediali deve prevedere la possibilità di essere interrotta, ripresa dal punto di interruzione, ripresa da un punto precedente, ripresa da un punto successivo, ricominciata dall'inizio o terminata. SRF4.2.37 RF4.2.38 Lingua delle informazioni Tutte le informazioni ed le voci di menu devono essere localizzate nella lingua prescelta. SRF4.2.38 RF4.2.39 L utente deve poter scegliere solo le informazioni di suo interesse Sarà l utente a decidere quali e quante informazioni dovrà ricevere dal sistema in modo da non riceverne di superflue SRF4.2.39 RF4.2.40 L utente deve poter scegliere quale oggetto osservare L utente deve essere libero di muoversi all interno del museo come preferisce, senza avere la costrizione della visita guidata SRF4.2.40 Pagina 30 di 69
RF4.2.41 Informazioni sull autonomia residua Deve essere possibile visualizzare informazioni riguardanti l'autonomia rimanente del dispositivo portatile SRF4.2.41 RF4.2.42 Tempo rimanente per completare la ricarica Deve essere possibile visualizzare il tempo rimanente per l avvenuta ricarica. SRF4.2.42 RF4.2.43 Segnalazione avvenuta ricarica Deve essere segnalata l avvenuta ricarica. SRF4.2.43 RF4.2.44 Visualizzazione da remoto posizione dispositivi Deve essere possibile visualizzare da remoto la posizione all interno del museo di tutti i dispositivi portatili SRF4.2.44 Pagina 31 di 69
5 dei requisiti non funzionali I requisiti non funzionali definiscono proprietà e vincoli come affidabilità, robustezza, usabilità, vincoli temporali, di memoria e di qualità. L analisi dei requisiti non funzionali porta normalmente alla loro suddivisione in classi. Presentiamo di seguito quella adottata in questo documento per la nostra disamina, ispirata in parte al modello FURPS+ sviluppato dalla HewlettPackard. Requisiti di Usabilità: si riferiscono a tutti gli aspetti riguardanti la semplicità d uso, la facilità per l utente di imparare ad usare il sistema, capirne il funzionamento oltre a riguardare l ergonomia del sistema nel suo complesso; Requisiti di Prestazioni: insieme di vincoli riguardanti la possibilità del sistema di mantenere il relativo livello di prestazione nei termini dichiarati per un periodo di tempo dichiarato; Requisiti di Affidabilità: visualizzano le capacità di un sistema o di una sua componente di fornire la funzione richiesta sotto certe condizione, mettendo in atto dei meccanismi di prevenzione degli errori; Requisiti di Rilascio: descrivono il modo in cui il sistema deve essere rilasciato al cliente, imponendo vincoli sulle modalità di installazione, di manutenzione e di accesso al sistema; Requisiti di Standard: mettono in luce la necessità di adeguarsi a procedure o normative standard per il sistema, l azienda o per il settore applicativo. Tutti questi requisiti sono stati introdotti per adempiere a quanto prescritto dalla normativa ISO 9126 per la valutazione della qualità del software. I requisiti non funzionali vengono inoltre classificati con la seguente suddivisione: 1. Requisiti di Prodotto 2. Requisiti di Processo 3. Requisiti Esterni Rimandiamo ai paragrafi seguenti la loro descrizione e l esposizione degli stessi, mediante lo schema sotto riportato. Breve stringa che identifica il requisito. del requisito. Motivo della scelta del requisito. Tipo del tipo di requisito. dei requisiti correlati a questo. Pagina 32 di 69