• Vedi
• Modifica
• Versioni
• Stampa

AnalisiESpecificaDeiRequisiti

Analisi e specifica dei requisiti

Autori: Alberto Taiocchi

Significato, motivazioni, processi

E’ fondamentale comprendere i requisiti prima di iniziare la fase di progettazione e costruzione di un sistema computerizzato. Per ottenere ciò, occorre condurre un’insieme di attività di ingegneria dei requisiti. Quest’ultima si verifica durante le attività di comunicazione con il cliente e modellazione che sono state definite per il processo generico di sviluppo del software. L’analisi dei requisiti è un processo complicato ed ostico in quanto alla realizzazione concorrono diverse parti interessate (responsabili, utilizzatori, progettisti, leggi), ma anche perché gli obiettivi possono essere diversi e variabili nel tempo (possono sorgere ‘conflitti’ all’interno del team di analisi a causa di viste diverse da parte dei committenti). In molti casi anche l’incompletezza e l’incapacità di definire in maniera chiara i requisiti rendono l’analisi difficile da realizzare. Essendo diverse le parti interessate, l’analisi dei requisiti ricopre un ambito non solo tecnico, ma anche sociologico, di comunicazione e linguistico. A causa di questa elevata complessità l’operazione viene scomposta in diverse fasi.

Fasi dell’analisi dei requisiti:

1. Avvio: E’ la prima fase durante la quale si da origine all’analisi. Scopo di questa fase è quello di definire una solida conoscenza del problema, delle persone che desiderano una soluzione, della natura della soluzione desiderata e dell’efficienza delle comunicazioni e collaborazioni preliminari fra il cliente e lo sviluppatore.
2. Deduzione: In questa fase vengono identificati una serie di problemi che aiutano a comprendere perché la deduzione dei requisiti è difficile da realizzare per:
   • Problemi di ampiezza, limiti del sistema mal definiti oppure il cliente specifica dettagli tecnici futili che possono confondere gli obiettivi del sistema
   • Problemi di comprensione, i clienti non sono completamente sicuri di ciò di cui hanno bisogno, non hanno una conoscenza completa del dominio del problema, oppure omettono informazioni ovvie. Possono andare in conflitto con altri bisogni di altri clienti.
   • Problemi di volatilità, i requisiti cambiano nel corso del tempo.
3. Elaborazione: Le informazioni ottenute dal cliente durante le fasi di avvio e deduzione vengono espanse e raffinate. L’attività si concentra sullo sviluppo di un modello tecnico e raffinato di funzioni, caratteristiche e vincoli.
4. Negoziazione dei requisiti: Molto spesso i clienti richiedono più di quanto possa essere ottenuto, in base alle risorse disponibili. Inoltre è relativamente comune che i clienti propongano requisiti in conflitto con altri. Scopo dell’ingegnere è quello di riconciliare questi conflitti tramite un processo di negoziazione. I clienti valuteranno i requisiti e ne discuteranno le priorità. Dovranno poi essere analizzati i rischi associati a ciascun requisito.

La stesura dei requisiti di un progetto non implica necessariamente il corretto svolgersi del lavoro, si può correre il rischio di non fare le cose bene e produrre un documento errato o incompleto.In elenco vengono riportate alcune delle cause che portano ad avere un’analisi dei requisiti scorretta:

• non esiste una spiegazione del perché sono state prese determinate scelte, questo può portare ad avere un software di ottima qualità ma non è quello che serve
• le specifiche possono essere incomplete, vaghe e contradditorie
• incertezza generale rigurdante i requisiti
• un non chiaro perch´e del cliente porta a fare cose inservibili.

Il tutto può portare ad un intervento sul progetto, ormai creato, a posteriori molto doloroso anche in termini economici. Quindi il documento dei requisiti deve contenere una serie di informazioni ritenute sufficienti per effettuare stime dell’attività di svilupppo, per valutare l’impatto di ciascun requisito sui costi e sui tempi di consegna. Utilizzando un approccio iterativo, i requisiti vengono eliminati, combinati e/o modificati in modo che ognuna delle parti venga il più possibile soddisfatta. Si deve essere comunque pronti a gestire requisiti contenenti inconsistenze. Tali requisiti verranno ulteriormente dettagliati nelle fasi successive. Durante la fase di negoziazione vengono distinti tre classi di requisiti:

