Best practice per la progettazione dei requisitiLuglio 2015

di Kevin Parker, Vicepresidente di marketing mondiale, Serena Software (ora parte di Micro Focus®)

White paper

Sommario pagina

I requisiti sono ancora un fattore importante? . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

I requisiti sono un processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Best practice per la gestione dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Attributi critici di una soluzione di gestione dei requisiti . . . . . . . . . . . . . . . . . . 6

Riepilogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1www.microfocus.com

I requisiti sono ancora un fattore importante?

Un requisito definisce un unico comportamento di base, necessario o voluto dall’azienda

al fine di raggiungere i propri obiettivi. Il requisito deve essere verificabile in modi

misurabili e completo, ossia contenere tutte le informazioni necessarie. Non deve essere

in contraddizione con nessun altro requisito e deve essere coerente con gli standard legali.

Deve avere almeno uno stakeholder e uno sponsor e deve essere vantaggioso per almeno un

utente .

Un requisito definisce una proprietà che è essenziale per l’azienda La definizione è semplice. La gamma delle metodologie adottate per la raccolta e la

gestione dei requisiti varia più di ogni altra disciplina di gestione del ciclo di vita delle

applicazioni (ALM, Application Lifecycle Management). Alcune differenze dipendono dal

livello di specificità necessaria per un dato progetto a causa dell’ambito del prodotto, della

complessità delle applicazioni o delle dimensioni del team e della distribuzione. All’interno

di una singola organizzazione, un team può richiedere la perfezione dei requisiti con una

verifica dettagliata da parte degli stakeholder, mentre un altro team può iniziare con una

semplice idea e reiterarla, quindi utilizzare prototipi fino ad ottenere la comprensione

necessaria per creare la soluzione .

L’IEEE definisce i requisiti come “… le condizioni o le funzionalità che un sistema (o un

componente di sistema) deve soddisfare per essere conforme a un contratto, uno standard,

una specifica o altri vincoli formalmente imposti…”.

Karl Wiegers1, l’autorità principale sulla progettazione dei requisiti, semplifica la

definizione riunendo le proprietà che un prodotto deve avere per poter fornire valore ad

uno stakeholder. Tutto il lavoro nel ciclo di vita dello sviluppo software (SDLC)2 inizia

con un’idea. Tale idea potrebbe essere un nuovo sistema da sviluppare, una richiesta di

miglioramento di un sistema esistente oppure la necessità di correggere qualcosa che non si

comporta come dovrebbe.

Questi nuovi sistemi vengono denominati miglioramenti e correzioni. Tali sistemi vengono

classificati, prioritizzati e organizzati in release, versioni e patch.

Novità: nuovi sistemi o nuove funzionalità di un sistema esistente, questi sono in genere i progetti di maggiori dimensioni in un’organizzazione e quindi i più costosi. Il finanziamento di questi progetti è, di conseguenza, più difficile da ottenere. La stima, la pianificazione e l’esecuzione sono più difficili perché abbiamo a che fare con molte incognite.

Esempio: aggiungere la funzionalità per mostrare il catalogo prodotti su un dispositivo mobile.

All’interno di una singola organizzazione, un team può richiedere la perfezione dei requisiti con una verifica dettagliata da parte degli stakeholder, mentre un altro team può iniziare con una semplice idea e reiterarla, quindi utilizzare prototipi fino ad ottenere la comprensione necessaria per creare la soluzione. __________

1 www.karlwiegers.com e http://en.wikipedia.org/wiki/Karl_Wiegers

2 Ciclo di vita di sviluppo del software, vedere: http://en.wikipedia.org/wiki/Software_development_process

2

White paperBest practice per la progettazione dei requisiti

Miglioramenti: miglioramenti al codice esistente, questo è un lavoro incrementale il lavoro e i costi sono inferiori, il rischio è minore e il finanziamento è in genere più facile da ottenere. Questi progetti possono essere brevi o lunghi. Sono più facili da stimare e hanno costi ridotti perché costituiscono un problema noto e un gruppo di soluzioni noto.

Esempio: visualizzare i prezzi sul catalogo dei prodotti in euro e sterline e yen, oltre che in dollari USA.

