Specifica dei requisiti

Tipologie di requisiti


La raccolta dei requisiti deve raccogliere tutte le indicazioni necessarie per comprendere le necessità del cliente ed i vincoli del sistema su cui intervenire.

Si possono individuare tre distinti livelli di requisiti che dovranno essere analizzati con il cliente:
- requisiti di business, ossia descrizione di massima dell’ambiente in cui il cliente opera, della sua organizzazione del lavoro, delle interfacce con altre entità (si tratta di notizie utili per descrivere il sistema di riferimento entro cui operare)
- requisiti utente, ossia la descrizione delle attività da informatizzare (descrivibili ad esempio attraverso formalismi del tipo "use cases",
- requisiti software, che descriveranno sia obiettivi funzionali (tipologia di elaborazioni, layout di report, etc) che non funzionali (prestazionali, qualità, regole di business, vincoli di progettazione e implementazione, interfacce esterne) da implementare nell’applicazione.


 

Forma del documento


Un documento di specifica dei requisiti deve prevedere, organizzate non necessariamente nello stesso modo, le seguenti voci:

INTRODUZIONE
- Scopo e ambito di validità
- Ambito di validità
- Presentazione del documento
- Glossario e lista degli acronimi
- Documenti applicabili e riferiti

DESCRIZIONE GENERALE
- Obiettivi del prodotto
- Descrizione dell’ambiente operativo
- Relazioni con altri sistemi
- Vincoli generali

DESCRIZIONE DEI REQUISITI
- Requisiti funzionali (per ogni requisito: descrizione, input, output, processo)
- Requisiti prestazionali
- Requisiti di interfaccia
- Requisiti operativi (modalità di utilizzo del software)
- Requisiti di risorse hardware e software di base
- Vincoli di progetto e implementazione
- Requisiti di sicurezza e protezione
- Requisiti di portabilità
- Requisiti di qualità
- Requisiti di affidabilità
- Requisiti di manutenibilità
- Requisiti relativi al personale utente
- Requisiti di installazione

VERIFICA, VALIDAZIONE, COLLAUDO
- Riferimento alle procedure per la verifica e validazione dei requisiti
- Riferimento alle procedure per il collaudo

Il documento di specifica dei requisiti deve essere accettato e controfirmato dal cliente.
Il documento sarà gestito in configurazione, ed ogni richiesta di modifica dovrà essere tracciata secondo le procedure definite.


 

Cosa richiedono le norme: ISO 9001


"Per procedere allo sviluppo del software, il fornitore dovrebbe avere un insieme completo e non ambiguo di requisiti funzionali.
Inoltre, tali requisiti dovrebbero includere tutti gli aspetti necessari a soddisfare le esigenze dell’acquirente.
Questi aspetti possono includere, tra l’altro, prestazioni, sicurezza, affidabilità, riservatezza.
Questi requisiti dovrebbero essere formulati in modo sufficientemente preciso da permettere la validazione in fase di accettazione del prodotto." (...)

"La specifica dei requisiti dell’acquirente registra questi requisiti.
In alcuni casi, tale documento è fornito dall’acquirente. Altrimenti, il fornitore dovrebbe sviluppare questi requisiti in stretta cooperazione con l’acquirente, e il fornitore dovrebbe ottenere l’approvazione dell’acquirente prima di entrare nella fase di sviluppo.
La specifica dei requisiti dell’acquirente dovrebbe essere assogettata a controllo della documentazione e a configuration management come parte integrante della documentazione di sviluppo."


 

Cosa richiedono le norme: CMM


I requisiti devono essere sottoposti a review (riesame) per:
- identificare i requisiti incompleti e mancanti,
- accertarsi che siano fattibili, non ambigui, consistenti e verificabili,
- sottoporre a revisione i requisiti che presentano dei problemi.

I requisiti devono essere:
- sottoposti a procedure di change management e version control,
- utilizzati come base per la pianificazione delle attività,
- utilizzati per derivare requisiti interni al progetto software.

In caso di variazione ai requisiti si dovrà:
- valutare l’impatto delle modifiche sul sistema, e negoziare con le parti interessate i relativi cambiamenti (tempi, costi, funzioni),
- effettuare le modifiche necessarie ai piani e ai prodotti dello sviluppo, per allinearli alle variazioni intervenute.


 

Difficoltà di comunicazione


In una situazione ideale, il committente comunica i requisiti all’avvio del progetto in forma già definita e completa, già pronti per essere presi in carico dai progettisti.
Nel mondo reale, invece, la scoperta dei requisiti è un'attività faticosa, e comporta una serie ripetuta di interazioni e discussioni tra gli attori coinvolti.
Il committente ha chiari i propri obiettivi di business, ma non è quasi mai in grado di elaborare autonomamente un elenco di requisiti completo e dettagliato. Il compito dell’analista consiste quindi nell’aiutare il committente a chiarire progressivamente tutti gli aspetti del problema, attraverso interviste, analisi degli scenari operativi, proposte di lavoro.
L'obiettivo in questa fase è stimolare il committente, rendendolo consapevole delle diverse possibilità di soluzione, in modo da aiutarlo nella definizione di requisiti quanto più precisi e dettagliati.