Web Engineering L2: Requirements Elicitation for the Web (2/8)
0 likes76 views
Il documento tratta della progettazione di applicazioni web nel contesto di un corso di master, evidenziando l'importanza della raccolta e analisi dei requisiti di sistema. Viene descritto il processo di estrazione dei requisiti, differenziando tra requisiti funzionali e non funzionali, e proponendo diverse tecniche per la loro identificazione. Si sottolinea l'importanza di strumenti come i diagrammi dei casi d'uso per documentare i requisiti e comunicare con gli utenti e gli stakeholder.
![MWT– Progettazione di Applicazioni Web Henry Muccini
13
Requirements Elicitation [estrazione]
Involves technical staff working with
customers to find out about the
application domain, the services that the
system should provide and the system’s
operational constraints.](https://image.slidesharecdn.com/webengineeringl2reqcollection-180415103142/85/Web-Engineering-L2-Requirements-Elicitation-for-the-Web-2-8-13-320.jpg)
![MWT– Progettazione di Applicazioni Web Henry Muccini
69
Estensione
Seleziona Esame
Verifica Idoneità studente
Studente
Prenota Appello
<<extend>>
<<extend>>
Validazione utente
<<include>> Extensions points:
Transazione abilitata
Verifica idoneità
(Transazione abilitata)
[Studente abilitato]
(Verifica idoneità)
[Appello selezionato]](https://image.slidesharecdn.com/webengineeringl2reqcollection-180415103142/85/Web-Engineering-L2-Requirements-Elicitation-for-the-Web-2-8-70-320.jpg)
Web Engineering L2: Requirements Elicitation for the Web (2/8)
- 1. Progettazione di Applicazioni Web corso del Master in Web Technology a.a. 2017-2018 https://app.schoology.com/course/1511186315/ Henry Muccini Università degli Studi dell’Aquila 2. Collezione e descrizione dei requisiti del sistema web
- 2. MWT– Progettazione di Applicazioni Web Henry Muccini 2 Note Orario di inizio: 9:30 MAT, 14:00 POM Gruppo Skype • #Principi • #Difficolta’ SVN Skip the Slides
- 3. MWT– Progettazione di Applicazioni Web Henry Muccini 3 NOTE: Problema identificato: gestione dei tempi! 1. Il cliente cambia i requisiti!! • Imp: meeting con «tutti» i clienti • Imp: vincolare il cliente a quanto e’ stato scritto ed approvato 2. I tempi tecnici di sviluppo non corrispondono con i tempi stimati Principio: definire il «criterio» usato per guidare la design decision Principio: sviluppo incrementale, con identificazione dei task prioritari Principio: Dipendenze tra task
- 4. MWT– Progettazione di Applicazioni Web Henry Muccini 4 Copyright Notice Il materiale riportato in queste slide puo’ essere riutilizzato, parziale o totalmente, a patto che le fonti e gli autori vengano citati Henry Muccini
- 5. MWT– Progettazione di Applicazioni Web Henry Muccini 5
- 6. Raccolta ed Analisi di Informazioni
- 7. MWT– Progettazione di Applicazioni Web Henry Muccini 7 Salta le slides: Quiz! Cosa sono i Requisiti funzionali del sistema? Cosa sono i system boundaries? Fatemi un esempio di vincoli di sistema (NFR)! Valore contrattuale dei requisiti?
- 8. MWT– Progettazione di Applicazioni Web Henry Muccini 8 Requirements engineering The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed. The system requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process.
- 9. MWT– Progettazione di Applicazioni Web Henry Muccini 9 What is a requirement? high-level abstract statement of a service or of a system constraint detailed mathematical functional specification. define the system boundaries Requirements may serve a dual function – May be the basis for a bid for a contract - therefore must be open to interpretation; – May be the basis for the contract itself - therefore must be defined in detail; What is inside, what is outside the system?
- 10. MWT– Progettazione di Applicazioni Web Henry Muccini 10 Functional and non-functional requirements Functional requirements – Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. – May state what the system should not do. Non-functional requirements – Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. – Often apply to the system as a whole rather than individual features or services.
- 11. MWT– Progettazione di Applicazioni Web Henry Muccini 11 Functional requirements Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail.
- 13. MWT– Progettazione di Applicazioni Web Henry Muccini 13 Requirements Elicitation [estrazione] Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.
- 14. MWT– Progettazione di Applicazioni Web Henry Muccini 14 The requirements elicitation and analysis process
- 15. MWT– Progettazione di Applicazioni Web Henry Muccini 15 The requirements elicitation and analysis process
- 16. MWT– Progettazione di Applicazioni Web Henry Muccini 16 Techniques to DISCOVER Requirements Bridging the gap between end user and developer: – Questionnaires & Interviews – Ethnography – User Stories & Scenarios – Use cases – State-of-the art analysis discussion
- 17. MWT– Progettazione di Applicazioni Web Henry Muccini 17 Techniques to DISCOVER Requirements Bridging the gap between end user and developer: – Questionnaires & Interviews: Asking the end user a list of pre-selected questions – Ethnography: Observing end users in their operational environment – User Stories & Scenarios: Describe the use of the system as a series of interactions between a concrete end user and the system – Use cases: Abstractions that describe a class of scenarios. – State-of-the art analysis: Competitors analysis discussion
- 18. MWT– Progettazione di Applicazioni Web Henry Muccini 18 Scenarios – Scenarios and user stories are real-life examples of how a system can be used – A synthetic description of an event or series of actions and events. – A scenario can include text, video, pictures and story boards. It usually also contains details about the work place, social situations and resource constraints.
- 19. MWT– Progettazione di Applicazioni Web Henry Muccini 19 Scenarios: should include – A description of the starting situation; – A description of the normal flow of events; – A description of what can go wrong; – Information about other concurrent activities; – A description of the state when the scenario finishes.
- 20. MWT– Progettazione di Applicazioni Web Henry Muccini 20 After the scenarios are formulated Find all the use cases in the scenario that specify all instances of how to report a fire – Example: “Report Emergency“ in the first paragraph of the scenario is a candidate for a use case Describe each of these use cases in more detail – Participating actors – Describe the entry condition – Describe the flow of events – Describe the exit condition – Describe exceptions – Describe nonfunctional requirements Functional Modeling (see next lecture)
- 21. MWT– Progettazione di Applicazioni Web Henry Muccini 21Questionario – Esempi concreti elaborato corso di Software Architecture
- 22. MWT– Progettazione di Applicazioni Web Henry Muccini 22Scenario - Esempi concreti Servizio Prenotazione Segreteria Scenario 1 Andrea prenota un appuntamento per il giorno 25/11/2016 alle ore 11:00 della durata di 20 minuti per il servizio X. Il giorno stabilito alle 11:20 Maria (l’operatore) si rende conto che è necessario che Andrea torni nuovamente per fornire ulteriori documenti, allora Maria concorda con Andrea una nuova data e gli riserva un nuovo appuntamento. Andrea riceve immediatamente la notifica della nuova prenotazione. Scenario 2 Andrea, Giulio e Giorgio richiedono un appuntamento per il servizio Y, Maria (l’operatore) sa che per il servizio Y è necessario compilare di persona n documenti e crede di poter servire tutti e tre nello stesso momento quindi riserva loro 3 appuntamenti per lo stesso orario.
- 23. MWT– Progettazione di Applicazioni Web Henry Muccini 23Lista di Servizi – Esempio concreto Servizio Prenotazione Segreteria https://docs.google.com/document/d/1bo55UmqvITv NiPDPS6uPTi4rXeJ2VCUIeCySR- pljQk/edit?usp=sharing
- 24. MWT– Progettazione di Applicazioni Web Henry Muccini 24Lista di Servizi - Esempio elaborato corso di Software Architecture
- 25. MWT– Progettazione di Applicazioni Web Henry Muccini 25 User Story - Esempio As a < type of user >, I want < some goal > so that < some reason >. As a user, I can backup my entire hard drive. Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two: As a power user, I can specify files or folders to backup based on file size, date created and date modified. As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved. https://www.mountaingoatsoftware.com/agile/user-stories
- 26. MWT– Progettazione di Applicazioni Web Henry Muccini 26
- 27. MWT– Progettazione di Applicazioni Web Henry Muccini 27 The requirements elicitation and analysis process
- 28. MWT– Progettazione di Applicazioni Web Henry Muccini 28 Classificazione dei requisiti Funzionali Non funzionali
- 29. MWT– Progettazione di Applicazioni Web Henry Muccini 29
- 30. MWT– Progettazione di Applicazioni Web Henry Muccini 30 The requirements elicitation and analysis process
- 31. MWT– Progettazione di Applicazioni Web Henry Muccini 31 Prioritizing requirements High priority – Addressed during analysis, design, and implementation – A high-priority feature must be demonstrated Medium priority – Addressed during analysis and design – Usually demonstrated in the second iteration Low priority – Addressed only during analysis – Illustrates how the system is going to be used in the future with not yet available technology
- 32. MWT– Progettazione di Applicazioni Web Henry Muccini 32 The requirements elicitation and analysis process
- 33. MWT– Progettazione di Applicazioni Web Henry Muccini 33 Ways of writing a system requirements specification Notation Description Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured natural language The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement. Design description languages This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications. Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. Mathematical specifications These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract
- 34. Use Case Diagram
- 35. MWT– Progettazione di Applicazioni Web Henry Muccini 35 Sommario Use Case Diagram – Attore – Use Case – Attore e Use Case – Relazione tra attori (generalizzazione) – Relazioni tra use case
- 36. MWT– Progettazione di Applicazioni Web Henry Muccini 36 Nota Gli Use Case Diagrams sono solo uno dei tanti modi possibili per documentare i requisiti – L’importante non e’ il linguaggio che si usa Gli UC Diagrams aiutano (ed “obbligano”) l’utente a seguire certi ragionamenti e a documentarli
- 37. MWT– Progettazione di Applicazioni Web Henry Muccini 37 Use Case Diagram Specifica le funzionalita’ del sistema Use Case Specifica gli attori umani o automatici che utilizzano il sistema (e le sue funzionalita’) Attori Evidenzia come le funzionalità del sistema vengono messe a disposizione degli utilizzatori del sistema Use Case Diagram = Use Case, attori, e relazioni tra loro Catturano il comportamento di un sistema che si sta sviluppando, senza specificare come il sistema lo implementerà Costituiscono il contratto tra il committente e l’implementatore del sistema
- 38. MWT– Progettazione di Applicazioni Web Henry Muccini 38 Vantaggi Strumento facilmente comprensibile dagli utenti e quindi utilizzati per comunicare ed ottenere la validazione dei requisiti Permettono di definire chiaramente i confini del sistema ed evidenziarne i vari attori (umani e non) Esprimono il comportamento del sistema, evidenziando eventuali incoerenze e lacune nella fase di analisi dei requisiti Forniscono un’ottima documentazione
- 39. MWT– Progettazione di Applicazioni Web Henry Muccini 39
- 40. MWT– Progettazione di Applicazioni Web Henry Muccini 40 Processo indotto da use case diagrams Estrarre requisiti funzionali (use cases) Identificare gli stakeholder (attori) che utilizzeranno tali funzioni Definire relazioni tra requisiti funzionali (specializzazione) Definire relazioni tra use cases (specializzazione, include, extend, …) Documentare, in forma tabellare, i requisiti funzionali del sistema Tale diagramma viene poi usato per guidare la fase di design
- 41. MWT– Progettazione di Applicazioni Web Henry Muccini 41 Sistema Prima di iniziare a modellare le funzionalità del sistema è necessario determinare i confini del sistema stesso E’ necessario stabile i confini in modo tale che non si rischia di modellare entità che non fanno parte del sistema Graficamente è rappresentato come un rettangolo che contiene tutti gli use case del sistema E’ opzionale e viene fatto raramente H1
- 42. Slide 41 H1 esempio di "confini" nell'esempio Trip4You Henry; 06/01/2014
- 43. MWT– Progettazione di Applicazioni Web Henry Muccini 42 Sistema Questo box non rappresenta per forza un package. Puo’ rappresentare un qualsiasi modo di collezionare Use Cases
- 44. MWT– Progettazione di Applicazioni Web Henry Muccini 43 Attore Insieme coerente di ruoli che un utente di un caso d’uso (funzionalità) recita quando interagisce con esso Non necessariamente persona fisica, può essere anche un altro sistema E’ un’entità esterna al sistema oggetto di modellazione Rappresentato mediante un omino stilizzato (stick man)
- 45. MWT– Progettazione di Applicazioni Web Henry Muccini 44 Attore UML2.x: Icone specifiche possono essere introdotte per non-human actors Amministratore Cliente Studente Universitario Billing System Legacy System
- 46. MWT– Progettazione di Applicazioni Web Henry Muccini 45 Attore Attori comunicano con il sistema inviando o ricevendo messaggi Due tipi – Primari: utilizzano le funzioni proprie del sistema; sono detti attivi – Secondari: fruiscono di informazioni o notifiche generate da use case; sono detti passivi Attore può essere attivo in uno use case e passivo in un altro
- 47. MWT– Progettazione di Applicazioni Web Henry Muccini 46 Use Case Descrizione di un insieme di sequenze di azioni che un sistema esegue per ottenere un risultato osservabile di valore per un attore Sequenza di azioni che l’entità esegue interagendo con il relativo attore che sono necessarie per erogare un certo servizio Rappresentano quindi i requisiti funzionali del sistema
- 48. MWT– Progettazione di Applicazioni Web Henry Muccini 47 Use Case Graficamente è rappresentato mediante una ellisse Ha un nome che identifica la funzionalità – Può essere semplice o con path (se appartiene ad un package) – Generalmente i nomi sono frasi brevi prese dal vocabolario del sistema che si sta modellando Ha una breve descrizione che descrive il ruolo e lo scopo dello use case
- 49. MWT– Progettazione di Applicazioni Web Henry Muccini 48 Use Case Validate user Place Order Sensors::Calibrate location
- 50. MWT– Progettazione di Applicazioni Web Henry Muccini 49 Use Case Descrive cosa un sistema fa (le sue funzionalità) ma non come, cioè la sequenza di azioni eseguita dal sistema per realizzare una determinata funzionalità E’ necessario descrivere un flusso di eventi che modella il comportamento dello use case Flusso di eventi può essere descritto – Formato testuale: generalmente rappresentato tramite pseudo-codice (cioè testo strutturato) – Formalmente: mediante activity oppure tramite sequence (generalmente vengono utilizzati successivamente alla descrizione testuale)
- 51. MWT– Progettazione di Applicazioni Web Henry Muccini 50 Use Case Flusso di eventi è composto – Flusso principale (basic flow o happy path) Descrive quello che accade il più delle volte quando viene eseguito lo use case – Flussi alternativi Generalmente descrivono i flussi eccezionali (cioè che gestiscono situazioni di errori) oppure flussi che si verificano raramente. Sono utilizzati anche per organizzare use case complessi
- 52. MWT– Progettazione di Applicazioni Web Henry Muccini 51 Use Case Pre-condizioni – Definiscono lo stato in cui si deve trovare il sistema prima che inizi lo use case – Possono essere descritte in forma testuale oppure formale (es. O.C.L.) Post-condizioni – Definiscono una lista di possibili stati in cui si deve trovare il sistema dopo che è terminato lo use case – Possono essere descritte in forma testuale oppure formale (es. O.C.L.)
- 53. MWT– Progettazione di Applicazioni Web Henry Muccini 52 Esempio Registrazione CorsiStudente Catalogo Corsi UML2.0: Notazione alternativa per Use Cases
- 54. MWT– Progettazione di Applicazioni Web Henry Muccini 53 Bacheca Virtuale: funzionalita’ analizzate dai gruppi – Il sistema deve permettere di: • Anagrafica messaggi: – Inserire, modiicare, cancellare e leggere messaggi – Anonimato • Identificare categorie di messaggi • Autenticazione, Registrazione, modifica, controllo diritti di accesso • Scadenza messaggi • Ricerca (con certi criteri) di messaggi • Moderazione sui messaggi • Newsletter sulla categoria di interesse • Profilo utente • Contatto: email, sms, chat • Amministrazione del sito
- 55. MWT– Progettazione di Applicazioni Web Henry Muccini 54 Considerazioni Solo funzionalita’, non altro! Cos’e’ una funzionalita’? Non tutte le funzionalita’ sono allo stesso livello di astrazione Una funzionalita’ puo’ contenere altre sotto- funzionalita’ Alcune funzionalita’ possono essere simili Alcune funzionalita’ possono richiedere altre funzionalita’ come pre-condizione Non tutte le funzionalita’ hanno la stessa importanza Diversi attori richiedono diverse funzionalita’ Accorpare funzionalita’
- 56. MWT– Progettazione di Applicazioni Web Henry Muccini 55 Attore e Use Case Attori sono entità esterne al sistema che interagiscono con esso Le interazioni consistono in uno scambio di messaggi Attore è connesso con gli use case mediante una relazione di associazione che permette di attivare (attore attivo) lo use case o di ricevere (attore passivo) i risultati
- 57. MWT– Progettazione di Applicazioni Web Henry Muccini 56 Attore e Use Case Relazione di associazione è l’unica relazione possibile tra attore e use case Può avere la proprietà di navigazione (cioè può esserci una freccia) la quale indica, per convenzione, la direzione dell’inizio della comunicazione tra lo use case e l’attore Per una comunicazione che coinvolge una risposta non è necessario inserire la freccia nella parte che ha attivato la funzionalità Se la comunicazione iniziale avviene da entrambe le direzioni le frecce vengono omesse
- 58. MWT– Progettazione di Applicazioni Web Henry Muccini 57 Attore e Use Case Cliente Effettua Ordine Verifica Ordine Ve nditore
- 59. MWT– Progettazione di Applicazioni Web Henry Muccini 58 Generalizzazione tra attori Può succedere che attori presentino diverse e significative similitudini E’ possibile raccogliere a fattor comune tale similitudini creando un attore padre ed esprimere gli altri attori in termini di estensione del primo Rappresentato come la relazione di generalizzazione tra classi
- 60. MWT– Progettazione di Applicazioni Web Henry Muccini 59 Generalizzazione tra attori Ve nditore Supervisore Studente Studente full-time Studente part-time
- 61. MWT– Progettazione di Applicazioni Web Henry Muccini 60 Generalizzazione tra attori Venditore Inserimento Ordine Verifica Stato Ordine Annullamento Ordine Supervisore Generazione Report
- 62. MWT– Progettazione di Applicazioni Web Henry Muccini 61 Generalizzazione tra attori Venditore Inserimento Ordine Verifica Stato Ordine Annullame nto Ordine Supervisore Ge nerazione Re port
- 63. MWT– Progettazione di Applicazioni Web Henry Muccini 62 Relazioni tra Use Case Generalizzazione Inclusione Estensione Realizzazione – Collaboration
- 64. MWT– Progettazione di Applicazioni Web Henry Muccini 63 Generalizzazione Può capitare che diversi use case presentino somiglianze e condividano comportamento E’ possibile utilizzare la generalizzazione per creare uno use case genitore (che contiene le somiglianze) ed estenderlo (modificando il comportamento o aggiungendo dei passi allo use case) mediante casi d’uso figli Rappresentata come la generalizzazione tra classi L’esecuzione degli use case “fratelli” è esclusiva
- 65. MWT– Progettazione di Applicazioni Web Henry Muccini 64 Generalizzazione Cliente Validazione Utente Check Password Scansione Retina
- 66. MWT– Progettazione di Applicazioni Web Henry Muccini 65 Inclusione Relazione tra due use case, dove uno use case include il comportamento dell’altro E’ simile al concetto di chiamata di funzione (metodo) Rappresentata con una linea tratteggiata (dipendenza) e con lo stereotipo <<include>> Nella versione 1.3 di UML era rappresentata come uno stereotipo (<<uses>>) della relazione di generalizzazione. Poteva generare confusione
- 67. MWT– Progettazione di Applicazioni Web Henry Muccini 66 Inclusione Reperimento Dati Cliente Repe rimento Articoli Cliente Compila Ordine <<include>> <<include>> La funzionalita’ di “compilare ordine” <<include>> anche delle sottofunzionalita’ quali “reperimento dati cliente” e “reperimento articoli”. A volte <<include>> si puo’ considerare anche come una pre-condizione
- 68. MWT– Progettazione di Applicazioni Web Henry Muccini 67 Estensione Vengono utilizzate per modellare condizioni facoltative rispetto al flusso principale Relazione tra uno use case estendente e uno base che specifica come il comportamento definito dal primo (l’estendente) debba essere inserito nel comportamento di quello base Nello use case base ci saranno dei punti che verranno estesi (punti di estensione) dagli use case estendenti Tali punti prevedono delle condizioni di guardia (cioè condizioni che si devono verificare per eseguire la parte estesa)
- 69. MWT– Progettazione di Applicazioni Web Henry Muccini 68 Esempio
- 70. MWT– Progettazione di Applicazioni Web Henry Muccini 69 Estensione Seleziona Esame Verifica Idoneità studente Studente Prenota Appello <<extend>> <<extend>> Validazione utente <<include>> Extensions points: Transazione abilitata Verifica idoneità (Transazione abilitata) [Studente abilitato] (Verifica idoneità) [Appello selezionato]
- 71. MWT– Progettazione di Applicazioni Web Henry Muccini 70 Inclusione vs. Estensione Se la sequenza di azioni di uno use case deve avvenire solo al verificarsi di determinate condizioni allora utilizzare estensione Se use case (o parte di) può essere riutilizzato da altri use case allora conviene utilizzare inclusione
- 72. MWT– Progettazione di Applicazioni Web Henry Muccini 71 Come Realizzare gli Use Case Diagram: Use Case Centric Actor Centric
- 73. MWT– Progettazione di Applicazioni Web Henry Muccini 72 Use Case Centric vs Actor Centric Use Case centric: – Per ciascuno Use Case, si identificano tutti gli attori • Puo’ diventare complesso Actor centric – Per ciascun attore, si identificano tutti i suoi use case • Se ho “n” use case, esistono “n” use case diagram • Ripetizione di Use Case
- 74. MWT– Progettazione di Applicazioni Web Henry Muccini 73 Use Case centric
- 75. MWT– Progettazione di Applicazioni Web Henry Muccini 74 Actor centric Ospite 1.1 Visualizza Offerta Formativa 1.2 Visualizza Modulistica 1.3 Visualizza Area Didattica 1.4 Visualizza News e Avvisi 1.5 Informazioni Generali «uses» «uses» «uses» «uses» «uses» Use Case 1 – Funzionalità Ospite
- 76. MWT– Progettazione di Applicazioni Web Henry Muccini 75 Template per Use Case, basic 1.3 •Visualizza Area Didattica Descrizion e Visualizza il calendario delle lezioni, l’elenco dei docenti che impartiranno le lezioni in un dato anno accademico, l’elenco dei corsi proposti in uno specifico anno accademico, nonché l’elenco delle aziende che sponsorizzano il master e i seminari da loro tenuti. Importanza Media. Evento scatenante Click dell’ospite nel menù della parte pubblica. Uses Include la visualizzazione di altre parti.
- 77. MWT– Progettazione di Applicazioni Web Henry Muccini 76 Use Case Template, advanced Use Case ID: Use Case Name: Created By: Date Created Actors: Description: Trigger: Preconditions: Postconditions: Normal Flow: Alternative Flows: Exceptions: Includes: Priority: Frequency of Use: Business Rules: Special Requirements: Assumptions: Notes and Issues:
- 78. MWT– Progettazione di Applicazioni Web Henry Muccini 77 Alistair Cockburn Use Case Template
- 79. MWT– Progettazione di Applicazioni Web Henry Muccini 78 Use Case table in Magic Draw
- 80. MWT– Progettazione di Applicazioni Web Henry Muccini 79 Lessons Learned You shall create a hierarchy of use case diagrams Do not try to put the all information on a unique diagram High-level with all functionalities, then detailed use case diagrams Only functional requirements Do not try to transform non functional requirements of data into use cases Use Case diagram is complex It seems so simple, but it is the most complicated diagram Use Case indexing: Associate an ID to use cases Usage of the <<Include>> <<extends>> stereotypes Importance of the “generalization” concept among actors