Porfirio Tramontana » 3.Specifica dei Requisiti

Linguaggi per la specifica

Spesso i requisiti di sistema vengono espressi in linguaggio naturale (NL).

Alcune alternative al NL:

• Linguaggio naturale strutturato e stilizzato (con uso di Moduli/Template standard);
• Modelli grafici (come gli use case e sequence diagrams);
• Specifiche matematiche formali (con macchine a stati, notazioni insiemistiche, o altro).

Specifiche in linguaggio strutturato

La libertà di chi scrive i requisiti è limitata usando un ‘modello’ predefinito e standard per tutti i requisiti.

Viene limitata anche la terminologia usata per descrivere il requisito.

Il vantaggio è che si conserva l’espressività del linguaggio naturale, ma al tempo stesso si impone un grado di uniformità per descrivere le specifiche.

Specifiche basate su un Modello

• Definizione della funzione o entità;
• Descrizione degli input e relative sorgenti;
• Descrizione degli output e loro destinazione;
• Altre entità richieste;
• Pre-condizioni e Post-condizioni;
• Eventuali effetti collaterali della funzione.

Il Documento di Specifica dei Requisiti (SRS)

È una dichiarazione ufficiale di ciò che gli sviluppatori dovrebbero implementare (attenzione: il COSA ma non il COME).

Deve includere sia i requisiti utente (RU), sia una specifica dettagliata dei requisiti di sistema (RS).

Talora RU e RS sono contenuti nello stesso documento, talora in documenti separati.

Il Documento di Specifica dei Requisiti (SRS) (segue)

Un SRS costituisce il punto di convergenza di tre diversi punti di vista: cliente, utente, sviluppatore.
Un SRS fornisce un punto di riferimento per la validazione del prodotto finale.
Un SRS di qualità è il pre-requisito per un software di alta qualità:

• un errore nell’SRS produrrà errori nel sistema finale.

Un SRS di qualità riduce i costi di sviluppo:

• correggere un errore dell’SRS dopo lo sviluppo costa 100 volte più che correggerlo durante la fase di Analisi.

FASE   →  COSTO (in ore uomo)
Analisi dei Requisiti  →  2
Progettazione  →  5
Codifica  →  15
Test di accettazione  →  50
Esercizio e manutenzione  →  150

Lo standard IEEE 830 -1998

Definisce una generica struttura per un documento dei requisiti che deve essere istanziata per ogni specifico sistema. Contiene più capitoli:

• Introduzione;
• Descrizione Generale;
• Requisiti Specifici;
• Appendici;
• Indice.

Standard IEEE per l’SRS

Table of contents
1.Introduction
1.1. Purpose (Scopo del documento)
1.2. Scope (Scopo del prodotto)
1.3. Definitions, Acronyms and Abbreviations
1.4. References
1.5. Overview (Descrizione generale del resto del documento)
2.General Description
2.1. Product Perspective
2.2. Product Functions
2.3. User Characteristics
2.4. General Constraints
2.5. Assumptions and Dependencies

….

Dallo standard IEEE 830 -1998.

Standard IEEE per l’SRS (segue)

3.Specific Requirements

3.1. Functional Requirements
3.1.1. Functional Requirement 1
3.1.1.1. Introduction
3.1.1.2. Inputs
3.1.1.3. Processing
3.1.1.4. Output
3.1.2. Functional Requirement 2

…

3.1.3.Functional Requirement n

…

Dallo standard IEEE 830 -1998.

Standard IEEE per l’SRS (segue)

3.2. External Interface Requirements

3.2.1. User Interfaces
3.2.2. Hardware Interfaces
3.2.3. Software Interfaces
3.2.4. Communications Interfaces

3.3. Performances Requirements
3.4. Design Constraints

3.4.1 Standard Compliance
3.4.2. Hardware Limitation

…

Dallo standard IEEE 830 -1998.

Standard IEEE per l’SRS (segue)

3.5. Software System Attributes

3.5.1. Security
3.5.2. Maintainability

…

3.6. Other Requirements