Correzioni: spesso piccole modifiche al codice esistente che non aggiungono nuove funzionalità, le correzioni modificano il comportamento delle funzionalità correnti per soddisfare le aspettative dell’azienda. La maggior parte delle correzioni riguarda i comportamenti errati e dannosi per l’azienda, ma a volte modificano il comportamento solo in modo che funzioni meglio o più velocemente.

Esempio: alla cassa, la tassa viene aggiunta solo sulle vendite del mercato interno e non su tutte le vendite mondiali.

Acquisire l’idea e trasformarla in una soluzione è ciò in cui consiste ALM. Realizzare questo

obiettivo è un percorso. In effetti, anche solo acquisire inizialmente l’idea, non è un compito

facile .

I requisiti sono un processo

La definizione del problema può richiedere minuti o mesi e dipende da molti fattori. Di

seguito, sono riportati solo alcuni dei fattori che l’organizzazione prende in considerazione

per la definizione di un problema:

Controlli normativi e di conformità

Sicurezza e integrità dei dati

Accessi e autenticazione

Tempi di introduzione sul mercato

Disponibilità di soluzioni commerciali

Complessità tecnica

Ritorno sull’investimento

Interruzioni dei piani del progetto

Disponibilità delle risorse

Finanziamenti

Esigenze di prestazioni

Esigenze di internazionalizzazione

Tutto questo prima di porre la domanda: “Cosa si desidera esattamente far fare a questa

tecnologia?”.

Dieci best practice per definire requisiti eccellenti:

1. Utilizzare prototipi e simulazione invece di definizioni scritte.

2. Condividere le idee con più stakeholder possibili e raccogliere il feedback.

3. Utilizzare tecniche di “ludicizzazione” per ottenere un feedback equilibrato.

4. Ogni requisito dovrebbe essere verificabile.

5. Ogni requisito dovrebbe essere relativo a un unico fattore.

6. Mantenere la tracciabilità dalla richiesta al requisito per l’implementazione.

7. Utilizzare storyboard, casi di utilizzo, pseudo-codici o qualunque altra cosa che esprima un significato chiaro.

8. Collaudare tutti i requisiti riguardo al loro impatto sulle funzioni attuali e future.

9. Continuare ad assegnare nuove priorità in base alle priorità aziendali.

10. Requisiti di versione e modifiche al documento.

3www.microfocus.com

Fase 1 - Ideazione e acquisizione della domanda: è comune che diversi sistemi per

la richiesta di assistenza vengano utilizzati contemporaneamente per diversi tipi di richieste

e per diversi sistemi. Alcuni sistemi sono di autosupporto e altri richiedono un’e-mail o

una telefonata. Troppo spesso, viene utilizzato Microsoft Excel come archivio per queste

richieste. La maggior parte delle organizzazioni ha un metodo di raccolta delle idee aziendali,

in genere tramite un tipo di sistema per la richiesta di assistenza, spesso denominato sistema

di richieste di modifica (o sistema CR). Tali sistemi vengono solitamente ospitati e gestiti

dall’help desk (denominato anche service desk).

Un elemento essenziale di questo processo è la raccolta di idee in modo coerente

e tracciabile. L’ideazione è un concetto più moderno e non formalizzato in molte

organizzazioni. In alcune aziende, si tratta del comitato di revisione per il controllo delle

modifiche (CCRB, Change Control Review Board) o del comitato consultivo delle modifiche

(CAB, Change Advisory Board) e di molti altri titoli analoghi. Troppo spesso, come sistema

di record viene utilizzato MS Excel, il che rende la collaborazione e la visibilità molto difficili.

Fase 2 - Gestione delle modifiche: questo è il punto in cui avviene la valutazione delle

idee per assegnare la priorità a quelle più importanti, quelle critiche in termini di tempo e

in termini di governance. Le idee vengono sottoposte a un processo di ricerca di fattibilità,

finanziamenti, risorse e pianificazione prima dell’approvazione per lo sviluppo. Alcune

richieste urgenti e di emergenza ricevono immediatamente l’approvazione quando l’impatto

aziendale è grave.

A volte denominato gestione della domanda, questo è un fenomeno più recente guidato

dall’IT, più affidabile in relazione alle spese. Lo scopo della gestione della domanda è quello

di garantire che i progetti sui quali lavora il reparto IT siano quelli che corrispondono alle

