progetto e-COM 1. Analisi e definizione dei requisiti >>>
documento 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).
Le finalità dell’analisi e definizione dei requisiti si possono quindi schematizzare in tre punti:
- Conoscenza del dominio del problema
:
Raccogliere e formalizzare le necessità dell'utente;
- Individuazione delle Responsabilità
:
Stabilire un elenco di obblighi che il sistema deve soddisfare;
- Corrispondenza diretta
tra il dominio del problema e le responsabilità del sistema.
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.
Le principali regole generali per ottenere una specifica dei requisiti precisa e senza ambiguità sono le seguenti:
- Scegliere il corretto livello di astrazione.
E’ bene evitare di utilizzare termini troppo generici o troppo specifici che rendono poco chiaro un concetto.
- Standardizzare la struttura delle frasi.
Nella specifica dei requisiti è preferibile usare sempre lo stesso stile sintattico.
- Evitare frasi contorte.
Le definizioni devono essere semplici e chiare.
- Individuare sinonimi/omonimi e unificare i termini.
Queste situazioni si possono chiarire: nel caso di sinonimi, unificando i termini, nel caso di omonimi, utilizzando termini diversi o specificandoli meglio.
- Rendere più esplicito il riferimento tra termini.
- Costruire un glossario dei termini.
Per ogni termine deve contenere: una breve descrizione, possibili sinonimi e altri termini contenuti nel glossario con i quali esiste un legame logico.
Gli strumenti più utili, sia durante le interviste con l’utente di primo livello che per l'organizzazione dei requisiti raccolti sono:
- Diagramma di Contesto,
evidenzia le interfacce (attori) del sistema e i flussi di informazioni tra essi rilevanti. Le interfacce individuate devono essere raggruppate per omogeneità e si ottiene così una prima ipotesi di Modalità Operative che il progetto può avere.
- Data Flow diagram (DFD),
ottenuto dal primo raffinamento del Diagramma di Contesto per individuare un primo insieme di responsabilità.
- Modello E-R,
realizzato sulla base delle classi di oggetti percepiti descrive lo schema scheletro per una prima rappresentazione dei dati del sistema.
- Prototipo
, costruito in un ambiente visuale, facilita il dialogo con l'utente.
Le principali fonti di informazione sono:
gli utenti della applicazione, tutta la documentazione esistente che ha qualche attinenza con il problema allo studio, eventuali realizzazioni preesistenti, che si devono rimpiazzare o che devono interagire in qualche maniera con il sistema da realizzare.