Ufficio Centrale per lo sviluppo e la gestione del Sistema Informativo
 |
MetoDoc v1.0 |
|
MetoDoc v1.0 |
6.1 Analisi e definizione dei requisiti
"L’analisi è lo studio del dominio di un problema che porta ad una specifica del comportamento esternamente osservabile, una descrizione completa, coerente e fattibile ed una trattazione quantitativa di ciò che occorre realizzare (cioè affidabilità, disponibilità, prestazioni); ovvero è il processo di astrarre i bisogni di un sistema" (Coad & Yourdon).
Ai fini di una corretta esecuzione delle fasi di produzione del software gestionale è necessario considerare il documento di fattibilità nella sua interezza. Alcune soluzioni dello studio di fattibilità privilegiano le caratteristiche di completezza, altre tengono maggiore conto di vincoli temporali e di costo. Solo lo studio di tutte le soluzioni proposte aumenta la conoscenza del dominio del problema. Inoltre, è importante tenere presente che l’utente deve svolgere un ruolo attivo, fin dall’inizio. L’utente è l’unico a sapere quali tipologie di dati sono da rappresentare e quali funzioni sono da automatizzare.
Figura 6.1.1 – Il prodotto della fase di Analisi e definizione dei requisiti.
Scopo principale dell’analisi e definizione dei requisiti è la comprensione del dominio del problema: la piena conoscenza è garantita se e solo se non esistono requisiti non espressi. Obiettivo dello studio è quindi descrivere in maniera completa cosa fa il sistema (senza stabilire come), in modo tale da stabilire un protocollo comune di comunicazione tra gli esperti del dominio del problema ed il gruppo di lavoro.
Si cercano e si esaminano pertanto tutte le "informazioni" disponibili e si prescinde dalle tecnologie che verranno utilizzate.
Le finalità dell’analisi e definizione dei requisiti si possono quindi schematizzare in tre punti:
La fase di analisi e definizione dei requisiti considera lo Studio di fattibilità e i requisiti e produce il Documento dei requisiti, come mostrato in Figura 6.1.1.
6.1.2 Comprensione del dominio del problema
La prima parte dell’attività di analisi e definizione dei requisiti è concentrata sulla comprensione e la conoscenza approfondita del dominio del problema. Osservare in prima persona, esaminare altri sistemi simili, ascoltare attentamente gli esperti e leggere qualsiasi riferimento che possa favorire la conoscenza degli argomenti ad esso inerenti sono attività fondamentali.
Questa è la fase in cui l'utente comunica le specifiche del sistema da realizzare al gruppo di sviluppo del software, che a sua volta si preoccupa di comprendere il dominio del problema preso in esame, formalizzare le specifiche e comunicare all'utente la sua comprensione del dominio.
Il rapporto diretto con gli utenti nella raccolta dei requisiti, riveste un’importanza assoluta; grazie ad esso è possibile percepire come viene visto il problema da tutte le tipologie di utenti ai vari livelli.
Avviene che utenti diversi forniscano informazioni diverse: spesso complementari, ma qualche volta contraddittorie. Gli utenti a livello più alto possiedono una visione più ampia e meno dettagliata ma possono indirizzare verso gli esperti dei singoli sottoproblemi.
Il meccanismo fondamentale per la conoscenza, definizione e rappresentazione del dominio del problema è l’astrazione. Ossia il principio di ignorare gli aspetti che non sono importanti, per concentrarsi maggiormente su quelli che lo sono.
La complessità dei sistemi da modellare oggi eccede generalmente le normali capacità di una mente umana. Quando si utilizza il concetto di astrazione, si ammette di considerare la questione trattata come complessa, ma piuttosto che cercare di comprenderla e rappresentarla interamente, si seleziona solo una parte. Ben si sa che la parte considerata contiene dettagli, ma semplicemente si decide di non cercarli e non usarli, per il momento. Questa tecnica è molto importante per gestire la complessità e per comunicare con l’utente e gli altri attori in tutte le fasi della produzione del software gestionale al giusto livello di dettaglio.
Durante l'analisi e definizione dei requisiti è importante individuare il giusto livello di astrazione.
Per quanto riguarda i dati, si definiscono le entità che si percepiscono direttamente dall’utente. L’analista deve essere, quindi, in grado di classificare gli oggetti indipendentemente dalle loro caratteristiche e guardarli solo dal punto di vista statico.
Per quanto riguarda l’aspetto funzionale, è necessario individuare le responsabilità di livello più alto. In questo caso, per astrazione si intende il principio secondo il quale ogni operazione che ottiene un effetto ben definito sul sistema possa essere considerata come un’entità singola, nonostante sia effettivamente realizzata da una sequenza di operazioni di livello inferiore. La scomposizione poi delle responsabilità in sottoresponsabilità è uno dei metodi fondamentali per gestire la complessità. Questo è comunque un processo arbitrario durante il quale è l’analista che mette in corrispondenza il dominio del problema con funzionalità e sottofunzionalità, occorre quindi sempre verificare con l’utente prima di procedere.
6.1.2.2 Scomposizione in sottosistemi
Nella maggior parte dei sistemi industriali la complessità è molto elevata ed è opportuno pertanto affrontare la realizzazione di un sistema software attraverso l'individuazione di sottosistemi. Per sottosistema intendiamo un'area organizzativa caratterizzata da una omogeneità di funzioni o da una omogeneità dei prodotti forniti al sistema globale.
L'individuazione di aree di lavoro o sottosistemi è un momento importante all’interno del processo di produzione del software e lo caratterizza in maniera determinante. E' importante che si arrivi alla definizione finale di un sottosistema dopo aver esaminato l'effettiva possibilità di formalizzare la parte dei requisiti relativa a quel particolare sottodominio.
E' l'analista che si preoccupa di estrarre i concetti e le aree operative fondamentali per l'individuazione dei sottosistemi. Questo processo risulta complesso e articolato ed è frutto di una serie di elaborazioni che richiedono operazioni di astrazione, raffinamento, ricerca di modularità.
Il reperimento e l’analisi dei requisiti sono attività difficilmente standardizzabili, a causa della variabilità del dominio del problema in esame e delle implicazioni generate dall’interazione con i diversi tipi di utenti.
Alcuni strumenti sono comunque utili, sia durante le interviste con l’utente di primo livello che per l'organizzazione dei requisiti raccolti. In questa fase non è importante che tali strumenti risultino descritti in maniera rigorosa e completa: la loro formalizzazione verrà effettuata solamente in fase di analisi concettuale.
Figura 6.1.2 – Il diagramma di contesto.
6.1.3.1 Il processo di analisi e definizione dei requisiti.
Il processo di analisi di un sistema informativo viene svolto attraverso raffinamenti successivi, più immediati se le descrizioni dei dati e delle funzioni procedono di pari passo. Per ogni responsabilità di primo livello, attraverso il colloquio con l’utente, il modello E-R e il DFD si individuano le sottoresponsabilità.
L’analista rappresenta le prime responsabilità percepite, realizza il primo prototipo in ambiente visuale e lo sottopone all’attenzione dell’utente. Ogni volta che si percepisce una nuova responsabilità di pari livello si incrementa il prototipo.
Il processo viene iterato fino alla rilevazione di tutte le responsabilità che il sistema deve soddisfare. Per ognuna di esse occorre definire i compiti e descriverli all’interno del documento dei requisiti. Questo, nella parte funzioni da implementare, riproduce esattamente la struttura del prototipo.
Figura 6.1.3 – Il processo di analisi e definizione dei requisiti.
6.1.3.2 Organizzazione dei requisiti
Al momento della definizione del progetto, nella maggior parte dei casi, l'analista non è un esperto nella materia dell'attività o dell'applicazione dell’utente, ma è necessario che egli possa comprendere a fondo il dominio del problema. Anche nel caso in cui sia un esperto della materia, è importantissimo che dialoghi con l'utente e con gli altri componenti del gruppo di progettazione, perché se un analista semplicemente presuppone di avere conoscenza della materia, è facile che il suo lavoro porti a requisiti non precisi. Un analista deve specificare requisiti funzionali che possano essere letti da ogni attore del processo di produzione.
I requisiti di una applicazione provengono da fonti diverse.
Le principali fonti di informazione sono le seguenti:
Gli strumenti ad esse correlati risultano essere:
6.1.3.3 Strategie di analisi dei requisiti
La strategia di analisi deve tenere conto delle caratteristiche linguistiche dei requisiti a disposizione. E’ chiaro infatti che, quanto più il linguaggio con cui sono espressi i requisiti è strutturato, espresso cioè secondo regole non ambigue e formali, tanto più sarà facile, attraverso un’analisi della struttura dei requisiti, comprenderne il significato.
Figura 6.1.4 – La strategia dell’analisi dei requisiti (Batini).
È dunque conveniente effettuare una analisi dei requisiti preliminare alla fase di concettualizzazione, in cui l’attenzione è posta sui requisiti e sul modo in cui sono strutturati, senza ancora prefigurare la loro espressione in termini del modello concettuale.
Quando la descrizione è ambigua e destrutturata converrà procedere, fin dall’inizio, ad una concettualizzazione dei requisiti in termini dello schema scheletro, a fronte del quale procedere a successivi raffinamenti.
Una rappresentazione schematica di questo approccio è riportato in figura 6.1.4.
6.1.3.4 Descrizione dei requisiti
Le principali regole generali per ottenere una specifica dei requisiti precisa e senza ambiguità sono le seguenti:
Figura 6.1.5 – L’analisi dei requisiti (Batini).
6.1.3.5 Necessità di iterare
Una metodologia per effettuare l’analisi dei requisiti può essere schematizzata come una sequenza iterativa dei passi evidenziati nella Figura 6.1.5.
I requisiti forniti dall’utente comprendono implicitamente la struttura dei dati, le funzioni del sistema (requisiti funzionali) e le altre caratteristiche che il sistema deve possedere come la facilità d’uso, l’affidabilità, la disponibilità, la modificabilità, le prestazioni, le interfacce con altri sistemi, gli ambienti in cui deve funzionare e qualunque altro vincolo di progetto applicabile (requisiti non funzionali).
Il percorso metodologico di riferimento per la realizzazione del documento dei requisiti è riportato in Figura 6.1.6.
Figura 6.1.6 – Il percorso metodologico della fase di Analisi
e definizione dei requisiti.
Gli input della fase di Analisi e definizione dei requisiti sono il documento di fattibilità e i requisiti forniti dall’utente.
A partire da questi prodotti di input, attraverso l’uso degli strumenti a disposizione, l’analista elabora una prima divisione dei requisiti a livello di sottosistema 1.
Per ogni sottosistema si procede con la rilevazione e definizione delle singole responsabilità. Individuati i requisiti di ogni responsabilità, li si integrano con quelli del sottosistema di primo livello e quindi si costruisce un primo documento dei requisiti a livello di sottosistema. Integrando i diversi documenti si ottiene il documento dei requisiti a livello di sistema. Questo sarà il prodotto finale della fase di analisi e definizione dei requisiti.
Come è evidenziato nella figura, il percorso metodologico prevede la possibilità di alcuni feedback.
Non sono possibili ritorni agli input poiché sono stati definiti e validati nelle fasi precedenti.
Se le responsabilità sono state raggruppate in maniera errata è possibile un ritorno ai requisiti dei sottosistemi per inquadrare le singole responsabilità nel sottosistema opportuno.
Nel caso in cui nei documenti dei requisiti dei sottosistemi si individuino espressioni che esprimono lo stesso concetto in punti differenti, allora è possibile un ritorno ai requisiti delle singole responsabilità oppure a quelli dei sottosistemi per andare eventualmente a ridefinire la suddivisione del sistema.
Gli eventuali errori vengono quindi individuati prima di effettuare l’integrazione dei diversi documenti dei requisiti dei sottosistemi. Una volta costruito il documento finale non sono quindi previsti feedback alle fasi precedenti.
Possiamo riassumere i passi da seguire per la redazione del documento nello schema seguente:
6.1.5 Contenuto del documento dei requisiti
Il Documento dei requisiti è organizzato nelle seguenti parti:
Premessa:
Descrizione della realtà d’interesse; Contesto; Vincoli; Ambiente Tecnologico; Sistema Operativo; DBMS; Ambiente di Sviluppo; Interfaccia.Obiettivi:
Descrizione degli obiettivi che il software da sviluppare deve perseguire.Glossario:
Definizione dei termini specifici introdotti secondo l’accezione propria del dominio del problema.Funzionalità Esistenti:
Descrizione delle funzionalità implementate ai livelli di informatizzazione precedente.Funzionalità da implementare:
Descrizione del comportamento delle funzionalità da automatizzare.Espansioni Future:
Funzionalità previste ma non realizzate; tali funzionalità rivestono una certa importanza poiché il sistema deve essere realizzato tenendo conto dell’eventualità di tali possibili espansioni.
