Creato da pastuweb.com
Share My Page
My Social Accounts
Account FaceBook Account LinkedIn Account Twitter Account Google Plus Account Git Hub

Un requisito è una condizione o una capacità necessaria per risolvere un problema o raggiungere un obiettivo. Raccogliere correttamente i requisiti significa circoscrivere il problema e limitare lo spazio di tutte le possibili soluzioni.

I requisiti devono essere:

  • verificabili: cioè cioè il requisito può o no essere soddisfatto;
  • tracciabili: cioè deve essere possibile ricondurre la soluzione ai requisiti iniziali.

Si può usare lo strumento chiamato "matrice di tracciabilità" che collega tra loro le vari etipologie di requisiti. Deve permettere di ricavare le informazioni sia in forward-mode cioè progredendo in avanti lungo il ciclo di sviluppo (dai requisiti ai prodotti), sia in backward-mode (dai prodotti ai requisiti).

Il Requirements Engineering (ingegneria dei requisiti) è il processo secondo cui i requisiti del sistema sono evidenziati, analizzati e validati. Scopo del processo è la produzione di un documento, il Requirements Document:

  1. Introduzione
    1. Obiettivo del Requirement Documenti
    2. Obiettivo del prodotto
    3. Definizioni, acronimi e abbrevviazioni
    4. Riferimenti
    5. Struttura del documento
  2. Descrizione generale
    1. Descrizione del prodotto dai diversi punti di vista
    2. Funzionalità del prodotto
    3. Caratteristiche utente
    4. Vincoli sul prodotto
  3. I requisiti (funzionali, non-funzionali, lato utente, ... )
  4. Appendici
  5. Indice

I requisiti nel documento devono essere opportunamente validati:

  • correttezza: il requisito deve rispecchiare il vincolo esposto dall'utente
  • completezza: devono coprire completamente i vincoli esposti dagli utenti
  • consistenza: non devono essere incongruenti tra loro.
Requisiti funzionali

descrivono le funzionalità e i servizi offerti dal sistema, possono essere descritti da Use Cases.

Lo Use Case è usato per esprimere CHI FA COSA con il sistema e PER QUALE SCOPO. Uno strumento grafico per esprimere gli scenari è quello dei diagrammi di sequenza.Uno strumento testuale è quello dello stroyboard. Qui entra in gioco l'UML.

Requisiti non funzionali

definiscono i vincoli sul sistema, esempio: sul suo utilizzo, sulla sua manutenzione, sulle performance, sul suo sviluppo ecc..

Ogni requisito è espresso da persone che hanno ruoli diversi all'interno o all'esterno dell'organizzazione:

  • requisiti business: espressi da figure che lavorano in ambito economico/finanziario;
  • requisiti tecnici: espressi da figure che lavorano in ambito IT;
  • requisiti normativi: espressi da regolamenti e leggi;
  • requisiti di progetto: vicnoli sui costi, tempi e qualità (espressi dal cliente, di solito);
  • requisiti di funzionamento: espressi dal cliente;
  • requisiti di utilizzo: espressi dagli utenti finali.

Il fatto che esistano punti di vista diversi vuol dire che esiste la possibilità di conflitti tra i reuquisiti, conflitti che devono essere risolti prima di di iniziare la fase architettural vera e propria.

Norma ISO/IEC 9126

Ha definito il modello di requisiti qualitativi del software. I requisiti sono raggruppati in 6 caratteristiche (una funzionale e 5 non-funzionali) e 21 sottocaratteristiche (distinte fra esterne, orientate all'utente e interne, orientate allo sviluppo e manutenzione.

  • Funzionalità
    • idoneità
    • accuratezza
    • interoperabilità
    • sicurezza
  • Disponibilità
    • maturità
    • tolleranza
    • recupero
  • Usavilità
    • comprensione
    • apprendimento
    • utilizzabilità
    • attrattività
  • Efficienza
    • tempo di risposta
    • utilizzo delle risorse
  • Manutenubilità
    • analizzabilità
    • modificabilità
    • stabilità
    • collaudabilità
  • Portabilità
    • adattabilità
    • installabilità
    • coesistenza
    • sostituibilità
Cambiamenti dei requisiti

Sono inevitabili durante il ciclo di vita di un progetto e così è necessario fare uso di un processo Change Management.

Le modifiche proposte devono essere opportunamente vagliate, approvate e quindi implementate. E' importante studiarne l'impatto, misurare il rischio introdotto dalle modifiche richieste e fare un'opportuna analisi costi-benefici. Tutto questo è un RFC (Request for Change), che è un documento di dettaglio in cui si richiede una modifica alle specifiche.

Una volta che la modifica è approvata, deve essere schedulata per la messa in opera. Dopo cio, il sistema deve essere monitorato per verificare un eventuale impatto negativo nell'ambiente in esercizio con un conseguente rollback della modifica effettuata.