• Requisiti obbligatori, cioè irrinunciabili per il cliente.
• Requisiti desiderabili, non necessari ma utili.
• Requisiti opzionali, relativamente utili oppure contrattabili in seguito.

Specifiche

Terminata la fase di negoziazione si otteranno una serie di documenti contenenti un elenco di funzioni e caratteristiche che il prodotto deve possedere. Una specifica può essere un documento scritto, un insieme di modelli grafici, un modello matematico, un prototipo o una combinazione di questi elementi. Esistono due tipi di specifiche, le specifiche funzionali indicanti il motivo per cui viene realizzato il prodotto (che cosa deve fare il prodotto software) e le specifiche non funzionali descritte nella normativa 9126. Quest’ultime descrivono la qualità di un prodotto software in termini di:

• Funzionalità, insieme delle funzioni svolte dal sistema.
• Affidabilità, capacità di mantenere un certo livello di prestazioni nelle condizioni di lavoro reviste nei tempi di lavoro.
• Usabilità, relativo alla facilità con la quale gli utenti riescono ad interagire con il sistema (di solito appresentato dalla comprensibilità di una interfaccia).
• Efficienza, indica il tempo di esecuzione, in relazione ai vincoli di tempo, dovuta ad una sincronizzazione di tutto il sistema.
• Manutenibilità, sforzo relativo alle modifiche.
• Portabilità, possibilità di trasferire il software da un ambiente all’altro.

Convalida

Viene valutata la qualità del prodotto finale realizzato come conseguenza dell’ingengeria dei requisiti. Esamina le specifiche per garantirsi che tutti i requisiti software siano stati affermati in modo non ambiguo, che siano state rilevate e corrette tutte le incoerenze, le omissioni e gli errori e che i prodotti finali siano conformi agli standard definiti per il processo, il progetto e il prodotto.

Gestione dei requisiti

Si tratta un insieme di attività che aiuta il team del progetto a identificare, controllare e tracciare i requisiti e i cambiamenti nei requisiti a mano a mano che procede lo sviluppo del progetto.

Modellazione e analisi

L’identificazione dei requisiti genera un modello del sistema da realizzare e del suo contesto di utilizzo. Tale modello può essere usato per studiare le proprietà del sistema. In base al tipo di sistema che si vuole realizzare esistono vari approcci alla modellazione. Ad esempio si possono usare modelli basati sui dati (E-R), oppure modelli che studiano il comportamento dinamico di un sistema. In base al tipo di modellazione decisa si adotteranno diversi linguaggi (linguaggi naturali, naturali-strutturati, semiformali, formali). L’analisi dei requisiti è basata su processi di comunicazione tra progettisti, responsabili, utenti e esperti. Per poter permettere una comunicazione fluente si necessita di documentazione, linguaggi di specifica che siano espressivi, rigorosi e leggibili da utenti di diversa formazione. Poichè un documento di specifica può contenere un insieme complesso di elementi sarebbe utile usare uno standard di documentazione e seguire la vita dei requisiti (e i loro cambiamenti) lungo tutto il processo di sviluppo (tracciabilità).

Tecniche e linguaggi

Tecniche di estrazione dei requisiti

I requisiti non sempre sono deducibili da documenti, che spiegano o cercano di spiegare il problema, creati dal cliente. Bisogna assolutamente far luce sugli aspetti in ombra. Ci sono diverse tecniche per farlo, come interviste al cliente (strutturate o meno per argomenti, in modo da pilotare il cliente a farci chiarire eventuali aspetti oscuri, registrando l’intervista), preparando questionari scritti mirati, osservando possibili utenti futuri del sistema e studiando il sistema preesistente, se c’è. E’ buona regola anche effettuare degli incontri periodici tra clienti e sviluppatori per fare il punto della situazione e rilevare eventuali percorsi errati intrapresi dal progetto. Il risultato di tutto finirà sui documenti che possono essere scritti con tre tecniche differenti, in ordine di completezza:

• elenco strutturato dei requisiti
• elenco dei casi d’uso e di scenari d’utilizzo.
• modelli che simulano la realtà

Questi tre punti affrontano il problema con approcci diversi, ma hanno delle caratteristiche comuni:

• presenza di schemi
• identificazione di ogni requisito
• distinzione tra requisiti funzionali e non funzionali

