Requisiti software

Nota:

• I requisiti: ancora oggi un anello debole Da uno studio effettuato dalla Standish Group, dei fattori che portano al fallimento di un progetto software, 5 su 8 riguardano i requisiti. Molto spesso, il fallimento del sistema viene scoperto solo alla sua messa in opera. Quali sono le cause che determinano il RITARDO nella individuazione del problema: 1) insufficiente interazione tra gli attori coinvolti 2) insufficiente individuazione dei conflitti tra requisiti 3) mancato coinvolgimento degli utenti nella verifica dei requisiti individuati dagli analisti 4) mancato coinvolgimento degli utenti per esprimere feedback sulle ipotesi progettuali 5) insufficiente controllo sull’evoluzione dei requisiti durante l’intero ciclo di vita del sistema 6) rinvio della presa in carico del nuovo requisito sopraggiunto in corso d’opera ad una release successiva 7) mancato accordo sui contenuti e/o costi e/o tempi durante la rinegoziazione per l’aggiunta di un requisito sopraggiunto in corso d’opera

1. Studio di fattibilità

   Nota:

   • OUTPUT: preventivo o documento di fattibilità
   1. valutazione preliminare di costi e benefici
   2. valutazione di opzioni alternative
   3. stima delle risorse umane e finanziarie necessarie
2. Specifica (raccolta e analisi) dei requisiti

   Nota:

   • NB La specifica dei requisiti risponde alla domanda COSA DEVE FARE IL SISTEMA non come dovrà farlo!
   • L’insieme delle attività che si occupano dei requisiti → Ingegneria dei requisiti  - requirements engineering
   1. analisi del problema: cosa deve fare il sistema
   2. definizione delle funzionalità: vincoli aziendali interni/esterni, caratteristiche sistema
   3. redazione di un documento di Specifica dei Requisiti sw: SRS Software Requirements Specification - documento formale
   4. convalida da parte del committente del SRS
3. Requisiti software e stakeholder
   1. Requisito

      Nota:

      • Def. ogni informazione circa le funzionalità, i servizi, le modalità operative e di gestione del sistema da sviluppare
      • Def. Requisito IEEE Std 610.12 (1990) A) A condition or capability needed by a user to solve a problem or achieve an objective (B) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. (C) A documented representation of a condition or capability as in definition (A) or (B)
      1. La definizione dei requisiti
         1. analizza i bisogni dell’utente
         2. indaga il dominio del problema
         3. coinvolge diverse persone
            1. sia il team di sviluppo
            2. sia l’azienda del cliente - engagement
            3. consulenti esterni (legali, sviluppatori legacy system)
         4. fattori esterni possono influenzare pesantemente i requisiti del sistema
            1. cambiamenti nell’organizzazione aziendale
            2. necessità di adeguamento a nuove politiche di mercato
            3. cambiamento a livello di obblighi legislativi
      2. La fase di analisi dei requisiti è molto delicata
         1. errori in questa fase → fallimento possibile dell’intero progetto
         2. rischi principali
            1. dimenticare o ignorare una funzionalità
            2. implementare in modo errato una richiesta
            3. realizzare interfacce utenti poco intuitive e difficili da usare
      3. Classificazione dei requisiti
         1. livello di dettaglio
            1. requisiti UTENTE
               1. osservati - proposti - dal cliente
               2. descritte con il linguaggio del cliente
               3. equisiti aperti perché sottoposti successivamente al team di sviluppo che propone una soluzione
            2. requisiti DI SISTEMA
               1. imposti da vincoli esistenti
                  1. esistenza di apparecchiature esistenti all’interno dell’azienda
                  2. vincoli di natura fiscale e/o legislativa
               2. molto strutturati e vincolanti
               3. scritti in linguaggi tecnici e/o semi-formali
               4. spesso non sono noti all’utente, ma solo al programmatore
               5. requisiti restrittivi o requisiti chiusi
         2. tipo di requisito
            1. requisiti FUNZIONALI

               Nota:

               • descrivono le funzionalità che il sistema deve avere e tutti i servizi che dovrà offrire agli utenti
               1. Devono essere COMPLETI: tutti i servizi richiesti dagli utenti
               2. Devono essere COERENTI: non devono esserci definizioni contraddittorie
            2. requisiti NON FUNZIONALI

               Nota:

               • Tutti quei requisiti imposti: dalle modalità operative dal CICLO DI VITA del prodotto dal rispetto della normativa vigent
               • Sommerville: distingue 3 macro categorie di requisiti non funzionali
               1. Req. di prodotto
                  1. affidabilità
                  2. portabilità
                  3. efficienza
                     1. spazio
                     2. performance
               2. Req. organizzativi
                  1. req. di consegna
                  2. di implementazione
                  3. su standard
               3. Req. esterni
                  1. interoperabilità
                  2. Req. etici
                  3. Req. legislativi
            3. requisiti di DOMINIO

               Nota:

               • dipendono dal DOMINIO in cui il sistema deve operare ES : - impianti industriali - riservatezza dati sensibili - accessi area riservata
      4. Verifica dei requisiti

         Nota:

         • req. funzionali - collaudo del sistema con gli utenti - verifica se le aspettative sono state soddisfatte
         • req. di dominio - collaudo del sistema con il “resto del mondo” (software aziendale preesistente, terze parti) - verifica delle normative di settore
         • req. non funzionali - spesso non quantificabili e difficili da verificare - grado di soddisfacimento del requisito
   2. Stakeholder

      Nota:

      • Le persone coinvolte sono chiamate STAKEHOLDER - portatori di interesse - e sono “persone o gruppi che influenzano e/o sono influenzati dalle attività di un’organizzazione, dai suoi prodotti o servizi e dai relativi risultati di performance (Freeman, 1984)
      1. Problema
         1. non hanno le idee chiare
         2. parlano un proprio linguaggio tecnico
         3. hanno poca dimestichezza nello sviluppo del software e idee confuse sulle funzionanlità da implementare
         4. possono effettuare richieste diverse tra loro, che vanno spesso in conflitto
         5. Compito dell’analista è ottenere una descrizione dettagliata (e il più possibile rigorosa) del sistema!