priorità aziendali. Frequentemente, i CIO parleranno di “allineamento” o “allineamento

dell’IT all’azienda”: in tali casi, stanno descrivendo la necessità di garantire che i progetti

mission-critical essenziali per la conformità siano quelli implementati prima e più

velocemente. Il comitato di revisione può sorvegliare questo processo e definire una serie

di priorità, obiettivi e anche budget.

Fase 3 - Raccolta dei requisiti: questo processo implica la raccolta e la registrazione dei

requisiti da parte degli stakeholder e di altre fonti. È possibile utilizzare diverse tecniche, tra

cui interviste, analisi dei documenti, gruppi di discussione, workshop e, più recentemente,

prototipazione, simulazione e “ludicizzazione”. La prototipazione iterativa definisce i

requisiti in un intervallo di tempo minore rispetto a quello richiesto per intervistare e

reintervistare l’utente aziendale.

L’ideazione è un concetto più moderno e non formalizzato in molte organizzazioni.

4

White paperBest practice per la progettazione dei requisiti

In un’organizzazione Agile, il procedimento seguito è pressoché lo stesso, tranne per la presenza di molte più iterazioni nel tempo rispetto a quelle richieste da un’attività di pianificazione dei requisiti tradizionale.

La persona chiave in un team Agile è il proprietario del prodotto, il cui compito è quello di fungere da collegamento tra l’azienda e il team di sviluppo.

Il proprietario del prodotto raccoglie i requisiti, li ordina e assegna le relative priorità per il team di sviluppo. Il proprietario del prodotto esegue la valutazione con l’azienda, aiutandola a restare focalizzata su ciò che è più importante.

I team Agile non utilizzano prototipi, ma realizzano un codice di lavoro il più velocemente possibile.

__________

3 http://en.wikipedia.org/wiki/Use_case

4 http://en.wikipedia.org/wiki/Unified_Modeling_Language

Fase 4 - Convalida dei requisiti: conferma che il gruppo di requisiti soddisfa le esigenze

e gli obiettivi aziendali. Questa fase consente di garantire che le informazioni raccolte siano

sufficienti per creare la soluzione desiderata e che le informazioni siano conformi ai vincoli

organizzativi, quali standard di conformità e governance.

Frequentemente, la definizione dei requisiti non riesce perché la lingua inglese è troppo

imprecisa per riflettere i dettagli delle sfumature delle esigenze aziendali. Lo sviluppo dei

casi di utilizzo3 e l’uso di metodi formalizzati come la guida al linguaggio di modellazione

unificato (UML, Unified Modeling Language)4 consentono di definire con precisione il

comportamento previsto per la soluzione. Questi strumenti assistono nello sviluppo di casi

di test che costituiranno la base della convalida dell’implementazione rispetto al requisito in

una fase successiva del ciclo di vita dello sviluppo.

Fase 5 - Gestione dei requisiti: spesso, questa attività segue procedure molto formali

ed è il processo in cui i requisiti vengono migliorati, versionati, monitorati, controllati,

prioritizzati, assegnati e, in breve, gestiti. Queste attività includono:

Il perfezionamento continuo dei requisiti man mano che vengono raccolti più dati, input e idee

L’ordinazione e l’assegnazione di priorità ai requisiti a seconda dell’input aziendale

La delimitazione degli sforzi richiesti per i singoli requisiti

L’organizzazione dei requisiti in gruppi che consentano ai team di sviluppo di svolgere parti ragionevoli di lavoro e completare le release

Il monitoraggio dei cambiamenti, degli aggiornamenti e delle modifiche dei requisiti con il perfezionamento delle esigenze aziendali

Il mantenimento della tracciabilità per assicurare un audit trail dalla richiesta all’implementazione

Il monitoraggio delle approvazioni per l’implementazione dei requisiti per il finanziamento dei progetti

Il mantenimento delle relazioni e delle dipendenze tra i requisiti

Il processo di gestione dei requisiti è essenziale per le best practice di sviluppo delle

applicazioni. Senza chiari obiettivi di sviluppo, la probabilità di una corrispondenza con

i requisiti aziendali è quasi pari a zero. Non importa come viene definito il termine o il

punto in cui si trova l’organizzazione nello spettro metodologico, è necessario comprendere