Elenco strutturato dei requisiti

Presenta un elenco di caratteristiche, ognuna delle quali è dotata di un codice univoco che la identifica, un titolo ed una descrizione della funzione svolta all’interno del sistema.

Scenari e casi d’uso

Un caso d’uso rappresenta il modo in cui l’utente interagisce con il sistema in un determinato insieme di circostanze. La descrizione può essere narrativa, basata su modelli o schematica. Un caso d’uso rappresenta il software o il sistema dal punto di vista dell’utente finale. Il primo passo nella realizzazione di un caso d’uso consiste nel definire un insieme di ‘attori’ che saranno coinvolti nell’azione. Gli attori sono le varie persone (o dispositivi) che utilizzeranno il sistema o il prodotto nel contesto della funzione e il comportamento che deve essere descritto. Gli attori rappresentano i ruoli che le persone o i dispositivi giocano durante il funzionamento del sistema. Un attore è un elemento che comunica con il sistema o il prodotto e che è esterno al sistema stesso. Quindi un attore e un utente finale non sono necessariamente la stessa cosa. Un tipico utente può giocare vari ruoli nell’uso di un sistema, mentre un attore rappresenta una classe di entità esterne che giocano un unico ruolo nel contesto del caso d’uso. Poichè l’analisi dei requisiti è un’attività evolutiva, nella prima iterazione non vengono identificati tutti gli attori. E’ possibile identificare nella prima iterazione tutti gli attori principali e identificare gli attori secondari a mano a mano che aumenta la conoscenza del sistema. Uno scenario di utilizzo è un insieme di informazioni che descrivono, dal punto di vista dell’ utilizzatore, un utilizzo del sistema. Ci si può immaginare che uno scenario sia un racconto in cui un utente o un commerciale descrivono uno specifico insieme di funzionalità e modalità operative che vengono utilizzate per uno scopo definito e decorano il racconto con informazioni aggiuntive utili dal punto di vista del mercato come ad esempio l’importanza che attribuiscono a questo insieme di funzionalità o la disponibilit` a delle stesse all’interno dei prodotti della concorrenza. Uno scenario viene descritto in italiano, diagrammi di flusso dati, reti di Petri. . . La definizione di scenari e casi d’uso è utile quando è difficile creare un modello che simula la realtà. Inoltre a volte lo scenario non è ben definito, ad esempio quando il prodotto è destinato al mercato. Questo implica una difficoltà nell’integrazione tra scenari e casi d’uso.

Modelli d’analisi

Il modello per analizzare un problema è quello che fornisce una maggiore completezza. Si possono utilizzare diversi tipi di modelli:

• Concettuali, non richiedono competenze informatiche e di solito sono utilizzati in modelli di business, realizzati da persone con grande conoscenza del dominio applicativo.
• Tecnici, modelli della struttura statica e dinamica (Esempio: per definire l’evolversi di una particolare procedura organizzativa di un’azienda).
• Prototipi usa e getta, si creano delle versioni provvisorie del prodotto finale e lo si sottopone all’attenzione del cliente il quale darà ulteriori indicazioni sulla direzione da intraprendere nell’analisi.

Forme linguistiche

La specifica può essere prodotta utilizzato diverse forme linguistiche:

• Stili di specifica (formalismo)
  • Informali, linguaggio libero, come se fosse un libro.
  • Semi formali, linguaggio con sintassi definita solo in modo parziale.
  • Formali, linguaggio con sintassi e semantica predefinite.
• Stili di specificà (proceduralità)
  • Operazionali, descrivono il comportamento desiderato di un prodotto.
  • Dichiarative, descrivono la proprietà desiderate di un prodotto.

Sviluppando un prodotto non è possibile scegliere una forma linguistica migliore delle altre, mentre invece esistono tecniche più adatte di altre in particolari situazioni (Esempio: Schema E-R per strutturare dei dati, non una macchina a stati finiti). Il documento dei requisiti cosi prodotto, la specifica, sarà quindi caratterizzato dalla integrazione di queste tecniche. Non è possibile inoltre definire linguaggi formali migliori di quelli informali e viceversa. Bisogna essere coscenti del fatto che ci sono diverse persone coinvolte nel lavoro, con diversi punti di vista e dalle diverse competenze tecniche. Bisogna mirare al formalismo delle tecniche linguistiche garantendo ambiguità nulla e una comprensione completa da parte delle persone coinvolte.

Documentazione

L’analisi dei requisiti produrrà un documento, la specifica, che è un oggetto materiale, per esempio un documento di word, un file. Tutte le informazione ricavate durante l’analisi non vanno inserite in questo documento in modo disordinato, ma seguendo uno schema preciso, comprensibile, facile da leggere, contenente ovviamente tutte le informazioni ricavate dall’analisi, ma anche una serie di attributi ausiliari utili per gestire revisioni future del documento. Un documento per questi scopi normalmente ha un indice di questo tipo:

1. Storia delle revisioni
2. Introduzione
3. Scopo
4. Definizioni, abbreviazioni, sigle
5. Riferimenti
6. Contesto di riferimento
7. Situazione attuale
8. Limiti della situazione attuale
9. Obiettivi
10. Requisiti funzionali
11. Requisiti non funzionali
12. Profili utenti
13. Allegati

Modellazione e riuso della conoscenza

Il problema

Il problema del riuso della conoscenza consiste nel fatto in cui una volta che un prodotto è stato creato, magari partendo da zero, inevitabilmente l’esperienza maturata negli sviluppatori lascia un segno nel loro bagaglio tecnico. Questa conoscenza va riutilizzata per affrontare nuovi progetti, che potranno essere sviluppati con più efficacia se si fa tesoro dell’esperienza precedente. Un prodotto software risulta quindi essere un insieme di conoscenze relative ad un dominio applicativo, ad un processo, un businnes, ecc. che in qualche modo va riutilizzato. Ci sono diverse tecniche moderne per riutilizzare prodotti software, sviluppo di prodotti per integrazione con legacy e cots, ecc. Un esempio efficace, utilizzato nella pratica ormai da tempo (e non solo nell’informatica) è quello dei pattern.

Pattern

Il pattern è uno schema che un’applicazione segue per risolvere un problema. Non è uno schema particolare relativo ad un certo problema, ma un’astrazione, un modello concettuale per risolvere vari casi. Infatti diversi problemi, per quanto abbiano domini applicativi diversi, hanno forme ricorrenti di base uguali e quindi possono essere affrontati tutti utilizzando una logica comune. Il cuore del concetto di riuso non risiede nello sfruttare la tecnologia precedente, ma nel capire il mercato e i processi dei clienti, in modo da scoprire la forma ricorrente su cui si basa il funzionamento.

Analisi del dominio applicativo

Per capire quale sia la forma ricorrente dietro un processo bisogna capirne il dominio applicativo. Per farlo, si deve raccogliere una serie di dati dello specifico settore. Dobbiamo identificare le caratteristiche, i requisiti ,le architetture comuni. Raccogliere una collezione di modelli che descrivono i processi di business dello specifico settore di interesse:

• Modelli del contesto
• Modelli di flusso di dati
• Modelli di dati
• Modelli ad oggetti
• Scenari
• Dizionario dei termini

Prodotti dell’analisi di dominio:

• Caratterizzazione del dominio delle caratteristiche
• Modelli Dominio & Framework, modelli delle entità e delle macrocomponenti comuni per le applicazioni del dominio

Relazioni con le altre fasi

Requisiti di sistema e requisiti software

I requisiti di sistema e i requisiti software rappresentano la descrizione delle caratteristiche che un software e i componenti del sistema devono avere per poter interagire tra di loro, formando un sistema completo e funzionante. Infatti nella realtà succede che ci sono diversi componenti, tutti di natura altrettanto diversa, che devono interagire tra di loro. Bisogna definire allora l’architettura, cioè integrare e far interagire in maniera corretta i requisiti del sistema con tale organizzazione.

Relazioni con la progettazione

Un’analisi dei requisiti per un prodotto di piccole dimensioni necessita di una breve analisi per poi passare più o meno facilmente alla sua implementazione. Di norma nella realtà, soprattutto per sistemi di grande dimensioni, si segue uno schema che prevede la progettazione architetturale del sistema, mentre in una fase successiva si analizzano aspetti più particolari, dando vita alla progettazione di dettaglio. Questo passo viene fatto per diversi motivi. Serve per stimare la dimensione di un progetto e poter cos`ı stabile i termini del contratto alla fine dell’analisi; serve anche per analizzare in dettaglio aspetti considerati più critici che necessitano più attenzione e uno studio più accurato.

