Requisiti software

Requisiti software

1. Studio di fattibilità

   • OUTPUT: preventivo o documento di fattibilità
   • valutazione preliminare di costi e benefici
   • valutazione di opzioni alternative
   • stima delle risorse umane e finanziarie necessarie

2. Specifica (raccolta e analisi) dei requisiti

   • 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
   • analisi del problema: cosa deve fare il sistema
   • definizione delle funzionalità: vincoli aziendali interni/esterni, caratteristiche sistema
   • redazione di un documento di Specifica dei Requisiti sw: SRS Software Requirements Specification - documento formale
   • convalida da parte del committente del SRS

3. Requisiti software e stakeholder

   • Requisito
     • 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)
     • La definizione dei requisiti
       • analizza i bisogni dell’utente
       • indaga il dominio del problema
       • coinvolge diverse persone
         • sia il team di sviluppo
         • sia l’azienda del cliente - engagement
         • consulenti esterni (legali, sviluppatori legacy system)
       • fattori esterni possono influenzare pesantemente i requisiti del sistema
         • cambiamenti nell’organizzazione aziendale
         • necessità di adeguamento a nuove politiche di mercato
         • cambiamento a livello di obblighi legislativi
     • La fase di analisi dei requisiti è molto delicata
       • errori in questa fase → fallimento possibile dell’intero progetto
       • rischi principali
         • dimenticare o ignorare una funzionalità
         • implementare in modo errato una richiesta
         • realizzare interfacce utenti poco intuitive e difficili da usare
     • Classificazione dei requisiti
       • livello di dettaglio
         • requisiti UTENTE
           • osservati - proposti - dal cliente
           • descritte con il linguaggio del cliente
           • equisiti aperti perché sottoposti successivamente al team di sviluppo che propone una soluzione
         • requisiti DI SISTEMA
           • imposti da vincoli esistenti
             • esistenza di apparecchiature esistenti all’interno dell’azienda
             • vincoli di natura fiscale e/o legislativa
           • molto strutturati e vincolanti
           • scritti in linguaggi tecnici e/o semi-formali
           • spesso non sono noti all’utente, ma solo al programmatore
           • requisiti restrittivi o requisiti chiusi
       • tipo di requisito
         • requisiti FUNZIONALI
           • descrivono le funzionalità che il sistema deve avere e tutti i servizi che dovrà offrire agli utenti
           • Devono essere COMPLETI: tutti i servizi richiesti dagli utenti
           • Devono essere COERENTI: non devono esserci definizioni contraddittorie
         • requisiti NON FUNZIONALI
           • 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
           • Req. di prodotto
             • affidabilità
             • portabilità
             • efficienza
               • spazio
               • performance
           • Req. organizzativi
             • req. di consegna
             • di implementazione
             • su standard
           • Req. esterni
             • interoperabilità
             • Req. etici
             • Req. legislativi
         • requisiti di DOMINIO
           • dipendono dal DOMINIO in cui il sistema deve operare ES : - impianti industriali - riservatezza dati sensibili - accessi area riservata
     • Verifica dei requisiti
       • 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
   • Stakeholder
     • 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)
     • Problema
       • non hanno le idee chiare
       • parlano un proprio linguaggio tecnico
       • hanno poca dimestichezza nello sviluppo del software e idee confuse sulle funzionanlità da implementare
       • possono effettuare richieste diverse tra loro, che vanno spesso in conflitto
       • Compito dell’analista è ottenere una descrizione dettagliata (e il più possibile rigorosa) del sistema!

4. Classificazione FURPS (1987)

   • Functionality
     • le caratteristiche e le funzionalità fornite dal programma
   • Usability - usabilità
     • semplicità di apprendimento e utilizzo del sistema da parte degli utenti
   • Reliability -affidabilità
     • il sistema deve garantire le funzioni richieste nel tempo
     • per un determinato insieme di situazioni
   • Performance - prestazioni e tempi di risposta
     • velocità nel fornire risultati
     • quantità di risorse utilizzate
     • throughput: efficienza / effettiva velocità di utilizzo
   • Supportability - supportabilità
     • manutenibilità
     • estendibilità e adattabilità
     • compatibilità e configurabilità
   • Ulteriori pseudo-requisiti o VINCOLI
     • - implementazione - interfacce - operazioni - packaging - legali

5. Tipi di raccolta dei requisiti

   • greenfield engineering
     • sviluppo da zero del sistema
     • la fonte dei requisiti è l’azienda committente
     • lo sviluppatore: deve valutare disponibilità sul mercato di un prodotto analogo da confrontare o proporre in alternativa allo sviluppo ex-novo
   • re-engineering
     • esiste già in azienda un sistema
     • analisi del sistema esistente → alla base del nuovo progetto
   • interface engineering
     • non è possibile sostituire completamente il software esistente
     • MA si deve adeguare ALMENO l’interfaccia grafica
     • non è necessario raccogliere nuovi requisiti
   • Elicitazione (scoperta) dei requisiti
     • questa fase è detta fase di esplorazione in quanto il problema da risolvere va esplorato elicitazione → “scoperta” dei requisiti (sono difficili da individuare)
     • è necessario raccogliere il maggior numero possibile di informazioni
       • sugli obiettivi del sistema
       • sulle necessità riguardanti il sistema
     • Passi da seguire
       • esaminare le richieste del committente → il principale referente del cliente
       • definizione degli stakeholder (attori)
         • Stakeholder engagement
           • partecipazione attiva degli attori che sono a tutti gli effetti parte del gruppo di lavoro
           • Gli ingegneri del software devono
             • dialogare con gli attori
             • integrare ciò che emerge da questo processo di dialogo (dipendenti vs direzione aziendale)
           • Si rende necessario
             • individuare criteri di selezione che garantiscano la rappresentatività degli stakeholder
             • conoscere tutti i punti di vista (viewpoint) dei diversi utilizzatori del sistema