ANALISI DEI REQUISITI

Spesso chi crea la base di dati non è la stessa persona o la stessa società che poi utilizzerà l’applicazione finita. L’analisi dei requisiti serve a chi deve creare e progettare l’archivio, per definire “cosa” si deve realizzare. Questa fase è necessaria anche per chi costruisce il database per sé, cioè quando l’utilizzatore e il creatore dell’archivio sono la stessa persona.
L’analisi dei requisiti è lo studio preliminare che si deve fare prima di creare la base di dati, per stabilire:

· gli obiettivi dell’archivio
· i “campi di interesse”
· gli oggetti da rappresentare
· le azioni che si vorranno svolgere sull’archivio
· la durata che avrà l’archivio
· l’ambito in cui dovrà lavorare la base di dati
· tutto ciò che abbia a che fare con l’archivio stesso.

ESEMPIO. Capire l’analisi dei requisiti.
La frase “si vuole realizzare una base di dati per memorizzare i libri” sembra essere sufficiente per definire un tipo di archivio. Questo non è vero, la frase individua solamente “l’obiettivo” principale del database, ma se cento persone dovessero progettare un archivio a partire da questa frase, probabilmente si avrebbero cento risultati diversi. Lo scopo dell’analisi dei requisiti è “analizzare a fondo l’obiettivo” per scoprire tutto ciò che serve per la creazione della base di dati. Per esempio si deve sapere se l’archivio serve per i libri di casa, oppure per una biblioteca, oppure per una libreria. Per i libri di casa sono importanti alcuni aspetti, per la biblioteca altri, per la libreria altri ancora. Per memorizzare i libri di casa non è importante il prezzo di ogni libro, non è importante la data di nascita di ogni autore o la sua nazionalità. Per la biblioteca è molto importante che sia gestito in modo accurato l’ordinamento dei libri e la loro disposizione negli scaffali, in modo che siano recuperabili velocemente. Per la libreria, che vende i libri, è importante conoscere l’aliquota IVA applicabile, sapere se un testo è scontato, si dovrà avere un elenco di clienti con i relativi dati per le fatture.
Una base di dati rappresenta una o più situazioni della vita reale, in base all’utilizzo dell’archivio, gli aspetti della vita reale che sono interessanti cambiano, quindi cambia anche il risultato finale, cioè il programma finale che è il risultato della progettazione e della realizzazione.
L’analisi dei requisiti è praticamente una interrogazione che deve fare chi progetta la base di dati, al committente (colui che richiede la creazione di un archivio). Questa interrogazione deve essere accuratissima, perché in questa fase devono risultare tutti i requisiti necessaria per il database stesso. Ogni singolo oggetto, caratteristica o dato che serve nell’archivio deve essere esplicato e deve “uscire” in questa fase.
La fase successiva, il progetto del sistema, si basa sull’analisi dei requisiti, per cui se la prima fase non è completa o è errata, anche il progetto risulterà incompleto o errato, di conseguenza anche la realizzazione finale sarà sbagliata. Se si trovano errori o elementi mancanti nelle fasi successive, si deve iniziare da capo, dalla prima fase.
Se la persona che “commissiona” il database è la stessa che lo realizza, si deve comunque fare l’analisi dei requisiti. È vero che, in questo caso, chi realizza il database è anche colui che ne ha bisogno e quindi ha già in testa tutto ciò che serve per la realizzazione, ma è meglio utilizzare carta e penna per elencare i requisiti, gli oggetti e gli aspetti da rappresentare. Se non si procede nel modo descritto e si inizia subito da una fase successiva, è facile (e succede quasi sempre quando si procede in questo modo) dimenticare gli aspetti che sembrano marginali o meno importanti. Ci si accorge degli errori solo dopo la creazione dell’applicazione finale, solo quando si inseriscono o si utilizzano i dati, ma, a quel punto, è troppo tardi per rimediare.

ESEMPIO. Banale analisi dei requisiti.
Si vuole rappresentare la lista degli studenti di un corso. I dati che interessano sono il nome, il cognome, la data di nascita, la città di residenza, il numero di telefono. La lista serve semplicemente per fare l’appello e per eventuali comunicazioni urgenti.
Il risultato di questa “pseudo analisi dei requisiti” è una semplice tabella, figura 3.01.
 

 
FIG. 3.01
 

Se non fosse stata fatta l’analisi dei requisiti, il progettatore avrebbe potuto inserire molte altre colonne nella tabella, per esempio indirizzo, e-mail, codice fiscale e professione.

