Nell’analisi strutturata il diagramma di contesto è considerato un must, il primo passo dell’analisi, da cui partire per identificare le funzionalità del sistema con le tecniche di scomposizione.

1. Linee guida per la Gestione
dei Requisiti
Iolanda Salinari

2. 2
Sommario
Introduzione
Un framework per il processo di gestione dei requisiti
Requisiti e altri processi del progetto
Requisiti e project management
Definire i requisiti
Gestire l’evoluzione dei requisiti (intro)
Scoprire i requisiti
Analizzare i requisiti
Specificare i requisiti
Verificare i requisiti
Gestire l’evoluzione dei requisiti
Linee guida per scrivere i requisiti
Le misure di qualità per valutare la specifica di un requisito software
Requisiti e standard
CMM
ISO 9000
ISO 9126 – La qualità del prodotto software
Glossario
Bibliografia e testi consigliati
Introduzione
La Gestione dei Requisiti è oggi considerata determinante per il miglioramento dello
sviluppo del software e per il successo dei progetti. E' raccomandata come prima "key
process area" nel Capability Maturity Model del SEI e dalle linee guida ISO 9000.
L'intento è quello di definire un processo che stabilisce e mantiene l'accordo tra le parti
interessate (clienti e team di progetto) sull'identificazione e l'evoluzione dei requisiti del
sistema. Tale processo comporta un approccio sistematico per individuare, analizzare,
specificare, verificare e gestire nel tempo i requisiti.
La Gestione dei Requisiti è stata ideata principalmente per migliorare lo sviluppo del
software, ridurre i costi e i rischi correlati alla sua costruzione.
Sebbene sia di importanza decisiva soprattutto nelle fasi iniziali di un progetto, si tratta
di un processo che accompagna tutto il ciclo di vita del software.
Un framework per il processo di gestione dei requisiti

3. 3
Il framework qui presentato è una rielaborazione di quanto proposto da Karl E. Wiegers
(vedi testo "Software requirements") sulla base dell'esperienza di Tecnet Dati nella
consulenza e formazione in tale ambito. L'intero documento si ispira, inoltre, alle idee
di altri autorevoli esperti di Requirements Engineering, quali Ian Sommerville, Suzanne
Robertson, Dean Leffingwell e Don Widrig.
Il processo di Gestione dei Requisiti deve integrarsi con il project management e altri
processi del progetto.
Requisiti e altri processi del progetto

4. 4
Requisiti e project management
La gestione dei requisiti è strettamente connessa alle attività di project management,
infatti i requisiti sono la base per la pianificazione dei progetti e le modifiche ai requisiti
hanno impatto su tale pianificazione.
I piani di progetto dovrebbero, per quanto possibile, anticipare le modifiche prevedibili
ai requisiti e conciliarle con l'ambito del progetto.
In relazione alla gestione dei requisiti, elenchiamo alcune attività d'importanza
fondamentale per il progetto:
• Selezionare un ciclo di vita del software
Scegliere un modello per il ciclo di vita del software idoneo alle esigenze del
progetto.
Se inizialmente l'ambito del progetto e i requisiti non sono sufficientemente
determinati, può essere utile adottare un approccio incrementale, che, pur
basandosi su un'architettura robusta e aperta al cambiamento, preveda di
rilasciare il prodotto in più tranche e consenta di focalizzarsi in un primo tempo
sui requisiti più chiari.
• Basare i piani di progetto sui requisiti
Occorre produrre in modo iterativo e incrementale i piani del progetto e le
relative stime d'impegno, in modo da riadattarli man mano che aumenta la
comprensione dei requisiti e la loro definizione si fa più precisa.
• Rinegoziare i termini dell'accordo/contratto con i clienti quando cambiano i
requisiti
A fronte di modifiche ai requisiti (nuovi requisiti, variazioni a requisiti esistenti),
valutare l'impatto su tempi e costi e rinegoziare i termini dell'accordo. Gestire in
modo opportuno gli eventuali rischi associati all'intervento richiesto.
• Documentare e gestire i rischi di progetto
Individuare i rischi correlati al contesto del progetto e alla gestione dei requisiti
(es: il successo del progetto dipende da entità esterne quali altri fornitori o altri
progetti; è richiesto l'utilizzo di tecnologie innovative e poco conosciute dai
progettisti; assenza di sponsor, è impossibile coinvolgere gli utenti in modo
continuativo, turnover nel gruppo di progetto o degli utenti; scarsa conoscenza
del dominio del problema, ecc.).
Documentare i rischi, definire le azioni correttive più idonee e controllarne lo
stato di avanzamento e l'efficacia.
• Tracciare il carico di lavoro richiesto per le attività di gestione dei requisiti
Tener traccia dell'impegno richiesto dalle attività di definizione e gestione dei
requisiti per migliorare la pianificazione di tali attività nei progetti successivi.
Definire i requisiti
Le principali attività sono le seguenti:
• Individuare le classi di utenti da coinvolgere nella definizione dei requisiti
• Scoprire le necessità dei clienti / utenti
• Capire gli attuali scenari di operatività degli utenti e le necessità del business