le aspettative del cliente (o del potenziale cliente) prima che inizi la costruzione. Il

“come” può essere elaborato in fase di sviluppo, ma il “cosa” deve essere compreso prima

dell’approvazione del finanziamento.

5www.microfocus.com

Best practice per la gestione dei requisiti

Aspettarsi un tasso di abbandono dei requisiti mensile tra l’1% e il 5%. (fonte

Gartner)

“La migliore gestione dei requisiti consiste nell’applicare le best practice definite per la

gestione della configurazione alla gestione dei requisiti” - Kay Fuhrmann, Product Manager,

Serena Software (ora parte di Micro Focus)

1. Convenzioni di denominazione. Definizione e mantenimento di convenzioni per l’identificazione delle release: dal requisito approvato definito alla release della linea di base fino alla correzione di emergenza o patch.

2. Requisiti di base. Ai requisiti, come le release software, devono essere assegnate linee di base direttamente associate alle release che producono.

3. Processo di controllo delle modifiche ben definito e compreso. Una volta creata una linea di base, le modifiche devono essere controllate, monitorate, tracciate, approvate e riviste.

4. Revisione dei requisiti. Deve essere presente e applicato un processo di revisione dei requisiti.

5. Aspettativa di modifiche. Assicurarsi che le modifiche possano essere effettuate facilmente, ma in base a regole di controllo degli accessi rigide con piena tracciabilità.

6. Gestione delle versioni. La cronologia dei requisiti deve essere mantenuta usando metodi che facilitano agli analisti la ricerca retrospettiva.

7. Tracciabilità dei requisiti. Senza la possibilità di monitorare un requisito, dall’idea fino all’implementazione definita, non è possibile comprendere l’impatto di una modifica proposta.

8. Manutenzione delle informazioni. Mantenere gli attributi per le dipendenze, le relazioni, i proprietari, gli stakeholder, gli utenti, il finanziatore, le date, i costi, i modelli, i prototipi, i diagrammi, la governance, ecc. riguardo al requisito.

9. Collaborazione. Fornire un facile accesso alle informazioni sui requisiti e inviare automaticamente notifiche agli stakeholder di qualsiasi modifica dello stato o del requisito per promuovere la collaborazione.

10. Requisiti in un’unica posizione. Mantenere i requisiti in un’unica posizione, preferibilmente in un database progettato per la loro gestione.

I progetti vengono gestiti tramite informazioni dettagliate (una raccolta di requisiti) e storie (un requisito) che costituiscono fasi arretrate (requisiti assegnati allo sviluppo ma non ancora completati) del lavoro da eseguire.

Il progresso viene monitorato tramite grafici burn-down (requisiti completati) che mostrano i progressi verso la fine della fase corrente. Un principio chiave di Agile è quello di avere un’organizzazione automatica e la riunione di informazioni quotidiane mantiene tutti sincronizzati all’interno del progetto.

Agli arretrati del progetto vengono costantemente assegnate nuove priorità per soddisfare le esigenze aziendali in continua evoluzione.

6

White paperBest practice per la progettazione dei requisiti

Attributi critici di una soluzione di gestione dei requisiti

Facilità di utilizzo

Implementazione

L’implementazione della soluzione deve essere facilmente configurata per adottare il

linguaggio utilizzato all’interno dell’organizzazione. La modifica del lessico per l’adattamento

alla soluzione non deve essere un requisito. Formazione, implementazione ragionevole e

localizzazione devono essere completate in un periodo da due a quattro settimane.

La soluzione deve essere facile da apprendere

I nuovi utenti, indipendentemente dal proprio ruolo, possono apprendere velocemente

ad accedere alla soluzione e a navigare nell’interfaccia del client. In questo contesto, i

revisori di requisiti non tecnici, con una comprensione dei requisiti aziendali, possono

iniziare a lavorare con la panoramica di una pagina. Tutti gli altri utenti della soluzione,

ad eccezione degli amministratori o dei responsabili di progetto addestrati al supporto

dell’implementazione, devono essere in grado di utilizzare il prodotto dopo una formazione

della durata da due a quattro ore .

La soluzione deve essere facile da usare

La soluzione scelta per la gestione e la generazione di rapporti dei requisiti deve facilitare

i processi di tutte le persone coinvolte migliorandone l’accesso alle informazioni. L’utente