Studio di fattibilità

Lo studio di fattibilità precede il processo di sviluppo. Si compone di vari punti

• Include un processo di sviluppo ‘in piccolo’ con lo scopo di
  • Dimostrare la fattibilità, anche attraverso modelli e prototipi
  • Valutare le scelte, costi, rischi e benefici
• Identificazione dei requisiti
  • Contesto nel quale il sistema dovrà lavorare e con chi dovrà interagire (utenti esperti, utenti generici)
  • Obiettivi
  • Specifiche generali
• Scelte e alternative architetturali
  • Architettura di sistema
  • Make or buy
• Servizi
  • Avvio
  • Formazione
  • Manutenzione
• Pianificazione di massima e tempi
  • Rischi
  • Costi
  • Benefici
  • Competitors
  • Eventuale realizzazione di componenti critici o prototipali

Validazione

La fase di validazione ha lo scopo principale di accertarsi che il lavoro svolto fino ad ora sia corretto. Validare un documento significa provare che si comporti come dovrebbe. Questo implica che ci sia un oggetto con la relativa descrizione, che dovrà essere validato. Validare una specifica risulta difficile per motivi quali:

• Aspetti cognitivi ( documento requisiti è un modello di una parte della realtà)
  • Mondo oggettivo che può essere modellato da un insieme consistente di conoscenze basato su osservazioni empiriche
  • Teorie scientifiche non possono essere provate corrette attraverso le osservazioni, esse possono essere solo falsificate (Popper)
  • Le osservazioni non sono neutre (libere da valori) ma si muovono lungo punti di vista dominanti (Kuhn)