4. Classificazione FURPS (1987)
   1. Functionality

      Nota:

      • le caratteristiche e le funzionalità fornite dal programma
   2. Usability - usabilità

      Nota:

      • semplicità di apprendimento e utilizzo del sistema da parte degli utenti
   3. Reliability -affidabilità
      1. il sistema deve garantire le funzioni richieste nel tempo
      2. per un determinato insieme di situazioni
   4. Performance - prestazioni e tempi di risposta
      1. velocità nel fornire risultati
      2. quantità di risorse utilizzate
      3. throughput: efficienza / effettiva velocità di utilizzo
   5. Supportability - supportabilità
      1. manutenibilità
      2. estendibilità e adattabilità
      3. compatibilità e configurabilità
   6. Ulteriori pseudo-requisiti o VINCOLI

      Nota:

      • - implementazione - interfacce - operazioni - packaging - legali
5. Tipi di raccolta dei requisiti
   1. greenfield engineering
      1. sviluppo da zero del sistema
      2. la fonte dei requisiti è l’azienda committente
      3. lo sviluppatore: deve valutare disponibilità sul mercato di un prodotto analogo da confrontare o proporre in alternativa allo sviluppo ex-novo
   2. re-engineering

      Nota:

      • esiste già in azienda un sistema
      • analisi del sistema esistente → alla base del nuovo progetto
   3. interface engineering

      Nota:

      • non è possibile sostituire completamente il software esistente
      • MA si deve adeguare ALMENO l’interfaccia grafica
      • non è necessario raccogliere nuovi requisiti
   4. Elicitazione (scoperta) dei requisiti

      Nota:

      • questa fase è detta fase di esplorazione in quanto il problema da risolvere va esplorato elicitazione → “scoperta” dei requisiti (sono difficili da individuare)
      1. è necessario raccogliere il maggior numero possibile di informazioni

         Nota:

         • sugli obiettivi del sistema
         • sulle necessità riguardanti il sistema
      2. Passi da seguire
         1. esaminare le richieste del committente → il principale referente del cliente
         2. definizione degli stakeholder (attori)
            1. Stakeholder engagement

               Nota:

               • partecipazione attiva degli attori che sono a tutti gli effetti parte del gruppo di lavoro
               1. Gli ingegneri del software devono

                  Nota:

                  • dialogare con gli attori
                  • integrare ciò che emerge da questo processo di dialogo (dipendenti vs direzione aziendale)
               2. Si rende necessario

                  Nota:

                  • individuare criteri di selezione che garantiscano la rappresentatività degli stakeholder
                  • conoscere tutti i punti di vista (viewpoint) dei diversi utilizzatori del sistema