generale deve impiegare non più di un’ora a comprendere come eseguire funzioni specifiche

utilizzando la soluzione .

Le proprietà e la visualizzazione devono essere configurabili

Gli utenti o gli amministratori devono essere in grado di modificare la quantità di

informazioni visualizzate.

Tutti gli stakeholder devono avere accesso ai documenti

Deve essere possibile pubblicare documenti in formato aziendale per la revisione e

l’approvazione. Non dovrebbe essere necessario che gli utenti utilizzino lo strumento per

visualizzare le informazioni contenute all’interno.

La filosofia e la tecnologia dello strumento devono essere trasparenti

Gli utenti non dovrebbero aver bisogno di alcuna competenza architetturale, amministrativa

o tecnica per utilizzare lo strumento al fine di aggiungere, modificare, rivedere o approvare i

requisiti e le relative proprietà.

Le 10 funzionalità più richieste di una soluzione di gestione dei requisiti - Fonte Forrester

Requisiti di base per monitorare la deviazione dall’ambito

Requisiti di modellazione e simulazione

Strumenti visivi che consentono di gestire i requisiti in release, funzioni e patch

Supporto decisionale per assegnare la priorità alla selezione dei requisiti

Collegamento e tracciabilità tra requisiti e richieste

Acquisizione di requisiti incentrati sull’utente

Riutilizzo di requisiti comuni e condivisi

Flusso di lavoro dei requisiti parallelo ad altri flussi di lavoro SDLC

Integrazione basata sulla tracciabilità con altri strumenti del ciclo di vita ALM

Requisiti out-of-the-box per esigenze di conformità comuni, quali ITAR

7www.microfocus.com

I requisiti utente (talvolta denominati requisiti aziendali) identificano le funzionalità che desidera o di cui necessita lo stakeholder, mentre i requisiti funzionali specificano cosa deve fare il sistema al fine di fornire la funzionalità definita.

Devono essere presenti metodi per organizzare i requisiti

Deve essere possibile creare contenitori (cartelle) come mezzo per organizzare i requisiti

a seconda del componente o del sottotipo oppure per creare elenchi per gruppi o utenti

specifici.

I ruoli utente devono essere supportati

Deve essere possibile definire ruoli organizzativi o progettuali e associare gli utenti a tali

ruoli .

Il sistema deve essere flessibile I requisiti vengono distinti in base al tipo o alla classificazione. I tipi di requisiti comuni

includono i requisiti utente e funzionali. I requisiti utente (talvolta denominati requisiti

aziendali) identificano le funzionalità che desidera o di cui necessita lo stakeholder, mentre

i requisiti funzionali specificano cosa deve fare il sistema al fine di fornire la funzionalità

definita. Altri tipi di requisiti comuni includono test non funzionali, di sistema, tecnici e casi

di test. Al di là di questi tipi di base, le classificazioni utilizzate per i requisiti sono svariate,

come il software da sviluppare o i procedimenti impiegati dall’organizzazione per effettuare

questa operazione. Una buona soluzione di gestione dei requisiti deve essere in grado di

fornire un mezzo per la classificazione di tutti i requisiti che l’organizzazione desidera

definire e anche le relative proprietà (metadati) devono essere completamente configurabili.

I requisiti devono essere memorizzati come singoli oggetti

I requisiti di tutti i tipi devono essere memorizzati come singoli oggetti e possono essere

collegati ad altri oggetti, ma non posseduti da essi. Qualsiasi combinazione di questi oggetti

può essere raccolta per la visualizzazione o la pubblicazione.

Deve essere possibile organizzare i requisiti in gerarchie e scomporli al livello

di base

Deve essere possibile dividere i requisiti di tutti i tipi in requisiti sempre più piccoli fino

a raggiungere una dimensione di base che rappresenti un unico requisito specifico. Deve

essere possibile utilizzare singolarmente le gerarchie di requisiti scomposti, al livello di base

e al livello di gerarchia, anche intermedia, con azioni a cascata verso i requisiti scomposti.

I tipi di requisiti devono riflettere gli standard aziendali

I tipi di requisiti devono essere denominati e descritti a seconda delle esigenze e dei processi

organizzativi, piuttosto che quelli del provider dello strumento. La soluzione non deve

