Architettura: tutto comincia dai requisiti!

Michele Aponte — Sun, 13 Sep 2009 20:45:26 GMT

Current revision posted to Articoli by Michele Aponte on 13/09/2009 22:45:26

ArchietturaArchitettura: tutto comincia dai requisiti!

Inserito sotto: Architettura

Rieccoci a parlare di architettura e come promesso in questo appuntamento parleremo di requisiti, i famosi requisiti software da cui un architetto comincia il suo lavoro e l’analista termina il suo con la loro definizione.

Che cos’è un requisito?

In accordo con la standardizzazione IEEE un requisito può essere definito come:

1. Una condizione o capacità necessaria ad un utente per risolvere un problema o raggiungere un obiettivo

2. Una condizione o capacità che deve essere posseduta dal sistema o da un componente del sistema per soddisfare un contratto, uno standard, una specifica o altre formalizzazioni.

3. Una rappresentazione documentata di una condizione o capacità che soddisfi i primi due punti

Alla luce di questa definizione, che ci aiuta a formalizzare meglio il concetto abbastanza intuitivo di requisito software, possiamo dunque dire che un requisito è un una capacità che il sistema deve possedere per risolvere un problema dell’utente, formalizzata opportunamente e opportunamente documentata.

Il fatto che un requisito per essere tale debba essere scritto da qualche parte è una fattore fondamentale: è l’unico modo di renderlo comunicabile efficacemente a chi ha bisogno di conoscerlo!

Tipologie di requisiti

Secondo la norma ISO 9126 è possibile raggruppare i requisiti in 6 categorie e 21 sottocategorie, alcune orientate all’utente, altre orientate allo sviluppo e manutenzione. Ognuna di queste categorie rappresenta una caratteristica del sistema:

Funzionalità

Esprime la capacità del sistema di soddisfare esigenze implicite o esplicite.

Idoneità:esprime l’appropriatezza delle funzionalità a specifici compiti.
Accuratezza: esprime la precisione con cui vengono forniti i risultati.
Interoperabilità: esprime la capacità di interagire con altre applicazioni
Sicurezza: esprime la protezione da utilizzi non autorizzati
Concordanza: esprime l’aderenza a standard o regolamentazioni legislative

Disponibilità

Esprime la capacità di fornire continuità nel servizio.

Maturità: esprime la mancanza di interruzioni per malfunzionamenti
Tolleranza: esprime il degrado delle prestazioni in presenza di malfunzionamenti
Recupero: esprime la capacità e la velocità di rispristino a seguito di malfunzionamenti

Usabilità

Esprime la facilità di utilizzo da parte degli utenti.

Comprensione: esprime la capacità di acquisire un adeguato livello di conoscenza del sistema
Apprendimento: esprime la facilità di familiarizzazione del sistema
Utilizzabilità: esprime la facilità di uso e controllo del sistema
Attrattiva: esprime il livello di gradimento nell’utilizzo del sistema

Efficienza

Esprime la capacità di fornire prestazioni adeguate

Tempo risposta: esprime la reattività agli stimoli dell’utente
Utilizzo di risorse: esprime l’adeguatezza dell’utilizzo delle risorse del sistema

Manutenibilità

Esprime la facilità di manutenzione correttiva ed evolutiva.

Analizzabilità: esprime la facilità di diagnosi e individuazione dei componenti
Modificabilità: esprime la facilità di applicazione delle modifiche al sistema
Stabilità: esprime il grado di introduzione effetti indesiderati a seguito di modifiche al sistema
Collaudabilità: esprime la capacità di testare le modifiche effettuate

Portabilità

Esprime la capacità di trasferibilità da un ambiente ad un altro

Adattabilità: esprime la facilità di adeguamento ad un nuovo ambiente
Installabilità: esprime la velocità e completezza di installazione
Coesistenza: esprime la capacità di risiedere con altre applicazioni nello stesso ambiente
Sostituibilità: esprime la capacità di rimpiazzare un’altra applicazione con simili funzionalità

Come si esprimono i requisiti?

Una volta capito cos’è un requisito chiediamoci adesso come esprimerli, una volta raccolti, in modo che sia possibile fornire la sopracitata rappresentazione documentata.

Il primo passo in assoluto da compiere è essere sicuri che abbiamo circoscritto per bene il sistema e gli unici a darci conferma della nostra corretta interpretazione delle interviste effettuate sono proprio gli intervistati: gli stakeholder! Dobbiamo quindi compilare per loro un documento che non utilizzi formalismi tecnici e che sia capace di descrivere, anche brevemente, quello che secondo noi è il sistema di cui il cliente ha bisogno. Questo documento ha un nome…

Documento di Vision e Scopo

Il documento di Vision e Scopo serve fondamentalmente ad allineare l’opinione di tutti gli stakeholder su quello che sarà fatto e a risolvere i conflitti nati da pareri discordati degli stessi.

Volendo fornire un template di tale documento, possiamo schematizzarlo nella seguente struttura:

Requisiti di Business

In questa sezione vengono descritti i principali benefici del nuovo sistema, con un’enfasi diversa a seconda del tipo di prodotto da realizzare.

Premessa:

in questo paragrafo descriveremo la storia delle valutazioni effettuate che hanno portato alla decisione di realizzare il prodotto.

Opportunità:

per un prodotto da immettere sul mercato in questo paragrafo descriveremo i principali fattori che potrebbero causare il successo delle vendite, nel caso di prodotto commissionato per una specifica azienda descriveremo i vantaggi dell’uso del sistema.

