Task1 DocAnalisiSpecificaRequisiti

Task 1 Documento di Analisi e Specifica dei Requisiti
UNIVERSITÀ CA’ FOSCARI DI VENEZIA

DIPARTIMENTO DI INFORMATICA
AA 2008-2009
Documento di Analisi e
Specifica dei Requisiti
Corso di Ingegneria del Software
Docente Responsabile : Agostino Cortesi
Task 1
03/11/2008
Gruppo:
Our-Chan Team
Gasparetto Andrea (Team Leader) Matr. 812882

Milan Luca Matr. 810648
Schiavinato Michele Matr. 810649
Caputi Salvatore Matr. 813103
Furegon Andrea Matr. 812693
1/39
INDICE ARGOMENTI
1 INTRODUZIONE ................................................................................................................................. 4
1.1 Scopi del documento .................................................................................................................. 4
1.2 Descrizione del documento ........................................................................................................ 4
1.3 Descrizione delle funzionalità generali del prodotto ................................................................. 5
2 ANALISI DEI VIEWPOINTS .................................................................................................................. 6
2.1 Viewpoints .................................................................................................................................. 6
2.1.1 Viewpoints interattivi .......................................................................................................... 6
2.1.2 Viewpoints di dominio ......................................................................................................... 6
2.2 Gerarchia dei viewpoints............................................................................................................ 7
2.3 Specifica degli attori ................................................................................................................... 7
2.4 Descrizione dei servizi ................................................................................................................ 9
2.5 Casi d’uso .................................................................................................................................. 14
3 MODELLAZIONE DEL SISTEMA ........................................................................................................ 22
3.1 Modello entità-relazioni ........................................................................................................... 22
4 DEFINIZIONE DEI REQUISITI FUNZIONALI ....................................................................................... 23
5 DEFINIZIONE DEI REQUISITI NON FUNZIONALI............................................................................... 26
5.1 Requisiti di prodotto................................................................................................................. 26
5.2 Requisiti di processo................................................................................................................. 27
6 EVOLUZIONE DEL SISTEMA ............................................................................................................. 29
6.1 Multiplayer in rete.................................................................................................................... 29
6.2 Possibilità di integrare più giochi di carte ................................................................................ 29
6.3 Miglioramenti delle prestazioni multimediali .......................................................................... 29
6.4 Supporto multilingua ................................................................................................................ 29
6.5 Supporto per Xbox 360............................................................................................................. 29
6.6 Classifiche ................................................................................................................................. 30
6.7 Supporto ad altre tipologie di gioco ......................................................................................... 30
7 SPECIFICA DEI REQUISITI ................................................................................................................. 31
7.1 Specifica .................................................................................................................................... 31
7.2 Matrice dei riferimenti ............................................................................................................. 33
8 GLOSSARIO ...................................................................................................................................... 35
9 BIBLIOGRAFIA .................................................................................................................................. 39
2/39
INDICE FIGURE
Capitolo 2
Figura 2.1……………………………………………………………………………………………………………………………7
Figura 2.2…………………………………………………………………………………………………………….……………15
Figura 2.3…………………………………………………………………………………………………………….……………17
Figura 2.4…………………………………………………………………………………………………………….……………18
Capitolo 3
Figura 3.1..………………………………………………………………………..…………………………….………….…… 22
Capitolo 7
Matrice dei Riferimenti…………………………………………………………………………………………………….34
DOCUMENTO RILASCIATO IL 03 NOVEMBRE 2008
VERSIONE 1.0
PAGINE TOTALI 39
3/39
1 INTRODUZIONE
1.1 Scopi del documento
Lo scopo di questo documento è un’attenta descrizione di ciò che dovrà offrire il sistema che si
andrà a sviluppare. In particolare verranno specificate le funzionalità accessibili ai suoi utenti, le
modalità con cui esso si dovrà integrare con l’ambiente, i vincoli che sia il processo di sviluppo che
il prodotto finale dovranno rispettare ed i diversi viewpoints che vi saranno coinvolti. Con il pre-
sente si intende inoltre mettere a disposizione al committente uno scritto da convalidare, nel qua-
le egli possa trovare una risposta alle sue richieste ed esigenze, ed al team di sviluppo una esatta
rappresentazione di ciò che dovrà implementare. Tutte le fasi del processo software dovranno fare
riferimento alle linee guida qui indicate, ed alla luce di quanto riportato nel piano di progetto si
potrà monitorare il rispetto degli impegni presi con il cliente.
1.2 Descrizione del documento
Il presente documento SRS (Software Requirements Specification) riguarda la creazione di una

piattaforma che metta a disposizione di chi la usa un’interfaccia utente per un qualsiasi gioco di
carte. Tale piattaforma deve essere sufficientemente flessibile da permettere il suo utilizzo indi-
pendentemente dalle regole che il gioco impone. Una panoramica delle varie sezioni del documen-
to viene proposta qui sotto:
2. Modelli di sistema: attraverso l’uso del modello Data-Flow si definiscono le entità che entreran-
no in gioco e come esse collaborano tra di loro.
3. Analisi dei viewpoints: la stesura e l’analisi di punti di vista diversi in base alla tipologia di usu-
fruitore consente di individuare le caratteristiche dei requisiti necessari alla stesura del progetto.
4. Definizione dei requisiti funzionali: si definiscono i servizi che il sistema dovrà offrire agli utenti e
le motivazioni per la quale tali servizi sono stati resi disponibili.
5. Definizione dei requisiti non funzionali: si definiscono i vincoli sul prodotto e sul processo di svi-
luppo, prendendo in considerazione anche alcuni requisiti e vincoli esterni.
6. Evoluzione del sistema: in questa sezione vengono elencate delle possibili vie per ampliare, mi-
gliorare o aggiornare il prodotto creato.
7. Specifica dei requisiti: partendo dai vincoli funzionali elencati nella sezione 4, si cerca di indivi-
duare le interdipendenze tra i requisiti attraverso una rappresentazione tabulare.
4/39
1.3 Descrizione delle funzionalità generali del prodotto
In base alle richieste imposte dal task, si è giunti all’elaborazione dell’architettura generale del
prodotto. Esso dovrà fornire in primo luogo un’interfaccia (UI = User Interface) che permetta
all’utente di giocare al gioco di carte Machiavelli. Il prodotto deve essere comunque sufficiente-
mente flessibile da garantire un integrazione di eventuali altri “regolamenti” di gioco, dando la
possibilità agli sviluppatori di modificare con facilità il codice per adattarlo ad altri giochi dello
stesso genere (altri giochi di carte). Questo prevede l’integrazioni di funzioni non necessarie per il
gioco Machiavelli (ad esempio in questo gioco non si scarta mai) ma che sono presenti in giochi
differenti (ad esempio in Scala 40 si scarta una carta ad ogni fine turno). La stesura dei requisiti ha
quindi un’importanza rilevante per garantire un prodotto quanto più completo.
5/39
2 ANALISI DEI VIEWPOINTS
Grazie all’analisi viewpoints-oriented è possibile guardare al problema da un punto di vista diverso