contenere alcun requisito di tipo out-of-the-box.

8

White paperBest practice per la progettazione dei requisiti

Le proprietà devono essere configurabili

Deve essere possibile definire e assegnare le proprietà ai tipi di requisiti, oltre a quelli

standard predefiniti dal prodotto. Anche i tipi di dati utilizzati nella definizione di queste

proprietà devono essere flessibili. Ad esempio, devono includere campi di testo (brevi e

lunghi), elenchi a discesa, campi numerici e campi relativi alla data. Deve essere possibile

associare grafici o allegati ai tipi di dati.

Le proprietà devono utilizzare termini familiari

La lingua utilizzata per definire i requisiti e le relative proprietà devono riflettere il lessico

dell’organizzazione e devono essere utilizzati come riferimenti in tutta la soluzione. Più team

di progetto all’interno della stessa organizzazione devono essere in grado di definire i tipi

di requisiti e di utilizzare termini che soddisfano le esigenze di ciascuno di essi. A nessun

gruppo deve essere richiesto di portare il carico di altri.

Deve essere presente un certo livello di tracciabilità

Deve essere possibile creare una vista di tracciabilità, con meccanismi tali da selezionare

i tipi di requisiti da tracciare. Le informazioni raccolte devono essere visualizzate in un

formato facile da leggere e da analizzare .

Importazione dei requisiti La maggior parte dei team di progetto, prima di adottare una soluzione di gestione dei

requisiti, mantiene i requisiti nei documenti MS Excel o MS Word. È fondamentale che

la soluzione importi i dati esistenti e deve essere in grado di continuare a importare gli

aggiornamenti dei requisiti .

Importazione dei dati dai file MS Word

La soluzione deve fornire funzionalità per facilitare l’importazione dei dati dai file MS Word.

Deve essere possibile, ad esempio, importare i requisiti in questo documento.

Importazione dei dati dai file MS Excel

Deve essere possibile importare i dati selezionati dai file MS Excel al fine di creare nuovi

requisiti, con semplici meccanismi per la mappatura di colonne alle proprietà.

Esportazione nei file MS Excel

Deve essere possibile esportare i dati dei requisiti selezionati in file MS Excel, con semplici

meccanismi per associare le proprietà alle colonne.

La lingua utilizzata per definire i requisiti e le relative proprietà devono riflettere il lessico dell’organizzazione e devono essere utilizzati come riferimenti in tutta la soluzione.

9www.microfocus.com

Aggiornamento degli oggetti esistenti da MS Excel

La soluzione deve supportare la funzionalità di aggiornamento dei requisiti esistenti con

i dati provenienti dai fogli di lavoro di MS Excel. La mappatura degli identificatori del

requisito o dei nomi dal foglio MS Excel al requisito corrente e la successiva aggiunta

di nuove proprietà o l’aggiornamento delle proprietà esistenti consentiranno a tutti gli

stakeholder, anche a quelli che non dispongono dell’accesso alla soluzione, di assumere

un ruolo attivo nel processo di revisione. Gli aggiornamenti dai fogli di lavoro di MS Excel

garantiranno anche le funzionalità batch.

Creazione o aggiornamento di collegamenti tramite i fogli di lavoro

È possibile creare collegamenti tra i requisiti tramite i fogli di lavoro di MS Excel.

Importazione dei dati dalle soluzioni ALM associate

I file MS Excel o CSV generati da qualsiasi soluzione nello spettro ALM possono essere

importati per collegare, modificare, aggiungere o eliminare i requisiti o le relative proprietà.

Meccanismi per il filtraggio e l’ordinamento dei requisiti

Filtri controllati dall’utente

I requisiti vengono gestiti, visualizzati e rivisti in diversi momenti durante il ciclo di

sviluppo e da diverse persone con esigenze molto diverse. Raramente, è necessario che tutti

visualizzino tutto.

Elenchi e rapporti filtrati in base alla proprietà del requisito

Deve essere possibile applicare un filtro a qualsiasi proprietà non binaria definita all’interno

del requisito .

Creazione e aggiornamento di gruppi di requisiti

Deve essere possibile creare gruppi di requisiti di qualsiasi tipo e stabilire le linee di base per

tali gruppi .

Domande a supporto della selezione dei requisiti

