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
      2. Ci si riferisce a direzione e altri utenti finali per capire loro esigenze
   3. 3)
      1. Requisiti del software
3. 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
4. 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
5. 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
6. 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)
7. 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
8. Cosa gli utenti potranno fare con il prodotto
9. Cosa gli sviluppatori devono costruire
   1. - Livello con più lavoro da fare - Richiesto LINGUAGGIO TECNICO (a differenza livello 1) e 2))
10. Perchè è stato avviato il progetto
    1. Progetti commissionati per: - Risparmiare - Guadagnare di più