da quello degli sviluppatori. “Calandosi” nella parte degli usufruitori, è possibile stabilire cosa è
necessario mettere a disposizione per avere un’esperienza completa e soddisfacente. E’ necessa-
rio quindi individuare i vari protagonisti e guardare all’applicazione con i loro “occhi”.
2.1 Viewpoints
I viewpoints che vengono trattati sono di 2 tipi:
- Interattivi: rappresentano le persone o gli altri sistemi che interagiscono direttamente con il si-
stema. Nell’applicazione che stiamo analizzando in questa categoria vengono inclusi i giocatori, gli
sviluppatori e il tavolo.
- Di dominio: Raggruppa gli standard a cui il sistema si deve adattare e/o integrare.
2.1.1 Viewpoints interattivi
- Sviluppatore: è colui che si occupa della progettazione, dell’implementazione e dell’eventuale

espansione dell’applicazione. Fornisce inoltre supporto tecnico in caso di bisogno.
- Usufruitore: è il super-viewpoints che include i servizi che vengono messi a disposizione di coloro
che partecipano al gioco, indipendentemente dal fatto che si tratti di un’intelligenza artificiale o di
un giocatore reale.
- Giocatore: è l’utilizzatore primario dell’applicazione, per il quale essa viene strutturata e model-
lata per garantire la migliore esperienza di gioco.
- Tavolo: è colui che si occupa di far rispettare le regole e decidere quali operazioni può fare il gio-
catore in quel momento. Si occupa inoltre di fornire un avversario al giocatore.
2.1.2 Viewpoints di dominio
- Standard: individua tutte le caratteristiche che il sistema deve rispettare. In particolar modo, ga-
rantisce un ottima flessibilità per quel che concerne l’applicazione e la sua adattabilità per quel
che riguarda l’implementazione di regole di gioco differenti.
6/39
2.2 Gerarchia dei viewpoints
All VPs
Di Dominio Interattivi
Standard Sviluppatori Giocatore
Tavolo
Figura 2.1
2.3 Specifica degli attori
La specifica dei viewpoints seguirà il seguente template:
Template
Reference Il nome del viewpoints.
Attributes Attributi che forniscono informazioni sui
viewpoints.
Events Riferimenti ad una serie di possibili eventi
che descrivono come il sistema reagisce.
Services Riferimenti alla descrizione di determi-
nati servizi.
Sub Vps il nome dei sotto-viewpoints.
7/39
Usufruitore
Reference Interattivo
Attributes --
Events --
Services Richiede una carta
Scarta una tupla
Modifica una tupla
Sub Vps Giocatore, Tavolo
Giocatore
Attributes Nome
Events Vittoria
Sconfitta
Services Accedi al menù
Gioca
Consulta manuale
Esci dall’applicazione
Riprendi partita
Interrompi partita
Richiede una carta
Scarta una tupla
Modifica una tupla
Sub Vps --
Tavolo
Attributes Livello di difficoltà
Stato del gioco
Events Partita terminata
Sconfigge il giocatore
Viene sconfitto dal giocatore
Services Controlla che le regole del gioco venga-
no rispettate
Pesca una carta
Mette sul tavolo una tupla
Modifica una tupla
Sub Vps --
8/39
Sviluppatore
Attributes Login all’applicazione di sviluppo
(server)
Events Download/Upload dei contenuti (ag-
giornamenti, nuovi contenuti, fix).
Services Sviluppo
Supporto
Aggiorna
Aggiungi IA
Sub Vps --
Standard
Reference Dominio
Attributes --
Events --
Services Applicazione che rispetti determinati livelli
di flessibilità, generalizzazione e usabilità.
Deve inoltre rispettare i requisiti di sistema
imposti.
Sub Vps --
2.4 Descrizione dei servizi
La descrizione dei servizi seguirà il seguente template:
Template
Reference Il nome del servizio.
Rationale Il motivo per il quale il servizio viene
reso disponibile
Specification Riferimento ad una lista di descrizione
dei servizi.
Viewpoints Lista dei nomi viewpoints che utilizzano il
servizio.
Non- Riferimento ad un set di requisiti non
Functional funzionali che vincolano il servizio.
requirements
Provider Riferimenti ad una lista di oggetti che
forniscono il servizio
9/39
Specifica dei servizi:
Accedi al Menù
Reference Accedi al Menù
Rationale Il menù rende possibile la navigazione
attraverso le funzioni messe a disposi-
zione dell’applicazione.
Specification Riferimento ad una lista di descrizione
dei servizi.
Viewpoints Giocatore
Non- RFN51.2
Functional
requirements
Provider Sistema
Gioca
Reference Gioca
Rationale Avvia una nuova partita
Specification Lo stato di gioco viene resettato e la
partita comincia
Non- RFN51.3
Functional
requirements
Provider Sistema
Consulta manuale
Reference Consulta manuale
Rationale Il manuale deve essere reso disponibile
per far apprendere all’utente le mecca-
niche di gioco e le regole.
Specification La possibilità di consultare il manuale
ingame aumenta l’usabilità del prodot-
to poiché permette di non uscire dal
gioco per consultarla.
Non- RFN51.1, RFN51.3
Functional
requirements
Provider Sistema
10/39
Reference Esci dall’applicazione
Rationale Il giocatore deve poter uscire
dall’applicazione in qualsiasi momento.
Specification E’ un servizio necessario per qualsiasi
applicazione.
Non- RFN51.3
Functional
requirements
Provider Sistema
Riprendi partita
Reference Riprendi partita
Rationale L’utente, potendo accedere al menù
anche durante una partita, deve poi
poter riprendere da dove l’aveva lascia-
ta.
Specification Il giocatore deve poter consultare il
menù durante una partita senza perde-
re lo stato attuale del gioco.
Non- RFN51.3
Functional
requirements
Provider Sistema
Interrompi partita
Reference Interrompi partita
Rationale L’utente può abbandonare una partita
in corso.
Specification Tramite il menù l’utente potrà abban-
donare la partita in corso e riaccedere
al menù principale.
Non- RFN51.3
Functional
requirements
Provider Sistema
11/39
Richiedi una carta

