Porfirio Tramontana » 2.Analisi dei Requisiti

Obiettivi

Introdurre i concetti di requisiti utente e di requisiti di sistema.

Descrivere i requisiti funzionali e non-funzionali.

Spiegare come i requisiti software possano essere organizzati in un documento di specifica dei requisiti.

Ingegneria dei requisiti

Il processo condotto per stabilire i servizi che il cliente richiede al sistema, i vincoli operativi e quelli per lo sviluppo.

I requisiti sono la descrizione di tali servizi e dei relativi vincoli.

Che cos’è un Requisito?

• Può variare tra una descrizione astratta, ad alto livello di qualcosa che il sistema farà, o di un suo vincolo, ed una dettagliata specifica funzionale matematica.
• Ciò è inevitabile perchè un requisito svolge una duplice funzione:
  • Può essere la base per una gara fra potenziali sviluppatori: quindi deve essere aperto ad interpretazioni diverse;
  • Può essere la base del contratto stesso- quindi deve essere definito in dettaglio;
  • Entrambi si possono chiamare requisiti.

Necessità di diversi livelli di astrazione nei requisiti

Se una compagnia vuole dare in appalto un grande progetto di sviluppo software, deve definire le sue esigenze in modo abbastanza astratto, da non predefinire alcuna soluzione.

I requisiti devono essere scritti in modo da consentire a vari appaltatori di interpretare le esigenze e proporre vari metodi per soddisfarle.

Quando l’appalto è stato assegnato, l’appaltatore deve scrivere per il cliente una descrizione del sistema molto dettagliata, in modo che il cliente possa capire e validare ciò che il sistema farà.

Entrambi i documenti si chiameranno documenti dei requisiti del sistema.

Analisi e Specifica dei Requisiti

• Analisi dei requisiti
  • Processo di valutazione delle necessità del committente del software, con redazione di un documento di analisi dei requisiti, di solito in linguaggio naturale;
  • Viene redatto al termine di una campagna di interviste svolte dagli analisti presso il committente.
• Specifica dei requisiti
  • Processo di schematizzazione dei requisiti di un sistema, con redazione di un documento formattato rispetto ad uno standard;
  • È la base del contratto di fornitura.

Tipi di Requisiti

Requisiti Utente
Frasi in linguaggio naturale (e diagrammi) relativi ai servizi che il sistema fornisce e i suoi vincoli operativi. Scritti per i clienti.

Requisiti di Sistema
Un documento strutturato che fornisce una descrizione dettagliata dei servizi del sistema. Può essere parte del contratto fra cliente e sviluppatore.

Definizioni e specifiche dei requisiti

Es. di definizione di un requisito utente:
Il software deve fornire un mezzo per rappresentare ed accedere a file esterni creati da altri tools.

Es. di Specifiche dei requisiti di sistema:

1. L’utente deve poter definire il tipo dei file esterni;
2. Ciascun tipo di file esterno deve avere uno strumento associato;
3. Ciascun tipo di file esterno deve essere rappresentato con una sua icona sul display utente;
4. Quando un utente clicca sull’icona di un file, l’effetto sarà di attivare lo strumento associato al tipo di quel file;
5. …

Requisiti Funzionali e Non-funzionali

• Requisiti Funzionali
  • Frasi che descrivono ciò che il sistema dovrà fare, come reagirà agli input e si comporterà in varie situazioni.
• Requisiti Non-funzionali
  • Vincoli sui servizi offerti dal sistema (come vincoli sui tempi di risposta, …) o a cui sottostare durante lo sviluppo → Requisiti di qualità;
• Requisiti di dominio
  • Requisiti che derivano dal dominio di applicazione del sistema e ne riflettono le caratteristiche ed i limiti.

Requisiti Funzionali

Descrivono le funzionalità e i servizi offerti.

Anche in questo caso, due livelli di astrazione:

• Requisiti funzionali utente: frasi ad alto livello su ciò che il sistema farà;
• Requisiti funzionali di sistema: descrizioni dettagliate dei servizi.

Esempi di requisiti funzionali utente

1. L’utente dovrà essere in grado di cercare un documento o in tutto il database o in un sottoinsieme di esso.
2. Il sistema dovrà fornire all’utente appropriati visualizzatori per leggere tutti i documenti presenti nel database.
3. Ad ogni ordine di articolo deve essere assegnato un identificatore univoco (ORDER_ID) che l’utente deve potre copiare nella propria area di salvataggio.

Diversi livelli di dettaglio (es. 1 e 3).

Imprecisioni nei requisiti

Requisiti imprecisi o ambigui possono essere interpretati in modi diversi da sviluppatori ed utenti.
Es.: il termine ‘appropriati visualizzatori’ nel req. 2

• L’utente intendeva avere specifici visualizzatori per ogni tipo di documento;
• Lo sviluppatore ha interpretato che dovrà fornire solo un generico visualizzatore di testi.

Completezza e Consistenza dei requisiti

I requisiti devono essere completi e consistenti.

• Completezza
  • Tutti i requisiti richiesti devono essere presenti.
• Consistenza
  • Non ci dovrebbero essere definizioni contraddittorie.

Nella realtà è facile commettere errori o omissioni, soprattutto per sistemi complessi!

Requisiti Non-funzionali

Definiscono o limitano le proprietà del sistema (es. Affidabilità, tempi di risposta, memoria occupata…).

Possono vincolare anche il processo di sviluppo da adottare (es. Uso di particolari standard per la documentazione, su sistemi CASE, linguaggi di codifica, metodi di sviluppo).