3.6.1. Logical Database Requirements
3.6.2. Operations
3.6.3. Site Adaptation requirements

…

Dallo standard IEEE 830 -1998.

Esempio di Specifica di Funzionalità

Ciascuna Funzionalità deve essere specificata indicando gli input, l’output e l’azione elaborativa. Ad esempio:

3.2.1 Inserisci articolo
Introduzione: La funzionalità consente l’immissione dei dati relativi ad un nuovo articolo ed alla loro registrazione in un archivio;
Input: codice articolo, descrizione, unità di misura;
Elaborazione: visualizzazione di un form per l’immissione dei dati di input; lettura dei dati di input; verifica che l’unità di misura sia uno dei tre valori possibili e registrazione dei dati immessi nell’archivio Articoli;
Output: dati di input registrati nell’archivio Articoli o messaggio di errore ‘Unità di misura non ammessa’.

Esempio di Specifica di Funzionalità (segue)

Elenco Fornitori

• Utenti della funzionalità: Titolare.
• Introduzione
  • La funzionalità visualizza la lista dei fornitori con i debiti verso questi e con possibilità di stampa. Consente, se richiesto, di selezionare un fornitore, di visualizzarne la scheda personale ed eventualmente di stamparla.

Esempio di Specifica di Funzionalità (segue)

Precondizione

L’utente si è precedentemente autenticato come titolare del ristorante

Input

• Ragione sociale – Facoltativo
• Nome titolare – Facoltativo
• Cognome titolare – Facoltativo
• Indirizzo – Facoltativo
• Città – Facoltativo
• P. I.V.A. – Facoltativo
• Telefono – Un recapito telefonico. Facoltativo
• E-Mail – Un solo indirizzo. Facoltativo
• Almeno uno tra le precedenti informazioni deve essere obbligatoriamente inserito

Esempio di Specifica di Funzionalità (segue)

Elaborazione

• Ristò presenta una lista con l’elenco dei fornitori;
• Selezionando un fornitore dalla lista è possibile richiedere la visualizzazione o la stampa della sua scheda riportante tutti i dati anagrafici e contabili del fornitore.

Output

• La lista con l’elenco dei fornitori, visualizzata a schermo o stampata, riporta per ciascuno di essi:
  • Ragione Sociale – Nome Fornitore – Cognome Fornitore – Data d’inizio periodo Corrente – Saldo fornitore.

Le caratteristiche di un buon SRS …

• Corretto/Valido
  • se ogni requisito presente nell’SRS è realmente richiesto/necessario per gli utenti del sistema finale;
• Completo
  • se ogni funzione richiesta al software ed il suo comportamento rispetto ad ogni possibile input è specificato;
• Non Ambiguo
  • ogni requisito ha una sola interpretazione (formale vs. informale);
• Verificabile
  • se è possibile verificare che il sistema realizzi ogni requisito (richiede la non ambiguità dei requisiti).

Le caratteristiche di un buon SRS … (segue)

• Consistente
  • se nessun requisito è in contraddizione con gli altri.
• Modificabile
  • se la struttura e lo stile dell’SRS sono tali da consentire facili modifiche, preservando consistenza e completezza (un SRS con ridondanze non si modifica facilmente).
• Tracciabile
  • se l’origine di ciascun requisito è chiara e può essere referenziata nello sviluppo futuro (def. IEEE);
  • forward traceability: requisito collegabile a qualche elemento del progetto e del codice;
  • backward traceability: dal progetto e dal codice è possibile risalire al requisito corrispondente.

La Validazione delle Specifiche

L’obiettivo è quello di assicurare che l’SRS rifletta accuratamente e con chiarezza i requisiti effettivamente richiesti al software.

Tipi di errori riscontrabili in un SRS:

• Omissione (mancata presenza di un requisito);
• Inconsistenza (contraddizione fra i vari requisiti o dei requisiti rispetto all’ambiente operativo);
• Incorrettezza (fatti non corretti nell’SRS);
• Ambiguità (requisiti con significati multipli).