Reference Richiedi una carta
Rationale Nel gioco Machiavelli questa è una del-
le operazioni consentite.
Specification Il giocatore richiede una carta che ag-
giungerà alla sua mano.
Viewpoints Usufruitore, Giocatore, Tavolo
Non- --
Functional
requirements
Provider Logica, Sistema
Scarta una tupla

Reference Scarta una tupla
Rationale Operazione consentita nel gioco di car-
te Machiavelli.
Specification Il giocatore (o il tavolo) può mettere
mettere sul banco una tupla.
Non- --
Functional
requirements
Modifica una tupla

Reference Modifica una tupla
Rationale Operazione consentita nel gioco di car-
te Machiavelli.
Specification Il giocatore e il tavolo, secondo le rego-
lo del Machiavelli, possono modificare
le tuple presenti sul banco comporne
altre o aggiungere carte a quelle pre-
senti.
Non- --
Functional
requirements
12/39
Sviluppo
Reference Sviluppo
Rationale Implementazione dell’applicazione.
Specification --
Viewpoints Sviluppatore
Non- Deve permettere l’uso di plugin svilup-
Functional pati da terzi che introducono logiche di
requirements gioco diverse da quelle del Machiavelli
Provider --
Supporto
Reference Supporto
Rationale Lo sviluppatore deve garantire il sup-
porto in termini di fissaggio degli errori.
Specification I problemi non riscontrati in fase di te-
sting devono essere comunque risolti.
Non- --
Functional
requirements
Provider --
Aggiorna
Reference Aggiorna
Rationale L’erogatore dell’applicazione può rila-
sciare aggiornamenti atti ad estender-
ne i contenuti.
Specification Maggiori informazioni sono disponibili
nella sezione 6 di questo documento.
Non- --
Functional
requirements
Provider --
13/39
Aggiungi IA
Reference Aggiungi IA
Rationale Possibilità di utilizzare plugin differenti
da quello del Machiavelli per poter usu-
fruire del sistema creato per giocare a
giochi differenti che rispettino i requisi-
ti imposti in questo documento.
Specification Il sistema deve poter ospitare plugin
sviluppate da terzi in modo da permet-
tere di utilizzare lo stesso sistema per
logiche di gioco differenti.
Non- Il plugin per essere utilizzabile dovrà ri-
Functional spettare i requisiti imposti.
requirements
Provider --
2.5 Casi d’uso
Un diagramma dei casi d’uso mostra:

• le modalità di utilizzo del sistema (casi d’uso);
• gli utilizzatori e coloro che interagiscono con il sistema (attori);
• le relazioni tra attori e casi d’uso.
Un caso d’uso:
• rappresenta un possibile “modo” di utilizzo del sistema;
• descrive l’interazione tra attori e sistema, non la “logica interna” della funzione (ossia una
funzionalità dal punto di vista di chi la utilizza).
Un use case cattura chi (attori) fa cosa (interazione) con il sistema. Con quale scopo (goal), senza
considerare ciò che è dentro il sistema un use case:
• Raggiunge un singolo, discreto, completo, significativo, e ben definito task di interesse per
un attore;
• È un pattern di comportamento tra alcuni attori ed il sistema — una collezione di possibili
scenari;
• È scritto usando il vocabolario del dominio;
• Definisce scopo ed intento (non azioni concrete);
• È generale e indipendente dalla tecnologia.
14/39
Gioco di carte Machiavelli
Gioca partita
Logica
Giocatore
Creazione di una
nuova logica
Sviluppo di nuo- Programmatore

ve funzionalità
Figura 2.2
Specifica dei casi d’uso del nostro problema:
Gioca partita contro la logica

Goal Il giocatore effettua una partita contro la logica del gioco con lo
scopo di divertirsi e di imparare aumentare la propria abilità nel
gioco di Macchiavelli
Attori Giocatore - Logica
Precondizioni Conoscere le regole di gioco da parte del giocatore
Trigger
Descrizione 1. Avviare l’applicazione
2. Iniziare una nuova partita contro la logica
3. Al proprio turno, scartare o modificare una tupla. Nel caso non
sia possibile pescare una carta.
4. Cedere il turno.
5. Attendere i turni degli avversari fino al proprio.
6. Ripetere le operazioni da 3 a 5. La partita si conclude quando un gio-
catore non ha più carte in mano e si decreta vincitore.
Alternative (estensioni)
Postcondizioni: Il giocatore ha concluso una partita di carte con la vittoria o con la
sconfitta
15/39
Creazione di una nuova logica