5. 5
• Analizzare le informazioni ricevute dagli utenti, differenziandole in requisiti
funzionali, vincoli di varia natura, regole di business, attributi di qualità,
necessità, suggerimenti e informazioni di vario genere
• Definire i confini del sistema, individuare eventuali sottosistemi, suddividere ed
allocare i requisiti del sistema in accordo a tale partizionamento
• Identificare i fattori di performance e gli attributi di qualità più importanti
• Tradurre i requisiti nelle specifiche del sistema
• Generare e valutare proposte alternative di implementazione del sistema al fine
di negoziare i requisiti e le priorità di implementazione
• Riesaminare la specifica dei requisiti per assicurarne una comprensione comune (a
gruppo di progetto e clienti / utenti) e per correggere ogni omissione, conflitto o
ambiguità prima dell'approvazione dei requisiti stessi.
Per il dettaglio comincia da "Scoprire i requisiti"
Gestire l’evoluzione dei requisiti (intro)
Prevede le seguenti attività:
• Definire una baseline dei requisiti
• Gestire la tracciabilità tra requisiti e prodotti dello sviluppo (documentazione e
componenti software)
• Esaminare le modifiche proposte e valutarne tutti gli impatti (a livello di altri
requisiti, della documentazione e dei componenti software; dei piani di lavoro,
ecc.) per deciderne l'approvazione
• Negoziare i nuovi impegni stimati in base all'impact analysis effettuata
• Mantenere i piani di progetto allineati ai requisiti
• Controllare lo stato del requisito e le attività di modifica durante l'intero ciclo di
vita del sistema.
Per il dettaglio vedi "Gestire l'evoluzione dei requisiti"
Scoprire i requisiti
Si tratta di indagare le necessità dei clienti / utenti e determinare i requisiti che
possono essere opportunamente implementati nel sistema per soddisfare tali necessità.
La tecnica principale per la scoperta dei requisiti consiste nell'identificazione dei casi
d'uso, ovvero delle modalità di utilizzo del sistema da parte dei suoi utilizzatori (attori)
per eseguire specifiche funzionalità del sistema stesso.
Ciò che viene richiesto dal committente e dagli altri interlocutori interessati, costituisce
il punto di partenza per l'individuazione dei casi d'uso.
Nello stesso tempo, i casi d'uso rappresentano uno strumento estremamente efficace ed
efficiente per determinare e analizzare i requisiti, portare alla luce nuovi requisiti non
ancora emersi, e per chiarire requisiti ambigui, generici o in conflitto tra loro.
L'efficacia dei casi d'uso per la scoperta dei requisiti è legata al fatto che, nel dialogo
tra progettisti e le altre funzioni interessate, vengono analizzati per ogni caso d'uso gli
scenari concreti di operatività degli utilizzatori nei confronti del sistema, le sequenze di
passi, le varianti e le eccezioni.
In questo modo il committente e le altre funzioni interessate possono esprimere

6. 6
feedback sugli scenari concreti ipotizzati dal progettista, contribuendo al chiarimento
dei requisiti esistenti o alla definizione di nuovi requisiti.
I casi d'uso servono quindi a chiarire che cosa dovrà fare il sistema e, una volta
concordati con il committente, costituiscono il punto di partenza per la progettazione
del sistema stesso e il riferimento principale per la definizione, progettazione ed
esecuzione dei test da effettuare per la verifica del sistema in sede di accettazione.
E' opportuno che l'identificazione dei casi d'uso parta da un'analisi dei processi di
business, per chiarire il contesto organizzativo in cui si andrà a collocare il sistema
software da realizzare.
In particolare, nel caso di rifacimento di un sistema esistente, non opportunamente
documentato o comunque poco conosciuto dai progettisti del nuovo sistema, può
risultare utile descrivere, in modo sommario, i casi d'uso relativi ai processi di business
del sistema attuale.
In tal modo sarà possibile far emergere tutte le criticità e le opportunità di
miglioramento, sia a livello organizzativo che a livello informatico, prima di procedere
alla definizione dei casi d'uso relativi alle funzionalità software del nuovo sistema da
realizzare.
Passi operativi principali
Descrivere gli obiettivi di business del progetto
Chiarire e descrivere le motivazioni di business (esigenze di
cambiamento funzionale e/o organizzativo e/o tecnologico; eventuali
problemi da risolvere) che hanno dato origine al progetto e i benefici
attesi. Descrivere in modo sintetico le feature richieste al prodotto e i
vincoli imposti (di business, tecnologici, ecc..). Definire i confini (scope)
del progetto.
Individuare interlocutori e fonti dei requisiti
Individuare gli stakeholder da coinvolgere nella raccolta dei requisiti.
Identificare almeno una persona per ogni classe di utenti, che ne possa
rappresentare in modo opportuno le necessità.
Identificare altre fonti per la scoperta dei requisiti (report, documenti,
manuali, procedure organizzative, documentazione del sistema
esistente, .).
Identificare i casi d'uso
Identificare con gli utenti le modalità di utilizzo del sistema necessarie