ESEMPIO. Analisi dei requisiti.
Questo esempio è tratto interamente dal libro “BASI DI DATI RELAZIONALI E A OGGETTI”, di Albano, Ghelli e Orsini.
“Questa segreteria si occupa della gestione di alcune pratiche relative agli studenti del Corso di Laurea e del Corso di Diploma in Informatica. In particolare, noi gestiamo le richieste di trasferimento di studenti che provengono da altri Corsi di Laurea o che si spostano tra Corso di Laurea e Corso di Diploma. Quando uno studente desidera trasferirsi da noi, presenta domanda alla Facoltà di appartenenza, che la trasmette alla nostra Facoltà, che poi la trasmette a questa segreteria. La segreteria apre una pratica e trasmette la domanda alla Commissione Pratiche Studenti del Consiglio di Corso di Laurea e di Diploma (CCLD) che prepara una bozza di delibera, dalla quale si specificano quali esami vengono riconosciuti allo studente, eventualmente con un colloquio integrativo. Nel convalidare gli esami, si tiene conto del modo in cui esami analoghi sono stati convalidati in passato. Normalmente, cerchiamo di trattare nello stesso modo esami cono lo stesso nome fatti nella stessa Facoltà, ma possono esserci delle eccezioni quando i contenuti sono diversi. Per ciò che riguarda le informazioni da trattare, una domanda di trasferimento ha un numero di protocollo e contiene il nome e il recapito dello studente che la presenta, il Corso di Laurea di provenienza, la data di presentazione e l’elenco degli esami esterni superati. Il numero di protocollo è assegnato da noi ed è diverso da pratica a pratica. Per ogni domanda di trasferimento viene creata una pratica di trasferimento, che ha un proprio numero d’ordine e che contiene la domanda di trasferimento ed eventuali nostre annotazioni. Una delibera approvata contiene anche il numero e la data del verbale del CCLD che ha approvato tale delibera. Un esame da convalidare è caratterizzato da un’Università, una Facoltà, un Corso di Laurea, un Nome, un anno Accademico. L’università, la Facoltà e il Corso di Laurea dove l’esame è stato superato non coincidono necessariamente con l’Università di provenienza, la Facoltà di provenienza e il Corso di Laurea di provenienza della domanda a cui l’esame esterno appartiene. Gli esami interni hanno un nome, un codice univoco, ed un numero di unità didattiche che varia da uno a quattro. Ogni esame interno può appartenere al Corso di Diploma, al Corso di Laurea, o ad entrambi. Quando un esame esterno è convalidato per un esame interno, la convalida può essere “piena” o con “previo colloquio”. Per alcuni esami esterni esiste una “convalida tipica” per uno studente che passa alla Laurea ed una “convalida tipica” per uno studente che passa al Diploma. Ad esempio, la convalida tipica dell’esame di Fisica I a Ingegneria Elettronica, Facoltà di Ingegneria, è “Fisica Generale (1 UD)” per uno studente che passa al Diploma ed è “Fisica Generale 1 (2 UD)” per uno studente che passa alla laurea. Se la convalida tipica di un esame esterno per uno studente che passa alla Laurea o al Diploma è un esame comune tra Laurea e Diploma, allora, per questo esame, la convalida tipica per la Laurea è uguale alla convalida tipica per il Diploma. La convalida tipica sarebbe utile per la preparazione automatica della bozza di delibera. La convalida tipica può essere “previo colloquio”. Non sempre un esame dato da uno studente è convalidato secondo la sua convalida tipica.
Siamo interessati ad un sistema che permetta di memorizzare tutte le informazioni relative alle pratiche di trasferimento che vengono via via sbrigate. Questo sistema dovrebbe essere anche in grado di preparare una bozza di verbale a partire dall’elenco degli esami allegato ad una domanda di trasferimento, lasciando però alla segreteria la possibilità di intervenire per modificare i riconoscimenti proposti dal sistema”.

Successivamente, l’analisi dei requisiti dovrebbe essere rielaborata e scritta in una forma più tecnica, ottenendo così un documento che si chiama SPECIFICA DEI REQUISITI. Per quanto riguarda utenti non programmatori, possiamo dire che si deve semplicemente stilare una lista di oggetti e requisiti che dovranno caratterizzare il database. Per capire cosa deve comprendere questa lista, però, si devono conoscere tutte le altre fasi e si deve avere un’idea chiara di cos’è un database, cioè si deve avere coscienza di come sarà l’applicazione finale. Solo dopo aver provato a realizzare un archivio completo si riesce a capire come stilare la lista.