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