Goal Creare ed implementare una nuova logica di gioco di carte per
fornire un’esperienza più ampia e divertente al giocatore
Attori Programmatore
Precondizioni Conoscere il regolamento della logica da implementare
Trigger I giocatori richiedono nuove logiche o il programmatore intende
realizzarne di nuove
Descrizione 1. Il programmatore si documenta sulla logica da implementare
in particolar modo sul regolamento e sulle azioni di gioco.
2. Il programmatore analizza e pianifica un sistema che sia in gra-
do di implementare a questa nuova logica.
3. Il programmatore crea la nuova logica
4. Il programmatore integra all’interno del gioco la logica appena
creata
5. Viene effettuata una sessione di test e debug per verificare
l’esatta implementazione della nuova logica
Postcondizioni: Il gioco implementa la nuova logica creata
Sviluppo di nuove funzionalità

Goal Fornire funzionalità avanzate per rendere più gradevole
l’esperienza ludica del giocatore
Attori Programmatore
Precondizioni Definire le caratteristiche delle funzionalità da implementare
Trigger I giocatori richiedono nuove funzionalità o il programmatore in-
tende realizzarne di nuove
Descrizione 1. Il programmatore si documenta sulla funzionalità da imple-
mentare.
2. Il programmatore analizza e pianifica un sistema che sia in gra-
do di implementare questa nuova funzionalità.
3. Il programmatore crea la nuova funzionalità
4. Il programmatore integra all’interno del gioco la funzionalità
appena creata
5. Viene effettuata una sessione di test e debug per verificare
l’esatta implementazione della nuova funzionalità
Postcondizioni: Il gioco implementa la nuova funzionalità creata
16/39
Scenari possibili:
Pesca Carta
Scarta Tupla
Modifica Tupla
Passa la Mano
Figura 2.3 – Scenario “Partita”
17/39
Gioca /
Riprendi Partita
Help
Esci /
Termina Partita
Figura 2.4 – Scenario “Accesso al Menù”
Specifica delle azioni previste dal nostro problema:
Accedi al menù
Goal Accede al menù e rende possibile la navigazione attraverso le fun-
zioni messe a disposizione dell’applicazione.
Attori Giocatore
Precondizioni ---
Trigger Aver premuto o cliccato l’apposito tasto del menù
Descrizione Il giocatore accede al menu principale per poter effettuare le ope-
razioni principali, come l’inizio, il riavvio e la chiusura di una parti-
ta e la chiusura dell’applicazione.
Postcondizioni:
Gioca
Goal Effettua una partita al gioco di carte
Attori Giocatore
Precondizioni Aver acceduto al menù principale
Descrizione Il giocatore avvia una nuova partita del gioco di carte, specifican-
do il numero degli avversari virtuali o reali.
Alternative (estensioni) (Multiplayer, gioco a solitario)
Postcondizioni: La partita di carte è iniziata
18/39
Consulta manuale
Goal Consulta il manuale documentativo per informazioni sul sistema,
sull’applicazione e risoluzione dei problemi elementari
Attori Giocatore
Descrizione Il giocatore accede alla documentazione
Alternative (estensioni) (Fornire assieme all’applicazione un manuale cartaceo e una ver-
sione disponibile online)
Postcondizioni: Il manuale è visualizzato
Goal Il gioco viene terminato e l’applicazione chiusa
Attori Giocatore
Descrizione Il giocatore termina il gioco attuale nel caso stia giocando ed esce
dall’applicazione
Alternative (estensioni) (Documentazione online)
Postcondizioni: L’applicazione è terminata
Riprendi partita
Goal Il gioco viene ripreso dallo stato di pausa
Attori Giocatore
Descrizione Il giocatore riprende la partita messa precedentemente in pausa
Alternative (estensioni) (Inibizione della pausa se vi è un gioco in multiplayer)
Postcondizioni: La partita è ripresa
Interrompi partita
Goal Il gioco viene interrotto e la partita corrente annullata
Attori Giocatore
Descrizione Il giocatore interrompe la partita corrente e viene resettato lo sta-
to
Alternative (estensioni) (Inibizione della pausa se vi è un gioco in multiplayer)
Postcondizioni: La partita è ripresa
19/39
Richiede una carta

Goal Il giocatore pesca una carta poiché è impossibilitato a scartare
una tupla
Attori Giocatore, Usufruitore (Controllare)
Precondizioni Il giocatore deve attendere che l’avversario precedente abbia
concluso il turno. Il giocatore non deve avere già pescato una car-
ta
Trigger Aver premuto o cliccato l’apposito tasto
Descrizione Il giocatore pesca una carta dal mazzo poiché non può al momen-
to scartare una tupla e passa il turno
Alternative (estensioni) ---
Postcondizioni: Il giocatore ha una carta in più in mano e cede il turno al giocatore
successivo
Scarta una tupla

Goal Il giocatore deve perseguire la vittoria
Attori Giocatore, Usufruitore
concluso il turno, la tupla selezionata deve essere valida per poter
essere scartata
Trigger Input dell’utente
Descrizione Il giocatore seleziona le carte della tupla da scartare, successiva-
mente preme o clicca il pulsante apposito per scartare le carte. Se
la tupla è valida viene scartata, altrimenti viene notificato al gioca-
tore che la tupla non può essere scartata
Postcondizioni: Il giocatore ha scartato una tupla o più e cede il turno al giocatore
successivo
20/39
Modifica una tupla

