System Requirements Specifications (SRS) MGT MiGiocoTutto

Transcript

1 Nome del Progetto MGT MiGiocoTutto Sito web per la gestione di scommesse sportive on-line Redazione Fulgenzi Alessandro data 05/02/2007 Firma Verifica Cliente data Firma _Ed1Rev3 11/11/ Pag 1 di 27

2 INDICE 1. INTRODUZIONE OBIETTIVO IDENTIFICATIVO DEL DOCUMENTO DOCUMENTI DI RIFERIMENTO DEFINIZIONI ED ACRONIMI REQUISITI REQUISITI FUNZIONALI REQUISITI NON FUNZIONALI SPECIFICHE DEI REQUISITI REQUISITI FUNZIONALI REQ_01_FUN_ REQ_01_FUN_ REQ_01_FUN_ REQ_02_FUN_ REQ_02_FUN_ REQ_03_FUN_ REQ_03_FUN_ REQ_04_FUN_ REQ_04_FUN_ REQ_04_FUN_ REQ_05_FUN_ REQ_05_FUN_ REQ_06_FUN_ REQ_06_FUN_ REQ_06_FUN_ REQ_06_FUN_ REQ_07_FUN_ REQ_07_FUN_ REQ_07_FUN_ REQ_07_FUN_ REQ_07_FUN_ REQ_07_FUN_ REQ_07_FUN_ REQ_08_FUN_ REQ_08_FUN_ REQUISITI DI PORTABILITÀ REQ_01_POR_ REQUISITI DI SICUREZZA REQ_01_SEC_ REQ_02_SEC_ REQ_03_SEC_ _Ed1Rev3 11/11/ Pag 2 di 27

3 3.4 REQUISITI DI PRESTAZIONI REQ_01_PRE_ REQ_02_PRE_ REQ_03_PRE_ CASI D USO UC_00 - SCHEMA GENERALE DEL SISTEMA Diagramma dei casi d uso UC_01 - GESTIONE ACCOUNT PERSONALE Diagramma dei casi d uso UC_02 - GESTIONE STORICO EVENTI Diagramma dei casi d uso UC_03 - GESTIONE PORTAFOGLIO Diagramma dei casi d uso UC_04 - GESTIONE SCOMMESSE Diagramma dei casi d uso UC_05 - GESTIONE EVENTI Diagramma dei casi d uso UC_06 - GESTIONE BOOKMAKER Diagramma dei casi d uso UC_08 - GESTIONE AMMINISTRATORI Diagramma dei casi d uso MATRICE DI TRACCIABILITÀ _Ed1Rev3 11/11/ Pag 3 di 27

4 1. INTRODUZIONE 1.1 Obiettivo Questo documento ha come obiettivo la descrizione formale dei requisiti utente. 1.2 Identificativo del documento Il documento in oggetto è denominato (_ed1rev3). 1.3 Documenti di riferimento Rxx = Documenti di Riferimento Cxx = Documenti Correlati [R01] Glossario (MGT_01_GLO_ed1rev1). 1.4 Definizioni ed acronimi Ogni requisito avrà il seguente identificativo : REQ_<progressivo a due cifre>_<tipologia di requisito>_<progressivo a quattro cifre> - Il progressivo a due cifre rappresenta un raggruppamento per macro-requisito (es. Gestione dati utente). - Il secondo progressivo a quattro cifre scorre i requisiti all interno del macro-requisito (es. Gestione dati utente registrazione, ecc..) La tipologia di requisito consente di distinguere i requisiti in base alla loro area di appartenenza. Di seguito viene riportata la tabella di identificazione delle tipologie di requisito : Acronimo FUN POR SEC Funzionale Portabilità Sicurezza _Ed1Rev3 11/11/ Pag 4 di 27

5 PRE Prestazioni Tabella 1.1 Tipologie di requisito Ad ogni requisito sarà associato uno stato in base alla seguente tabella : Acronimo Note PRO Proposto Requisito da sottoporre all approvazione del cliente ACC Accettato Requisito accettato dal cliente SCA Scartato Requisito scartato dal cliente Tabella 1.2 Stati di un requisito Per quanto non specificato, fare riferimento al documento [R01]. _Ed1Rev3 11/11/ Pag 5 di 27