7. 7
per portare a termine i loro compiti (casi d'uso). Discutere i dialoghi e
le interazioni tra utenti e sistema necessari per completare ogni task.
"Osservare" gli utenti durante lo svolgimento delle loro attività;
documentare il workflow dei processi di business per facilitare
l'individuazione dei casi d'uso e dei requisiti funzionali che supportano
tali processi.
Documentare i casi d'uso con un template standard e derivare i requisiti
funzionali dai casi d'uso.
Scoprire i requisiti non funzionali
Individuare gli attributi di qualità del prodotto (efficienza, usabilità,
ecc.) e altri requisiti non funzionali che soddisfino le aspettative dei
clienti.
L'analisi dei problemi del sistema attuale e delle richieste di
manutenzione correttiva o perfettiva può essere determinante per
l'individuazione delle caratteristiche più appropriate da includere nel
nuovo prodotto.
Utilizzare tecniche diverse per la scoperta dei
requisiti
Oltre ai casi d'uso, l'individuazione dei requisiti può richiedere tecniche
diverse:
• Interviste
• Brainstorming
• JAD
• Prototipazione
• Analisi documentazione esistente (eventuale Reverse
Engineering)
Analizzare i requisiti
Si tratta di analizzare, raffinare e valutare i requisiti raccolti in modo da:
• assicurarsi che siano comprensibili per tutti gli stakeholder;
• individuare eventuali errori, omissioni o altre carenze.
L'obiettivo è quello di sviluppare i requisiti a livelli di qualità e di dettaglio sufficienti
per poter formulare una o più ipotesi di soluzione per il prodotto da realizzare,

8. 8
effettuare stime realistiche del progetto e procedere con la progettazione e la
realizzazione del prodotto stesso.
Passi operativi principali
Definire il diagramma di contesto del sistema
Disegnare il diagramma di contesto del sistema per individuarne i
confini e le interfacce con gli attori.
Costruire prototipi per chiarire i requisiti
Costruire prototipi delle interfacce utente per rendere maggiormente
tangibili i concetti e le possibilità di soluzione. (Soprattutto nel caso in
cui i requisiti non siano sufficientemente chiari)
Il prototipo delle interfacce utente aiuta a chiarire gli scenari di
interazione, espressi attraverso i casi d'uso, e i requisiti sottostanti.
Valutare la fattibilità dei requisiti
Valutare la possibilità di implementare i requisiti a costi accettabili e
con prestazioni adeguate nell'ambiente di implementazione previsto.
Vagliare i rischi associati alla realizzazione di ogni requisito.
Assegnare una priorità ai requisiti
Indurre gli utenti a classificare la priorità di implementazione dei
requisiti. Tale classificazione è un input fondamentale per determinare
i rilasci incrementali del prodotto.
Modellare i requisiti
Sviluppare i casi d'uso individuati, per definire ciò che il sistema deve
essere in grado di fornire ed analizzare ulteriormente i requisiti.
Iniziare a produrre i modelli di analisi a partire dai casi d'uso
(diagrammi delle classi o diagrammi E/R, diagrammi di attività,
diagrammi di stato, ecc.) per esplorare funzionalità e informazioni
richieste al sistema e individuare eventuali omissioni o incongruenze

9. 9
nei requisiti.
Creare un glossario
Creare un glossario dei termini di business del sistema per rendere
comune la terminologia al team di progetto e agli utenti.
Specificare i requisiti
I requisiti devono essere documentati ed espressi in modo coerente, non ambiguo e
verificabile.
La specifica dei requisiti deve essere chiara sia per gli utenti che per i progettisti. (Vedi
anche "Linee guida per scrivere i requisiti").
La documentazione deve essere facilmente accessibile per tutti gli attori coinvolti (team
di progetto, committenti, utenti).
Passi operativi principali
Adottare un template standard per documentare i
requisiti software
Fare riferimento al Software Requirement Specification template
secondo gli standard IEEE.
Documentare l'origine di ogni requisito
Documentare l' origine di ogni requisito: un caso d'uso o un altro input
del cliente (es: un documento di richiesta offerta), una regola di
business, uno standard aziendale, un vincolo legislativo o derivato da
un'altra fonte esterna all'azienda, ecc...
Assegnare un identificativo ad ogni requisito
Assegnare un identificativo univoco al singolo requisito per poterlo
referenziare e gestirne la tracciabilità lungo tutto il ciclo di vita del
prodotto.
Gestire la versione del requisito per poter tracciare tutte le modifiche
apportate al requisito.

10. 10
Definire gli altri attributi di ogni requisito
Oltre all'identificativo e alla descrizione, ogni requisito ha una serie di
attributi, che ne consentono una maggiore specificazione:
• Tipologia requisito
• Richiedente
• Data richiesta, data ultima modifica
• Versione (per tener traccia dell'evoluzione del singolo requisito)
• Importanza per il committente (es: essenziale, importante,
secondario)
• Priorità di rilascio (es: alta, media, bassa)
• Stato (es: proposto, approvato, implementato, verificato,
annullato)
• Criterio di validazione o accettazione
• Origine
• Stabilità (indica il grado di probabilità con cui il requisito
cambierà in futuro)
Creare una matrice di tracciabilità dei requisiti
La matrice serve a gestire la tracciabilità dei requisiti con altri requisiti
e con i casi d'uso, in prima battuta, e successivamente con i diversi
"artefatti" dello sviluppo (classi, ecc.) fino ai componenti fisici che li
implementano e con le specifiche dei test che li verificano.
Verificare i requisiti
Occorre effettuare con i clienti una revisione dei requisiti documentati, per esaminarne
l'accuratezza e la completezza, prima di procedere all'approvazione degli stessi.
(vedi "Le misure di qualità per valutare la specifica di un requisito software")
Passi operativi principali
Definire i criteri di accettazione dei requisiti
Stabilire per ogni requisito i criteri di accettazione che guideranno i
test di verifica della rispondenza del prodotto al requisito stesso.

11. 11
Scrivere i casi di test per i requisiti
Specificare i casi di test a fronte dei casi d'uso (correlati ai requisiti
funzionali) permette di scoprire ambiguità, imprecisioni e omissioni
nella documentazione dei requisiti.
Individuare eventuali conflitti o incongruenze tra i
requisiti
I conflitti tra i requisiti possono essere dovuti a
• incomprensioni, fraintendimenti, errori
• reali divergenze di opinioni ed intenzioni.
I conflitti del primo tipo sono, di norma, quelli più facilmente
risolvibili.
Per risolvere i conflitti del secondo tipo occorre utilizzare opportune
tecniche di negoziazione e mediazione.
Gestire l’evoluzione dei requisiti
Richiede attività quali:
• mantenere traccia e storia di ogni requisito e delle sue variazioni
• determinare quali dipendenze tra i requisiti sia utile tracciare
• stabilire relazioni di tracciabilità tra i requisiti e i casi d'uso, tra i casi d'uso e i
prodotti dello sviluppo
• gestire la versione dei requisiti.
E' opportuno definire un vero e proprio processo di controllo e approvazione delle
modifiche richieste.
Passi operativi principali
Definire un processo per controllare le modifiche
ai requisiti
Definire un processo per gestire le modifiche proposte ai requisiti
(nuovi requisiti o variazioni a requisiti esistenti), analizzarle,
approvarle e decidere come e quando attuarle.

12. 12
Definire un unico canale di controllo delle
modifiche
In progetti di dimensione considerevole è necessario definire un canale
ufficiale, il CCB (Change Control Board), che ha il compito di
determinare l'impatto della modifica sul sistema e decidere come e
quando effettuare la modifica stessa.
Stabilire una baseline dei requisiti
La baseline è una fotografia dei requisiti inclusi nell'accordo iniziale
con il cliente; tutte le modifiche richieste successivamente possono
essere effettuate solo tramite il processo di "controllo delle modifiche"
(change control) definito. Sottoporre il documento dei requisiti a
procedure di change management e version control.
Valutare le modifiche proposte ai requisiti
Analizzare le modifiche proposte per valutarne l'impatto su altri
requisiti o sui prodotti dello sviluppo (utilizzare a questo scopo le
matrici di tracciabilità) e determinare il carico di lavoro necessario.
Definire un piano per gestire le modifiche.
Utilizzare un sistema che tracci tutte le richieste di modifica (change
request) e le anomalie (defect), possibilmente in un repository
centrale.
Il sistema dovrebbe essere usato per catturare tutti gli input e
trasmetterli all'autorità del CCB per la loro risoluzione.
Per l'approvazione di una richiesta di modifica, il CCB deve considerare
una serie di fattori, tra cui:
• l'impatto della modifica sulle funzionalità del sistema, su tempi
e costi
• l'impatto su clienti e stakeholder esterni: altri progetti, fornitori
di componenti, ecc..
• il potenziale effetto di "destabilizzazione" del sistema in seguito
alla modifica.
Se le richieste di modifica hanno impatto sui tempi e i costi, è
necessario rinegoziare i termini dell'accordo con il cliente prima di
approvarle.

13. 13
Gestire le modifiche in modo "gerarchico"
Una modifica ad un requisito può avere impatto su un altro requisito,
un caso d'uso, sul disegno del sistema, su un componente fisico
realizzato, ma anche su costi e tempi pianificati, su un rischio
associato al progetto, ecc.
Le modifiche devono essere introdotte in modo top-down seguendo la
tracciabilità tra i requisiti e i prodotti dello sviluppo (non prima nel
codice e poi.).
Mantenere la storia di tutte le modifiche ai
requisiti
E' importante conoscere quando, come e perché un requisito è
cambiato.
Tracciare lo stato di ogni requisito
Per avere una visione chiara dello stato di avanzamento di ogni
requisito (proposto, approvato, implementato o verificato), in modo
da conoscere in ogni istante il numero dei requisiti in ognuna delle
diverse categorie di stato.
Misurare la stabilità dei requisiti
Un numero eccessivo di modifiche potrebbe essere sintomo di una
scarsa comprensione del problema o di una definizione inadeguata
degli obiettivi e dell'ambito del progetto oppure di frequenti
cambiamenti negli scenari di mercato o nelle strategie aziendali.
Monitorare la stabilità dei requisiti può consentire di evidenziare
tempestivamente i rischi correlati ed intraprendere le opportune
azioni correttive.
Linee guida per scrivere i requisiti
• Scrivere frasi e paragrafi brevi
• Utilizzare la forma attiva del verbo

14. 14
• Scrivere frasi complete dal punto di vista ortografico, grammaticale (soggetto,
verbo, completamento oggetto, ecc.) e della punteggiatura
• Utilizzare termini coerenti con quanto definito nel glossario (di progetto, di
sistema o aziendale)
• Assicurarsi che il significato dei termini utilizzati sia conosciuto, compreso dagli
stakeholder.
• Esprimere i requisiti nella forma "il sistema deve." , "l'utente deve.", con frasi in
cui compaia una verbo e un risultato osservabile. Ad esempio: " Il sistema deve
visualizzare l'elenco dei containers presenti in magazzino"
• Per ridurre l'ambiguità, evitare termini vaghi come user-friendly, facile, semplice,
rapido, efficiente, accettabile, robusto, ecc. Verificare che cosa significa
esattamente per il cliente un termine quale user-friendly o rapido, ecc.
• Evitare parole come: migliorare, massimizzare, minimizzare, ottimizzare, ecc..
Quantificare il grado di miglioramento necessario o indicare i valori massimo e
minimo accettabili per un dato parametro.
• Evitare paragrafi lunghi che contengono più requisiti
• Tipicamente i requisiti sono espressi in prima battuta in modo vago e astratto,
man mano che l'esplorazione del sistema va avanti, emergono requisiti più
specifici, più dettagliati e meno ambigui. Scomporre un requisito di alto livello che
risulti ambiguo, in più requisiti per chiarirne il significato ed eliminarne le
ambiguità
• Una linea guida per scrivere requisiti ad un opportuno livello di granularità
consiste nello specificare requisiti in modo che siano individualmente verificabili
(sottoponibili a test) .
Se è sufficiente un piccolo numero di casi di test per verificare che un requisito sia
correttamente implementato, probabilmente il requisito è scritto al giusto livello
di dettaglio.
Se i casi di test sono numerosi e diversificati, è opportuno suddividere il requisito
in più requisiti.
• Evitare di specificare dettagli di disegno
Le misure di qualità per valutare la specifica di un requisito software
Secondo gli standard IEEE 830 un requisito deve essere:
• corretto
deve descrivere che cosa vuole lo stakeholder
• non ambiguo
deve essere soggetto ad una sola possibile interpretazione
• completo (nell'insieme)
un insieme di requisiti è completo se e solo se descrive tutti i requisiti significativi
per l'utente, inclusi quelli che riguardano le funzionalità, le performance, i vincoli
di disegno, i dati o le interfacce esterne
• consistente
non deve essere in conflitto con altri requisiti
• classificato
deve riportare l'importanza per l'utente (grado di soddisfazione del cliente nel
caso in cui il requisito venga implementato con successo) e il grado di stabilità
(un indicatore della probabilità con cui il requisito cambierà in futuro)

15. 15
• verificabile
deve essere possibile verificare la rispondenza del prodotto al requisito
• modificabile
deve essere possibile effettuare modifiche al requisito in modo semplice,
completo e coerente
• tracciabile
deve essere chiara l'origine del requisito, deve essere inoltre possibile definire
una corrispondenza tra il requisito e altri requisiti e tra il requisito e i prodotti
dello sviluppo
Requisiti e Standard
CMM
Il Capability Maturity Model è un modello di riferimento per migliorare il processo di
lavoro delle organizzazioni di sviluppo software.
E' stato sviluppato dal Software Engineering Institute sotto l'egida del Dipartimento della
Difesa americano.
Il modello esprime l'organizzazione di riferimento dei processi di sviluppo e
manutenzione del software attraverso le "key process area", ovvero quell'insieme di
attività che influenzano maggiormente i vari aspetti della produzione e della qualità del
software.
Il modello definisce 5 livelli di maturità e descrive quali passi occorre intraprendere per
passare da un processo non definito e instabile ad un processo maturo e ottimizzato.
Livelli di maturità e key process area
Livello di maturità Key Process Area
1. Iniziale (initial)
Il processo non è ben
definito, segue strategie
occasionali e caotiche, il
suo successo dipende solo
dall'impegno degli individui.
2. Ripetibile (repeteable)
Sono eseguite le attività di
base per la gestione dei
progetti in modo da
controllare: le funzionalità,
i costi e la schedulazione.
Il processo è
sufficientemente
Requirements Management
Software Project Planning
Software Project Tracking and
Oversight
Software Subcontract Management
Software Quality Assurance
Software Configuration
Management

16. 16
disciplinato per essere
ripetuto.
3. Definito (defined)
Il processo è conforme agli
standard
dell'organizzazione.
Le attività di gestione e
progettazione sono
documentate e integrate.
Organization Process Focus
Organization Process Definition
Training Program
Integrated Software Management
Software Product Engineering
Intergroup Coordination
Peer Reviews
4. Gestito (managed)
Dettagliate misure del
processo e dei prodotti sono
rilevate e raccolte, in modo
da tener sotto controllo
entrambi.
Quantitative Process Management
Software Qualità Management
5. Ottimizzato (optimizing)
Il miglioramento continuo
del processo è perseguito
tramite l'applicazione
sistematica delle attività di
raccolta dei feedback di
processo, l'analisi dei difetti
e delle cause che li hanno
generati, l'introduzione di
tecnologie innovative.
Defect Prevention
Technology Change Management
Process Change Management
Il CMM riassume la key process area "Requirements Management" come segue:
"Scopo della Gestione dei Requisiti è quello di stabilire tra cliente e progettisti
software una comprensione comune dei requisiti del cliente che saranno affrontati nel
progetto software"
Obiettivi:
• I requisiti per lo sviluppo software sono posti sotto controllo in modo da costituire
la baseline ad uso dei progettisti software e del management
• I piani, i prodotti e le attività dello sviluppo software devono essere coerenti con i
requisiti del sistema
Le attività previste sono le seguenti:
1. il team di progetto rivede i requisiti prima che essi vengano incorporati nel
progetto

17. 17
2. il team di progetto utilizza i requisiti come base per la definizione dei piani, dei
prodotti e delle attività dello sviluppo
3. le modifiche ai requisiti vengono esaminate e riviste prima di essere incorporate
nel progetto.
ISO 9000
ISO 9000 è un insieme di standard per il controllo e la guida della qualità in tutti i settori
produttivi.
L'organizzazione che adotta ISO 9000 deve dotarsi di un Sistema Qualità che definisce le
modalità per valutare, controllare e guidare la qualità di tutti i processi aziendali.
I dettagli del sistema qualità sono contenuti in un Manuale della Qualità.
ISO 9001 rappresenta un modello per l'assicurazione della qualità nella progettazione,
sviluppo, produzione, installazione e assistenza.
Per quanto riguarda la gestione dei requisiti, la normativa ISO stabilisce che: "per
procedere allo sviluppo del software, il fornitore dovrebbe avere un insieme completo e
non ambiguo di requisiti funzionali".
Lo stesso documento dichiara che tali requisiti dovrebbero includere tutti gli aspetti che
determinano l'accettazione del sistema realizzato da parte del cliente, quali requisiti
relativi a prestazioni, sicurezza, affidabilità, riservatezza.
ISO 9000 enfatizza la necessità di un'effettiva collaborazione tra clienti e progettisti del
sistema software richiedendo:
• la responsabilità di entrambe le parti nella definizione dei requisiti
• la definizione di metodi e procedure per concordare e approvare le modifiche ai
requisiti
• l'impegno a prevenire fraintendimenti e incomprensioni nei requisiti
• la definizione di procedure per memorizzare e rivedere i risultati delle discussioni
sui requisiti.
ISO 9126 - La qualità del prodotto software
Le caratteristiche di qualità del prodotto software secondo la norma ISO/IEC 9126:
Caratteristica Sotto-caratteristica
FUNZIONALITA' (functionality) Adeguatezza
rispondenza del sistema rispetto
alle necessità informative
dell'utente
Accuratezza
livello di precisione dei risultati
Interoperabilità
capacità di interazione con altri
sistemi
Conformità
aderenza a standard,

18. 18
regolamentazioni legislative e
normative specifiche
Sicurezza
capacità di proteggere il sistema
da accessi non autorizzati
AFFIDABILITA' (reliability) Maturità
mancanza di interruzioni per
malfunzionamenti
Tolleranza ai difetti
livello di operatività garantito dal
sistema in caso di
malfunzionamenti
Ricoverabilità
capacità di ripristino delle
normali condizioni d'uso dopo
interruzioni
USABILITA' (usabilità) Comprensibilità
facilità di comprensione della
logica funzionale e operativa del
sistema
Apprendibilità
facilità di apprendimento dell'uso
del sistema
Operabilità
facilità di utilizzo del sistema
EFFICIENZA (efficiency) Prestazioni di tempo
capacità di minimizzare i tempi di
risposta e massimizzare il carico
elaborativo del sistema
Utilizzo risorse
capacità di ottimizzare l'utilizzo
delle risorse del sistema
MANUTENIBILITA'
(maintainability)
Analizzabilità
facilità di diagnosi dei problemi e
di individuazione dei punti di
intervento
Modificabilità
facilità di modifica
Collaudabilità
facilità di testare le modifiche
apportate
Stabilità
capacità di sopportare più
modifiche senza produrre "effetti
collaterali" indesiderati
PORTABILITA' (portability) Adattabilità

19. 19
predisposizione del sistema
all'installazione in ambienti
hw/sw differenti
Aderenza
conformità con gli standard in
vigore negli ambienti target
Installabilità
facilità di installazione
Sostituibilità
capacità di rimpiazzare un'altra
applicazione con simili
funzionalità
Corrispondenza tra caratteristiche di qualità secondo ISO e tipologia di
requisiti
I requisiti funzionali e alcuni dei requisiti non funzionali relativi al prodotto software
possono configurarsi come qualità attese nel prodotto e trovano quindi corrispondenza
con le "caratteristiche di qualità del software" ISO. La tabella sottostante illustra la
corrispondenza tra le tipologie di requisito, così come sono state indicate nel presente
documento (vedi glossario), e le caratteristiche di qualità ISO.
Tipologie di requisiti
Caratteristiche
di qualità
del software Funzionale di
Utilizzo Organiz
zativo di
Progettazione di
Sicurezza Tecnologico Normativo,
Legale
Fiscale
F
U
N
Z
I
O
N
A
L
I
T
A'
Adeguatezza X X
Accuratezza X
Interoperabilità X X
Conformità X
Sicurezza X X X
A
F
F
I
D
A
B
I
L
I
T
A'
Maturità X
Tolleranza ai
difetti X
Ricoverabilità X
U Comprensibilità X

20. 20
S
A
B
I
L
I
T
A'
Apprendibilità X
Operabilità X
E
F
F
I
C
I
E
N
Z
A
Prestazioni di
tempo X
Utilizzo Risorse X
M
A
N
U
T
E
N
I
B
I
L
I
T
A'
Analizzabilità X
Modificabiità X
Collaudabilità X
Stabilità X
P
O
R
T
A
B
I
L
I
T
A'
Adattabilità X
Aderenza X
Installabilità X
Sostituibilità X

21. 21
Glossario
Brainstorming
E' una tecnica utilizzata nelle riunioni di gruppo per generare idee su un determinato
argomento.
Ad ogni persona del gruppo è richiesto di suggerire più idee possibili. Nessuna idea è
respinta durante la sessione di "storming", solo alla fine le idee vengono discusse dal
gruppo, valutate e selezionate.
Change Control Board
Consiglio (comitato guida) per il controllo delle modifiche. Può essere costituito da una
varietà di stakeholder, che insieme hanno l'autorità di valutare le modifiche richieste ai
requisiti e la competenza tecnica per decidere quali richieste di modifica debbano
essere ufficialmente approvate.
Criterio di accettazione
Il criterio di accettazione o di validazione indica il criterio sulla base del quale il
committente verificherà la conformità del prodotto al requisito in fase di accettazione.
Per i requisiti funzionali, i criteri di validazione saranno espressi in termini di casi di
prova a fronte dei casi d'uso corrispondenti.
Per i requisiti non funzionali, è necessario che il criterio di validazione sia non ambiguo
e verificabile senza lasciare troppi margini all'interpretazione soggettiva
IEEE
Institute of Electrical and Electronics Engineers. E' un organismo mondiale nato nel 1963;
è diventato un punto di riferimento per tutto ciò che riguarda l'innovazione tecnologica
nell'ambito dell'elettronica, dell'informatica, ecc.
ISO
International Organization for Standardization
È un'associazione mondiale di organismi nazionali di normazione.
L'ISO collabora strettamente con l'IEC (International Electrotechnical Commission) in
tutti i campi di normazione del settore elettrotecnico.
Joint Application Design (JAD)
Tecnica sviluppata dall'IBM negli anni '70. Si basa su riunioni intensive (senza telefono e
con partecipazione full-time) di committenti, utenti e progettisti. Le riunioni sono
guidate da un "conduttore" possibilmente esterno al gruppo di progetto.
Il conduttore intervista anticipatamente il manager e gli utenti per definire l'ambito e gli
obiettivi della riunione e determinare i partecipanti alla sessione JAD.
L'efficacia dell'approccio sta nell'integrazione di tecniche legate al comportamento e
alle dinamiche di gruppo con aspetti metodologici.
Feature
Caratteristica funzionale del sistema; espressione, ad alto livello di astrazione, del
comportamento del sistema.
Un servizio fornito dal sistema per soddisfare una o più necessità dell'utente.

22. 22
Prototipazione
Realizzazioni parziali di un prodotto software.
La prototipazione è utilizzata principalmente per risolvere anticipatamente incertezze
del ciclo di sviluppo: un prototipo rappresenta un modo eccellente per evidenziare e
risolvere ambiguità e incompletezze dei requisiti.
Un prototipo può servire a:
• chiarire e completare i requisiti
• esplorare alternative di disegno (ad esempio per valutare le scelte architetturali)
• fornire un nucleo iniziale del prodotto che evolverà nel prodotto finale (in questo
caso attenzione all'approccio "quick & dirty", non far evolvere il prototipo in un
prodotto senza un'analisi solida!).
In particolare, il prototipo delle interfacce utente è essenziale per chiarire gli scenari di
interazione dei casi d'uso e i requisiti ad essi correlati.
Requisito
E' una caratteristica del sistema, richiesta al gruppo di progetto dal committente (o da
un altro interlocutore interessato), perché ritenuta necessaria per risolvere determinati
problemi o raggiungere i propri obiettivi.
Requisito funzionale
Funzionalità attesa dal prodotto per soddisfare determinati obiettivi.
Esempi: "il sistema deve permettere di aprire un conto corrente" , "il sistema deve
consentire di effettuare prelievi dal conto corrente".
Requisito non funzionale
Una qualità richiesta al prodotto relativamente a usabilità, performance, sicurezza, ecc.
oppure l'espressione di un vincolo inerente i tempi e le modalità di rilascio del prodotto,
il budget previsto per la sua realizzazione, ecc.
Reverse Engineering
Il Reverse Engineering è un insieme di tecniche e di strumenti che consentono di :
• analizzare il software esistente
• derivarne in automatico la documentazione
• modificarne l'impostazione
• rigenerare il codice (Forward Engineering).
In particolare, a riguardo della componente dati di un sistema, è possibile, tramite il
reverse engineering, derivare le strutture concettuali dei dati a partire da DDL o copy di
tracciati record di archivi esistenti.
Stakeholder
Letteralmente: chi tiene le puntate in una scommessa.
Gli stakeholder di un progetto sono tutti coloro che sono coinvolti nella definizione dei
requisiti e che sono in qualche modo interessati all'esito del progetto:
• committenti (clienti)

23. 23
• sponsor
• utilizzatori del sistema
• funzioni aziendali quali Marketing, Esercizio dei Sistemi
• partecipanti allo sviluppo
• esperti del dominio del problema
• esperti di particolari tecnologie
• esperti legali
• rappresentanti di aziende, associazioni o enti esterni all'azienda con cui il sistema
deve interagire (es: banche o enti nazionali) o autorità interessate al rispetto di
vincoli esterni predeterminati.
Tipologia requisito
Classificazione del requisito.
E' possibile una prima distinzione tra requisiti funzionali e non funzionali
E' opportuno classificare ulteriormente i requisiti non funzionali, ad esempio:
• di utilizzo
• di sicurezza
• temporale
• economico
• organizzativo
• di progettazione
• tecnologico
• normativo, legale, fiscale.
La suddivisione in tipologie dei requisiti funge da template per la raccolta e la
qualificazione dei requisiti, serve essenzialmente a verificare se i requisiti stessi sono
stati sufficientemente compresi da poter essere opportunamente classificati.
Seguono alcuni esempi per ogni tipologia di requisito non funzionale
Classificazione requisiti non funzionali
Utilizzo Requisito relativo alle modalità di
utilizzo del sistema da parte degli
utenti.
Rientrano in questa categoria i
requisiti di:
• Disponibilità: specifica quando
il sistema deve essere
utilizzabile.
Es.: "il sistema deve essere
attivo 24 ore su 24"
• Documentazione: completezza,
chiarezza, facilità di
consultazione, facilità di

24. 24
aggiornamento.
Es.: "il sistema deve prevedere
un help a livello di singolo
campo"
• Efficienza: efficienza di
memoria, efficienza di
esecuzione
Es.: "il sistema deve consentire
di far lavorare simultaneamente
300 utenti nell'orario dalle 9
alle11, 150 utenti negli altri
orari"
• Supporto: installazione,
assistenza, help desk
Es.: "deve essere disponibile un
numero verde per l'assistenza
alla clientela"
• Training
Es.: "gli utilizzatori dovranno
partecipare ad una settimana di
corso"
• Usabilità: utilizzo operativo del
sistema da parte dell'utente
(consistenza, univocità di
comportamento, semplicità,
chiarezza )
Es.: "il sistema deve poter
essere utilizzato da bambini di
10 anni"
di Sicurezza Requisito che specifica chi è
autorizzato ad accedere al sistema e
in quali circostanze tale accesso è
garantito
Es.:
"il prelievo al bancomat è autorizzato
solo a chi è in possesso della carta
bancomat ..."

25. 25
Temporale Requisito che esprime un vincolo sulle
date di rilascio del sistema o sulle
date di completamento di specifiche
attività di progettazione
Esempi:
"il sistema deve essere rilasciato in
produzione entro la fine del 2003"
"le specifiche di analisi devono essere
completate entro la data ..."
Economico Requisito che esprime un vincolo sui
costi di progettazione del sistema o sui
costi gestionali (risorse umane,
energia, ...) del sistema in
produzione.
Esempi:
"il costo globale per la progettazione
del sistema non può superare l'importo
di ..."
"il numero delle risorse impegnate in
attività gestionali continuative non
può essere superiore a ..."
Organizzativo Requisito che specifica un'attribuzione
di responsabilità organizzativa.
Esempi:
"gli ordini di importo superiore al
massimale previsto per il reparto
devono essere autorizzati dal direttore
di stabilimento"
"la selezione dei servizi previsti per le
polizze deve essere effettuata dal
marketing"

26. 26
di Progettazione Requisito relativo all'architettura
logica o ad altre caratteristiche
"tecniche" del software che il sistema
dovrà possedere.
Rientrano in questa categoria i
requisiti di:
• Interoperabilità: capacità di
interagire con sistemi,
piattaforme, protocolli
eterogenei
Es.: "deve essere possibile
accedere a DBMS eterogenei"
• Manutenibilità: tracciabilità,
modularità, ...
Es.: "deve essere possibile
modificare gli algoritmi per il
calcolo delle tasse ogni anno,
sulla base dell'evoluzione delle
norme legislative"
• Portabilità: specificano altre
piattaforme o ambienti su cui i
sistema deve essere "portato" in
futuro
Esempi:
"il prodotto deve funzionare con
Window 98 e UNIX"
"il sistema deve funzionare
anche sul mercato giapponese"
• Riusabilità: capacità di
incorporare componenti
predefinite
Es.: "devono essere utilizzate le
routine standard di calcolo del
rateo"
Tecnologico Requisito relativo a specifiche
tecnologie (prodotti o tipologie di
prodotti) HW e SW che il sistema dovrà
utilizzare.
Esempi:

27. 27
"il sistema deve utilizzare il DBMS
Oracle"
"il sistema deve essere in grado di
interfacciarsi con qualsiasi tipo di
browser HTML"
Normativo, legale, fiscale Requisito relativo a leggi o standard a
cui il sistema deve essere conforme.
Esempi:
"il sistema deve essere conforme alla
legge sulla privacy"
"la definizione del nuovo
prodotto/servizio deve essere
coerente con la normativa prevista a
livello aziendale"
Tracciabilità
Gestione delle corrispondenze tra elementi diversi, appartenenti a livelli di astrazione
diversa, ad es. tra un livello logico e un livello fisico, tra una classe di oggetti e una
tabella Oracle.
La tracciabilità tra requisiti e prodotti dello sviluppo è essenziale, perché:
• fornisce una visione chiara dello stato di avanzamento di ogni requisito
• quando il requisito è soggetto a revisione, è possibile verificare l'impatto della
modifica sul sistema.
Tale tracciabilità è gestita innanzitutto attraverso la correlazione tra requisiti e casi
d'uso.

28. 28
Bibliografia e testi consigliati
SOMMERVILLE, Ian, SAWYER, Pete "Requirements Engineering: A Good Practice Guide"-
Wiley and Sons 1997
SOMMERVILLE, Ian, KOTONYA, Gerald "Requirements Engineering: Processes and
Techniques"- Wiley and Sons 1998
ROBERTSON Suzanne, ROBERTSON James "Mastering the Requirements Process"-
Addison Wesley 1999
LEFFINGWELL D., WIDRIG D. "Managing Software Requirement: A Unified Approach"-
Addison Wesley 2000
WIEGERS, Karl E. "Software requirements" - Microsoft Press 1999
Per un maggiore dettaglio sui casi d'uso si rimanda al tutorial "Introduzione ai Casi
d'Uso" disponibile sul sito di Tecnet Dati
Ogni key process area identifica un insieme di attività che, se applicate collettivamente,
permettono di innalzare il livello di maturità dell'organizzazione

29. Tecnet Dati s.r.l.
C.so Svizzera 185 –
10149 - Torino (TO), Italia
Tel.: +39 011 7718090 Fax.: +39 011 7718092
P.I. 05793500017 C.F. 09205650154
www.tecnetdati.com