Obiettivi e criteri si successo:

in questo paragrafo descriveremo i vantaggi, in termini statistici e/o numerici, dell’adozione del prodotto; per un nuovo portale ad esempio descriveremo l’incremento di visite derivante dall’adozione del nuovo sistema.

Necessità del cliente o del mercato:

senza entrare nel dettaglio tecnico, descriveremo in questo paragrafo le necessità di un tipico cliente o del segmento del mercato in cui si colloca il prodotto, descrivendo ad esempio come il cliente dovrebbe usare il sistema.

Rischi:

qui descriveremo i potenziali rischi a cui si potrebbe andare incontro durante e dopo lo sviluppo del sistema; ad esempio un radicale cambio di interfaccia potrebbe portare l’utente a smettere di utilizzare il nuovo prodotto.

Vision della soluzione

In questa sezione sarà descritto il sistema che si andrà a realizzare per soddisfare gli obiettivi proposti. Non saranno descritti né i requisiti funzionali né informazioni sulla pianificazione del progetto.

Descrizione della soluzione:

in questo paragrafo sarà riassunto il sistema che sarà realizzato e come quest’ultimo permette di raggiungere gli obiettivi proposti. Si tratta di una descrizione che deve indicare le seguenti informazioni:

1. Per: clienti target
2. che: necessità e opportunità
3. il: nome del prodotto
4. è: la categoria del prodotto
5. che: benefici e/o ragioni che portano all’acquisto e/o all’utilizzo
6. a differenza: del sistema esistente o del non utilizzo del nuovo sistema
7. il nostro prodotto: principali differenze e vantaggi del nuovo prodotto

Un esempio potrebbe essere:

Per gli utenti che necessitano di emettere fatture e altri documenti in modalità differita, il nuovo MDVIN è un software gestionale che permette una gestione automatizzata di tutti i documenti necessari alla gestione di impresa. A differenza del suo predecessore il nostro prodotto permette di lavorare in modalità disconnessa da tutte le postazioni, sincronizzando solo quando necessario o indicato i dati con il server centrale.

Chiaramente sono indicazioni, che permettono di restare sintetici e incisivi sulle informazioni fornite.

Principali caratteristiche:

In questo paragrafo descriveremo le principali caratteristiche del nuovo prodotto, indicando cosa il nuovo sistema farà. Le nuove features vanno elencate con un identificativo univoco, in modo da potercisi riferire facilmente. E’ inoltre possibile fare confronti con prodotti direttamente concorrenti o precedenti versioni del sistema.

Assunzioni e dipendenze:

Qui è possibile elencare tutte le assunzioni venute fuori dalle interviste con gli stakeholder, probabilmente diverse o addirittura in contrasto tra di loro. Questo è il momento per mettere ordine e allineare tutti. E’ qui inoltre che vengono descritte eventuali dipendenze da altri sistemi o standard.

Scopo e limitazioni

In questa sezione saranno illustrati scopi e limitazioni del nuovo prodotto definendo delle priorità per i vari rilasci. Qui indicheremo sostanzialmente cosa il sistema farà e non farà.

Scopo del primo rilascio

Qui verranno descritte le priorità che saranno perseguite per il primo rilascio del software.

Scopo dei rilasci successivi

In questo paragrafo verranno descritte le schedulazioni dei vari rilasci fino al raggiungimento di tutti gli obiettivi mediante l’implementazione di tutte le caratteristiche.

Limitazioni ed esclusioni

Questo è il momento migliore per indicare cosa il sistema non farà e i limiti del suo utilizzo, indicando eventualmente eventuali predisposizioni a sviluppi futuri.

Contesto di analisi

In questa sezione viene descritto il contesto in cui ci muoviamo, indicando le categorie di stakeholder intervistati, le priorità del progetto e l’ambiente in cui il sistema sarà utilizzato.

Profili degli stakeholder

In questo paragrafo descriveremo schematicamente le categorie di stakeholder intervistati. Non necessariamente tutti vanno inclusi, solamente i più indicativi per gli obiettivi del progetto.

Priorità del progetto

Qui descriveremo le priorità funzionali e non funzionali del progetto, bilanciando tempi di sviluppo e obiettivi delle varie release, costi e benefici, considerando le cinque dimensioni di un progetto software: features, qualità, schedulazione, costo e staff.

Ambiente operativo

In questo paragrafo sarà descritto l’ambiente operativo in cui il sistema sarà utilizzato definendo la disponibilità, le performance e l’integrità richiesta. Queste informazioni influenzeranno sensibilmente l’architettura del sistema.

Naturalmente non tutte le voci potrebbero applicarsi a tutti i progetti ma soprattutto ricordiamoci che tale documento dovrà essere letto e approvato dagli stakeholder ed essendo un documento preliminare non mettiamoci a scrivere la bibbia del progetto: il documento deve essere sintetico altrimenti nessuno lo leggerà (o diranno di averlo letto ma in verità non lo hanno fatto!)

Conclusioni

Una volta avuta l’approvazione dagli stakeholder, dopo le n revisioni del documento, si passa alla realizzazione dei documenti che arriveranno all’architetto e da cui comincerà il suo lavoro! Alla prossima puntata!

Archiettura: tutto comincia dai requisiti!

Michele Aponte — Sun, 13 Sep 2009 20:43:26 GMT

Revision 1 posted to Articoli by Michele Aponte on 13/09/2009 22:43:26