Goal Il giocatore modifica una tupla presente sul tavolo
Attori Giocatore, Usufruitore (Controllare)
concluso il turno, la modifica di tupla deve essere valida per poter
essere scartata
Trigger Aver selezionato le carte della tupla e premuto o cliccato il pulsan-
te per scartare le carte
Descrizione Il giocatore seleziona le carte della tupla da scartare, successiva-
mente preme o clicca il pulsante apposito per scartare le carte. Se
la tupla è valida viene scartata, altrimenti viene notificato al gioca-
tore che la tupla non può essere scartata
Postcondizioni: Il giocatore ha scartato una tupla o più e cede il turno al giocatore
successivo
21/39
3 MODELLAZIONE DEL SISTEMA
Per modellare il sistema ci si avvale di una rappresentazione schematica e generalizzata utile per
sintetizzare le caratteristiche principali che esso dovrà avere. Ci si può avvalere di modelli differen-
ti per questa rappresentazione. Essi differiscono per il livello di astrazione a cui si vuole puntare.
Prendendo in considerazione il nostro caso specifico, si è deciso di optare per l’uso del modello en-
tità-relazioni. Questa tipologia di modello è utile per individuare le entità che fanno parte del si-
stema e come esse si relazionano tra loro.
3.1 Modello entità-relazioni
Il modello ad entità-relazioni si sposa bene con il progetto che stiamo analizzando, dando una vista
generale di quelli che sono gli attori che si devono considerare nella nostra analisi.
Attori del sistema