6 2. REQUISITI In questo capitolo sono sintetizzati tutti i requisiti in modo da averne una visione globale. Gli stessi saranno successivamente dettagliati nel capitolo successivo. 2.1 Requisiti funzionali Segue la lista di tutti i requisiti funzionali relativi al progetto. Requisiti Funzionali ID Nome Stato REQ_01_FUN_001 Gestione dati utente - Registrazione PRO REQ_01_FUN_002 Gestione dati utente Modifica dati PRO REQ_01_FUN_003 Gestione dati utente Modifica modalità pagamento PRO REQ_02_FUN_001 Gestione eventi Categorizzazione eventi PRO REQ_02_FUN_002 Gestione eventi Inserimento eventi PRO REQ_03_FUN_001 Gestione esiti Categorizzazione esiti PRO REQ_03_FUN_002 Gestione esiti Inserimento nuovi esiti PRO REQ_04_FUN_001 Gestione quotazioni Inserimento quotazioni PRO REQ_04_FUN_002 Gestione quotazioni Presenza quotazioni (1) PRO REQ_04_FUN_003 Gestione quotazioni Presenza quotazioni (2) PRO REQ_05_FUN_001 Gestione storico Archiviazione dati storici PRO REQ_05_FUN_002 Gestione storico Consultazione PRO REQ_06_FUN_001 Gestione Scommesse - Inserimento scommessa PRO REQ_06_FUN_002 Gestione Scommesse Composizione scommesse PRO REQ_06_FUN_003 Gestione Scommesse Accettazione puntata PRO REQ_06_FUN_004 Gestione Scommesse Registrazione in corso PRO REQ_07_FUN_001 Admin Inserimento bookbaker PRO REQ_07_FUN_002 Admin Rimozione bookmaker PRO REQ_07_FUN_003 Admin Abilitazione / disabilitazione bookbaker PRO REQ_07_FUN_004 Admin Inserimento amministratori PRO REQ_07_FUN_005 Admin Rimozione amministratori PRO REQ_07_FUN_006 Admin Esistenza super-amministratore PRO REQ_07_FUN_007 Admin Abilitazione/disabilitazione amministratori PRO REQ_08_FUN_001 Portafoglio Creazione portafoglio giocatori PRO REQ_08_FUN_002 Portafoglio Scadenza pagamenti PRO Tabella 2.1 Tabella dei Requisiti Funzionali _Ed1Rev3 11/11/ Pag 6 di 27

7 2.2 Requisiti non funzionali Segue la lista di tutti i requisiti non funzionali relativi al progetto. Requisiti di Portabilità ID Nome Stato REQ_01_POR_001 Browser web PRO Requisiti di Sicurezza ID Nome Stato REQ_01_SEC_001 Accessibilità PRO REQ_02_SEC_001 Comunicazione compagnie gestione credito PRO REQ_03_SEC_001 Connessione bookmaker PRO Requisiti di Prestazioni ID Nome Stato REQ_01_PRE_001 Numero connessioni PRO REQ_02_PRE_001 Popolazione giocatori PRO REQ_03_PRE_001 Accessibilità PRO Tabella 2.2 Tabella dei Requisiti non Funzionali _Ed1Rev3 11/11/ Pag 7 di 27

8 3. SPECIFICHE DEI REQUISITI In questo capitolo sono esposti nel dettaglio i requisiti. 3.1 Requisiti Funzionali Seguono i requisiti di carattere funzionale, ovvero le funzionalità che dovranno essere implementate per soddisfare le esigenze del cliente REQ_01_FUN_001 REQ_01_FUN_001 Gestione dati utente - Registrazione Proposto Ogni utente, per poter accedere al sito dovrà essere registrato. Pertanto dovrà essere disponibile la funzionalità di registrazione con la richiesta da parte del sistema di tutti i dati necessari per identificare l utente e per effettuare analisi statistiche. Dovranno essere gestiti almeno i seguenti dati : Utente Password Data registrazione REQ_01_FUN_002 REQ_01_FUN_002 Gestione dati utente Modifica dati Proposto Ogni utente potrà modificare in ogni momento i propri dati (compresi utente e password). _Ed1Rev3 11/11/ Pag 8 di 27

