Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti
Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4 2 - ACTORS... 5 2.1 - ACQUIRENTI...5 2.2 - VENDITORI...5 2.3 - AMMINISTRATORI DEL SISTEMA...5 2.4 - DIAGRAMMA DEI CASI D USO...6 3 - REQUISITI FUNZIONALI... 7 3.1 - ISCRIZIONE...7 3.2 - AUTENTICAZIONE...7 3.3 - MODIFICA DEI DATI...8 3.3.1 - Modifica dei dati anagrafici...8 3.3.2 - Modifica dei dati account...8 3.4 - RICERCA OGGETTI...8 3.4.1 - Ricerca per parola chiave...9 3.4.2 - Ricerca per categoria...9 3.4.3 - Ricerca per numero d oggetto...9 3.4.4 - Ricerca per venditore...9 3.4.5 - Ricerca per offerente...9 3.5 - RICERCA UTENTI...9 3.6 - ACQUISTO DI UN OGGETTO... 10 3.6.1 - Partecipazione all asta... 10 3.6.2 - Annullamento dell offerta... 10 3.6.2 - Aggiudicazione dell oggetto... 10 3.6.3 - Perdita dell oggetto... 10 3.6.4 - Compralo subito... 10 3.7 - VENDITA DI UN OGGETTO... 11 3.7.1 - Inserimento di un oggetto... 11 3.7.2 - Oggetto venduto... 11 3.7.3 - Oggetto non venduto... 11 3.7.4 - Annullamento asta... 11 3.7.5 - Invio del pagamento... 12 3.7.6 - Pagamento ricevuto... 12 3.7.7 - Oggetto spedito... 12 3.8 - INSERIMENTO COMMENTO DI FEEDBACK... 12 3.9 - COMUNICAZIONE TRA UTENTI... 13 3.10 - AMMINISTRAZIONE... 13 3.10.1 - Avvio server... 13 3.10.2 - Arresto server... 13 3.10.3 - Sospensione utente... 13 3.10.4 - Cancellazione utente... 14 3.10.5 - Cancellazione oggetto... 14 Pagina 2 di 16 Analisi dei Requisiti
4 - REQUISITI NON FUNZIONALI... 15 4.1 REQUISITI DEL PRODOTTO... 15 4.1.1 Usabilità... 15 4.1.2 Efficienza... 15 4.1.3 Affidabilità... 15 4.1.4 Portabilità... 15 4.2 REQUISITI ORGANIZZATIVI... 15 4.2.1 Consegna... 15 4.2.2 Standard ed implementazione... 15 4.3 REQUISITI ESTERNI... 16 4.3.1 Privacy e sicurezza... 16 4.3.2 - Norme legali... 16 Pagina 3 di 16 Analisi dei Requisiti
1 - Introduzione 1.1 - Obiettivo del documento Nell analisi del dominio erano state individuate tutte le specifiche relative alle gestioni dei servizi che il nostro sistema dovrà essere in grado di sviluppare. Ora ci occuperemo di descrivere le funzionalità relative ad ogni singola gestione. 1.2 - Struttura del documento Il presente documento è così strutturato: 1. Introduzione: definisce gli obiettivi del documento in questione e ne riporta i riferimenti e la storia. 2. s: definisce gli attori del sistema e ne delinea i casi d uso per ognuno di loro. 3. Requisiti funzionali: contiene la specifica di tutti i requisiti funzionali del sistema in realizzazione. 4. Requisiti non funzionali: contiene tutti i requisiti non funzionali al quale il prodotto software deve obbedire. 1.3 - Riferimenti Analisi del Dominio Manuale della Qualità Norme di Progetto 1.4 - Storia del documento Versione attuale: 1.1 Redazione del documento Autore Data Versione Firma Cannioto Fabio 24/11/2005 1.0 Rosalia Giulio Giuseppe * 05/01/2006 1.1 Approvazione del documento Autore Data Versione Firma Rosalia Giulio Giuseppe 25/11/2005 1.0 Foti Mauro 25/11/2005 1.0 Cannioto Fabio 06/01/2005 1.1 * Modificato il paragrafo 3.7.1 e aggiunti i paragrafi 3.7.5, 3.7.6 e 3.7.7 Pagina 4 di 16 Analisi dei Requisiti
2 - s Gli actors interagiscono con il sistema per ottenere servizi o funzioni. Dai requisiti utente si evince che gli actors relativi all applicazione che si sta sviluppando sono: Acquirenti Venditori Personale Amministrativo 2.1 - Acquirenti La loro interazione con il sistema riguarderà principalmente l acquisto on-line, l interrogazione al sistema per ricercare oggetti ed eventualmente la partecipazione alle aste. Per chi non e registrato e possibile diventare acquirente con una iscrizione on-line. Per avere accesso al sistema gli acquirenti avranno una user-id ed una password. Per semplificare la visione dell uso di un applicazione, l OMG (Object Management Group) ha introdotto nel linguaggio di definizione dei modelli UML i diagrammi dei casi d uso, speciali diagrammi dove vengono rappresentati gli attori di un sistema e i casi d uso del sistema correlati ad ogni attore. Il diagramma dei casi d uso relativo alla figura dell acquirente è presente, all interno dell analisi dei requisiti, presso il relativo capitolo (cfr. 2.4). 2.2 - Venditori Il venditore possiede tutte le caratteristiche dell acquirente ma in più ha la facoltà di vendita. Le interazioni con il sistema riguardano la possibilità di introdurre oggetti all interno del sistema. Il diagramma dei casi d uso relativo al venditore è un estensione del diagramma dei casi d uso dell acquirente, nel quale l unico caso d uso aggiunto è quello relativo all inserimento di un oggetto (cfr. 2.4). 2.3 - Amministratori del sistema L amministratore del sistema ha il compito di avviare ed arrestare il servizio (avviando o arrestando il server) in caso di necessità, di gestire il sistema comunicando con l utenza o eventualmente sospendendo o cancellando alcuni di loro. L amministratore del sistema può inoltre cancellare alcuni oggetti in vendita se le inserzioni non rispettano le regole per l inserimento di un oggetto. L amministratore del sistema è l unico attore che opera in un ambito differente rispetto agli altri: infatti se l acquirente e il venditore operano dallo stesso lato del sistema, ovvero il lato client, l amministratore è l unico attore che opera dal lato server, poiché è l unico che ha la facoltà e la necessità di operare direttamente sul sistema per gestirlo e amministrarlo senza via indirette. I casi d uso di un amministratore sono limitati rispetto a quelli degli altri due attori principali del sistema (cfr. 2.4). Pagina 5 di 16 Analisi dei Requisiti
2.4 - Diagramma dei casi d uso Pagina 6 di 16 Analisi dei Requisiti
3 - Requisiti funzionali Una volta individuati tutti i casi d uso del sistema, si procede alla compilazione dei requisiti funzionali. Il ruolo dei requisiti funzionali è quello di specificare le funzionalità che il sistema che si sta sviluppando dovrà essere in grado di effettuare. Di seguito saranno elencate le funzionalità previste, analizzando, per ogni caso d uso, l attore, i dati in input e i dati in output. 3.1 - Iscrizione L iscrizione al sistema è l unica funzionalità visibile solo agli utenti che accedono al sistema per la prima volta e non possiedono ancora un account. Gli ultimi due campi permetteranno al cliente on-line di poter essere autenticato all interno del sistema. Nella fase di scelta dello user-id il sistema provvederà a verificare che non ne esista già un altro uguale. Utente non registrato Nome Cognome Indirizzo Città di residenza Provincia di residenza CAP Telefono principale Data di nascita Città di nascita Provincia di nascita Sesso Codice fiscale Indirizzo e-mail User-id Password 3.2 - Autenticazione L autenticazione è l operazione necessaria a qualunque utente per accedere al sistema. L acquirente e il venditore effettueranno l autenticazione tramite il modulo client mentre l amministratore effettuerà l autenticazione al modulo server. I dati in input sono uguali per ogni utenza e sarà possibile operare su qualunque funzione del sistema solo dopo l autenticazione., Venditore, Amministratore User-id Password Pagina 7 di 16 Analisi dei Requisiti
3.3 - Modifica dei dati In questa fase ogni utente può cambiare i propri dati anagrafici o i propri dati relativi all account. L acquirente e il venditore possono modificare sia i dati anagrafici che i dati account, mentre l amministratore, non avendo memorizzati sul sistema i propri dati anagrafici, avrà la possibilità di modificare solamente i propri dati relativi all account. Tutte le operazioni di modifica dei dati richiedono l autenticazione dell utente al sistema (cfr. 3.2). 3.3.1 - Modifica dei dati anagrafici, Venditore Nome Cognome Indirizzo Città di residenza Provincia di residenza CAP Telefono principale Data di nascita Città di nascita Provincia di nascita Sesso Codice fiscale 3.3.2 - Modifica dei dati account, Venditore, Amministratore Indirizzo e-mail User-id Password 3.4 - Ricerca oggetti Un acquirente avrà la possibilità di ricercare all interno del sistema uno o più oggetti secondo differenti modalità. La ricerca tornerà in output una lista degli oggetti corrispondenti ai criteri di ricerca utilizzati. Ogni oggetto della lista sarà composto dai seguenti dati: formato di vendita; categoria; titolo; descrizione; foto; durata dell'inserzione. Tutte le modalità di ricerca, tranne la ricerca per numero d oggetto, sono combinabili, cioè è possibile ricercare un oggetto immettendo più vincoli in input e ottenendo un risultato più ristretto e più adatto alle esigenze di ricerca. Le operazioni di ricerca vedono la sola presenza come actor dell acquirente poiché il venditore eredita dall acquirente questa funzionalità. Tutte le operazioni di ricerca richiedono l autenticazione dell utente al sistema (cfr. 3.2). Pagina 8 di 16 Analisi dei Requisiti
3.4.1 - Ricerca per parola chiave Parola o parole chiave Lista degli oggetti risultanti dalla ricerca 3.4.2 - Ricerca per categoria Categoria di oggetti Lista degli oggetti risultanti dalla ricerca 3.4.3 - Ricerca per numero d oggetto : : : Numero identificativo dell oggetto Descrizione dell oggetto 3.4.4 - Ricerca per venditore : : : User-id Lista degli oggetti risultanti dalla ricerca 3.4.5 - Ricerca per offerente User-id Lista degli oggetti risultanti dalla ricerca 3.5 - Ricerca utenti Tramite questa funzionalità è possibile visualizzare le informazioni di contatto di ogni utente del sistema. E necessario inserire un user-id di un utente e la ricerca restituirà, se l user-id immesso è valido, il profilo dell utente, con informazioni sui feedback e un collegamento al modulo per la comunicazione con l utente ricercato (cfr. 3.9). La ricerca utenti è eseguibile solo previa autenticazione (cfr. 3.2). Il venditore eredita dall acquirente questa funzionalità. User-id Profilo di feedback Pagina 9 di 16 Analisi dei Requisiti
3.6 - Acquisto di un oggetto In questa funzionalità l acquirente potrà concorrere all acquisto di un oggetto in due differenti maniere: immettendo un offerta a partire da una base d asta o comprando direttamente un oggetto ad un prezzo fisso. Per quanto riguarda la partecipazione all asta, l acquirente potrà aggiudicarsi o perdere l oggetto. In entrambi i casi riceverà una notifica del termine dell asta e il relativo esito. E possibile acquistare oggetti solo se autenticati al sistema (cfr. 3.2). Il venditore eredita dall acquirente questa funzionalità. 3.6.1 - Partecipazione all asta Offerta 3.6.2 - Annullamento dell offerta Ricordiamo che un acquirente può annullare un offerta già effettuata solo in due casi: Se ha commesso un errore, inserendo l'importo sbagliato; Non è possibile contattare il venditore. Numero identificativo dell oggetto Notifica al venditore dell oggetto 3.6.2 - Aggiudicazione dell oggetto Messaggio di notifica 3.6.3 - Perdita dell oggetto Messaggio di notifica 3.6.4 - Compralo subito In questa modalità il prezzo è fisso e l acquirente si aggiudica l oggetto senza inserire l offerta. Messaggio di notifica Pagina 10 di 16 Analisi dei Requisiti
3.7 - Vendita di un oggetto Ogni venditore ha la possibilità di inserire un nuovo oggetto nel sistema per promuoverne la vendita. All inserimento il venditore dovrà selezionare il formato di vendita (Asta o Compralo Subito) e immettere alcuni dati identificativi dell oggetto. Una volta inserita, l asta può essere cancellata solo dal venditore stesso o dall amministratore del sistema (cfr. 3.10.5). Ogni operazione sull inserimento di un oggetto e sulle funzionalità susseguenti necessita di un autenticazione preventiva (cfr. 3.2). 3.7.1 - Inserimento di un oggetto Venditore Formato di vendita Prima categoria di appartenenza Seconda categoria di appartenenza Titolo Descrizione Foto Durata dell'inserzione Prezzo di partenza Prezzo Compralo Subito Luogo in cui si trova l oggetto 3.7.2 - Oggetto venduto Venditore Messaggio di notifica User-id acquirente 3.7.3 - Oggetto non venduto Venditore Messaggio di notifica 3.7.4 - Annullamento asta Venditore Numero identificativo dell oggetto Messaggio di notifica a tutti gli offerenti e agli amministratori Pagina 11 di 16 Analisi dei Requisiti
3.7.5 - Invio del pagamento Messaggio di notifica al venditore 3.7.6 - Pagamento ricevuto Venditore Messaggio di notifica all acquirente 3.7.7 - Oggetto spedito Venditore Messaggio di notifica all acquirente 3.8 - Inserimento commento di feedback Al termine della vendita di ogni oggetto, sia esso venduto tramite asta o tramite prezzo fisso, sia l acquirente che il venditore dovranno inserire un commento di feedback per giudicare l esito della transazione. Il commento di feedback è inserito da entrambi i tipi di utenza ed ha un valore: 1 se positivo 0 se neutro -1 se negativo Anche la funzione di inserimento feedback, per essere eseguita, necessita dell autenticazione da parte degli utenti (cfr. 3.2)., Venditore Commento Valore (positivo, neutro, negativo) Pagina 12 di 16 Analisi dei Requisiti
3.9 - Comunicazione tra utenti Tra due utenti del sistema (siano essi acquirenti, venditori o amministratori) è possibile scambiare messaggi tramite questa funzionalità. I messaggi possono riguardare un oggetto messo in vendita, oppure possono solo essere comunicazioni da parte dell amministratore verso un utente. Qualsiasi tipo di notifica all interno del sistema verrà comunque effettuata attraverso questa funzionalità. Per poter comunicare con altri utenti è necessaria l autenticazione al sistema (cfr. 3.2)., Venditore, Amministratore User-id Messaggio 3.10 - Amministrazione Le seguenti funzionalità saranno accessibili solamente tramite il modulo server e di conseguenza usufruibili solo dall amministratore. Le funzioni riguardano la sospensione o l eventuale cancellazione di un utente o di un asta, se l inserzione o l utente non rispettano le norme del sistema, oppure la semplice gestione del server con l operazione di avvio e di arresto del server. Ognuna di queste operazioni necessita l autenticazione da parte del personale amministrativo (cfr 3.2). 3.10.1 - Avvio server Amministratore 3.10.2 - Arresto server Amministratore 3.10.3 - Sospensione utente La sospensione di un utente blocca temporaneamente alcune delle operazioni usufruibili dall utente. Se l utente è bloccato, potrà autenticarsi al sistema, comunicare con altri utenti o con gli amministratori del sistema, potrà effettuare ricerche, ma non potrà effettuare offerte, né acquistare e vendere oggetti. Amministratore User-id dell utente Messaggio di notifica all utente Pagina 13 di 16 Analisi dei Requisiti
3.10.4 - Cancellazione utente La cancellazione di un utente consiste nella rimozione definitiva dell account dal sistema. Ciò significa che l utente cancellato non avrà più la possibilità di accedere al sistema e di sfruttarne le funzionalità. Amministratore User-id dell utente E-mail all utente 3.10.5 - Cancellazione oggetto Amministratore Numero identificativo dell oggetto Messaggio di notifica al venditore Pagina 14 di 16 Analisi dei Requisiti
4 - Requisiti non funzionali Lo scopo dell individuazione dei requisiti non funzionali è quello di specificare tutti quei vincoli e quelle dipendenze al quale il software in fase di realizzazione dovrà sottostare. Essi includono requisiti specifici del prodotto, requisiti organizzativi della produzione e eventuali requisiti esterni. 4.1 Requisiti del prodotto 4.1.1 Usabilità Il sistema di autenticazione deve essere semplice, infatti basterà inserire la user-id e la password per accedere e operare sul sistema. L accesso alle varie funzioni deve essere estremamente intuitivo, ciò sarà possibile grazie ad un approccio user-friendly e ad un interfaccia semplice ma allo stesso tempo funzionale. Gran parte delle funzioni saranno accessibili grazie a dei menu. L uso della tastiera deve essere necessario solo per l inserimento di dati alfanumerici, mentre tutto il resto deve essere accessibile sia tramite la tastiera che il mouse. 4.1.2 Efficienza Il tempo medio per l esecuzione di una interrogazione al server da parte del client non deve superare i 3 secondi. Il server deve mantenere un massimo di 30 connessioni attive con i vari client contemporaneamente mantenendo dei tempi di risposta accettabili. Lo spazio in memoria occupato dal server non dovrà superare i 50 megabyte mentre il client non dovrà occupare in memoria una quantità maggiore di 5 megabyte. 4.1.3 Affidabilità Il prodotto deve rispettare gli standard di comportamento in tutte le situazioni normali. È da tener in conto che i tempi di risposta del server alle interrogazioni del client sono soggetti al carico della rete che, in situazioni estreme può compromettere, se non addirittura interrompere, il normale dialogo tra client e server. Inoltre si deve considerare l affidabilità del ambiente in cui il software stesso viene utilizzato. 4.1.4 Portabilità Il prodotto deve essere compatibile con le principali piattaforme disponibili. È in progetto una versione del client per piattaforme portatili (palmari e cellulari). 4.2 Requisiti Organizzativi 4.2.1 Consegna Il prodotto verrà progettato, realizzato e testato nel minor tempo possibile garantendo l ottimo funzionamento dell applicativo. Il prodotto finito dovrà essere consegnato entro e non oltre il 28 Febbraio 2006. 4.2.2 Standard ed implementazione Il prodotto verrà implementato seguendo le regole e le norme di qualità stabilite dall azienda e ufficializzate nel documento manuale della qualità. Gli standard che verranno utilizzati per l implementazione sono riportati nel documento norme di progetto, che specifica le regole per lo sviluppo e l implementazione del progetto. Pagina 15 di 16 Analisi dei Requisiti
4.3 Requisiti Esterni 4.3.1 Privacy e sicurezza La privacy e la sicurezza dei dati confidenziali dei clienti devono essere protetti dal sistema di autenticazione con user-id e password e da precise politiche di sicurezza del server. 4.3.2 - Norme legali Poiché il sistema in realizzazione si occupa della compravendita di beni mobili e immobili, saranno rispettate tutte le norme vigenti della legge italiana e verranno informati gli utenti delle relative limitazioni di vendita e degli oneri e tasse applicabili ai suddetti beni. Pagina 16 di 16 Analisi dei Requisiti