
Sviluppo “centrato sull’utente” di applicazioni interattive
Analisi e specifica dei requisiti
utente
per applicazioni interattive
multimediali
(+ AWARE: un metodo
goal-oriented
Milano, 23 gennaio 2003
www.tec-lab.ch
© TEC-LAB 2003 -
1
 OUTLINE
Introduzione ai requisiti
Il processo di requirements management
Il Metodo AWARE
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
2
 Il ciclo di vita di una applicazione Web
Requirements management
Requirements
Design
Implementazione
Valutazione e testing
Promozione
Maintenance
Aggiornamento
Fonte: Hull, Jackson & Dick, 2002
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
3
 Ragioni di insuccesso di un progetto
Requisiti incompleti [13,1%]
Mancanza di coinvolgimento degli utenti [12,4%]
Mancanza di risorse [10,6%]
Aspettative irrealistiche [9,9%]
Mancanza di supporto esecutivo [9,3%]
Cambiamento di requisiti/specifiche [8,7%]
Mancanza di pianificazione [8,1%]
Fonte: Hull, Jackson & Dick, 2002
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
4
 Fattori di successo di un progetto
Coinvolgimento dell’utente [15,9%]
Supporto gestionale [13,9%]
Chiara definizione dei requisiti [13,0%]
Pianificazione appropriata [9,6%]
Aspettative realistiche [8,2%]
Milestones più piccole [7,7%]
Staff competente [7,2%]
Fonte: Hull, Jackson & Dick, 2002
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
5
 Che cos’è un requisito?
Un requisito è un’asserzione che identifica una
capacità, una caratteristica od un fattore di
qualità che un sistema deve possedere per avere
valore ed utilità per un utente
(R. Young 2001)
Esempi:
– “L’applicazione deve fornire all’utente
informazioni sui prodotti in offerta speciale”
– “L’utente deve poter effettuare transazioni di
pagamento con carta di credito attraverso una
connessione sicura”
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
6
 Requisiti funzionali o non funzionali
Un requisito funzionale esprime un
servizio od una funzionalità
dell’applicazione
– “L’applicazione deve fornire all’utente
informazioni sulla vita di Munch”
Un requisito non funzionale esprime una
proprietà dell’applicazione
– “Le transazioni devono avvenire
attraverso una connessione sicura”
“L’applicazione deve contenere immagini
di alta qualità”
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
7
 Requirements management: obiettivi
Definire i bisogni degli stakeholder (utenti,
committenti, fornitori, sviluppatori, ecc.)
Definire cosa il sistema deve o non deve
fare per soddisfare tali bisogni
Tenere traccia delle decisioni e delle
ragioni delle decisioni prese lungo l’intero
ciclo di vita dell’applicazione
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
8
 Requirements management: attività
Elicitazione
– Capire i bisogni, le esigenze, gli obiettivi, e i vincoli
Analisi
– Decidere le soluzioni da adottare, a quali obiettivi dare
più importanza, ecc.
Specifica (documentazione)
– Documentare il risultato della fase di analisi (i requisiti)
Validation
– Negoziare con gli stakeholder il consenso sugli obiettivi
e sui requisiti
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
9
 Sì, ma come?
Esistono molte pratiche, strumenti e tecniche nel
campo del Requirements Engineering
Le metodologie esistenti sono:
– in larga misura indipendenti dal dominio
– complesse e difficilmente accessibili ai non specialisti
Gli sviluppatori di applicazioni Web:
– In parte possono prendere a prestito le esistenti tecniche
di RE
– In parte devono definirne di nuove per rivolgersi ai loro
specifici bisogni
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
10
 Web Requirements Management
ELICITATION
ANALYSIS
SPECIFICATION
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
11
 Elicitation: definizione
L’elicitazione è l’arte di
– “portare a galla” gli obiettivi degli stakeholder,
i loro bisogni e le aspettative nei confronti del
servizio Web da costruire
– stimolare gli stakeholder a descrivere i loro
obiettivi
– ascoltare
– far concentrare gli stakeholder sui problemi
piuttosto che sulle soluzioni di design, sui
processi più che sui prodotti
– capire e comunicare i vincoli (tecnici, di
risorse, ecc.)
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
12
 Stakeholders (1)
Committenti (clienti)
– Prendono le decisioni strategiche e di
business
– Sono rappresentanti del settore
– Fonte per capire il dominio
– Fonte per capire i possibili utenti (target
dell’applicazione)
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
13
 Stakeholders (2)
Utenti
– User profiles
– Segmenti di mercato
– Rappresentano possibili utilizzatori
– Rappresentano istituzioni, partner e
collaboratori
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
14
 Stakeholders (3)
Azionisti
Opinion makers (a livello aziendale)
– Danno le loro opinioni
– Influenzano le opinioni degli altri
Esperti del dominio (altri che i
committenti)
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
15
 Esempio: Louvre
Stakeholder
Chi potrebbe
essere
interessato al
sito?
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
16
 Esempio: Louvre
Stakeholder
Museum
Museum
Visitor
Other
Museum
Educator
Press
Milano, 23 gennaio 2003
Chi potrebbe
essere
interessato al
sito?
Sponsor
-
© TEC-LAB 2003 -
www.tec-lab.ch
17
 Esempio: Louvre
Goal
Che cosa vuole
o si aspetta uno
Stakeholder dal
sito?
Museum
Visitor
Vedere le
esposizioni
correnti
Milano, 23 gennaio 2003
Pianificare
una visita
-
© TEC-LAB 2003 -
www.tec-lab.ch
18
 Esempio: Louvre
Attrarre più
investitori
Museum
Promuovere eventi ed
esposizioni temporanee
Arricchire l’esperienza
culturale del visitatore
Attrarre più
visitatori
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
19
 Esempio: Louvre
Sponsor
Assicurarsi che il proprio
denaro non sia stato sprecato
Farsi una
buona
pubblicità
Milano, 23 gennaio 2003
Controllare la
pubblicità sul sito
-
© TEC-LAB 2003 -
www.tec-lab.ch
20
 Esempio: Louvre
Raccogliere
informazioni su un
argomento specifico.
Educator
Decidere se
portare o no gli
studenti al
museo
Milano, 23 gennaio 2003
Collaborare con le
attività od i programmi
didattici del museo
Organizzare una
visita scolastica
-
© TEC-LAB 2003 -
www.tec-lab.ch
21
 Esempio: Louvre
Press
Trovare i contatti.
Trovare
informazioni
ufficiali su novità
ed eventi.
Milano, 23 gennaio 2003
Trovare informazioni
specifice relative al museo.
-
© TEC-LAB 2003 -
www.tec-lab.ch
22
 Esempio: Louvre
Museum
Visitor
Vedere le
esposizioni correnti
Educator
Lo stesso goal
può essere
espresso da
differenti
Stakeholders.
Pianificare
una visita
Raccogliere
informazioni su un
argomento specifico.
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
23
 Elicitation: problemi
Gli stakeholders hanno tipicamente una scarsa
coscienza:
– dei propri bisogni
– di ciò che la tecnologia è capace di fornire loro
Gli obiettivi possono cambiare nel corso del
progetto
Problemi di comunicazione
– Differente background (tecnico vs manageriale)
– Differente conoscenza del dominio (ad extra vs ad intra)
– Differente linguaggio (specifico del sistema vs specifico
del dominio)
– Differenti obiettivi (efficienza e facilità di manutenzione
vs massima funzionalità)
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
24
 Tecniche di elicitazione
 Interviste
– Permettono di interagire direttamente con lo stakeholder e di
capire il suo punto di vista
– Prendono molto tempo
 Questionari
– Permettono di avere dati quantificabili e comparabili con
sistemi statistici scientifici
– Le risposte sono focalizzate alle sole domande specifiche e
non è possibile risolvere incomprensioni o malintesi
 Focus group
– Permettono di rilevare nuove informazioni dalla discussione e
dall’interazione
– Fanno emergere solo le opinioni “pubbliche”
 Osservazione diretta
– Gli stakeholder sono osservati mentre lavorano, permettendo
di elicitare informazioni tacite o processi automatici
– Effetto Howthorne: le persone che sanno di essere osservate
si comportano differentemente rispetto a quando non sono
osservate
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
25
 Elicitation: suggerimenti
Combinare differenti tecniche
Creare un ambiente in cui gli stakeholder si
sentano a loro agio
Stimolare gli stakeholder a mostrare materiale,
esempi ed a dimostrare le proprie idee
Bilanciare atteggiamenti di ascolto o passivi con
quelli di guida od intrusivi
Definire a priori:
– Lo scopo delle riunioni
– Le aspettative dell’analista, ciò che verrà richiesto allo
stakeholder
– I termini chiave
– Come verranno utilizzate le informazioni
– Come le informazioni saranno utili per entrambi
(analista e stakeholder)
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
26
 Uso di scenari per l’elicitazione
“A scenario is a story about use” (J. Carrol 2002)
Attraverso gli scenari è possibile capire meglio gli
obiettivi degli stakeholder
Gli scenari possono essere usati per elicitare i
profili utente
Gli scenari sono un buon mezzo di comunicazione
tra l’analista e gli stakeholder
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
27
 Esempio: Opendrama
User profile
Goal
Tasks
Milano, 23 gennaio 2003
Un appassionato d’opera lirica, di 20-30 anni e con una
buona familiarità con le tecnologie Web
vuole prepararsi ad uno spettacolo.
L’utente accede al cartellone della stagione attuale. Il
centro di collezione mostra una lista di spettacoli in
cartellone, sia già avvenuti che futuri. L’utente
seleziona una futura rappresentazione dell’Aida diretta
da Riccardo Muti. Si accede alle informazioni della
performance e si naviga tra di essi. L’utente naviga
attraverso l’associazione semantica verso l’Opera
correlata e naviga anche tra quei contenuti. Poi scarica
il libretto. Infine torna alla edizione corrente e compra
un biglietto.
-
© TEC-LAB 2003 -
www.tec-lab.ch
28
 Esempio: Opendrama
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
29
 Esempio: Opendrama
1
2
3
4
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
30
 Web Requirements Management
ELICITATION
ANALYSIS
SPECIFICATION
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
31
 Dall’elicitazione all’analisi
Il “prodotto” dell’attività di elicitazione è un mix
destrutturato di:
– Bisogni, aspettative, scenari, esempi di soluzione,
visioni, obiettivi, regole di business, vincoli tecnici, sogni
di design, ecc.
– Registrati in differenti forme: documenti, grafici, tabelle,
ecc.
La prossima attività è filtrare, decidere ed
analizzare cosa fare per giungere a soluzioni di
design
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
32
 AWARE
Analysis of Web Applications Requirements
Metodologia e notazione per l’analisi e la
specifica dei requisiti di applicazioni Web
Semplice e comprensibile
Goal-based
Goal-based
Il primo passo non è definire ciò che
Tool: UWA Add-in
for Rational Rose
l’applicazione deve fare (i requisiti) ma
perché, quali siano gli obiettivi di business
dei committenti, le esigenze degli utenti,
ecc.
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
33
 Vantaggi di un approccio goal-based
Mettere in relazione i requisiti con gli obiettivi che
essi soddisfano
Mettere in relazione i requisiti con il contesto
dell’azienda e con il contesto di business
Permettere di tener traccia delle decisioni di
design
Facilitare la validation
Gestire i cambiamenti
Supportare il riuso
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
34
 Analisi dei requisiti
 L’analisi dei requisiti consiste nel decidere, filtrare e
ridefinire goal fattibili in requisiti applicativi, in accordo con
i vincoli e le risorse disponibili
Stakeholders’
Goals
Constraints
User Scenarios
Time and budget
resources
Requirements set
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
35
 Dai goal ai requisiti
Questo è il passo chiave tra lo spazio dei problemi
allo spazio delle soluzioni
L’analista riflette sul materiale raccolto
Decide come risolvere gli obiettivi ed i bisogni
degli stakeholder
Tiene traccia delle relazioni tra stakeholder e goal
Scompone i goal in subgoal ed infine in requisiti
applicativi
Tiene traccia di ogni cambiamento di obiettivi
Tiene traccia delle decisioni prese sui requisiti e
delle loro ragioni
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
36
 Esempio: Louvre
Plan a Visit
Museum
Visitor
Goal
Refinement
Process
Quickly Find
Practical Visit
Information
Provide C
Clear and
Complete
Visit Info
Milano, 23 gennaio 2003
Make Visit A
Info easily
accessible
-
© TEC-LAB 2003 -
www.tec-lab.ch
37
 Requirements dimensions
Le dimensioni rappresentano l’ambito di design
su cui il requisito ha implicazioni
–C Contenuto (“Informazioni sulle opere esposte”)
–S Struttura del contenuto (“Mettere in evidenza le
dimensioni reali dell’opera”)
–A percorsi di Accesso (“Informazioni sulle visite
facilmente accessibili”)
–N Navigazione (“Collegare ad ogni autore le sue opere”)
–P Presentazione (“Ogni opera su una pagina diversa”)
–U operazione dell’Utente (“Pagare con carta di credito”)
O Operazione del sistema (“Confermare che la transazione
–
è avvenuta regolarmente”)
Tassonomia aperta
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
38
 Esempio: Louvre
Plan a Visit
Requirement
Museum
Il subgoal è sufficientemente di basso livello?
Visitor
Goal
Refinement
Process
Un designer può prenderlo come input per il design?
Quickly Find
Practical Visit
Information
Provide Clear C
and Complete
Visit Info
Provide C
Clear and
Complete
Visit Info
Milano, 23 gennaio 2003
Make Visit A
Info easily
accessible
-
© TEC-LAB 2003 -
www.tec-lab.ch
39
 Non prendere decisioni premature
I requisiti non devono anticipare soluzioni di
design
Il lavoro dell’analista non deve sovrapporsi a
quello del designer
Difficoltà di bilanciare requisiti vaghi e decisioni
troppo preconfezionate
L’analista deve rinegoziare continuamente i
requisiti
Deve guardare il problema da differenti
prospettive
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
40
 Esempio: Louvre
Plan a Visit
Museum
Visitor
Goal
Refinement
Process
Quickly Find
Practical Visit
Information
Provide C
Clear and
Complete
Visit Info
Milano, 23 gennaio 2003
Make Visit A
Info easily
accessible
Relate to
Restaurant
Info
N
U
Post
Brochure
Request
-
© TEC-LAB 2003 -
www.tec-lab.ch
41
 CAVEAT
I grafi dei goal non sono use cases di UML
– Gli use cases modellano utenti in interazione
col sistema (utile per il design dettagliato)
– AWARE modella stakeholder con obiettivi
rispetto all’applicazione
– Gli stakeholder possono non essere utenti
diretti
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
42
 Esempio: Louvre
Plan a Visit
Museum
Visitor
Quickly Find
Practical Visit
Information
Provide C
Clear and
Complete
Visit Info
Milano, 23 gennaio 2003
Make Visit A
Info easily
accessible
Goal
Refinement
Process
Scenario 1
Una coppia di turisti canadesi sta pianificando un
viaggio a Parigi. I coniugiUvogliono vedere il Louvre,
Post
N sono
poiché
non
ci
mai stati. Cercano quindi di farsi
Relate to
Brochure
Restaurant
un’idea
di ciò che Request
andranno a vedere.
Info
-
© TEC-LAB 2003 -
www.tec-lab.ch
43
 Esempio: Louvre
Plan a Visit
Museum
Visitor
Choose
What to See
Scenario
2
Quickly Find
Practical Visit
Information
Get an
Idea of the
Collection
Provide C
Clear and
Complete
Visit Info
Milano, 23 gennaio 2003
Make Visit A
Info easily
accessible
Goal
Refinement
Process
A
Allow
Choice
among
selected
parts of
Collection
Un appassionato d’arte andrà
a Parigi la
Get an
settimana prossima. È Idea
stato
al Louvre diverse
of the
View
Exhibitions
volte,
perciò
Details
if è interessato alle esposizioni
Interested previste per questo periodo.
temporanee
C
Provide
C
Provide
Detailed Info
Detailed
on each Coll.
Exhibit. Info
Selection
-
© TEC-LAB 2003 -
Allow
Choice
among
Exhibitions
A
www.tec-lab.ch
44
 Esempio: Louvre
Goal
Refinement
Process
Plan a Visit
Museum
Visitor
Scenario 3
Choose
Quickly
Find
Un professore
d’arte ha sentito
di una esposizione
What toparlare
See
Practical Visit
Find Temporary
Exhibitions
di pittori
impressionisti al Louvre. Vuole portare la sua classe liceale a vederla,
Information
ma non sa per quando è prevista questa esposizione.
Get an
Idea of the
Collection
Provide C
Clear and
Complete
Visit Info
Milano, 23 gennaio 2003
Make Visit A
Info easily
accessible
A
Allow
Choice
among
selected
parts of
Collection
Get an
Idea of the
Exhibitions
View
Details if
Interested
C
Provide
C
Provide
Detailed Info
Detailed
on each
Exhibit. Info
Selection
-
© TEC-LAB 2003 -
Allow
Choice
among
Exhibitions
Find
Exhibitions
on a Specific
Date
C
Allow Access to A
Exhibit. by Date
www.tec-lab.ch
45
 Esempio: Louvre
Plan a Visit
Museum
Visitor
?
Get an
Idea of the
Collection
Milano, 23 gennaio 2003
Make Visit A
Info easily
accessible
Find Temporary
Exhibitions
Choose
What to See
Quickly Find
Practical Visit
Information
Provide C
Clear and
Complete
Visit Info
Goal
Refinement
Process
A
Allow
Choice
among
selected
parts of
Collection
Get an
Idea of the
Exhibitions
View
Details if
Interested
C
Provide
C
Provide
Detailed Info
Detailed
on each
Exhibit. Info
Selection
-
© TEC-LAB 2003 -
Allow
Choice
among
Exhibitions
Find
Exhibitions
on a Specific
Date
C
Allow Access to A
Exhibit. by Date
www.tec-lab.ch
46
 Esempio: Louvre
Goal
Refinement
Process
Plan a Visit
Quickly Find
ractical Visit
nformation
Get an
Idea of the
Collection
Make Visit A
Info easily
accessible
Milano, 23 gennaio 2003
Find Temporary
Exhibitions
Choose
What to See
A
Allow
Choice
among
selected
parts of
Collection
View
Details if
Interested
C
Provide
C
Provide
Detailed Info
Detailed
on each
Exhibit. Info
Selection
Get an
Idea of the
Exhibitions
Allow
Choice
among
Exhibitions
-
Find
Exhibitions
on a Specific
Date
C
Find a
Specific
Exhibition
A
Allow Access to A
Exhibit. by Date
© TEC-LAB 2003 -
www.tec-lab.ch
Allow Access
to Exhibit. by
Theme
47
 L’analisi è un processo iterativo
L’analisi non è un processo lineare
L’analista deve rimanere flessibile a continue
revisioni
Deve continuare ad incontrarsi con gli
stakeholder per validare le decisioni prese
Deve risolvere i fraintendimenti
Deve risolvere i conflitti tra diversi goal di
differenti stakeholder
Deve esplorare soluzioni alternative
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
48
 Web Requirements Management
ELICITATION
ANALYSIS
SPECIFICATION
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
49
 Specifica dei requisiti
La specifica dei requisiti è la documentazione del
risultato del processo di analisi
Tale specifica non è una specifica di design ma
serve come input per il design
Le specifiche dei requisiti sono informali, quelle di
design sono semi formali o formali
La specifica dei requisiti è uno strumento di
comunicazione (e di analisi) con obiettivi specifici
ed un pubblico-target
La documentazione è un modo per autovalutarsi e
per permettere agli altri di valutare (ed essere
d’accordo o no con) le scelte fatte
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
50
 Scopo e pubblico della specifica
Definire i requisiti cruciali dell’applicazione Web
da costruire
Comunicare con gli stakeholder
– Per discutere e negoziare le decisioni
– Per documentare i risultati dell’elicitazione
– Per mostrare i risultati dell’analisi
Comunicare coi progettisti
– Per aiutarli a capire cosa fare
– Per aiutarli ad organizzare il design
– Per permettere loro di prendere decisioni basate sugli
obiettivi reali dell’applicazione
Assicurare coerenza e coordinamento tra i gruppi
di lavoro
– Analisti, Progettisti, Grafici, Tecnici/Implementatori,
Esperti di usabilità, Web Master, Fornitori di contenuti,
…
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
51
 La specifica dei requisiti deve…
Specificare i requisiti cruciali e tralasciare i
dettagli
Essere leggibile (altrimenti è inutile)
Tener conto che esistono delle “assunzioni”
inespresse (consistenza grafica, usabilità, ecc.)
Essere facile da capire per i progettisti
(strutturata)
Essere facile da capire per gli stakeholder
(informale)
Le notazioni attualmente presenti in letteratura
– sono troppo poco espressive oppure
– eccessivamente complesse
– non catturano la specificità del Web e dei requisiti
ipermediali
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
52
 AWARE: notazione
.4
Scenario
Exemplify
.1
Stakeholder
Stakeholder priority
[1,n]
Own
Help uncover
Relevance of a
goal for a
stakeholder
.6
Refine
[1,n]
Goal
[1,n]
[1,n]
Operazionalize
[1,n]
Dimension [0,N]
Requirement
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
53
 Dai requisiti al design
Le dimensioni aiutano ad organizzare le attività di
design
I progettisti possono leggere i requisiti
– “per dimensione”
– “per stakeholder”
– “per goal”
I progettisti possono poi adottare una
metodologia di design (W2000, UML, WebML,
HDM, informale, ecc.) per delineare soluzioni di
design in termini di specifiche dettagliate che
risolvano i requisiti
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
54
 Ricapitolazione
AWARE è un modello goal-oriented per la
gestione dei requisiti di applicazioni Web
Aiuta ad evidenziare il „perché“ dei requisiti
Elicitazione: far emergere obiettivi e bisogni
Analisi: filtrare e raffinare i goal in requisiti
Specifica: documentare i requisiti
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
55
 Vantaggi
AWARE registra i risultati dell‘elicitazione
È uno strumento strutturato per l‘analisi
È uno strumento per la negoziazione e la
comunicazione con lgi stakeholder
È un input strutturato per il design
Aiuta a mantenere la tracciabilità
– Mostra al cliente che tutti i goal sono stati efficacemente
tenuti in considerazione
– Supporta le „impact analysis“
– Aiuta i progettisti a prendere decisioni basate sui reali
obiettivi dell‘applicazione
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
56
 Bibliografia (1)
 Davis, A., Just Enough Requirements Management, T01 Tutorial
Notes, IEEE Joint International Workshop on Requirements
Engineering, Essen, September 2002.
 Browne, J., Ramesh, V., Improving Information Requirements
Determination: a Cognitive Perspectives,
Information&Management, 39 (2002), pagg. 625-645.
 Gause, D., Weinberg, G., Exploring Requirements – Quality Before
Design, Dorset House, 1989.
 Bolchini, D., Paolini, P., Capturing Web Application Requirements
Through Goal-Oriented Analysis, Proc. Workshop WER 02 on
Requirements Engineering, Valencia, November 2002.
 Bolchini, D., Paolini, P., Goal-Oriented Requirements
Specifications for Digital Libraries, Proc. ECDL conference, Rome,
September 2002.
 Carroll, J.M., Making Use. Scenario-based design of human-computer
interactions, MIT Press, 2000.
 Sutcliffe, A., User-Centred Requirements Engineering, Springer,
2002
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
57
 Bibliografia (2)
 A. van Lamsweerde. Requirements Engineering in the Year 00: A
Research Perspective. In Proceedings of ICSE’2000 – 22nd
International Conference on Software Engineering, Limerick, 2000.
ACM Press. Invited Paper.
 Mylopoulos, J., Chung, L., Yu, E., “From object-oriented to goaloriented requirements analysis”, Communications of ACM, Vol. 42
No. 1, January 1999, 31-37.
 Robertson, S., Robertson, J., Mastering the Requirements Process,
Addison Wesley, 1999.
 UWA Consortium, www.uwaproject,org, public downloads.
 Potts C., Using schematic scenarios to understand user needs,
Conference proceedings on Designing interactive systems:
processes, practices, methods, & techniques, August 1995.
 Antòn, A., Goal Identification and Refinement in the specification
of Software-based Information Systems, Ph.D Dissertation,
Georgia Institute of Technology, Atlanta, GA, 1997.
 Nüell, N., Schwabe, D., Vilain, P., Modeling Interactions and
Navigation in Web Applications, Proceedings of the World Wide
Web and Conceptual Modeling'00 Workshop, ER'00 Conference,
Springer, Salt Lake City, 2000.
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
58
 Bibliografia (3)
 Dömges, R. & Pohl, K. (1998). Adapting Traceability Environments
to Project-Specific Needs. In: Communications of the ACM, Vol.
41, No. 12 (dec 1998), pp. 54-62
 Egyed, A., Gruenbacher, P. & Medvidovic, N. (2000). Refinement
and Evolution Issues in Bridging Requirements and Architectures.
Technical Report of USCCSE.
 Gotel, O. & Finkelstein, A. (1994). An Analysis of the Requirements
Traceability Problem. In: Proceedings of International Conference on
Requirements Engineering (ICRE), IEEE CS Press, pp. 94-101.
 Gotel, O. & Finkelstein, A. (1995). Contribution Structures. In:
Proceedings of 2nd International Symposium on Requirements
Engineering (RE ’95), York, UK, pages 100-107.
 Gotel, O. & Finkelstein, A. (1996). Making requirements Elicitation
traceable.
 Haumer, P., Pohl, K. & Weidenhaupt, K. (1998). Requirements
Elicitation and Validation with Real world Scenes. CREWS Report
98-16. In: IEEE Transactions on Software Engineering, Vol. 24, No.
12 (dec 1998). Special Issue on Scenario Management.
Milano, 23 gennaio 2003
-
© TEC-LAB 2003 -
www.tec-lab.ch
59