- Sviluppatori-> si occupano dell’ideazione, dello sviluppo e dell’ampliamento dell’applicazione
- Giocatori -> usufruitori finali del prodotto
- Logica -> sezione del sistema che si occupa delle regole del gioco e di fornire un avversario al gio-
catore.
Prodotto Interagisce Usufruitore
Logica Persona
Implementa
Giocatore Sviluppatore
Figura 3.1
22/39
4 DEFINIZIONE DEI REQUISITI FUNZIONALI
I requisiti esterni imposti dalla consegna riguardano la possibilità di poter utilizzare diversi moduli
di intelligenza artificiale senza dover modificare tutto il sistema di base, cercando delle soluzione
che riducano al minimo il tempo necessario all’implementazione di regole di gioco diverse.
Ogni requisito funzionale seguirà il template sottostante:
Codice Una breve stringa identificativa del requisito, nella forma RF.X, dove RF sta per
requisito funzionale e X è un numero progressivo
Definizione La definizione del requisito, espressa sinteticamente in linguaggio naturale
Motivazione Succinta spiegazione della ragion d’essere del requisito
Influisce Codici identificativi dei requisiti funzionali correlati
Specifica Stringa identificativa della specifica del requisito descritto
Codice RF.1
Definizione L’utente deve poter giocare al gioco di carte Machiavelli una volta avviata
l’applicazione.
Motivazione L’obbiettivo primo di questa applicazione è consentire all’utente di giocare al
gioco di carte Machiavelli.
Influisce RF.3
Specifica SRF.1
Codice RF.2
Definizione Deve essere messo a disposizione dell’utente un aiuto in linea che spieghi le
meccaniche di gioco.
Motivazione Le istruzioni all’uso servono per coloro che non conoscono il gioco o non ne
hanno familiarità.
Influisce RF.3
Specifica SRF.2
Codice RF.3
Definizione L’utente deve poter accedere al menù di gioco in qualsiasi momento
Motivazione Per qualsiasi ragione deve essere possibile accedere al menù che mette a dispo-
sizione diverse opzioni, tra cui il poter uscire dall’applicazione
Influisce --
Specifica SRF.3
23/39
Codice RF.4
Definizione All’utente deve essere messa a disposizione la possibilità di consultare lo stato
del gioco attuale.
Motivazione Questo è necessario per rendere il giocatore partecipe e dargli la possibilità di
organizzare le proprie mosse.
Influisce RF.5
Specifica SRF.4
Codice RF.5
Definizione Il gioco deve cambiare il suo stato in caso di vittoria o sconfitta, passando da “in
gioco” a “attesa della scelta del giocatore”.
Motivazione L’obbiettivo ultimo è quello di sfidare l’intelligenza artificiale in un gioco di carte
in cui si può vincere o si può perdere.
Influisce RF.6
Specifica SRF.5
Codice RF.6
Definizione L’utente deve avere la possibilità di uscire dall’applicazione in qualsiasi momen-
to.
Motivazione --
Influisce --
Specifica SRF.6
Codice RF.7
Definizione L’utente deve avere la possibilità di effettuare un’ulteriore partita una volta fini-
ta la precedente
Motivazione L’utente non si deve trovare nella situazione di dover uscire dal gioco per poter
effettuare un'altra partita.
Influisce RF.8
Specifica SRF.7
Codice RF.8
Definizione L’utente deve poter ricominciare una partita in qualsiasi momento.
Motivazione L’utente, in caso di difficoltà, deve poter ricominciare la partita senza dover usci-
re dall’applicazione
Influisce --
Specifica SRF.8
24/39
Codice RF.9
Definizione L’utente deve avere la possibilità di pescare una carta dal mazzo.
Motivazione Azioni di gioco consentite dal Machiavelli
Influisce --
Specifica SRF.9
Codice RF.10
Definizione L’utente deve avere la possibilità di scartare una tupla.
Influisce --
Specifica SRF.10
Codice RF.11
Definizione L’utente deve avere la possibilità di modificare una tupla (combinazione di carte
consentita) sul tavolo: aggiungendo delle carte, rimuovendole (per poterle usare
in un'altra tupla).
Influisce --
Specifica SRF.11
Codice RF.12
Definizione L’utente deve avere la possibilità di passare la mano se non ha altre operazioni
da fare.
Influisce --
Specifica SRF.12
Codice RF.13
Definizione L’utente deve poter giocare e interagire con tutto il sistema tramite l’uso del
mouse.
Motivazione Maggiore semplicità nell’uso dell’applicazione.
Influisce --
Specifica SRF.13
25/39
5 DEFINIZIONE DEI REQUISITI NON FUNZIONALI
Per ciascun requisito non funzionale verranno fornite le seguenti informazioni:
Codice Una breve stringa identificativa del requisito, nella forma RNFX.Y, dove RNF sta
per requisito non funzionale, X ha il valore del paragrafo a cui appartiene il re-
quisito, Y è un numero progressivo
Definizione La definizione del requisito, espressa sinteticamente in linguaggio naturale
Scopo Spiegazione dei fini per cui il requisito è stato elaborato
Tipo Definisce il tipo di requisito non funzionale
Influisce Codici identificativi dei requisiti funzionali correlati
5.1 Requisiti di prodotto
Codice RFN51.1
Definizione Un utente che abbia dimestichezza con dei giochi di carte affini (es. Scala 40 o
simili) deve essere in grado di giocare dopo aver letto le istruzioni in linea una
volta.
Scopo --
Tipo Requisito di usabilità
Influisce RF.1
Codice RFN51.2
Definizione Il giocatore deve trovarsi di fronte ad un menù con più opzioni di scelta una volta
avviata l’applicazione
Scopo Il giocatore deve essere consapevole delle azioni che il gioco mette a disposizio-
ne.
Influisce RF.1
Codice RFN51.3
Definizione Il menù deve dare la possibilità di:
Giocare
Consultare il manuale online
Uscire
In base allo stato del gioco (ingame o no) avrà a disposizione anche:
Riprendi partita
Nuova partita (interrompi la partita corrente)
Scopo Opzioni base che un gioco dovrebbe mettere a disposizione.
Influisce RF.3
26/39
Codice RFN51.4
Definizione L’applicazione supporterà giochi di carte che utilizzano unicamente carte france-
si.
Scopo Requisiti di espandibilità
Tipo Requisito di evoluzione
Influisce --
Codice RFN51.5
Definizione Il sistema supporterà giochi che richiedono 2 giocatori.
Scopo Serve per escludere dalla compatibilità di giochi come il solitario.
Tipo Requisito di realizzabilità.
Influisce --
Codice RFN51.6
Definizione L’utente per poter usufruire dell’applicazione deve disporre di un sistema che
ospiti il framework .Net e XNA, DirectX 9.0c e una scheda video che disponga di
almeno i pixel shader 1.1.
Scopo Requisiti minimi di sistema.
Tipo Requisito di portabilità
Influisce --
5.2 Requisiti di processo
Codice RFN52.1
Definizione Il documento dei requisiti deve essere stilato entro il 3 Novembre 2008
Scopo Data di consegna
Tipo Requisito di consegna
Influisce --
Codice RFN52.2
Definizione La Fase di progettazione deve essere ultimata entro il 9 Dicembre 2008
Influisce --
27/39
Codice RFN52.3
Definizione La fase di testing, la consegna del prototipo e la presentazione dovranno essere
ultimate entro il 15 Gennaio 2009
Influisce --
28/39
6 EVOLUZIONE DEL SISTEMA
Il sistema sarà realizzato in modo tale da essere facilmente modificabile e ampliabile. In una realtà
come quella di un gioco per computer è di essenziale importanza permettere l’evoluzione del pro-
dotto che sarà garantita dalla buona generalizzazione dei requisiti. In questa sezione del documen-
to stileremo alcune possibile evoluzioni del gioco di carte.
6.1 Multiplayer in rete
Il multiplayer, che permette di giocare a più persone rispetto all’attuale modalità single-player, è
una caratteristica decisiva in un gioco come questo. Una possibile evoluzione del sistema quindi
può essere l’implementazione del multi-player su rete locale ma anche internet.
6.2 Possibilità di integrare più giochi di carte
Il sistema sfrutta una sola intelligenza artificiale (AI) del gioco di Machiavelli, ma uno dei principali
obbiettivi del progetto è quello predisporre l’ambiente nel ospitare diverse intelligenze artificiali
fissando chiaramente delle caratteristiche comuni.
Il risultato è la possibilità da parte dell’utente di poter scegliere il suo gioco di carte preferito. Non
avremo quindi tante UI diverse per ogni gioco, ma tante AI (fino a quando questo è sempre possi-
bile).
6.3 Miglioramenti delle prestazioni multimediali
Il gioco di carte proprio come realtà non presenta particolari esigenze dal punto di vista
dell’impatto grafico e/o sonoro. In ogni caso il pubblico è abituato ad interfacce utente sempre più
vistose ed elaborate, con la presenza di effetti speciali e musiche di sottofondo. Proprio per segui-
re questa attuale direzione, potrebbe essere preso in considerazione un aggiornamento riguardan-
te il miglioramento delle prestazioni multimediali .
6.4 Supporto multilingua
Il gioco nella sua prima incarnazione sarà rivolto ad un pubblico italiano. Potrebbe essere prevista
una sua localizzazione in altre lingue (inglese in primis) in modo da ingrandire il bacino d’utenza.
Inoltre potrebbe essere implementato un sistema che permetta agli utenti/utilizzatori di inserire il
supporto ad altre lingue (senza il bisogno di mettere mano al codice).
6.5 Supporto per Xbox 360
Il framework che viene utilizzato per la creazione dell’applicazione permette una sua facile traspo-
sizione verso la console Xbox 360. Anche questa operazione è atta all’ingrandimento del bacino di
utenza.
29/39
6.6 Classifiche
All’utente potrebbe essere messo a disposizione un sistema per salvare i propri risultati in locale
(in cui vede se una partita è andata meglio di un'altra) oppure in rete (in cui può confrontarsi con
altri giocatori).
6.7 Supporto ad altre tipologie di gioco
L’applicazione potrebbe essere aggiornata in un secondo momento per permettere l’uso di plugin
che forniscano logiche di giochi che non sono stati presi in considerazione, come quelli che utiliz-
zano carte italiane (trevigiane, napoletane ecc ecc) o quelli che prevedono di giocare in solitario
(come l’omonimo gioco).
30/39
7 SPECIFICA DEI REQUISITI
7.1 Specifica
Per ogni specifica del requisito seguirà il template sottostante:
Codice Codice identificativo: è della forma SRF.X, dove S sta per Specifica, RF.X è la
stringa distintiva del requisito cui si fa riferimento nella specifica
Inputs Ciò che il sistema richiede per l’erogazione della funzionalità
Outputs Ciò che è restituito dal sistema a seguito della richiesta pervenuta
Pre-condizioni Presupposti validi al momento dell’invocazione della funzionalità
Post-condizioni Proprietà valide ad operazione conclusa
Codice SRF.1
Inputs Richiesta da parte dell’utente di iniziare il gioco
Outputs Visualizzazione dell’interfaccia di gioco
Pre-condizioni Il terminale mostra l’interfaccia del menu
Post-condizioni Il terminale mostra l’interfaccia di una nuova partita
Codice SRF.2
Inputs Richiesta da parte dell’utente di un aiuto che spieghi le meccaniche del gioco
Outputs Visualizzazione dell’interfaccia di guida richiesta dall’utente
Pre-condizioni --
Post-condizioni Il terminale mostra l’interfaccia di guida utente
Codice SRF.3
Inputs Richiesta da parte dell’utente di visualizzare il menu di gioco
Outputs Visualizzazione del menu di gioco
Pre-condizioni --
Post-condizioni Il terminale mostra il menu di gioco
Codice SRF.4
Inputs Richiesta di avere una maggiore panoramica dello stato del gioco
Outputs Visualizzazione dell’interfaccia più dettagliata dello stato del gioco
Pre-condizioni Il terminale sta mostrando la partita corrente
Post-condizioni Il terminale mostra l’interfaccia più dettagliata dello stato del gioco
31/39
Codice SRF.5
Inputs Evento di vittoria o sconfitta da parte del giocatore
Outputs Visualizzazione di una scelta all’utente dopo aver vinto o perso
Pre-condizioni Il terminale è nello stato di partita in corso
Post-condizioni Il terminale mostra l’interfaccia di scelta
Codice SRF.6
Inputs Richiesta di uscita dall’applicazione
Outputs Visualizza una domanda di conferma per uscire dall’applicazione
Pre-condizioni --
Post-condizioni Il terminale mostra una domanda di conferma per uscire dall’applicazione
Codice SRF.7
Inputs Richiesta da parte dell’utente di iniziare una nuova partita
Pre-condizioni Il terminale mostra la fine di una determinata partita
Codice SRF.8
Inputs Richiesta da parte dell’utente di iniziare una nuova partita
Pre-condizioni Il terminale mostra la partita in corso
Codice SRF.9
Inputs Richiesta da parte dell’utente di pescare una carta dal mazzo
Outputs Visualizzazione dell’interfaccia per la scelta di quale carta pescare dal mazzo
Post-condizioni Il terminale mostra l’interfaccia per la scelta di quale carta pescare dal mazzo
Codice SRF.10
Inputs Richiesta da parte dell’utente di scartare una tupla
Outputs Visualizzazione dell’interfaccia per eseguire lo scarto di una tupla
Post-condizioni Il terminale mostra l’interfaccia per eseguire lo scarto di una tupla
32/39
Codice SRF.11
Inputs Richiesta da parte dell’utente di modifica tupla (combinazione di carte con-
sentita) sul tavolo.
Outputs Visualizzazione dell’interfaccia per le operazioni di modifica tupla.
Post-condizioni Il terminale mostra l’interfaccia per le operazioni di modifica tupla.
Codice SRF.12
Inputs Richiesta da parte dell’utente di passare la mano
Outputs Visualizzazione dell’interfaccia di gioco dopo aver passato la mano
Pre-condizioni Il terminale mostra la partita in corso e inoltre l’utente non deve aver la pos-
sibilità di eseguire altre operazioni
Post-condizioni Il terminale mostra l’interfaccia di gioco dopo aver passato la mano
Codice SRF.13
Inputs Uso del dispositivo mouse
Outputs In base all’evento richiamato, l’applicazione risponde.
Pre-condizioni Il dispositivo mouse deve essere correttamente collegato al terminale
Post-condizioni Il terminale mostra l’interattività col dispositivo mouse
7.2 Matrice dei riferimenti
La rappresentazione grafica proposta di seguito vuole offrire una visione completa delle interdi-
pendenze e delle reciproche influenze che i vari requisiti esercitano tra di loro. La seguente matri-
ce li identifica attraverso il codice corrispondente, mettendoli in relazione tra di loro, in modo che
la entry corrispondente a due vincoli correlati sia contraddistinta da un colore significativo.
33/39
Requisiti funzionali Requisiti non funzionali

Requisiti 1 2 3 4 5 6 7 8 9 10 11 12 13 51.1 51.2 51.3 51.4 51.5 51.6 52.1 52.2 52.3
1
2
3
4
Requisiti funzionali
5
6
7
8
9
10
11
12
13
51.1
51.2
Requisiti non funzionali
51.3
51.4
51.5
51.6
52.1
52.2
52.3
Dipendenze banali Dipendenze non banali
34/39
8 GLOSSARIO
A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z
Application Programming Interface (API)

Insiemi di procedure disponibili al programmatore di solito raggruppate a formare un set di stru-
menti specifici per un determinato compito.
D
Debugger
Software spesso integrato in un IDE, il cui compito è analizzare e correggere eventuali errori di
programmazione (bug) all’interno del codice.
Direct X
Una collezione di API per lo sviluppo semplificato di videogiochi per Windows. Attualmente
l’ultima versione è la 10.
Framework
Struttura di supporto su cui viene sviluppato un software ed alla cui base ci sono serie di librerie
e/o codice utilizzabili in diversi linguaggi di programmazione. Può essere corredato da una serie di
strumenti come un IDE e/o un debugger.
Framework .NET
E’ il framework proprietario di Microsoft.
Graphics Processing Unit (GPU)

Microprocessore di una scheda video per computer o console.
Integrated Development Environment (IDE)

Software per mezzo del quale il programmatore sviluppa altro software.
35/39
Intelligenza artificiale (AI)

“Abilità” di un computer di svolgere funzioni e ragionamenti tipici della mente umana.
Interfaccia utente o user interface (UI)

“Maschera” che permette l’interazione tra l’utente e il sistema. Può essere grafica (in questo caso
parliamo di GUI) o puramente testuale.
Livello di astrazione
Esprime la “distanza” tra uno schema o un linguaggio rispetto all’hardware di un elaboratore. Ad
un livello alto le informazioni sono chiare all’essere umano; al contrario un livello basso usa un lin-
guaggio più vicino alla macchina.
Modello data-flow
Modello di diagramma utilizzato principalmente per rappresentare il flusso e l’elaborazione delle
informazioni in un sistema.
Modello entità-relazioni (Modello E-R)

Modello per la rappresentazione dei dati ad alto livello di astrazione molto usato nella progetta-
zione dei database. I costrutti usati sono le entità (con i relativi attributi) e le relazioni, o associa-
zioni, che rappresentano i legami tra le varie entità.
Modello di sistema
Presentazione astratta del sistema di cui si stanno analizzando i requisiti. Di solito vengono utiliz-
zati schemi grafici.
Multi-player
Modalità di gioco dove si sfidano diversi utenti.
Pixel Shader
Sequenza di istruzioni eseguita da una GPU per ogni pixel da elaborare.
Plugin
Estensione che aggiunge una o più funzionalità al software.
36/39
Requisito funzionale
Descrive il servizio o la funzione realizzata dal sistema.
Requisito non funzionale

Descrive un vincolo sul sistema o sul processo di sviluppo.
Rete locale o Local Area Network (LAN)

Rete di computer collegati tra loro in un ambito fisico delimitato che non superi la distanza di
qualche km.
Server
Componente informatica che fornisce servizi ad altre periferiche utilizzando una rete.
Single-player
Modalità di gioco per un solo utente. Se ci sono avversari essi sono rappresentati dall’AI.
Software Requirements Specification (SRS)

Documento contenente la specifica dei requisiti di un sistema.
Team di sviluppo
Gruppo di persone il cui compito è lavorare allo sviluppo di un sistema.
Template
Modello di documento formato da una parte fissa (ad esempio layout e schemi vari) ed una modi-
ficabile.
Viewpoints
Letteralmente “punti di vista”. Rappresentano i vari “attori” di un sistema.
XBox 360
Console next-generation prodotta da Microsoft.
37/39
XNA
Insieme di strumenti per la progettazione, lo sviluppo e la gestione di software per videogiochi re-
so disponibile da Microsoft.
38/39
9 BIBLIOGRAFIA
1. Testo ufficiale del corso di Ingegneria del Software:

Ian Sommerville, Ingegneria del Software, 7 edizione, Pearson-Addison Wesley, ISBN 88-
7192-241-7.
2. Materiale aggiuntivo del corso di Ingegneria del Software:

Slide prodotte dal prof. Agostino Cortesi.
39/39

Task1 DocAnalisiSpecificaRequisiti

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Task1 DocAnalisiSpecificaRequisiti

Caricato da

Copyright:

Formati disponibili

Task 1 Documento di Analisi e Specifica dei Requisiti

UNIVERSITÀ CA’ FOSCARI DI VENEZIA

Gasparetto Andrea (Team Leader) Matr. 812882

DOCUMENTO RILASCIATO IL 03 NOVEMBRE 2008

1.1 Scopi del documento

1.2 Descrizione del documento

Il presente documento SRS (Software Requirements Specification) riguarda la creazione di una

1.3 Descrizione delle funzionalità generali del prodotto

2 ANALISI DEI VIEWPOINTS

Grazie all’analisi viewpoints-oriented è possibile guardare al problema da un punto di vista diverso

I viewpoints che vengono trattati sono di 2 tipi:

2.1.1 Viewpoints interattivi

- Sviluppatore: è colui che si occupa della progettazione, dell’implementazione e dell’eventuale

2.1.2 Viewpoints di dominio

2.2 Gerarchia dei viewpoints

Standard Sviluppatori Giocatore

2.3 Specifica degli attori

La specifica dei viewpoints seguirà il seguente template:

2.4 Descrizione dei servizi

La descrizione dei servizi seguirà il seguente template:

Specifica dei servizi:

Richiedi una carta

Scarta una tupla

Modifica una tupla

2.5 Casi d’uso

Un diagramma dei casi d’uso mostra:

Gioco di carte Machiavelli

Sviluppo di nuo- Programmatore

Specifica dei casi d’uso del nostro problema:

Gioca partita contro la logica

Creazione di una nuova logica

Sviluppo di nuove funzionalità

Figura 2.3 – Scenario “Partita”

Figura 2.4 – Scenario “Accesso al Menù”

Specifica delle azioni previste dal nostro problema:

Richiede una carta

Scarta una tupla

Modifica una tupla

3 MODELLAZIONE DEL SISTEMA

3.1 Modello entità-relazioni

Attori del sistema

- Giocatori -> usufruitori finali del prodotto

Prodotto Interagisce Usufruitore

4 DEFINIZIONE DEI REQUISITI FUNZIONALI

5 DEFINIZIONE DEI REQUISITI NON FUNZIONALI

Per ciascun requisito non funzionale verranno fornite le seguenti informazioni:

5.1 Requisiti di prodotto

5.2 Requisiti di processo

6 EVOLUZIONE DEL SISTEMA

6.1 Multiplayer in rete

6.2 Possibilità di integrare più giochi di carte

6.3 Miglioramenti delle prestazioni multimediali

6.4 Supporto multilingua

6.5 Supporto per Xbox 360

6.7 Supporto ad altre tipologie di gioco

7 SPECIFICA DEI REQUISITI

Per ogni specifica del requisito seguirà il template sottostante:

7.2 Matrice dei riferimenti

Requisiti funzionali Requisiti non funzionali

Dipendenze banali Dipendenze non banali

Application Programming Interface (API)

Graphics Processing Unit (GPU)

Integrated Development Environment (IDE)