Lo strumento deve supportare l’uso di domande semplici o complesse per raccogliere i

requisiti in base al tipo, alla proprietà, all’assenza o alla presenza in un elenco, alla relazione

(collegamento) o a una combinazione di questi, ad esempio, tutti i requisiti utente ad

alta priorità collegati ad almeno un caso di test di cui la proprietà del risultato del test è

impostata su “non riuscito”.

I requisiti vengono gestiti, visualizzati e rivisti in diversi momenti durante il ciclo di sviluppo e da diverse persone con esigenze molto diverse. Raramente, è necessario che tutti visualizzino tutto.

10

White paperBest practice per la progettazione dei requisiti

Creazione semplice di documenti, elenchi o file CSV

Deve essere possibile salvare, stampare o creare file MS Excel o CSV da qualsiasi finestra di

dialogo nell’interfaccia utente.

La soluzione deve gestire la cronologia dei requisiti La soluzione deve essere in grado di fornire un meccanismo per la creazione, l’eliminazione

e la modifica di un requisito, nonché di tutti i metadati memorizzati con il requisito. Deve

anche offrire la possibilità di mantenere un record di tutte le transazioni di questo tipo.

La cronologia dei requisiti deve essere mantenuta

La soluzione deve essere in grado di mantenere la cronologia delle modifiche per tutti i

requisiti e le proprietà dei requisiti.

I requisiti possono essere rinviati o abbandonati

La soluzione deve fornire la funzionalità che consente di abbandonare o rinviare i requisiti.

Deve essere possibile filtrare facilmente questi requisiti dagli elenchi generali mantenendo

l’accessibilità per la revisione o la riadozione.

I requisiti possono essere eliminati

La soluzione deve consentire l’eliminazione definitiva di un requisito dal progetto.

Le linee di base possono essere create e aggiornate con agilità

Devono essere presenti funzioni per la creazione di linee di base di rilascio che possono

essere versionate e monitorate per le modifiche. Deve essere possibile confrontare le linee di

base e creare un elenco semplice di requisiti modificati, nonché un rapporto dettagliato delle

differenze tra le linee di base .

Collegamento e tracciabilità dei requisiti Un buon sistema di requisiti deve essere in grado di fornire non solo un mezzo di

classificazione di qualsiasi tipo di requisito, ma deve anche essere in grado di collegare

requisiti di vario tipo. Il collegamento dei requisiti fornisce i meccanismi per i rapporti di

tracciabilità.

Un buon sistema di requisiti deve essere in grado di fornire non solo un mezzo di classificazione di qualsiasi tipo di requisito, ma deve anche essere in grado di collegare requisiti di vario tipo.

11www.microfocus.com

Collegamento dei requisiti

Devono essere presenti funzionalità che consentono di creare relazioni tra i tipi di requisiti.

I collegamenti che esprimono tali relazioni devono essere del tipo da uno a molti, da molti a

uno o da molti a molti. Ad esempio, vi possono essere più casi di test per un singolo requisito

funzionale, ma un caso di test potrebbe essere applicabile a più di un requisito funzionale.

Collegamenti manuali

La soluzione deve garantire la possibilità di stabilire collegamenti manualmente o tramite

una forma di importazione in batch.

Collegamenti eliminati

Deve essere presente la funzionalità che consente di eliminare i collegamenti.

Gli oggetti collegati segnalano l’impatto della modifica

Gli oggetti collegati devono mostrare l’impatto dei cambiamenti a monte. Ad esempio, dato

un caso di test collegato a un requisito funzionale che è collegato a un requisito utente,

la modifica a un requisito utente presupporrà un possibile impatto e quindi forzerà una

revisione del requisito funzionale e del caso di test. Una modifica del requisito funzionale

forzerà una revisione del caso di test, ma non del requisito utente.

Matrice di tracciabilità

Una matrice di tracciabilità completa tramite qualsiasi tipo di requisito definito deve

essere disponibile e facile da usare. La tracciabilità visualizza i collegamenti tra i requisiti,

consentendo agli stakeholder di vedere che i requisiti dell’utente siano stati dettagliati

tramite i requisiti funzionali associati e che siano stati definiti casi di test per ciascun

requisito funzionale. La matrice di tracciabilità deve segnalare l’adempimento e, per tutta la