• Aspetto sociale (documento dei requisiti è espressione di un sistema sociale)
  • Gli attori hanno ruoli diversi (dirigente vede il sistema alla sua maniera diversa da quella dell’impiegato, interessi diversi, conoscenze diverse)
• Non esiste ancora un codice che mi permetta di toccare con mano i risultati (non si può pensare di scriverlo perch´e si salterebbe la fase di validazione e tutto il discorso che si sta facendo) Bisogna allora fare delle prove, delle simulazioni che accrescano la fiducia nei confronti

della specifica che si è realizzata, assicurandosi di ciò che il prodotto finale sarà in grado di svolgere. In ogni caso è necessario gestire requisiti che contengono inconsistenze ed evolvono nel tempo Ci sono diversi metodi per accrescere la fiducia nei confronti di un prodotto:

• Verificare la coerenza interna analizzando la struttura, la comprensibilità del linguaggio e della funzione svolta, ricercare incompletezze, inconsistenze e definizioni vaghe.
• Verificare le proprietà del sistema.
• Creare corrispondenza tra i desideri delle parti interessate, analizzando il tutto con utenti, clienti, sviluppatori ed esperti del dominio applicativo.
• Simulare il prodotto finale (anche con dei prototipi) per valutare con mano.
• Negoziare contrasti interni di viste a proposito di qualsiasi aspetto che produce incongruenze tra i modi diversi di vedere il prodotto finale o alcune delle sue caratteristiche.

Evoluzione

Fin dall’inizio dell’analisi dei requisiti bisogna impostare lo studio tenendo bene in mente che il nostro prodotto sarà per forza di cose soggetto a dei cambiamenti. La storia insegna che i software di maggiore successo sono quelli che hanno saputo adattarsi hai cambiamenti. Un software di successo è esso stesso motore del cambiamento, gestire il cambiamento è una attività fondamentale dell’analisi dei requisiti. Sin dall’inizio del progetto bisogna pensare al cambiamento. Per cambiamenti si intende una serie di aspetti fondamentali:

• Correggere errori che si trovano durante l’utilizzo del prodotto finale ormai consegnato al cliente.
• Adattarsi ai cambiamenti dell’organizzazione aziendale, delle tecnologie e degli obiettivi per cui il prodotto è stato creato.
• Garantire una specializzazione sufficiente, evitando di generalizzare troppo, cosi come specializzare troppo.
• Basare la progettazione su ciò che è stabile per garantire una certa efficienza.

La progettazione è il cuore del mestiere. Non esiste una vera tecnica che viene applicata, ma esistono una serie di strumenti messi a disposizione dell’ingegnere utili per produrre il documento di progetto.