9 3.1.3 REQ_01_FUN_003 REQ_01_FUN_003 Gestione dati utente Modifica modalità pagamento Proposto Ogni utente potrà modificare in ogni momento la modalità di pagamento prescelta REQ_02_FUN_001 REQ_02_FUN_001 Gestione eventi Categorizzazione eventi Proposto Gli eventi saranno divisi per tipologie (partita di calcio, gara automobilistica, ecc). Gli eventi sono raggruppati secondo diverse categorie e sottocategorie (ad esempio Calcio, Automobilismo, Ciclismo, Hockey su ghiaccio etc. come macrocategorie, Tornei internazionali di Club e di Nazionali, Campionati nazionali, Coppe nazionali etc. come sottocategorie per il Calcio) REQ_02_FUN_002 REQ_02_FUN_002 Gestione eventi Inserimento eventi Proposto I bookmaker provvederanno all inserimento di nuovi eventi su cui scommettere REQ_03_FUN_001 REQ_03_FUN_001 Gestione esiti Categorizzazione esiti Proposto _Ed1Rev3 11/11/ Pag 9 di 27

10 Lo stesso evento può essere caratterizzato da diversi tipi di esito, ad esempio, per una partita di calcio (scelta 1X2, scelta 1X2 primo tempo, scelta punteggio primo tempo, scelta punteggio finale, scelta realizzatore primo gol, etc.). Gli esiti sono caratterizzabili (es. risultati sintetici, punteggi, giocatori, minutaggio etc., per una partita di calcio, vincitore, piazzamenti, numero ritirati, giro a cui il vincitore si è portato in testa etc., per una gara automobilistica) REQ_03_FUN_002 REQ_03_FUN_002 Gestione esiti Inserimento nuovi esiti Proposto I bookmaker potranno definire nuove tipologie di esito per una data tipologia di evento REQ_04_FUN_001 REQ_04_FUN_001 Gestione quotazioni Inserimento quotazioni Proposto Le quotazioni saranno inserite dai bookmaker, sulla base della categorizzazione degli eventi, e degli esiti REQ_04_FUN_002 REQ_04_FUN_002 Gestione quotazioni Presenza quotazioni Proposto Non tutti gli esiti di un evento avranno associata una quotazione. _Ed1Rev3 11/11/ Pag 10 di 27

11 REQ_04_FUN_003 REQ_04_FUN_003 Gestione quotazioni Presenza quotazioni (2) Proposto Il sistema prende in considerazione solo gli esiti per cui sono state fissate delle quote REQ_05_FUN_001 REQ_05_FUN_001 Gestione storico Archiviazione dati storici Proposto Il sistema deve mantenere uno storico di tutti gli esiti su cui ha proposto scommesse e delle quote relative negli ultimi due anni REQ_05_FUN_002 REQ_05_FUN_002 Gestione storico Consultazione Proposto Lo storico deve essere interrogabile dai giocatori in modo tale da presentare informazioni organizzate su richiesta, in relazione all esito scelto (ad esempio, selezionando Roma-Milan si avrà accesso ai dati storici sui precedenti per questa partita e per le due squadre) REQ_06_FUN_001 REQ_06_FUN_001 Gestione Scommesse - Inserimento scommessa Proposto Un giocatore potrà eseguire le scommesse tramite selezione della categoria, dell evento, dell esito, e della puntata per ogni scommessa da effettuare. _Ed1Rev3 11/11/ Pag 11 di 27

12 REQ_06_FUN_002 REQ_06_FUN_002 Gestione Scommesse Composizione scommesse Proposto Il sistema deve consentire la composizione di diverse scommesse su eventi diversi, richiedendo un unica conferma complessiva REQ_06_FUN_003 REQ_06_FUN_003 Gestione Scommesse Accettazione puntata Proposto Il sistema accetterà le puntate solo da parte di utenti registrati REQ_06_FUN_004 REQ_06_FUN_004 Gestione Scommesse Registrazione in corso Proposto Un utente non registrato, potrà registrarsi al momento della prima scommessa REQ_07_FUN_001 REQ_07_FUN_001 Admin Inserimento bookbaker Proposto _Ed1Rev3 11/11/ Pag 12 di 27

13 Gli amministratori di sistema potranno inserire nuovi bookmaker REQ_07_FUN_002 REQ_07_FUN_002 Admin Rimozione bookmaker Proposto Gli amministratori di sistema potranno rimuovere bookmaker esistenti REQ_07_FUN_003 REQ_07_FUN_003 Admin Abilitazione / disabilitazione bookbaker Proposto Gli amministratori di sistema potranno abilitare/disabilitare i bookmaker a fissare quote per eventi di un determinato tipo sulla base delle categorie e sottocategorie esistenti REQ_07_FUN_004 REQ_07_FUN_004 Admin Inserimento amministratori Proposto Gli amministratori di sistema abilitati (super-amministratori) potranno creare nuovi amministratori di sistema REQ_07_FUN_005 _Ed1Rev3 11/11/ Pag 13 di 27