durata dell’applicazione, deve segnalare l’impatto della modifica.

Deve essere presente un’eccellente funzionalità di generazione di rapporti La soluzione deve facilitare la generazione di rapporti e deve essere possibile generare

documenti usando un formato familiare a tutti gli stakeholder. Mantenere rapporti

aggiornati è fondamentale per il processo di gestione dei requisiti e la creazione di

tali rapporti deve essere una semplice estensione del filtraggio e dell’ordinamento

dall’interfaccia del client.

Mantenere rapporti aggiornati è fondamentale per il processo di gestione dei requisiti e la creazione di tali rapporti deve essere una semplice estensione del filtraggio e dell’ordinamento dall’interfaccia del client.

12

White paperBest practice per la progettazione dei requisiti

Supporto di documenti flessibili

Deve essere possibile selezionare elenchi di requisiti utilizzando script o query e utilizzare

facilmente tali elenchi per creare o aggiornare un documento.

Documenti di controllo della versione

Deve essere possibile bloccare i contenuti di un documento e assegnare un nome al

documento o alla versione bloccata. Deve anche essere possibile eliminare liberamente tali

documenti .

Requisiti pubblicabili in forma di documento

Deve essere possibile esportare (pubblicare) i documenti utilizzando un formato (modello)

che sia familiare e che possa essere condiviso tra i progetti.

Funzione di confronto dei documenti

La soluzione deve fornire la possibilità di confrontare i documenti versionati.

Generazione di rapporti grafici

Deve essere possibile creare rapporti in forma grafica o raccogliere ed esportare i dati

necessari per creare rapporti correnti sugli strumenti esistenti. I rapporti dovrebbero anche

includere grafici a barre che mostrano i requisiti pianificati per tipo, numero pianificato per

release denominata e numero ancora da implementare .

I rapporti dovrebbero anche includere grafici a barre che mostrano i requisiti pianificati per tipo, numero pianificato per release denominata e numero ancora da implementare.

13www.microfocus.com

Riepilogo

La disciplina di gestione dei requisiti è difficile da comprendere per alcune organizzazioni e,

di conseguenza, i gruppi spesso sovraccaricano il processo a scapito del progetto. I team di

progetto spesso dedicano più tempo a discutere dell’appropriata struttura del caso di utilizzo

o della differenza tra un requisito utente e aziendale piuttosto che del contenuto di entrambi.

Poiché tali discussioni non fanno progredire il progetto, i membri del team procederanno

supponendo che le domande aperte verranno affrontate durante lo sviluppo.

Il processo di gestione dei requisiti è essenziale per le best practice di sviluppo delle

applicazioni. Senza chiari obiettivi di sviluppo, la probabilità di una corrispondenza con i

requisiti aziendali è quasi pari a zero. La gestione dei requisiti può iniziare con un elenco

in cui vengono definite le aspettative del progetto. L’elenco può essere visualizzato come

una lavagna aperta, che raccoglie e ordina note e modifiche. È anche possibile espanderla

per controllare i dettagli tecnici e per collegare i dettagli ai casi di test, abilitando in ultima

analisi complete funzionalità di generazione di rapporti sui requisiti.

Le migliori soluzioni di gestione dei requisiti sono facili da apprendere, facili da utilizzare,

accessibili e trasparenti. Dispongono inoltre di eccellenti funzionalità di tracciabilità,

controllo delle versioni e generazioni di rapporti. Queste funzioni interagiscono per fornire il

fondamento di una soluzione di livello mondiale e l’inizio di un processo di best practice per

i requisiti .

Le migliori soluzioni di gestione dei requisiti sono facili da apprendere, facili da utilizzare, accessibili e trasparenti.

162-IT0100-001 | S | 05/17 | © 2017 Micro Focus. Tutti i diritti riservati. Micro Focus e il logo Micro Focus, tra gli altri, sono marchi di fabbrica o marchi registrati di Micro Focus o delle sue controllate o consociate nel Regno Unito, negli Stati Uniti e in altri Paesi. Tutti gli altri marchi appartengono ai rispettivi proprietari.

www.microfocus.com

Micro FocusItalia+39 02 366 349 00

Micro FocusSede centraleRegno Unito+44 (0) 1635 565200

www.microfocus.com