Fondamenti di Ingegneria dei Requisiti Software

Requisiti di Sistema

Il processo di scoprire, analizzare, documentare e verificare i servizi necessari per un sistema e dei suoi vincoli operativi. Un requisito può variare da un livello astratto di istruzione elevato di un servizio o un vincolo di sistema a una specifica matematica funzionale.

Tipi di Requisiti

• Richieste degli Utenti: Dichiarazioni in linguaggio naturale, nonché diagrammi di servizi che il sistema fornisce e dei suoi vincoli operativi. Scritto per gli utenti.
• Requisiti di Sistema: Un documento strutturato contenente la descrizione dettagliata delle funzioni, dei servizi e dei vincoli operativi del sistema. Definisce ciò che dovrebbe essere attuata e quindi può essere parte di un contratto tra il cliente e sviluppatore.

LIBSYS System

Una libreria di sistema che fornisce un'unica interfaccia per una serie di database di articoli in diverse librerie.

Requisiti Funzionali e Non Funzionali

• Requisiti Funzionali: Dichiarazioni di servizi che il sistema dovrebbe prevedere, come il sistema deve reagire agli input e come dovrebbe comportarsi in determinate situazioni.
• Requisiti Non Funzionali: Vincoli sui servizi o funzioni offerte dal sistema, come vincoli temporali, vincoli sul processo di sviluppo, standard, ecc.
• Requisiti di Dominio: Requisiti che provengono dal campo di applicazione del sistema e che riflettono le caratteristiche di quella zona.

Classificazione dei Requisiti Non Funzionali

• Requisiti di Prodotto: Specificano come il prodotto consegnato deve comportarsi, ad esempio, velocità di esecuzione, affidabilità, ecc.
• Requisiti Organizzativi: Conseguenza di politiche e procedure dell'organizzazione, ad esempio, standard di processo utilizzato, requisiti di implementazione, ecc.
• Requisiti Esterni: Derivano da fattori esterni al sistema e al processo di sviluppo, ad esempio, interoperabilità, requisiti legali, ecc.

Documento di Specifica dei Requisiti

Il documento dei requisiti software deve essere composto da frasi in linguaggio naturale, seguendo certe norme:

1. Usare 'must' per i requisiti obbligatori e 'should' per i requisiti desiderabili. Esempio: "Il sistema dovrebbe funzionare su PC IBM linea di microcomputer che hanno microprocessore 486 DX o superiore."
2. I requisiti devono essere organizzati in modo logico, per esempio, inizialmente tutti i requisiti di ingresso, quindi il trattamento e i requisiti di output finale.
3. Ogni requisito deve avere un identificatore univoco, per esempio, un identificatore numerico per riferimento futuro.
4. I requisiti software sono divisi in requisiti funzionali e non funzionali (qualità).
5. Evitare di utilizzare il gergo del computing.

Format Specifica dei Requisiti: Standard IEEE/ANSI 830/1998. (Introduzione > Descrizione > Requisiti Specifici > Appendici > Indice)

Problemi con il Linguaggio Naturale nella Specifica

• Ambiguità: Lettori e scrittori della specifica devono interpretare le stesse parole nello stesso modo. Il linguaggio naturale è intrinsecamente ambiguo, rendendo questo aspetto molto difficile.
• Eccessiva Flessibilità: La stessa cosa può essere detta in molti modi diversi nelle fasi di specifica.
• Mancanza di Modularizzazione: Le strutture del linguaggio sono inadeguate per strutturare i requisiti di sistema.

Requirements Engineering

Studio di redditività, elicitazione e analisi dei requisiti, validazione dei requisiti, gestione dei requisiti. Risultato: Documenti dei requisiti.

Studio di Fattibilità

Decide se valga la pena investire tempo e fatica nel sistema proposto. È uno studio breve e mirato che verifica se il sistema contribuisce agli obiettivi organizzativi; se può essere implementato con la tecnologia attuale e nei limiti del budget; se può essere integrato con altri sistemi.

Elicitazione e Analisi dei Requisiti

Raccolta di informazioni sul sistema proposto e sulle fonti esistenti: l'organizzazione, le specifiche, i documenti esistenti, osservazioni, interviste, ecc.

Validazione dei Requisiti

Mostra che i requisiti definiscono il sistema che il cliente desidera realmente. I costi degli errori nei requisiti sono elevati, quindi la validazione è molto importante per:

• Verificare la validità: Il sistema fornisce le funzioni che meglio supportano le esigenze del cliente?
• Controllo di coerenza: Ci sono conflitti tra i requisiti?
• Completezza: Sono incluse tutte le funzioni richieste dal cliente?
• Verifica di realismo: I requisiti possono essere implementati con il budget e la tecnologia disponibili?
• Verificabilità: I requisiti possono essere verificati?

Gestione dei Requisiti

È il processo di gestione dei requisiti che cambiano durante l'ingegneria dei requisiti e lo sviluppo del sistema. I requisiti sono inevitabilmente incompleti e incoerenti.

Difficoltà nella Gestione dei Requisiti

• Le parti interessate non sanno cosa vogliono dal sistema e non esprimono chiaramente le loro esigenze.
• Le parti interessate esprimono naturalmente i requisiti con i propri termini.
• Diverse parti interessate hanno esigenze diverse che possono influenzare fattori politici.
• L'ambiente è dinamicamente in continua evoluzione. Nuove esigenze possono derivare da nuove parti interessate.

Tracciabilità

È legata ai rapporti tra le esigenze, le loro fonti e la progettazione del sistema:

• Tracciabilità della Sorgente: Collega i requisiti alle parti interessate che li hanno proposti.
• Tracciabilità dei Requisiti: Collega i requisiti ai requisiti di livello superiore.
• Tracciabilità del Progetto: Lega i requisiti ai moduli del progetto.