1. 1 REQUISITI (secondo IEEE <- associazioni ingegneri americana)
   1. 1) Funzionalità per utente per raggiungere obiettivo o risolvere un problema
   2. 2) Condizione/funzionalità presente nel prodotto per soddisfare contratto o standard o legge,...
      1. Cose che programmatore deve aggiungere non per sua volontà, ma per diverse esigenze
   3. 3) Documentazione funzionalità descritte al punto 1) e 2)
2. 2 Piramide dei requisiti
   1. 1)
      1. Requisiti di business
   2. 2)
      1. Requisiti degli utenti
         1. Ci si riferisce a direzione e altri utenti finali per capire loro esigenze
   3. 3)
      1. Requisiti del software
3. 3 Processo Ingegneria Requisiti
   1. FASE 1 -> INDIVIDUARE
      1. FASE 1 -> INDIVIDUARE - Identifica stakeholder - Recupero di tutta la documentazione Es: Potrebbe esserci una Intranet aziendale dove trovare le info utili
   2. FASE 2 -> ANALIZZARE
      1. - Identificare scopo prodotto - Capire interazione prodotto con utente - DARE PRIORITA' AI REQUISITI '-> necessaria NEGOZIAZIONE <- priorità cliente potrebbero non coincidere con quelle del programmatore! Vanno spiegate a cliente le vere priorità progetto
   3. FASE 3 -> SPECIFICARE
      1. - Dividere requisiti funzionali e non funzionali - Capire caratteristiche qualitative e VINCOLI
   4. FASE 4 -> VALIDARE
      1. - Capire se a cliente va bene lavoro svolto - NEI VARI MODELLI QUESTA E' LA FASE DI FEEDBACK (-> 1) 2) e 3) invece appartengono alla fase di Comunicazione)
   5. E' un CICLO perchè di solito non si finisce in un colpo solo Se nella fase 4) cliente vuole apportare modifiche, si ricomincia il ciclo
4. 4 Approcci metodologici
   1. top down
      1. generico -> specifico
         1. - Approccio più usato - Utile quando si ha ESPERIENZA (<- in questo modo difficile dimenticarsi qualche macro area)
   2. bottom up
      1. specifico -> generico
         1. - Utile quando si fa REVERSE-ENGINEERING (<- quando si prende esempio da un progetto già finito, quando si copia) - Prima si guardano funzionalità specifiche poi quadro più ampio
5. 5 Granularità
   1. Non tutti i requisiti vengono documentati con stesso livello di dettaglio
      1. grana grossa
         1. Requisiti semplici
      2. grana sottile
         1. Requisiti complessi
6. 6 Tipologia requisiti
   1. requisiti funzionali
      1. Funzioni svolte da sistema
   2. requisiti non funzionali
      1. Proprietà e vincoli sistema
         1. Es. Vincolo delle pagine web di caricarsi entro 5 sec per evitare che utente cambi pagina
   3. Sono requisiti che magari cliente non chiede, ma sui quali dobbiamo informarci noi
7. 7 Verifica e Validazione
   1. Requisiti di business
      1. decisi da chi paga
   2. Requisiti utenti
      1. si chiede cosa vorrebbero utenti
   3. Design Sistemi e sotto-sistemi
      1. Dividi et impera
      2. non si parte facendo tutto sistema -> prima vengono SUDDIVISI REQUISITI, che sono quelli raccolti prima (business, utenti, software)
   4. Design Componenti
      1. ! Qui si inizia a scrivere il codice !
   5. Test unitari
      1. simile a funzione debug Java
   6. Test di integrazione
      1. verifica che Sistemi e sotto-sistemi funzioni insieme
   7. Test di sistema
      1. x assicurarsi che non ci siano bug
   8. Test di accettazione utente
      1. è il feedback dell'utente, NON è una VERIFICA, MA una VALIDAZIONE