Possono essere più critici dei req. funzionali: se non sono soddisfatti, il sistema è inutile.

Tipi di requisiti non-funzionali

• Requisiti del prodotto
  • Specificano il comportamento del prodotto (usabilità, efficienza, affidabilità, portabilità).
• Requisiti organizzativi
  • Derivano dalle politiche e procedure dell’organizzazione del cliente e dello sviluppatore (es. Standard di processo da usare, piattaforme, requisiti di consegna, etc.).
• Requisiti esterni
  • Derivano da fattori esterni al sistema e al suo processo di sviluppo (come i requisiti di interoperabilità, legislativi, etici, etc.).

Esempi di requisiti non funzionali

Requisiti del Prodotto
8.1 L’interfaccia utente deve essere implementata come semplice pagina HTML senza frame o Java applets (per garantirne l’accessibilità).

Requisiti organizzativi
9.3.2 Il processo di sviluppo e I documenti consegnati devono essere conformi alle norme XYZCo-SP-STAN-95.

Requisiti esterni
7.6.5 Il sistema non deve rivelare agli operatori del sistema alcuna informazione personale sui clienti, tranne il nome ed un numero di riferimento.

Verificabilità dei requisiti

I Requisiti non-funzionali possono essere difficili da definire precisamente, e quindi difficili da verificare.

L’utente li specifica come obiettivi: Es. La facilità d’uso.

Requisito verificabile:
Una frase che contiene qualche misura che potrà essere oggettivamente verificata.

Esempi

Un obiettivo di sistema
Il sistema dovrebbe essere usato facilmente da controllori esperti e dovrebbe minimizzare gli errori.

Un requisito non-funzionale verificabile
I controllori esperti dovranno essere capaci di usare tutte le sue funzioni dopo due ore di addestramento. Dopo tale addestramento, il numero medio di errori fatti dagli utenti non dovrà essere superiore a due errori al giorno.

Contraddizioni fra i Requisiti

I diversi requisiti non-funzionali possono essere in contraddizione fra loro, soprattutto in sistemi complessi (es. Tempi di risposta e portabilità).

Es.: Sistemi aerospaziali:

• Per minimizzare il peso, il numero di chips a bordo dovrebbe essere minimo e la memoria complessiva non superiore a 4Mbyte;
• Un vincolo potrebbe richiedere di usare il linguaggio ADA (adatto a sistemi critici real time);
• Purtroppo può accadere che non si possano avere tutte le funzioni richieste in 4 Mbyte. Quale requisito dovrà essere soddisfatto fra i due?

Requisiti di Dominio

Derivano dal dominio di applicazione, piuttosto che da necessità degli utenti.

I requisiti di dominio possono essere nuovi requisiti funzionali, vincoli su altri requisiti funzionali, o possono delineare calcoli da effettuarsi.

Se non sono soddisfatti, il sistema potrebbe essere inutilizzabile.

Problemi dei requisiti di dominio

Comprensibilità

• I requisiti sono espressi nel linguaggio del dominio;
• Tale linguaggio potrebbe non essere immediatamente comprensibile per gli ingegneri del software.

Implicitezza

• Gli specialisti del dominio cononscono così bene l’area, da lasciare fuori dai requisiti informazioni che potrebbero sembrare ovvie (e invece non lo sono…).

Requisiti Utente

Dovrebbero descrivere requisiti funzionali e non-funzionali in modo da essere comprensibili ad utenti del sistema privi di dettagliate conoscenze tecniche.

Non devono descrivere caratteristiche di progettazione, ma solo il comportamento esterno.

Vengono definiti usando il Linguaggio Naturale, tabelle e diagrammi che sono comprensibili a tutti gli utenti.

Problemi del linguaggio naturale

Mancanza di chiarezza
È difficile usare il linguaggio in modo preciso e non ambiguo, senza rendere il documento lungo e difficile da leggere.

Confusione dei requisiti
Le varie tipologie di requisiti potrebbero non essere facilmente distinguibili.

Mescolanza dei requisiti
Diversi requisiti potrebbero essere espressi insieme come un singolo requisito.

Un esempio di requisito

4.5 Il sistema deve fornire un sistema di contabilità finanziaria che memorizzi tutti i pagamenti fatti dagli utenti del sistema. I gestori del sistema possono configurarlo in modo che gli utenti abituali possano ricevere prezzi scontati.

Confonde due tipi di requisiti: (un requisito funzionale concettuale e un requisito di sistema di dettaglio)!

Un requisito per una griglia su un editor grafico

2.6 Funzionalità della griglia. Per facilitare il posizionamento delle entità in un diagramma, l’utente può abilitare una griglia, in centimetri o pollici, attraverso una opzione del pannello di controllo. La griglia può essere abilitata e disabilitata durante le sessioni di lavoro, variando anche fra centimetri e pollici.
Il requisito della griglia sarà presente anche quando si è scelta la visione ridotta dell’immagine (adattata alla finestra) ma, in tal caso, il numero di righe della griglia sarà ridotto.

Problemi dei requisiti

Il requisito della griglia combina tre tipi di requisiti:

• Un requisito funzionale concettuale (il bisogno di una griglia);
• Un requisito non-funzionale dettagliato (le unità di misura);
• Un requisito non funzionale dell’Interfaccia Grafica definisce come la griglia può essere abilitata o disabilitata in vari casi.

I requisiti utente dovrebbero dare una descrizione generale del requisito, per essere compresi più facilmente e non confondere il lettore.