Raccolta e analisi dei requisiti

La raccolta dei requisiti consiste nella individuazione delle caratteristiche statiche (dei dati) e dinamiche (delle operazioni) dell'applicazione da realizzare. I requisiti vengono raccolti in specifiche espresse in linguaggio naturale e per questo motivo spesso ambigue e disorganizzate. L'analisi dei requisiti consiste nel chiarimento e nell'organizzazione delle specifiche raccolte.

I requisiti dell'applicazione provengono da diverse fonti, tra le quali: gli utenti dell'applicazione, la documentazione esistente attinente al problema allo studio, eventuali realizzazioni preesistenti dell'applicazione.

Il coinvolgimento del cliente nel processo di sviluppo aumenta il suo livello di soddisfazione nei confronti del sistema che gli verrà consegnato e agevola il lavoro di raccolta dei requisiti dei progettisti. Spesso i progettisti vengono inseriti direttamente nell'ambiente di lavoro in cui l'applicazione dovrà essere utilizzata (si parla di progettazione contestuale). E' prassi percorrere assieme al cliente il flusso di lavoro e gli scenari di esecuzione delle transazioni del sistema proposto, oppure creare un prototipo dimostrativo dell'applicazione.

Alcune regole generali per ottenere una specifica precisa e priva di ambiguità:

• Evitare termini troppo generici o troppo precisi. Mantenere un livello di astrazione costante.
• Evitare l'uso di sinonimi (termini diversi con il medesimo significato) e omonimi (termini uguali con differenti significati). Riferirsi allo stesso concetto sempre nello stesso modo.
• Usare frasi brevi e semplici possibilmente uniformandone la struttura.
• Dividere il testo in paragrafi. Dedicare ogni paragrafo alla descrizione di una specifica entità della realtà modellata. Evidenziare l'entità descritta in ogni paragrafo.

E' fondamentale fin da questa fase differenziare le seguenti componenti del modello:

1. Entità. Una entità è un concetto complesso e di rilievo che descrive classi di oggetti con esistenza autonoma. Esempi di entità nel contesto di una rete di teatri potrebbero essere teatro, dipendenti, spettacoli.
2. Attributi delle entità. Un attributo è un concetto che ha una struttura semplice e non possiede proprietà rilevanti associate. Ad esempio, il nome del teatro, il codice fiscale del dipendente, il titolo dello spettacolo.
3. Relazioni tra entità. Queste sono associazioni tra due o più entità. Ad esempio una relazione che associa teatri e relativi dipendenti. Delle relazioni occorre identificare anche le cardinalità con cui le entità vi partecipano. Ad esempio, ogni teatro può avere più dipendenti e ogni dipendente può lavorare per più teatri.

Accanto alle specifiche sui dati vanno raccolte le specifiche sulle transazioni tipiche del sistema, cioè le operazioni che si stimano essere più frequenti. Non tutte le transazioni sono note in fase di progettazione ma esiste una regola informale che afferma che l'80% del carico del sistema è prodotto dal 20% delle transazioni. Una operazione tipica deve essere efficiente. E' possibile fare delle particolari scelte nelle successive fasi della progettazione al fine di migliorare l'efficienza delle transazioni tipiche. Nella descrizione informale delle transazioni bisogna adottare la medesima terminologia usata per i dati.

La progettazione delle transazioni è importante quanto quella dei dati e dovrebbe procedere di pari passo. Conoscere le transazioni tipiche permette di capire come modellare i dati affinchè queste transazioni possano essere eseguite (efficientemente). Ad esempio, se una tipica transazione richiede il numero di posti liberi per uno spettacolo, occorre registrare nella base di dati la capienza degli spazi e il numero di posti prenotati per uno spettacolo. Inoltre, se una transazione tipica richiede gli spettacoli ordinati cronologicamente, è bene che gli spettacoli vengano mantenuti ordinati (creando un indice sul campo data dello spettacolo). In realtà, spesso la progettazione dei dati, affidata ai progettisti della base, è disgiunta dalla progettazione delle transazioni svolta dagli ingegneri del software.