8. 8 Use-Case
   1. Introduzione
      1. Schema di alto livello
      2. X discutere con utenti funzioni che sistema dovrà erogare (dal loro punto di vista!!)
      3. Devono essere comprensibili a utenti SENZA CONOSCENZE INFORMATICHE
      4. In software estesi vanno suddivisi in SCENARI di utilizzo
      5. NON RAPPRESENTA IL TEMPO
   2. Elementi
      1. ATTORE
         1. Persona o dispositivo che interagisce con sistema; possono essere ATTIVI o PASSIVI, nel caso 1 si collegano agli use case con connettore 'use', nel caso 2 con 'associate'
      2. USE-CASE
         1. Funzione o servizio erogati da sistema. Possono collegarsi tra loro con 'include', 'extend' e 'generalize'
      3. ARTIFACT
   3. Connettori
      1. Extend
         1. Indica che funzione rappresentata da use case alla base della freccia PUO' essere impiegata nel contesto dello use case alla punta. Quindi ne rappresenta una sorta di arricchimento
      2. Include
         1. Indica che funzione rappresentata da use case alla base della freccia include completamente la funzione dello use case alla punta
      3. Generalize
         1. Caso d'uso che eredita caratteristiche di un altro caso d'uso, aggiungendo particolarità che lo differenziano
9. 9 Activity Diagram
   1. Introduzione
      1. Schema di alto livello
      2. Utilizzati per descrivere FLUSSI DI LAVORO (business workflow)
      3. Utilizzati x descrivere FLUSSI SISTEMA e ALGORITMI (pseudo-codice)
      4. Spesso associati a use-case (come dettaglio)
      5. Devono essere comprensibili a utenti SENZA CONOSCENZE INFORMATICHE
      6. Rappresenta attività, FLUSSI DECISIONALI, flussi concorrenti
      7. NON RAPPRESENTA IL TEMPO
      8. In caso di flussi estesi, possono essere suddivisi
   2. Elementi
      1. Activity
         1. singola attività all'interno del flusso, un solo flusso può entrare e uscire (!)
      2. Structured activity
         1. contiene un sotto flusso
      3. Activity initial
         1. inizio del flusso
      4. Activity final
         1. fine flusso
      5. Flow final
         1. fine ramo flusso, non determina fine diagramma
      6. Decision
         1. divisione del flusso
      7. Merge
         1. elemento ricezione flussi multipli
      8. Fork/Join
         1. elemento divisione/ricezione flussi PARALLELI
      9. Swimlanes
         1. elemento utile per enfatizzare attori coinvolti
   3. Connettori
      1. Control flow
         1. Collegamento logico tra elementi flusso
         2. NON RAPPRESENTA IL TEMPO
   4. Scenari EX ANTE / EX POST
      1. Uno degli utilizzi degli activity diagram è confrontare un dato flusso di lavoro (business workflow) prima (ex-ante) e dopo (ex-post) l’implementazione del software
      2. È anche possibile determinare le differenze a livello di tempi necessari per l’esecuzione, ponendo basi concrete per un analisi costi/benefici accurata
10. Possibili domande test
    1. Cos'è il sistema in use-case?
       1. E' la somma di tutti i casi d'uso
    2. Come vengono rappresentati gli attori nell'Act. Diagr.?
       1. Con le Swimlane
    3. Come vengono rappresentate attività concorrenti in AD?
       1. Con il Fork/Join
    4. Si può rappresentare tempo nell'AD?
       1. NO, ma volendo si può calcolare facendo gli scenari ex-ante e ex-post
    5. Quali sono i possibili punti di vista nello use case?
       1. 2
          1. Punto di vista degli ATTORI
             1. grazie a use case
          2. Punto di vista del SISTEMA
             1. grazie a REQUISITI funzionali e non funzionali
11. Perchè è stato avviato il progetto
    1. Progetti commissionati per: - Risparmiare - Guadagnare di più
12. Cosa gli utenti potranno fare con il prodotto
13. Cosa gli sviluppatori devono costruire
    1. - Livello con più lavoro da fare - Richiesto LINGUAGGIO TECNICO (a differenza livello 1) e 2))
14. Errori comuni
    1. 2 o + connettori escono dalla stessa attività
    2. fork aperto, ma senza join per la chiusura
    3. diagramma senza initial e/o final