14 REQ_07_FUN_005 Admin Rimozione amministratori Proposto Gli amministratori di sistema abilitati (super-amministratori) potranno rimuovere altri amministratori di sistema REQ_07_FUN_006 REQ_07_FUN_006 Admin Esistenza super-amministratore Proposto Deve esistere sempre almeno un super-amministratore REQ_07_FUN_007 REQ_07_FUN_007 Admin Abilitazione/disabilitazione amministratori Proposto I super-amministratori potranno abilitare/disabilitare altri amministratori ad essere superamministratori REQ_08_FUN_001 REQ_08_FUN_001 Portafoglio Creazione portafoglio giocatori Proposto Il sistema dovrà mantenere un portafoglio per ogni giocatore registrato e provvedere all incasso o al versamento delle vincite e perdite alla scadenza. _Ed1Rev3 11/11/ Pag 14 di 27

15 REQ_08_FUN_002 REQ_08_FUN_002 Portafoglio Scadenza pagamenti Proposto I pagamenti da e verso i giocatori possono essere effettuati per ogni scommessa, o su base giornaliera, settimanale, o mensile, secondo le scelte del giocatore, non modificabili prima della scadenza del periodo corrente. 3.2 Requisiti di Portabilità Seguono i requisito relativi alla portabilità del prodotto, ovvero i requisiti che garantiscono il funzionamento del sistema sulle diverse piattaforme REQ_01_POR_001 REQ_01_POR_001 Browser web Proposto Gli utenti esterni accederanno al sistema usando un browser Web. Sarà garantito l accesso da : Internet Explorer 5 Netscape 6 Firefox Requisiti di Sicurezza REQ_01_SEC_001 _Ed1Rev3 11/11/ Pag 15 di 27

16 REQ_01_SEC_001 Accessibilità Proposto Il sistema dovrà essere accessibile esclusivamente in seguito ad autenticazione dell utente tramite UTENTE e PASSWORD REQ_02_SEC_001 REQ_02_SEC_001 Comunicazione compagnie gestione credito Proposto Il sistema dovrà comunicare con le diverse compagnie coinvolte nelle forme di pagamento prescelte, utilizzando canali sicuri (protocollo https) REQ_03_SEC_001 REQ_03_SEC_001 Connessione bookmaker Proposto I bookmaker accederanno al sistema secondo modalità sicure. 3.4 Requisiti di Prestazioni REQ_01_PRE_001 REQ_01_PRE_001 Numero connessioni Proposto _Ed1Rev3 11/11/ Pag 16 di 27

17 Il sistema deve supportare un carico di 1000 connessioni al secondo, di cui 100 da parte di bookmaker REQ_02_PRE_001 REQ_02_PRE_001 Popolazione giocatori Proposto La popolazione di giocatori gestita dovrà essere di almeno REQ_03_PRE_001 REQ_03_PRE_001 Accessibilità Proposto Il sistema deve essere in funzione 24/24h e 7/7g _Ed1Rev3 11/11/ Pag 17 di 27

18 4. CASI D USO I casi d uso nascono come rappresentazione dei requisiti espressi dal cliente e formalizzati nel documento [R02]. Esprimono in formato grafico quanto già specificato formalmente nel precedente documento. Nomenclatura Ad ogni caso d uso sarà assegnato un identificativo. Il diagramma dei casi d uso che rappresenta l intero sistema sarà denominato UC_00. Ai casi d uso direttamente contenuti dell UC_00 (diagramma principale), ovvero ai casi d uso principali sarà assegnato un progressivo secondo la seguente modalità : UC_<progressivo a due cifre> Talvolta tali casi d uso saranno troppo generici e saranno ulteriormente dettagliati, dando luogo a casi d uso secondari, il cui identificativo sarà il seguente : <identificativo padre>_<progressivo a due cifre> Ad esempio si potrà avere il caso d uso UC_01 che avrà come figli UC_01_01, UC_01_02, ecc Qualora anche UC_01_01 abbia figli, questi saranno denominati UC_01_01_01, UC_01_01_02, ecc. In questo modo si potrà tenere traccia della gerarchia che lega tutti i casi d uso. _Ed1Rev3 11/11/ Pag 18 di 27

