Gestione dei requisiti

Linee guida per la Gestione dei Requisiti

Iolanda Salinari

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

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

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

• 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

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

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

effettuare stime realistiche del progetto e procedere con la progettazione e la realizzazione del prodotto stesso.


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

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).


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

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")


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

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.


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

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

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

• 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

• 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

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

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

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

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

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

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

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

• 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

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

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

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

"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

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

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

Gestione dei requisiti

Software

Transcript of Gestione dei requisiti