19 4.1 UC_00 - Schema generale del sistema Questa sezione contiene la rappresentazione grafica dei casi d uso tramite diagrammi UML. I singoli casi d uso contenuti nei diagrammi saranno dettagliati nella sezione relativa alle specifiche Diagramma dei casi d uso Il seguente rappresenta un primo diagramma ad alto livello dei requisiti generali del sistema. Tale diagramma sarà raffinato in seguito, ovvero ogni diagramma sarà ulteriormente sviluppato nelle sezioni successive. _Ed1Rev3 11/11/ Pag 19 di 27

20 4.2 UC_01 - Gestione account personale Questo caso d uso modella la variazione dei dati personali e della modalità di pagamento prescelta da parte dell utente. E ulteriormente suddiviso nei seguenti casi d uso : - UC_01_01 Registrazione utente - UC_01_02 Modifica dati utente - UC_01_03 Modifica modalità di pagamento - UC_01_04 - Login Diagramma dei casi d uso _Ed1Rev3 11/11/ Pag 20 di 27

21 4.3 UC_02 - Gestione storico eventi Questo caso d uso modella la gestione dell archiviazione degli eventi e della visualizzazione dello storico degli esiti su richiesta dell utente. E ulteriormente suddiviso nei seguenti casi d uso : - UC_02_01 Consultazione storico evento - UC_02_02 Consultazione storico partecipante - UC_02_03 Archiviazione dati storici Diagramma dei casi d uso _Ed1Rev3 11/11/ Pag 21 di 27

22 4.4 UC_03 - Gestione portafoglio Questo caso d uso modella la gestione del portafoglio dell utente E ulteriormente suddiviso nei seguenti casi d uso : - UC_03_01 Versamento utente - UC_03_02 Prelievo utente - UC_03_03 Versamento sistema - UC_03_04 Prelievo sistema (richiesta) - UC_03_05 Prelievo utente (esecuzione) Diagramma dei casi d uso _Ed1Rev3 11/11/ Pag 22 di 27

23 4.5 UC_04 - Gestione scommesse Questo caso d uso modella la gestione delle scommesse eseguite dall utente E ulteriormente suddiviso nei seguenti d uso : - UC_04_01 Impostazione scommessa - UC_04_02 Aggiunta evento - UC_04_03 Selezione esito evento - UC_04_04 Esecuzione scommessa - UC_04_05 Pagamento scommesse - UC_04_06 Elimina scommessa evento Diagramma dei casi d uso _Ed1Rev3 11/11/ Pag 23 di 27

24 4.6 UC_05 - Gestione eventi Questo caso d uso modella la gestione degli eventi (fare riferimento al documenti []) da parte di un bookmaker. E ulteriormente suddiviso nei seguenti casi d uso : - UC_05_01 Nuova tipologia di esito - UC_05_02 Nuovo evento - UC_05_03 Nuova quotazione - UC_05_04 Impostazione esito evento - UC_05_05 Selezione evento Diagramma dei casi d uso _Ed1Rev3 11/11/ Pag 24 di 27

25 4.7 UC_06 - Gestione bookmaker Questo caso d uso modella la gestione di Bookmaker (utenti autorizzati ad inserire quotazioni, eventi, esiti, ecc) da parte di un amministratore. E ulteriormente suddiviso nei seguenti casi d uso : - UC_06_01 Aggiungi bookmaker - UC_06_02 Rimuovi bookmaker - UC_06_03 Imposta abilitazione per categoria evento Diagramma dei casi d uso _Ed1Rev3 11/11/ Pag 25 di 27

26 4.8 UC_08 - Gestione amministratori Questo caso d uso modella l aggiunta e rimozione di amministratori da parte di altri amministratori. L operazione di rimozione è riservata ai Super Amministratori, ovvero amministratori ai quali sono riservati poteri speciali. E ulteriormente suddiviso nei seguenti casi d uso : - UC_08_01 Aggiungi amministratore - UC_01_02 Rimuovi amministratore Diagramma dei casi d uso _Ed1Rev3 11/11/ Pag 26 di 27

27 5. MATRICE DI TRACCIABILITÀ La matrice di tracciabilità consente di verificare che tutti i requisiti sono stati trattati da almeno un caso d uso. Poiché i casi d uso descrivono l aspetto funzionale del sistema, la matrice di tracciabilità contemplerà soltanto questa tipologia di requisiti. Requisiti (funzionali) Macro req Micro req UC_01 x x x x UC_02 x x Casi d'uso UC_03 UC_04 x x x x x UC_05 x x x x x x x x x UC_06 x x x UC_08 x x x x _Ed1Rev3 11/11/ Pag 27 di 27